What needs improvement with Mule ESB?

In my opinion, the real-time analytics part of Mule ESB is not up to the mark for the decision-making process. While there are some analytics features, they lack the standards needed for enterprise use. Compared to other analytics tools such as Power BI, MuleSoft falls short.Points for improvement in Mule ESB definitely include enhancing the analytics capabilities because currently, they rely on external logging tools such as Splunk or ELK, which is lagging behind compared to other tools such as Workato that offer more analytical features. Additionally, issues arise with AI-based use cases due to dependencies on Salesforce tools such as agent force, making development more complicated when it should be more independent. Developing AI-based agents without being tied to Salesforce applications could also enhance functionality.

Licensing cost could be improved in this regard. Overall, the product is a bit on the expensive side. Pricing is one factor that could be improved about Mule ESB; other than that, I'm pretty fine with it. There are some product issues maybe a bit here and there, which only arise if you use it for certain scenarios. There are certain gaps specific to the nature of the product.

They come up with new versions frequently, but at a COE level, it's difficult to upgrade to new features because it's not easy to upgrade. We have to spend some extra manual efforts to upgrade that version, and that's where we see the challenges.

From my perspective, Mule ESB is lightweight, but it can be improved when it comes to the agility of the system. It's a bank, so it's expected that we're waterfall, and things don't really work for us in Agile, but I'm hopeful that one of these days ESB can help us with that.

I cannot say that installation with Kubernetes ( /products/kubernetes-reviews ) needs to be improved to be less tricky, but more information is needed from MuleSoft. They do not help much with Kubernetes ( /products/kubernetes-reviews ), so we should have a person who is well-versed in Kubernetes to handle this.

In India, particularly in the banking sector, clients do not prefer cloud solutions due to regulatory and compliance requirements. This creates a challenge for Mule's adaptability as the control systems are on the cloud. Having the control plane on-premises would increase adaptability in the financial sector. There are challenges with getting consistent technical support and the cost of licensing is high compared to other solutions.

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.