Principal Director at LTI - Larsen & Toubro Infotech
Real User
Top 20
2025-07-24T03:04:34Z
Jul 24, 2025
They are dependent on Salesforce for agent orchestration and AI-related activities. For any agent creation, they must rely on Salesforce agent force, which creates a lock-in with Salesforce. They should develop their own agent studio within MuleSoft Anypoint Platform to ensure independent usage. Having completed Salesforce agent force integration, I noticed that Salesforce has different nomenclature. When implementing AI in MuleSoft Anypoint Platform, users must use Einstein AI and depend on agent force. This creates additional lock-in with Salesforce agent force. Developing a MuleSoft-specific agent studio would help implement AI-specific use cases. This would reduce the dependency on Salesforce agent force.
Solutions Architect at a manufacturing company with 10,001+ employees
Real User
Top 20
2025-04-03T14:10:00Z
Apr 3, 2025
An improvement could be the usage of OpenAPI specifications. Currently, it uses other standards, but adopting OpenAPI, the standard in the market, would be beneficial.
From a monitoring point of view, MuleSoft Anypoint Platform can improve on tracking transactions. When dealing with multiple transactions or trading, the system can lose control, and tracking becomes hectic. Enhanced monitoring can make transaction tracking easier.
Integration Lead at a retailer with 10,001+ employees
Real User
Top 20
2024-11-07T16:16:17Z
Nov 7, 2024
One area for improvement is the Community Hub or developer portal, which should be part of the base offering. Additionally, MuleSoft is considered expensive, so pricing is a major concern.
With GenAI coming into the picture, it can be used to focus on specific setups and use cases. If you want to have an end-to-end solution, more AI infusion into the product will be beneficial. For example, when it comes to an industry-based solution, and someone approaches our company and states that they want to focus on healthcare or some financial services, we have some specific end-to-end solutions where Anypoint can be used as a backbone. If you are able to enable some AI on top of the functionalities provided by the product, it would be beneficial for users. The inclusion of GenAI in the tool can be good since it is an area that is currently unavailable in the solution. Mule Anypoint Platform can serve as a backbone when trying to build up an end-to-end solution using AI.
When it comes to external systems, we need to use APIs. So, it needs some extra effort. When we are integrating with other applications, readily available connectors make it easy. However, when it comes to external applications, connectivity isn't as straightforward. We need to use RESTful APIs to get and push messages. While it's doable, it's not as simple as using the pre-built connectors. In future releases, Anypoint MQ can increase the message size limit a little bit. We faced issues while working with SAP integrations. SAP can have very large files, and we couldn't handle those within the Anypoint MQ limit.
The product does not provide a priority level for the message. It also does not have Topic. It has an exchange instead of Topic. The users request for the Topic functionality. Such functionalities are available in ActiveMQ. There is a limitation of 10 MB for messages. It's something we must take into consideration when we have a large payload. The storage must be expandable. We shouldn’t have to do additional setups for correlation.
Director and Solution Architect at a tech services company with 11-50 employees
Real User
2023-08-31T03:03:35Z
Aug 31, 2023
The solution is very costly. The solution should provide a package with fewer capabilities at a lower price for specific companies that don’t have a big IT budget. Not every customer requires all the capabilities of the software. It will be a good fit in the market, and they will easily sell it more.
MDG SAP Global Data Architect at a manufacturing company with 10,001+ employees
Real User
2022-04-05T17:23:50Z
Apr 5, 2022
It's extremely expensive to change things in Anypoint MQ, e.g. we have to go through either Accenture or IBM. IBM will do the changes, but the actual change we ask for costs huge amounts of money. I'm not sure why that is, or whether that's just a contract, but they always complain about multiple changes, regression testing, etc. It sounds like it's a very long winded task just to make a simple change. This is an area for improvement for Anypoint MQ. Another problem we have with Anypoint MQ is that some of our end systems cannot cope with the throughput. If we put too many messages down to it, then there's a delay to send those messages onto the system that can't take them in as fast, and this means that the queue blows. We have either a 40 gigabyte or 40 megabyte queue space, but if we send 7,000 messages which need to be combined and sent out, the queue blows, because it just can't manage that throughput because the output is so slow. With the memory, we don't have a big enough queue to cope, so there's that problem. If there was a way around that problem, we could send it. What we need to do is to be able to send 50,000 messages an hour or more, which we can do SAP to SAP, but we haven't found a solution on how to cope with sending it to Anypoint MQ because it blows up, so that's the big problem we have. What we'd like to see in the next release of Anypoint MQ is for the issue of slow output of messages to be solved. Even if we wrote into disc, e.g. the disc space is cheap, so if you could write the messages to disc and then just feed them out and when the queue is caught up with itself, that would solve our problems. It means we could send MuleSoft all the messages in one go, and then it could drip feed them out. The additional feature we'd like to see in Anypoint MQ is to be able to write the message queue to disc, to allow for ample queueing of messages, because currently, the output to a particular system is slow.
Anypoint MQ's capabilities are mainly used for messaging purposes, but it doesn't have typical use cases that extend as far as other Message Queue software. For one, it would be helpful, from an additional features perspective, to see that it can handle large files of any type, whether image files, video files, etc. And if they would include an SFTP solution such as is available in AWS or Azure, this would be an added advantage for our clients.
Senior Integration Consultant at a tech services company with 1-10 employees
Consultant
2021-12-08T00:12:00Z
Dec 8, 2021
Anypoint MQ is not a pure messaging product. There are so many solutions like this, but this is not as mature as those products. The other MQ products have the capability of reprocessing and maintaining the persistence of the data. They can handle large volumes and large messages, but Anypoint MQ doesn't have those capabilities. It can only handle a maximum size of 10 megabytes. The other MQ products have a larger capacity. IBM MQ can handle 100 megabytes of data or even solid gigabytes. This doesn't have that capability. This solution has a lot of gaps. It's not a pure MQ product. We have sort of exposed this product with different protocols like TCP. Also, it has to evaluate these capabilities compared to the other market products.
MuleSoft Anypoint Platform provides API management and integration capabilities with scalability, ensuring seamless connectivity across systems.MuleSoft Anypoint Platform offers API management and integration capabilities within a user-friendly interface. With a range of connectors and the ability to handle integration patterns, it enables data integration across environments with support for API-led connectivity. High scalability, observability, batch processing, and tooling are key...
They are dependent on Salesforce for agent orchestration and AI-related activities. For any agent creation, they must rely on Salesforce agent force, which creates a lock-in with Salesforce. They should develop their own agent studio within MuleSoft Anypoint Platform to ensure independent usage. Having completed Salesforce agent force integration, I noticed that Salesforce has different nomenclature. When implementing AI in MuleSoft Anypoint Platform, users must use Einstein AI and depend on agent force. This creates additional lock-in with Salesforce agent force. Developing a MuleSoft-specific agent studio would help implement AI-specific use cases. This would reduce the dependency on Salesforce agent force.
An improvement could be the usage of OpenAPI specifications. Currently, it uses other standards, but adopting OpenAPI, the standard in the market, would be beneficial.
From a monitoring point of view, MuleSoft Anypoint Platform can improve on tracking transactions. When dealing with multiple transactions or trading, the system can lose control, and tracking becomes hectic. Enhanced monitoring can make transaction tracking easier.
One area for improvement is the Community Hub or developer portal, which should be part of the base offering. Additionally, MuleSoft is considered expensive, so pricing is a major concern.
The product is expensive.
The tool requires programming language.
With GenAI coming into the picture, it can be used to focus on specific setups and use cases. If you want to have an end-to-end solution, more AI infusion into the product will be beneficial. For example, when it comes to an industry-based solution, and someone approaches our company and states that they want to focus on healthcare or some financial services, we have some specific end-to-end solutions where Anypoint can be used as a backbone. If you are able to enable some AI on top of the functionalities provided by the product, it would be beneficial for users. The inclusion of GenAI in the tool can be good since it is an area that is currently unavailable in the solution. Mule Anypoint Platform can serve as a backbone when trying to build up an end-to-end solution using AI.
When it comes to external systems, we need to use APIs. So, it needs some extra effort. When we are integrating with other applications, readily available connectors make it easy. However, when it comes to external applications, connectivity isn't as straightforward. We need to use RESTful APIs to get and push messages. While it's doable, it's not as simple as using the pre-built connectors. In future releases, Anypoint MQ can increase the message size limit a little bit. We faced issues while working with SAP integrations. SAP can have very large files, and we couldn't handle those within the Anypoint MQ limit.
The product does not provide a priority level for the message. It also does not have Topic. It has an exchange instead of Topic. The users request for the Topic functionality. Such functionalities are available in ActiveMQ. There is a limitation of 10 MB for messages. It's something we must take into consideration when we have a large payload. The storage must be expandable. We shouldn’t have to do additional setups for correlation.
The solution's licensing model is expensive and could be improved.
There are issues with dead-letter queues.
The solution is very costly. The solution should provide a package with fewer capabilities at a lower price for specific companies that don’t have a big IT budget. Not every customer requires all the capabilities of the software. It will be a good fit in the market, and they will easily sell it more.
Anypoint MQ could improve the user interface.
It's extremely expensive to change things in Anypoint MQ, e.g. we have to go through either Accenture or IBM. IBM will do the changes, but the actual change we ask for costs huge amounts of money. I'm not sure why that is, or whether that's just a contract, but they always complain about multiple changes, regression testing, etc. It sounds like it's a very long winded task just to make a simple change. This is an area for improvement for Anypoint MQ. Another problem we have with Anypoint MQ is that some of our end systems cannot cope with the throughput. If we put too many messages down to it, then there's a delay to send those messages onto the system that can't take them in as fast, and this means that the queue blows. We have either a 40 gigabyte or 40 megabyte queue space, but if we send 7,000 messages which need to be combined and sent out, the queue blows, because it just can't manage that throughput because the output is so slow. With the memory, we don't have a big enough queue to cope, so there's that problem. If there was a way around that problem, we could send it. What we need to do is to be able to send 50,000 messages an hour or more, which we can do SAP to SAP, but we haven't found a solution on how to cope with sending it to Anypoint MQ because it blows up, so that's the big problem we have. What we'd like to see in the next release of Anypoint MQ is for the issue of slow output of messages to be solved. Even if we wrote into disc, e.g. the disc space is cheap, so if you could write the messages to disc and then just feed them out and when the queue is caught up with itself, that would solve our problems. It means we could send MuleSoft all the messages in one go, and then it could drip feed them out. The additional feature we'd like to see in Anypoint MQ is to be able to write the message queue to disc, to allow for ample queueing of messages, because currently, the output to a particular system is slow.
Anypoint MQ's capabilities are mainly used for messaging purposes, but it doesn't have typical use cases that extend as far as other Message Queue software. For one, it would be helpful, from an additional features perspective, to see that it can handle large files of any type, whether image files, video files, etc. And if they would include an SFTP solution such as is available in AWS or Azure, this would be an added advantage for our clients.
Anypoint MQ is not a pure messaging product. There are so many solutions like this, but this is not as mature as those products. The other MQ products have the capability of reprocessing and maintaining the persistence of the data. They can handle large volumes and large messages, but Anypoint MQ doesn't have those capabilities. It can only handle a maximum size of 10 megabytes. The other MQ products have a larger capacity. IBM MQ can handle 100 megabytes of data or even solid gigabytes. This doesn't have that capability. This solution has a lot of gaps. It's not a pure MQ product. We have sort of exposed this product with different protocols like TCP. Also, it has to evaluate these capabilities compared to the other market products.
The product could be improved by having available more information on what's happening with the monitoring, as well as simplifying the login process.