Mule ESB Reviews

We use it for creating APIs and integrating with different messaging systems.

Most of our use cases are for Salesforce. So, the connectors for Salesforce have been really helpful. They've made development two times faster.

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.

I have been working with Mule ESB for two years. I work with Anypoint Platform ESB and the complete platform, including CSV and gateway.

I would rate the stability an eight out of ten. The solution is quite stable on the cloud. However, there have been some issues when it's on-premise or located in a specific location.

With the current trend and new tools emerging, like the JNA stuff, MuleSoft has plugins for all IDEs. If these plugins continue to be available and supported in the future, it'll be easier to develop. This would definitely enhance the product's scalability.

In my specific department, around 60 people are using it.

In my experience, I've received fairly standard responses. For my specific use cases, I didn't always find their solutions helpful. They often provided standard information, which we were already aware of. A deeper dive into the issues would have been more beneficial. There's an area of improvement.

Neutral

Since most of us are on the cloud, most clients prefer the cloud, where the entire platform as a service is provided. So, the setup process is very smooth, and there's really no setup needed. It's all cloud-based. For local development work, the setup for the IDE is taken care of by the cloud, making everything easy to set up.

Initially, we did get some minimal support, but it wasn't extensive. We collaborated to resolve issues or gain clarity on certain points.

I would rate the pricing a five out of ten, where one is high price, and ten is low price. I would place it in the middle. It's neither too expensive nor too cheap. 

Overall, I would rate the solution an eight out of ten.

My current client is using Oracle Fusion Middleware as their integration platform, and they want us to build a new platform enabling the same functionality using MuleSoft. 

Mule ESB has a user-friendly design, and everything is in one place. The API and architecture are popular right now. Also, MuleSoft has a large and supportive online community. 

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. 

We've used Mule ESB for four years now.

Mule ESB is stable. 

Mule ESB is scalable.

I haven't personally contacted MuleSoft support. Our team has contacted them during some test scenarios, and they were responsive. I would rate MuleSoft support a solid nine out of 10 based on my limited experience with them. 

I have little experience with Oracle Fusion. It's quite good, but the interface is pretty old-fashioned. I worked with IBM WebSphere as well. That was a big part of another project I worked on, but these are the two technologies I've used.

Currently, I'm working with Oracle Fusion. These solutions require elaborate coding, so you need to be extremely experienced in programming, with the ability to write tons of complex code. It's good to have a solid background in coding, but you shouldn't need to be an expert to work. 

Mule ESB isn't difficult to set up, but there are specific procedures you need to follow. Prerequisites need to be in place to set up the whole environment. It's straightforward once you set up the platform.

After deployment, it doesn't require much maintenance. Most things can be automated, so you don't need someone to always monitor the solution.  Ultimately, it depends on your use case. 

I rate Mule ESB nine out of 10. It works well for me. If you're using Mule ESB for the first time, I recommend taking advantage of the free training. If you go through that training, you'll have a basic understanding of the technology. That's a good starting point.

Mule ESB excels in orchestrating workflows and seamlessly integrating with business implementations while keeping technical details hidden. It also offers protocol transformation, converting between different protocols, and supports service exposure to customers while maintaining technical invisibility.

We utilize data transformation capabilities extensively. For complex cases, we employ the SSLi engine, whereas for simpler ones like healthcare or response data, such as EDI 270 or 271. We prefer to use an external XRT engine instead of handling it within the ESB for ease of management. For smaller data transformations, we rely on DSPS.  

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.

I have been using Mule ESB for the last five years.

The solution is generally stable. We ensure proper sizing and memory management, which helps avoid glitches and slowdowns.

Mule ESB is scalable because it can be easily scaled in a cloud deployment and is containerized, making scaling up or down straightforward. This shouldn't be a major concern nowadays.

MuleSoft's customer support is excellent.

Positive

Setting up Mule ESB is relatively easy, although it depends on factors like account categorization and whether you're using Docker or Kubernetes. 

Typically, installation and configuration take around three to four days initially, but subsequent deployments or updates are quicker. One engineer or developer is usually sufficient for deployment, but implementation complexity may vary based on the use case.

The ROI of Mule ESB is greatly influenced by the design and governance of the solution, particularly focusing on reusability and adherence to microservices architecture. Properly designing and implementing these aspects can significantly enhance ROI.

Regarding licensing and pricing, I find it somewhat flexible. They are more flexible with larger customers compared to small and medium ones, as their licensing model depends on ports and other factors. Large customers benefit from more flexibility in implementation and renewal compared to smaller ones.

Working with Mule ESB has taught us the value of experience with different ESBs, making it easier to adapt to new solutions.

Overall, I would rate the solution a ten out of ten. 

We use this solution to get data.

The stability could be improved.

We have been using this solution for about two years.

The scalability is good, and I rate it a nine out of ten. We have about 20 users using this solution. We do not have plans to increase the number of users, as it depends on the number of use cases we deploy. We have developers, managers and business users using this solution.

Technical support comes with the subscription plan.

We used Oracle ten years ago.

The setup is straightforward. It was a fast deployment and took one week.

The subscription is annual.

I rate the solution a nine out of ten.

We use Mule ESB for integrating with third-party vendors. Mule ESB bridge between internal systems and third-party systems. Additionally, we use it for enterprise, web, and APIs services.

The most valuable features of Mule ESB are its ease of use, documentation, ease to adapt to newer security and vulnerabilities, and a lot of help available. Additionally, there is a lot of flexibility, many patches available, and they provide APIs. They are a market standard.

The price of Mule ESB could improve.

I have been using Mule ESB for approximately four years.

