Mule ESB Reviews

We were using it for EDI. We were using it for integration between RFID portals and our ERP system. We were also using it for the integration of customer data between the CRM and the ERP systems. I am no longer using it because I changed the company.

We were using the cloud version.

When we bought the solution, it was an in-the-cloud or PaaS solution. Because of that, I didn't have to take care of the infrastructure, which was a big plus.

It was pretty fast to develop APIs on this platform, which is something I liked about it. So, the time to value was pretty good. 

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.

I used this solution for maybe five years.

It is very stable.

It is very scalable. It is also easily scalable.

I had about two developers internally, and they were taking care of its deployment and maintenance. In terms of the end users, it probably impacted hundreds or thousands of employees.

It was okay. There is room for improvement. I had some tickets that were taking a long time to be resolved, and I had to escalate to my account manager to push them through. I would rate them a three out of five.

In the latest implementation, we decided to start small with a very simple project that we had, which was customer integration between our CRM and ERP solutions. We started with a very small API. It was a small integration with only about three APIs, and that was it. We had success with it, and we ran it. 

We did it in partnership with a third-party consultant, and then we took it from there. Our experience was very good.

Pretty good. I would rate it a four out of five.

Its licensing was yearly. There were minor fees additionally, but those were related to VPN's high availability. When you purchase MuleSoft, you purchase it because it is highly available. So, you have to make sure that your VPN can support that. That's pretty much it. The other tools that we picked were things to deploy the solution to build the CI/CD pipeline using MuleSoft. We picked the one that wasn't free. So, we had to pay for it, but it was a minor cost.

They have a package to get you started. I would advise using at least a partner at the very beginning so that they can show you the best practices within MuleSoft and different layers of APIs. Sometimes, there are challenges around security and things like that. So, my advice is to get external help to get your developers started on it. Once they're taught the best practices, your intermediate to senior developers will pick it fairly quickly.

I would rate it a nine out of 10.

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.

I used the free trial account to test the product, it allows 10 days free trial.  

I'm a software engineer and a user of Mule ESB. 

The best feature for me was the easy connectivity and easy integration. In comparison, if you go through code license for APN, it will require more configuration or more code but if you're going to Anypoint Studio and using Mule ESB, you just drag and drop the connectors, configure the credentials and complete your process as per your requirements. The product helps me a lot to integrate quickly. 

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 have used the solution for one year. Really helpful tool for integration with multiple system.

This is a stable solution.

The solution is scalable.

I haven't used technical support, I tend to check the documentation when there are problems. It's actually quite good. There is a video which explains integration in only three minutes, and that helped me understand the documents.

I used some of the notes and YouTube tutorials that explain the setup. They've simplified the process with the latest version which is a good thing. 

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

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.

The most valuable features are the connectors, DataWeave, and the way it simplifies the application development and deployable files.

Connectors:

• Being a Java developer, I have experienced how much logic and coding one needs to put in while accessing the database.
• With the DB Connectors developer, I just need to place the query, and in some cases the drivers, if Mule doesn't provide out-of-the-box support.
• With the HTTP Connector and the APIkit router with RAML, managing the resources and handling is made easy.
• With Mule's expected release in Q3 of 2017, generating RAML would also be made easy.

DataWeave:

• With good knowledge of DataWeave operators, anything can be achieved in a couple of lines of code, which otherwise would be time consuming in Java.

It has reduced interdependency.

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.

I have used this solution for around a year.

The older versions of Mule IDE, Anypoint Studio 5.x.x are more unstable.

There were no scalability issues.

I would give technical support a rating of 4.5/5.

The setup was pretty straightforward.

This is an affordable product.

Since most organizations are now going digital and opening up their resources via APIs, companies should explore using this solution.

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.