Mule ESB Reviews

There are many already defined endpoint components such as HTTP, JMS, FTP, etc., and these are the main tools for communicating with various services. By having these, developers just need to concentrate on the functionalities instead of making modules to talk to other services.

I am not sure about how it has improved the way my organization functions but certainly with regard to simple integration, development speed is faster than writing from scratch.

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

I've used this product for eight years from Mule v3.0 to v3.8.

We had an issue in v3.4 with clustering but as of v3.7, MuleSoft has fixed the problem.

Scalability depends on how an application using Mule ESB is designed and so far, we haven't had any issues with the scalability.

The technical support is OK and I've never really needed it.

The setup is straightforward in terms of deployment and environment setup.
Just download the "mule-esb runtime environment" zip file and unzip under a particular directory. Then a Mule setup is done. To deploy an application, just drop a Mule app into ${MULE_HOME}/apps along with the properties file under class path, then done.

It is getting expensive and I recommend clients to use Camel ESB if enterprise support is not required.

If a cluster is not required, then just buy the non-clustered version.

I've been in a consultancy environment for a long time and knew various frameworks and tools already.

Make an architectural plan in depth before implementing a solution based on this product. Otherwise, it might cost far more than expected.

I use Mule ESB to exchange data between four or five systems at one time. We exchange government organizations' data.

Mule ESB is a very easy-to-use and user-friendly solution.

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 have been using Mule ESB for approximately two years.

The stability of Mule ESB is very good.

Mule ESB is a highly scalable solution.

I am the only one using Mule ESB in my organization and I use it daily.

The community version of Mule ESB does not have support. I  find information online if I need it.

I was previously using Talend ESB but it's more complex than Mule ESB to use. The commercial versions have more features than Talend ESB.

Mule ESB was very easy to set up. I did three months of testing Mule ESB before I went into production.

I did the implementation of Mule ESB myself. There is no maintenance required for Mule ESB.

The price of the Mule ESB commercial version is expensive. However, they have a free community version.

I recommend this solution to others. If you have any data exchanges with other systems, Mule ESB is very useful and easy to use, even if it's the commercial version.

I rate Mule ESB a nine out of ten.

My primary uses are asset maintenance and data management.

The most valuable feature is that it's programmer-friendly, so it's very easy to develop APIs.

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.

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

It's very stable and reliable.

This solution is scalable.

The technical support is reliable and quick to resolve any block we have.

The initial setup is straightforward and only takes a day, but it looks at many data sources, so you have to be specific about what you need. 

This product is expensive, but it does offer value for money.

I would give this product a rating of ten out of ten.

It's used for regional implementation, where several systems are integrated and contributing to a central on-premises system.

The transformation and the data format are the features that I like the most.

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 have been using Mule ESB for five years.

It starts and stops, so we haven't had a chance to test it in production.

We have not reached out to technical support. Our case was so complex that we had to reach out to the architect to come on-site and help us with it here. This type of support is definitely expensive.

The initial setup was complex.

Deployment took a week. We were waiting for the team to be onsite.

We had a team from Mulesoft to help us.

The licensing is yearly, and there are additional fees for services. For example, having the help of the architect was a separate fee.

It's definitely allowed us to develop everything but we are stuck in testing. It works then it stops working, and now we are trying to figure out why. It's not related to the software but related to the teams that work with it. It's a new technology for us.

I am still trying to discover the benefits. I know that it has many connectors, that it's a tool to integrate with Salesforce. That's when they say we cannot do what we need to without MuleSoft. We didn't use it for that purpose. For our purposes, custom integration as ESB, we are still trying to discover where our benefits are. I don't have a good idea yet.

We were able to develop what we were planning to. It's highly configurable. We were able to configure the workflows and orchestrations, but we are not able to run it yet.

I don't want to give people the wrong impression because of my experience so far because it may not be an accurate one. It may not be the fault of the solution.

When I worked with IBM in the past, it was easier.

Due to the complexities, I would rate MuleSoft a six out of ten.

Our primary use for this solution is API driven related management and lightweight message processing.

The most powerful feature is DataWeave, which is a powerful language where data can be transformed from one form into another. 

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.

This solution is very good, and it is stable.

In terms of scalability, it is very good.

Technical support for this solution is very good, and very interactive. If I have any questions then I reach out to them and they respond very quickly.

We were using a variety of technologies, but we use this solution because it is a very lightweight message processing system.

I would say that this initial setup was moderate.

Our DevOps handled the implementation.

We looked at other options, but this one is what our vendor recommended.