Mule ESB is a stable solution.

The scalability of Mule ESB is very good. 

Mule ESB has been in use since 2008. It has been a long-running tool and application and has supported multiple phases.

Mule ESB is easy to set up, configure, and change the configuration. It only takes a couple of days to make any changes the client asks for. The longest project we had using Mule ESB was one week.

We do the implementation and support of Mule ESB. The solution is easily maintained and manageable.

Mule ESB is a costly solution. We pay approximately $80,000 annually for the system. The cost of the number of instances, annual subscription, and cloud hosting services are expensive.

We are thinking about moving away from Mule ESB and using Red Hat because of the high costs of Mule ESB. However, Mule ESB is a good solution.

We propose Mule ESB in terms of solutions for any kind of enterprise service bus application.

I rate Mule ESB a nine out of ten.

I am a solution architect where I design solutions by leveraging integration tools, low-code platforms, and BPM platforms. We are using Mule EBS for transformation purposes.

Mule allows us to transform our data into our desired outcome and then translate it. This allows it to be moved forward for further processing.

This tool has exceptional API management and integration connectors in addition to multiple out of the box connectors. 

The UI is good. From a development perspective, it's pretty easy and pretty intuitive for the developers to work with. We have fresh graduates who have started picking up MuleSoft. Its user interface is pretty intuitive.

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 am working on my third project that utilizes Mule.

The solution is quite stable. We have not experienced any stability related issues as of now.

We have not had any issues regarding up-scaling and other things. We are in the process of increasing the usage of Mule so that it can take up to two thousand requests per unit minute.

The last time I raised a ticket with them where we needed additional guidance, they were pretty good and responsive. On one of my previous projects that I worked with where we needed some information or we needed some additional guidance from them, we were able to collaborate with them and solve the issue pretty quickly.

The initial setup was straightforward as we chose to go with the Mule cloud where the infrastructure was taken care of by them. We only needed to ensure connectivity between on-premise databases/systems and Mule cloud.

Because it's their cloud, the setup is much easier. It would be interesting to see what the setup is like for an on-premise or hybrid environment. It might be a completely different setup. It would probably be more complex because you have to go through certain process to ensure the compliance and the security standards of the organization are met, and that the connectivity is established.

We looked in to using Apache Camel and TIBCO.

It’s a pretty good tool to have it when you try to go with a microservices type of an architecture where you want to decouple your systems and where you want all the systems to talk to each other, share that knowledge, and create those experiences that you want as part of your digital transformation journey. This tool perfectly fits that. It's a good tool to have as part of your digital transformation journey.

I would rate it a seven out of ten.

This is an enterprise service bus, and it is mainly used for transferring data. For example, it is used when System A has the data that needs to be sent to System B. 

Our use case is transferring the enterprise data from one enterprise to a different enterprise. We use different types of connectors or connections to get the data, transform the data, and send it to a system. Almost all the integrations work in the same manner.

It can be deployed on-premise, but nowadays, most of us prefer cloud-based solutions.

It is easy to use and easy to understand. 

It is easily deployable and manageable. It has microservices-based architecture, which means that you can deploy the solution based on your needs, and you can manage the solution very easily.

It should have some amount of logging.

I've been using this solution for almost two years.

It is stable.

It can scale based on your needs. It is scalable vertically and horizontally.

We have used it in many projects. Its usage might increase. It depends on the high-level management. If new products are coming, they're going to use it for sure.

Their response is based on the subscription. If you are experiencing any production-related issues, they're immediately available. 

There are various levels of tech support, and the service depends upon the level of support to which you have subscribed. Titanium support is at the highest level.

We have used webMethods, which is an on-prem solution. 

For a cloud-based deployment, there is no need for us to manage anything. It is directly deployable. We build and deploy it. That's all. 

For an on-prem deployment, a lot more installation is required, but it is a very easy process.

We can do an on-prem deployment ourselves. Developers mainly focus on the development aspect of the solutions, and admins manage all deployments.

We didn't evaluate other options.

I would recommend this solution to others. It is the best integration platform for those who are looking to implement or are going for API-based architecture and microservices-based architecture.

I would rate it a nine out of 10.

We used Mule ESB for the integration between two or three organizations.

The solution's drag-and-drop interface and data viewer helped us quite a lot.

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

We have been implementing the solution for three years now in our company.

Sometimes, we had to restart the servers from time to time because of some environmental issues.

I rate the solution a six out of ten for stability.

Mule ESB is a scalable solution. Our clients for Mule ESB are small and medium enterprises (SMEs).

The solution's initial setup is easy.

On a scale from one to ten, where one is difficult and ten is easy, I rate the solution's initial setup an eight out of ten.

The solution can be deployed in a few minutes.

Mule ESB is an expensive solution.

On a scale from one to ten, where one is cheap and ten is expensive, I rate the solution's pricing an eight out of ten.

We were using the solution for the transformation of requests. So, it was good for us to exchange data and establish communication between different legacy and modern systems.

Mainly, we were using the transformers. Other than that, the process flows were very helpful for us to implement them. Earlier, the integration was done into the development and through the languages itself, like custom implementation. With Mule ESB, we could do many transformations and implement the process flows within the services itself.

We were having the same service which we had to distribute among the different clients. The proxy and role assignment was done through Mule ESB. This helped us with the distribution of services among different vendors and then validating them based on their roles.

Although we faced some challenges initially, we got the expertise by learning from Mule ESB itself. Eventually, everything got smooth, and we never had any issues with the deployment. Depending on the requirements and the size of the projects, I would recommend Mule ESB to other users.

Overall, I rate the solution a seven out of ten.