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
Top 20
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.
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.