I would rate this solution a seven out of ten.

• Salesforce connector
• Enterprise JDBC
• SAP connector and other connectors like FTP and SFTP
• Parallel processing support
• JMS integration

We are a technology consulting company specialized in Systems Integration using Mule ESB. (www.app-integrators.com)

Through App Integrators, we have integrated disparate Enterprise Applications for different customers across the globe. Most of our integrations for clients are:

• Hybrid Integration Model: On-premises and cloud based applications
• Large volume data handling: Handled batch applications supporting up to 20 million records to Salesforce.
• Support for Enterprise Batch Applications: We have used Mule ESB for running 120 batch applications on different scheduled intervals.
• SAP based Integrations with manufacturing systems

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

I have used this solution since 2012.

There were stability issues. It is very complex to set up an Enterprise grade application and it is not easy to use.

Like a typical Java application, one should know how to tune a Java based server.

However, we have experienced issues when handling massive volumes of 20 million records to Salesforce (from on premises systems). We also experienced issues when we executed batch jobs of up to 120 jobs in a cluster of Mule ESB instances and when handling large volume of data (in the millions).

Nevertheless, many connectors like Enterprise JDBC and DataWeave support the streaming of data.

Technical support has been excellent. They are very helpful through their customer support tool and/or through their forums.

We used Oracle OSB before and some of our clients used TIBCO middleware or Java CAPS.

But we suggested that clients switch to Mule ESB due to:

• The lower licensing cost
• The availability of cloud connectors
• CloudHub platform (supporting iPaaS)
• A suite of 110+ connectors to use.

It is complex to set up because any Enterprise grade middleware needs hardening. This is why we need to set up clusters, integrate with source control tools for continuous integration in different environments like DEV, QA, TEST, and also consider firewalls and internet security.

So other than a DEV Server, the setup is not straightforward. It depends on the organization security/development methodologies and policies.

It is cheaper than competitors in pricing and licensing. We have an open source option available as well.

Most of the licenses can be added as entitlements on top of a basic Enterprise license. Licenses are renewed every year and there is no perpetual license.

We evaluated Oracle ESB, Apache Camel, and ServiceMix.

I would recommend this solution due to its support for multiple integration options.

Flexibility and high performance.

I can perform integrations with any environment and scenery as well as growth in apps integration, is an agnostic tool architecture ie can generate components on different architectures are JEE or .Net.  

Mule ESB has a lot components and tools that apply integration patterns making it easier to development without much knowledge of patterns

It allows communication between different applications with different protocols. It's also helped solve business integration issues.

Mule ESB is the heart of applications that required routing and improvement of messages such as electronic invoicing

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

We've used the tool for about six years.

• Writing your complex business logic as a simple workflow which can be understood by not so technical people
• Hot deployment of those workflows, which helps in automation and self-learning/healing.
• Provides a variety of connectors: SalesForce, Twitter, SAP, Facebook, and WebService consumer. Most of them come for free with the Community Edition.
• Async/concurrent execution of services within a flow
• Logging

We had to design a complex diagnostic and analysis tool that catered to different ERPs. For example, connecting to different types of data sources and listening from different types of services (over Web and FTP).

Business services for diagnostics should be modified by admin/functional people and applications should be updated on-the-fly without any down time.

The Mule runtime engine served the purpose and we developed a drag-and-drop workflow designer (web app) that is built on top of Mule to make it easy for admins to create and edit services.

I’ve been using Mule ESB for 18 months.

We have had no issues with stability.

We did have scalability issues. It demanded more RAM at times, when there were a larger number of requests while listening over FTP. This is the case with any web container.

I am a Community Edition user, so I can’t comment about the enterprise support by Mule. However, you will not get an immediate response for your queries in any of the technical forums.

I did not use any ESB earlier, but this is the best Community Edition ESB available in the market. However, we abused it as a workflow engine.

To get an initial setup is straightforward.

1. Write a simple HTTP-based listener workflow.
2. Print whatever you send in a context path in a browser.
3. Dump it in a standalone runtime.
4. Start it.

I would advise using the Community Edition if you are developing an application as an additional service to a customer or a non-critical Tier-2 application. You can do this without support.

Apart from support and a few additional connectors, the enterprise edition is not so different from CE.

I was not part of choosing this solution.

Don’t abuse it. Be clear if you want a Mule application to solely solve your business problems, or if you want it as an add-on to solve a few problems that your main application can’t solve.

You may get into scalability issues if you are not clear about this basic difference.