Mule ESB Reviews

We are using the on-premises version of this solution.

The most valuable feature is DataWeave. It allows for the transformation of data, for example to JSON or from JSON. It's very powerful.

There are also many connectors available, which is nice.

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.

This is a very stable solution. It doesn't require much memory or other resources. Once it is started, we don't see any problems on a day to day basis. Even when you need to make changes, they are easy to do. 

The scalability is easy. It can be done horizontally or vertically. We are scaling horizontally because we don't have any space left in the server. If we need to expand the number of nodes then it depends upon the licensing.

Our development team has three people, and I am the lead.

The community forums for this solution have been very helpful. You find plenty of information there. In the past three or four years, I have only raised three issues. They were related to the VM, and not the product itself, so I did not need product assistance.

We did not use another solution prior to this one. We started with the open source solution, version 3.1.0, and we implemented all of the services. We then paid for a licensed version.

The initial setup is pretty easy. We have multiple applications bounded by that domain, for resource sharing, so it was easy.

I set up the solution myself.

The calculation of ROI is difficult because we work in terms of providing support to other applications. There are many departments involved, and we cannot calculate our support in terms of money.

Before moving to the licensed version of this solution, we had a meeting to discuss the IBM Oracle web method. After looking at everything, including our code and the capability that Oracle has, we decided to continue with Mule ESB because of the ease in moving from the older, open source version, to the newer one. All we had to do is download it and continue with our work.

My advice to others who are implementing this solution is to first become acquainted with the forums. There are always reports coming out about the software, and new technologies. The next thing is that I would suggest always starting with the latest version. Older versions are available, but you should install the most recent one.

I would rate this solution an eight out of ten.

When I worked for the Sprint telephone company, we used the solution as a bridge between their legacy systems and the front end. We developed a lot of the functionality, for example, logging into users' accounts and activating cell phones.

The solution improved the company by modernizing the way they offer services and improving the user experience.

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.

I've been using Mule ESB since 2016, so about six years.

The stability of the solution is great. In fact, the stability is another improvement that the solution brought to the company.

The solution has great scalability.

I previously used an eCommerce platform called Intershop, but it's not really an ESB. Intershop allows for the development of the whole eCommerce system, from the back end to the front end. I switched to Mule due to the needs of a new project that I was starting because it acts as a bridge between legacy systems and front-end systems.

It was kind of straightforward. We had to study their legacy systems and then make some kind of mapping between those legacy systems and the RESTful APIs handled by Mule.

We used a consultant directly from MuleSoft for deployment. It took about an hour or two to deploy the solution, plus time for testing. 

To those looking into implementing this solution, I would say that you will enjoy the experience of using Mule.

I would rate this solution as a ten out of ten. 

We use Salesforce to store the most valuable information in our system. We have many clients that request this data, and we send it to them using the Mule ESB solution.

The most valuable feature is the Salesforce integration.

The drag and drop feature makes it very easy for transformation, and to use the Anypoint platform.

It is very easy to manage the flow using Anypoint.

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.

The version that I am using, 3.8, is quite stable. My understanding of version 4 is that it is not stable, yet, because it is new, and it will take some time.

This solution is very scalable, and we can use it however we like. It can connect to every kind of system.

There are approximately two hundred people using the system, directly and indirectly.

We have used technical support for some issues that we could not figure out by ourselves. They are fast and don't take a long time to respond.

We started with Mule ESB.

The Anypoint platform is based on Eclipse, so anyone who has worked in Java will find it easy.

I performed the installation myself.

The various features and components for this solution are no longer free.

I will soon be migrating to version 4 of Mule ESB, although we are also interested in the WSO2 solution because it seems to be very complete.

Using Mule ESB does not require somebody to be a Java developer, although there are some Java concepts that you need to know. For example, some people use JSON, and I find that they are scared of Mule ESB because it is based on Java. But really, it isn't a problem if they don't know it.

This solution has good performance and support, but not everybody can use it because many of the features are expensive. Especially for application management, it is expensive compared to solutions such as WSO2. It is limiting for small and medium-sized companies.

I would rate this solution a seven 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.

• Deployment strategies: Mule supports a wide variety of deployment strategies.
• SOA architectural style: Mule can embrace the architectural style and SOA practices in place where it’s deployed.
• Focused on higher-level concerns: It deals extensively with all the details of integration and provides a wide range of connectors. It has the ability to be an integration framework open to all sorts of protocols.
• They have comprehensive and up-to-date documentation, a subject on which the vendor has made huge progress recently.

