The price of Mule ESB could improve.

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.

From an improvement perspective, there should be fewer coding challenges for users in Mule ESB.

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 main issue we currently have is that the version we are using will not be supported for much longer and we'll have to migrate to the newer version. 

The initial setup is not easy.

It would be much more beneficial if the solution included AI and business process management.

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. 

Mule ESB isn't as secure as IBM. Financial companies go with IBM for that reason.

In the next release, I would like to see improvement in the generator for the DataWeave language so that it's a little more graphic.

It should have some amount of logging.

The stability could be improved.

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.

I think using Anypoint Studio at the beginning can be seen as not straightforward, especially when dealing with the visual editor. A vertical representation of the flow can really improve the understanding of the case and a good mapping to the use case.

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.

Its licensing or pricing model should be improved. If I compare it to other solutions, it is very expensive for small and medium businesses.

Their support should also be improved. Some of the tickets took a long time to be resolved, and I had to escalate to my account manager.

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.

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.

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 needs more samples. Also, the dependency on Maven should be removed.

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

In an upcoming release, I would like to see more additional concept for exception handling, batch processing, and increased integration with other application.

The HTTP request connector should have the ability to change the hostname on the fly instead of the URL endpoint only.

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.

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.

• SOA governance of ESB
• Versioning and exception handling
• Easier development
• Documentation/good design guidelines are not sufficient

The documentation is not extensive and is limited to examples which are too basic.

The solution's setup needs to be a bit more straightforward and its support needs to respond faster. 

In order to meet the new trend of active metadata management, we need intelligent APIs that can retrieve new data designs and trigger actions over new findings without human intervention.

• Limitation on external subscribers to listen to the messages on the bus.
• VM queues and memory/thread management need more stability.

The initial setup could be more straightforward.

I'd like to see more attention given to the community editions.  

The Mule IDE (Integrated Development Environment) could be more stable. For example, in Anypoint Studio, when we add some components and then remove them, they don't get deleted from XML in the background. It gives a duplicate error when we try to add them another time. However, this has been fixed with Anypoint Studio 6.

MuleSoft ESB is a wonderful product. However, in order to help the developers utilize it extensively, I would suggest adding some scenario-based and audio-visual tutorials.

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.

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.

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 some issues with both stability and scalability.

I have experienced some issues with clustering.

Documentation is cryptic, product releases are far too frequent, and upgrades become troublesome.

The CloudHub offering requires some time to mature. However, it is a good overall solution.

Some further details:

1. The AnypointMQ offering is not very stable, as such can cause issues
when dealing with high volume burst messages.

2. The CloudHub offering is EC2 instance based and does not run in
containers.

3. The speed of the CloudHub user interface is poor.

4. Deployment takes several minutes (due to Ec2 architecture as opposed to
containerization).

5. There is currently no cross application object store.

• 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.