There's room for improvement in multi-file transfer functionality. It's not convenient when using MuleSoft, and it should have better capability for handling large amounts of data. For example, applications like GoAnywhere can handle huge chunks of data, so the tool should also have something to facilitate that aspect of integration.
CTO and Head of Strategy, Technology & Innovation at Cashapona
Real User
Top 5
2024-04-29T07:56:00Z
Apr 29, 2024
One notable drawback is the user experience aspect, particularly in terms of self-service functionality within Mule ESB. It would be beneficial if users could navigate the UI easily without extensive training or learning curves.
One area that could be improved is the way that policies are propagated when APIs are moved from one environment to another. It's an issue, but when you develop and test the rest APIs in a lower environment and need to move them, there's a propagation process. This process moves certain aspects of the APIs, like the basic features. But when we move them, the policies don't always move with them. The policies should be able to move so we don't have to redo them manually. There are some APIs we use, but it's a bit tedious. One thing that would be helpful is a built-in reconnection strategy for connections to third-party systems. For example, when you have your request connecting to any third-party system, each connection needs a reconnection strategy. This means if a connection fails while an application is running in production and the backend system is down, we usually try to reconnect several times. But in the ESB world, the out-of-the-box component for connection requests, which has the reconnection strategy configuration, only retries during deployment. If there's a failure post-deployment, it doesn't retry. You have to add extra logic for that. If that reconnection capability can be embedded within that configuration, it would avoid the need for external logic. It would reduce extra steps and make the process smoother.
MuleSoft isn't as mature as some other integration technologies out there like IBM WebSphere. There's room for growth, and MuleSoft is working toward that. They're already implementing a graph system, which should help organize the APIs in a branched way. It looks more like a relational database now. They're also working on MuleSoft Composer. These are the features that they're working on.
There are some features on the commercial version of the solution that would be great if they were on the community version. Additionally, if they added more authorization features it would be helpful.
Mule ESB could be more user-friendly. I think users must learn about the architecture before they start coding. The price could be better. In the next release, I would like to see an EDIFACT integration.
We would like the ability to use our own code. This would allow us to develop customizations with ease. Additionally, it would be nice to have more analytics or insights on the exchanged information between databases.
Senior Software Engineer at a tech services company with 10,001+ employees
Real User
2021-07-12T18:55:00Z
Jul 12, 2021
In respect of the UI or the interface, a concept such as that offered by Microgateway would be preferable. We basically use ESB for the gateways. Yet, sometimes when we make use of on-premises standard applications, we require a Microgateway or sidecar proxy products or sidecar proxy-type gateways. This should be addressed. A Microgateway type of application should be available for lending support to MuleSoft. When it comes to standalone applications, it would be better if a sidecar proxy were available, rather than the security models being implemented inside the application. The sidecar proxies make things very simple in respect of microservices. It would be great to see implementing security modules as a feature.
In an upcoming release, I would like to see more additional concept for exception handling, batch processing, and increased integration with other application.
Senior Consultant at a tech services company with 1-10 employees
Consultant
2020-10-19T09:33:00Z
Oct 19, 2020
As for what can be improved, in my experience the SMPT connectors need some improvement. It definitely takes some amount of integration knowledge but it is still pretty easy to learn. But I would request that the documentation be more informative. That would help the development community to understand the solution better, to deal with whatever challenges they face and ensure they'll be able to solve them on their own. The integrations are complicated so maybe that aspect of the solution should also be made simpler to use so that it wouldn't require such experienced resources to build a more complex integration. Additionally, there are limitations with the subscription model that comes with the product. If you subscribe to the platinum subscription, you get more benefits. Now there are limitations in keeping the logs and the ability to handle the max of 30 days. They could improve that. Lastly, they could provide us a bit more coding features.
Consultant, Architecture and Standards at a tech services company with 51-200 employees
Consultant
2020-08-30T08:33:32Z
Aug 30, 2020
There are several areas that need improvement. It's not easy to troubleshoot and we still can't make it work. It starts then stops. We are still trying to make it work using other tools that we have in-house, such as Kubernetes. So far, we have not found the proper way to connect them. Stability is an issue as well as scalability. Both of these need improvement. Pricing is always an area that can be improved. It's everyone's wish.
Software Engineer at a tech services company with 51-200 employees
Real User
2020-08-19T07:57:39Z
Aug 19, 2020
I think there are some connectors that are not available that should be included. Supports like Salesforce Connector that are available in APN could be included. It's possible that this requires more configuration in our system. I've also found that running Mule Anypoint Studio ESB can slow things down. They have good documentation but it's better to have a video explanation for some of the demos, something basic that runs for 10 minutes or so. If you have that and combine it with the documentation, it would simplify the learning process.
I'm not sure of any areas Mule ESB needs to improve. The price of the solution is a little bit high. It would be helpful if different sized businesses had access to different plans. The solution isn't as stable as we'd like it to be. There are some ongoing issues and therefore Mule has to provide frequent patches. Mule's core IP should be more stable overall.
IT Consultant at a financial services firm with 5,001-10,000 employees
Real User
2019-06-19T05:02:00Z
Jun 19, 2019
Technically, there are mainly two API standards. One we call SOAP and the other one is the REST API. SOAP is nothing but fully external. It's very old, but huge complex enterprise companies are still using SOAP-based web services. In the mobile smartphone era, most of the hand-held devices are using REST APIs. Mule ESB is more into the latest REST APIs, not much into the SOAP web services. Developing is all about web services and not easy with Mule. That is one of the disadvantages of Mule. In next-gen products, Mule is in a good position. Normally, if you're declaring a parameter or a variable, you can have visibility until it's not operating the variable. As an architect, programmer, or developer, you know when it's available. Graphically, that's not been available until this tool appeared. It is this kind of enhancement that I'm looking for from MuleSoft. Two weeks ago or a month back, they had a big release. With this package, they are saying that APIs are your products. You can sell your API to different organizations and the developers can register on their portal. It's available this fall. These are the best features I am looking for now. My product is an API. I need to market it through the internet. I can have my portal with all of the tools built-in. This kind of feature I didn't see with the competitors currently in the market.
Developer at a tech services company with 1,001-5,000 employees
Real User
2019-05-30T08:12:00Z
May 30, 2019
This solution could be improved by making it more flexible, and more user-friendly. I would like to see support for BPM in the next release of this solution.
We would like to have a built-in logging framework in which we can do auditing. In our case, we are working on-premise. We are not using the cloud solution, so we have MMC, which is not enough in a high transaction environment.
Developer JAVA/JEE, Mule ESB at a computer software company with 11-50 employees
Real User
2019-05-28T07:45:00Z
May 28, 2019
I would like to see the transformation component improved such that they can support the integration of more datatypes. For example, in version 3.7 they do not support the Excel format, and some companies using that version cannot do transformation with Excel input. As a workaround, they have to manually write Java code to do it. The Anypoint platform consumes a lot of memory, and it would be great for developers if it were more lightweight. It would be great if they extended the free trial of the API designer to two months.
For companies looking to modernize and unlock the value of existing on-premises systems and applications, an enterprise service bus (ESB) architecture serves as a critical foundation layer for SOA. When deployed as an ESB, the Mule runtime engine of Anypoint Platform combines the power of data and application integration across legacy systems and SaaS applications, with a seamless path to the other capabilities of Anypoint Platform and the full power of API-led connectivity.
There's room for improvement in multi-file transfer functionality. It's not convenient when using MuleSoft, and it should have better capability for handling large amounts of data. For example, applications like GoAnywhere can handle huge chunks of data, so the tool should also have something to facilitate that aspect of integration.
One notable drawback is the user experience aspect, particularly in terms of self-service functionality within Mule ESB. It would be beneficial if users could navigate the UI easily without extensive training or learning curves.
It would be much more beneficial if the solution included AI and business process management.
From an improvement perspective, there should be fewer coding challenges for users in Mule ESB.
One area that could be improved is the way that policies are propagated when APIs are moved from one environment to another. It's an issue, but when you develop and test the rest APIs in a lower environment and need to move them, there's a propagation process. This process moves certain aspects of the APIs, like the basic features. But when we move them, the policies don't always move with them. The policies should be able to move so we don't have to redo them manually. There are some APIs we use, but it's a bit tedious. One thing that would be helpful is a built-in reconnection strategy for connections to third-party systems. For example, when you have your request connecting to any third-party system, each connection needs a reconnection strategy. This means if a connection fails while an application is running in production and the backend system is down, we usually try to reconnect several times. But in the ESB world, the out-of-the-box component for connection requests, which has the reconnection strategy configuration, only retries during deployment. If there's a failure post-deployment, it doesn't retry. You have to add extra logic for that. If that reconnection capability can be embedded within that configuration, it would avoid the need for external logic. It would reduce extra steps and make the process smoother.
The solution's setup needs to be a bit more straightforward and its support needs to respond faster.
The initial setup could be more straightforward.
The stability could be improved.
MuleSoft isn't as mature as some other integration technologies out there like IBM WebSphere. There's room for growth, and MuleSoft is working toward that. They're already implementing a graph system, which should help organize the APIs in a branched way. It looks more like a relational database now. They're also working on MuleSoft Composer. These are the features that they're working on.
The price of Mule ESB could improve.
There are some features on the commercial version of the solution that would be great if they were on the community version. Additionally, if they added more authorization features it would be helpful.
Mule ESB could be more user-friendly. I think users must learn about the architecture before they start coding. The price could be better. In the next release, I would like to see an EDIFACT integration.
We would like the ability to use our own code. This would allow us to develop customizations with ease. Additionally, it would be nice to have more analytics or insights on the exchanged information between databases.
It should have some amount of logging.
I'd like to see more attention given to the community editions.
In respect of the UI or the interface, a concept such as that offered by Microgateway would be preferable. We basically use ESB for the gateways. Yet, sometimes when we make use of on-premises standard applications, we require a Microgateway or sidecar proxy products or sidecar proxy-type gateways. This should be addressed. A Microgateway type of application should be available for lending support to MuleSoft. When it comes to standalone applications, it would be better if a sidecar proxy were available, rather than the security models being implemented inside the application. The sidecar proxies make things very simple in respect of microservices. It would be great to see implementing security modules as a feature.
In an upcoming release, I would like to see more additional concept for exception handling, batch processing, and increased integration with other application.
As for what can be improved, in my experience the SMPT connectors need some improvement. It definitely takes some amount of integration knowledge but it is still pretty easy to learn. But I would request that the documentation be more informative. That would help the development community to understand the solution better, to deal with whatever challenges they face and ensure they'll be able to solve them on their own. The integrations are complicated so maybe that aspect of the solution should also be made simpler to use so that it wouldn't require such experienced resources to build a more complex integration. Additionally, there are limitations with the subscription model that comes with the product. If you subscribe to the platinum subscription, you get more benefits. Now there are limitations in keeping the logs and the ability to handle the max of 30 days. They could improve that. Lastly, they could provide us a bit more coding features.
There are some issues with both stability and scalability. I have experienced some issues with clustering.
MuleSoft is not so strong in method-based integration, so they're not so functional in that regard. It seems that it has not been their priority.
There are several areas that need improvement. It's not easy to troubleshoot and we still can't make it work. It starts then stops. We are still trying to make it work using other tools that we have in-house, such as Kubernetes. So far, we have not found the proper way to connect them. Stability is an issue as well as scalability. Both of these need improvement. Pricing is always an area that can be improved. It's everyone's wish.
I think there are some connectors that are not available that should be included. Supports like Salesforce Connector that are available in APN could be included. It's possible that this requires more configuration in our system. I've also found that running Mule Anypoint Studio ESB can slow things down. They have good documentation but it's better to have a video explanation for some of the demos, something basic that runs for 10 minutes or so. If you have that and combine it with the documentation, it would simplify the learning process.
I'm not sure of any areas Mule ESB needs to improve. The price of the solution is a little bit high. It would be helpful if different sized businesses had access to different plans. The solution isn't as stable as we'd like it to be. There are some ongoing issues and therefore Mule has to provide frequent patches. Mule's core IP should be more stable overall.
Technically, there are mainly two API standards. One we call SOAP and the other one is the REST API. SOAP is nothing but fully external. It's very old, but huge complex enterprise companies are still using SOAP-based web services. In the mobile smartphone era, most of the hand-held devices are using REST APIs. Mule ESB is more into the latest REST APIs, not much into the SOAP web services. Developing is all about web services and not easy with Mule. That is one of the disadvantages of Mule. In next-gen products, Mule is in a good position. Normally, if you're declaring a parameter or a variable, you can have visibility until it's not operating the variable. As an architect, programmer, or developer, you know when it's available. Graphically, that's not been available until this tool appeared. It is this kind of enhancement that I'm looking for from MuleSoft. Two weeks ago or a month back, they had a big release. With this package, they are saying that APIs are your products. You can sell your API to different organizations and the developers can register on their portal. It's available this fall. These are the best features I am looking for now. My product is an API. I need to market it through the internet. I can have my portal with all of the tools built-in. This kind of feature I didn't see with the competitors currently in the market.
This solution could be improved by making it more flexible, and more user-friendly. I would like to see support for BPM in the next release of this solution.
We would like to have a built-in logging framework in which we can do auditing. In our case, we are working on-premise. We are not using the cloud solution, so we have MMC, which is not enough in a high transaction environment.
I would like to see the transformation component improved such that they can support the integration of more datatypes. For example, in version 3.7 they do not support the Excel format, and some companies using that version cannot do transformation with Excel input. As a workaround, they have to manually write Java code to do it. The Anypoint platform consumes a lot of memory, and it would be great for developers if it were more lightweight. It would be great if they extended the free trial of the API designer to two months.
* Support, and with respect to licensing cost. * Many of the customers feel that the licensing cost is much.
* The payment system * The accounting and financial areas * The provisioning and enrollment system, because the response time was short.