It integrates between an ERP (J2EE inventory module), a CRM (PHP) and a new mobile development platform (Angular JavaScript web services).

The aim of the solution was to connect to the inventory application provided by the ERP system, read and send data to the CRM, then hook that to the smartphone with a user-friendly UI.

Some requirements:

• Integrate applications or systems on premise or in the cloud.
• Use out-of-the-box connectors to create SaaS integration applications.
• Build and expose APIs.
• Consume APIs.

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.

I have been using it for 1-2 years.

Like any application, Mule is constrained by the limits of memory size and CPU performance.

Threading profiles define the overall capacity of your Mule instance in terms of scaling and capacity. The performance of each moving part involved in processing each request will also impact the global throughput of your application.

Setup was realy straightforward as the product is well documented. Also, we should mention the efforts of a good and reactive community.

Before choosing, we also evaluated:

• Oracle SOA Suite
• Open ESB
• JBoss ESB

My advice to organisations looking to implement this product is to begin with the community version as a proof-of-concept and a way to avoid risks. You can then directly migrate to the enterprise edition as the Anypoint Platform offers tools that architects and developers across the enterprise can adapt quickly to design, build, and manage the entire lifecycle of their APIs, applications and products. With Mule as its core runtime engine, Anypoint Platform is built with open technologies to promote reusability, modularity and collaboration, increasing developer productivity and project speed.

• We can use Java expressions anywhere in the flow
• Provides API support out-of-the-box
• API management can be done using RAML

It is very easy to learn and implement. We were able to meet project deadlines on time.

It needs more samples. Also, the dependency on Maven should be removed.

I have used Mule ESB for one year.

We had issues in Munit but rarely any stability issues.

We have not had stability issues.

We have not had scalability issues.

We had few guys from their support team.

They were excellent.

I would give technical support a rating of 8/10.

Firstly, the project architecture team decided to go with Mule.

Secondly, the project was from scratch and we want only microservices exposed over API hence, Mule was a promising deal.

However, in my next project we weren't able to go with as it much pricier than its competitors. Actually, from all the other vendors.

The setup was complex, as I came from a different background (IBM products). However, it became smoother down the line.

We went for a training first and then it was in-house after that.

This is expensive. In my next project, we had to go to other vendor.

Apparently, this is the most expensive ESB solution out there as there is no more Community Edition.

We looked at IBM IB and webMethods.

Go for it, but first read their sample exercises.

It is a one stop solution and it is an amazing product.
However,

1. It is an expensive product

2. Expensive support

We use this solution to integrate with other software applications.

Now, we are running almost 50 integration APIs, and will have over 1 million billable transactions.

The solution can be deployed on cloud or on-premises. I'm using version 4.2.

It's open source, and there are a lot of community resources. Mule ESB makes it easy to connect to other software applications.

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

I have been using this solution for over nine years.

The stability is great compared to IBM.

The scalability is amazing. You can increase the horizontal perspective or the increase the vertical perspective. It depends on your business needs.

We have a dedicated support person from the MuleSoft tech support.

Development is very easy. Initial setup took two days. We needed to open a firewall, download the necessary things, clean the server, file storage, network storage, and we needed to work on the installation of the servers.

For deployment, we had one person for admin and one person for development.

I would rate this solution seven out of ten. 

I would recommend this solution for those who want to use it. It will depend on the customer's needs and what they want to use it for.

We primarily provide services using the Mule ESB. We use it to integrate multiple systems.

The connectivity the solution provides is excellent. There are often too many systems that we have to integrate and this helps with that.

The platform itself is very good.

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.

I've been familiar with the solution for two years.

We had a bit of an issue with stability when it came to running some large files. We kept getting an error. In the end, we had to divide the files and process it via multiple files because of the way we implemented them. Large file processing also seems to take up more memory.

The technical support has been very good. It depends on the account we're working on, however. Good accounts get prompt responses in regards to queries.

We didn't previously use a different solution. We've only been working with MuleSoft.

The initial setup was straightforward. We haven't faced any issues with implementation. They've recently simplified the processes. I recall, earlier it was not that easy to set up.

Deployment doesn't take too much time. Sometimes it can be done in minutes. It shouldn't take more than an hour.

I'm unsure of the licensing costs. I believe the total price is less than IBM, but it's still rather expensive.

We're partners of MuleSoft. We provide the solution's service to our clients.

The solution would be useful for large organizations. If there are more than three or four systems, and if there is an expansion, it would work best. Small or medium enterprises with two or three systems, may find the solution a little bit unorganized.

I'd rate the solution seven out of ten. If the stability were more reliable, I'd rate it higher.