Mule ESB Reviews

Mule ESB is an enterprise service bus where all applications are integrated, making them loosely coupled systems with an API-led architecture. The architecture includes an experience layer, system layer, process layer, and system layer. The experience layer can push data to the process layer, but there may be a delay in processing by the downstream system. The data must be pushed into a service bus, such as a message layer or messaging layer, where it will be published and the API in the system layer picks up the data and pushes it to the downstream system. These architectures allow sending the same data to multiple downstream systems, reusing the same data required to push to multiple systems rather than getting it from the source system. Mule ESB works with an enterprise service bus along with a common data model, done through common messaging through an enterprise messaging system called the ESB model.

Mule ESB supports different types of ESB messaging layers such as Anypoint MQ, ActiveMQ, or Apache Kafka. There are different ways to use publish-subscribe architecture or a hub-and-spoke architecture where the enterprise service bus plays different roles. Additionally, it supports reliable delivery, meaning if data is pushed to the downstream system and the downstream systems are unavailable for some reason, the data will be persisted in the messaging layer. Whenever the system comes up, due to durable subscription, it will receive the data, ensuring that whatever enterprise service bus is being used provides reliable delivery.

One of the key features I find unique and most useful in Mule ESB is the loosely coupled architecture, allowing for multi-delivery where the same data can be sent to multiple systems. It ensures reliable delivery and prevents issues, which is one of the biggest features. It is also reusable, meaning the same service can be used in multiple places simply by adding it, and this comes with the API-led architecture that makes integrations more secure and reliable.

Regarding API management capabilities in Mule ESB, I find that it is a good feature that adds value to the current market strategy. MuleSoft is a leading tool for API management, providing secure integrations with customers and different clients. It has the capability to set up security policies, including auth-based authentication, JWT-based authentication, and client ID enforcement. Everything can be set up in API management, which is a very good feature of Mule ESB. It also allows integration with Active Directory for authorization and enables role-based access to the API. While there are some limitations compared to tools like Apigee or Kong gateway for API gateway features, Mule ESB excels in secure enterprise application integration. When assessing the best tools for customer needs, I consider the specific requirements and evaluate the features accordingly to propose suitable tools.

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.

I have been working with Mule ESB for almost six to seven years.

Mule ESB is a stable product, and I have no doubts about its reliability.

When it comes to scalability and the ability to expand, I would rate Mule ESB as an eight or nine.

The technical support from Salesforce is moderate, and I do not have extensive support to rely on.

Positive

The initial setup process for Mule ESB is comparatively a little complex.

Regarding pricing for Mule ESB, I would rate it as a ten, indicating it is high. The pricing is comparatively high when looking at other tools, and they recently introduced customized pricing options, but I am unsure of their feasibility in practice. Mule ESB's pricing structure, which is based on flow development and other factors, does not seem realistic, especially since Mule ESB is already established in many organizations. Customers indicate that they feel they are paying excessively for current integrations.

The ability to work with multiple messaging patterns in Mule ESB, such as publish-subscribe, asynchronous requests, synchronous requests, synchronous request-reply, and asynchronous request-reply, is very useful as each has its own advantages based on the requirements. For instance, when working with SAP applications, asynchronous request-replies are beneficial because pushing data to SAP can take time, and events can be generated as request-replies through messaging. Synchronous request-replies can also be implemented using a queue-based mechanism to push data and immediately receive it. Topic-based subscriptions allow for multiple subscribers to get the same message, adapting based on functional requirements.

I have worked in both on-premise and cloud environments with Mule ESB. Nowadays, everything is oriented towards cloud-based environments because cloud tenants are widely available. On-premise systems are typically used when there is a need to limit external access and remain behind a firewall. The biggest disadvantage of on-premise is that all application monitoring, infrastructure monitoring, and overall control remain under the organization. In contrast, cloud-based infrastructure is maintained by service providers such as AWS or CloudHub, which is advantageous. Additionally, many organizations are now adopting hybrid architectures where external cloud applications connect with CloudHub, and on-premise applications can be developed through virtual private cloud connections, effectively supported by MuleSoft.

Mule ESB can indeed be deployed on various cloud providers such as AWS, Azure, and GCP. The approach varies based on customer requirements. For instance, organizations may have their own private cloud where MuleSoft can be installed using Runtime Fabric (RTF), which operates within specific enterprise environments. RTF utilizes Kubernetes clusters and Docker for deployment, providing flexibility. Additionally, applications can be installed on public clouds or within CloudHub, demonstrating the versatility of deployment options.

Overall, ease of development needs improvement. The stability of the product is commendable, while the pricing should be around a five. Scalability is strong, around an eight. My overall rating for Mule ESB is between seven and eight.

Mule ESB and TIBCO are used in our organization. We build APIs for connecting systems with Mule ESB in our system. We don't use real-time analytics to that extent; it's primarily unlocking the system of records, and that's what we do as we expose back-end systems.

Most of the features in Mule ESB are pretty good, especially the platform and the way you can expose an API.

Mule ESB platform provided is very cohesive, and that's why it's leading in the Gartner quadrant as well and it's one of the best integration products as of now, especially when it comes to APIs, which has helped integration projects, particularly in terms of control and efficiency.

Mule ESB's real-time analytics has been used for data-driven decision-making, not to the very extreme extent, but it is utilized.

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.

I have been working with Mule ESB for eight years.

There are no problems with stability; rather there are certain scenarios in which it doesn't work properly.

The adaptability of Mule ESB in supporting multiple messaging patterns is pretty decent and pretty good. Other than for ETLs where it doesn't fit in properly, like when you have very heavy bulk load sort of processing, Mule ESB works pretty well. It cannot be used as an Informatica sort of tool, but other than that it works pretty well.

A return on investment with Mule ESB has been seen, definitely.

Mule ESB's API management capabilities have been utilized.

Mule ESB's security features have a positive influence on our organization's data protection and compliance strategies. The way the components are connected and the out-of-the-box policies, along with a few custom ones, provide what is needed to begin with and then can be improvised and built upon.

Mule ESB is covering up the necessary aspects; they are introducing more AI features, so that's in line with what should be done and what's being expected.

Whether to stay with Mule ESB or look for other options is an organization-level decision that cannot be commented on extensively.

The review rating for this product is 8.5 out of 10.

Private Cloud

Amazon Web Services (AWS)

We use Mule ESB for microservices, connecting to the internal systems of the bank.

Mule ESB helps a lot with our microservice architecture that we're trying to build, and it is still our go-to technology when it comes to that, so it's very promising for us.

We are heading to the framework where we're trying to build a system for all of our legacy applications to interface with Mule ESB onto our mainframe.

The best features of Mule ESB are that it's very robust and solid; I find that even our legacy systems go well with ESB.

We just started to explore Mule ESB's API management capabilities, and I find it very useful in our day-to-day operations.

Mule ESB is a scalable solution.

Mule ESB is a stable solution.

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 have been with Metrobank for three years now, so I have around three years of experience with Mule ESB as well.

We started doing the cloud environment implementation with Mule ESB, and so far, it's working pretty well for us, although we've yet to deploy to the cloud. We are still doing a lot of testing on it, but it's very promising.

I would rate technical support for Mule ESB as nine out of ten, as we have a good relationship with our vendor, and they are ready to help us with any technical issues.

Positive

When I came into the company, Mule ESB was already in use, although it was the older version. We needed to catch up and teach the new team members, so the exercise of microservice architecture for Mule ESB should be the bread and butter of our team. There were hardliners that didn't agree with it, and they left the company already, so we're fine now. We hired a bunch of young professionals that are very open to the microservice architecture, and we're doing fine with it at the moment.

Our Java team concentrates on the JBoss stuff, and they are also concentrating on ESB as well.

We bought Mule ESB directly from our Oracle vendor, not through the AWS Marketplace or other channels.

We have seen an ROI from using Mule ESB, as we're expanding our contract with the vendor for it. I have not calculated it yet.

Regarding my experience with pricing, although I'm not the chief decision-maker on it, our leader has involved us with making decisions on it as a team, so we'd like to explore more of what Mule ESB has to offer for us.

I am a customer of Mule ESB.

Our legacy systems include the mainframes and all our older applications that are VB based; they all gel well with the Oracle ESB.

I haven't actually delved into real-time analytics for data-driven decision-making in Mule ESB; there's another team that concentrates on that, but I've been hearing good things.

On a scale of 1-10, I rate Mule ESB an 8.

My main use cases for Mule ESB are mostly for enterprise integration.

The best features of this solution are that everything we get into a single platform, whether it's integration, API, or data modeling; everything is available in one platform. It's a hybrid, including cloud and on-premise solutions with good connectivity and good connectors.

From the benefits of using Mule ESB, we could reduce the manual tasks to 50% in one to two years. The cost is still something we are trying to make lower because we see some advantages when we move from point-to-point integration to API-led connectivity. We have seen a lot of reusable assets, so the cost is reduced. Ultimately, we want to see how it's transformed into business revenue; that's what we are still looking into.

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.

I have been working with that solution for seven years.

When we increase the number of applications, the cost is mostly the same, with a 10% difference. When we have a very small solution, the cost is on the higher side, so it's shining at high scalability with high projects.

The technical support team from Salesforce is good.

Positive

In terms of costing, I consider it 50-50; I would not say it's 100% cost-effective because the platform itself is a little costly. We are trying to improve how efficiently we make our ecosystem. It's not only one platform that determines the cost; it's how that platform is utilized in integrating with other platforms, and that's where the cost comes up. Overall, in isolation, it's a costly solution. When we integrate with different systems, it becomes more cost-effective.

When comparing Mule ESB to other competitors such as Boomi or Workato, it is costly. The price difference compared to some competitors is around 20 to 30% more costly.

I would rate the technical support between eight to nine out of ten. I would recommend Mule ESB to other people, but I think it depends on the use case; in general, it's a good product. On a scale of one to ten, I rate Mule ESB a nine overall.

Hybrid Cloud

Other

In my specific industry, using Mule ESB is about connecting and harmonizing data between different applications or systems. This involves efficiently communicating and connecting data between different applications or systems.

The impact of this product on operational costs and revenue generation reflects in the time to market. With MuleSoft APIs, we have completed our work in six months, whereas using specific languages would have taken more time. This is one of our returns on investment.

From the operations perspective, there are multiple benefits. From the business perspective, much of the paperwork that was done earlier has been removed through APIs built using these MuleSoft API workflows. Building these APIs brings the operation costs down.

The features most impactful for my API management include the low-code, no-code concept. We have batch processing for handling large amounts of dataset. They have policy implementation, which is very easy, along with straightforward API designing.

Mule ESB's data transformation supports integration needs effectively. They have their own language called DataWeave, which helps transform data and is efficient enough to handle any kind of transformation.

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

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

The installation of Mule ESB was difficult on Kubernetes.

It was easy on the on-premise and cloud hub, but on Kubernetes it is a bit tricky.

With on-premise installations, it might take 1 day or 1-2 hours, but with Kubernetes, it is different. When using MuleSoft, you cannot only configure MuleSoft. We need to configure Kubernetes first, and then configure MuleSoft on top of it. When everything is set up in Kubernetes, the MuleSoft installation is easy. However, if something goes wrong in Kubernetes, then MuleSoft installation becomes difficult.

The stability of Mule ESB is reliable. It is a stable product.

Mule ESB is a scalable solution. The scalability of Mule ESB can be rated from eight to nine.

The technical support of Mule ESB can be rated from nine to ten. We do troubleshooting and work with vendors, and MuleSoft has its own support and troubleshooting services.

Positive

For the installation, there were only one to two people involved.

I am working with Mule ESB and use both the on-premise and cloud versions.

I am using the latest update, the newest version of Mule ESB.

It is one of the best integration tools in the market. It helps to build an end-to-end API lifecycle management starting from monitoring to governing, designing, and deployment. It provides end-to-end API solution and API lifecycle management solutions. I recommend this product.

Mule ESB helps with AI-driven projects, and I am satisfied with the AI functionality.

My overall rating for Mule ESB is 8.5 out of 10.

Mostly, we use Mule ESB for an integration piece where the source and destination need to be integrated with user-defined logic in between. This integration involves an API-led connectivity approach, which is a major component in MuleSoft.

The most valuable features of Mule ESB are DataWeave, which is the core of MuleSoft, and batch processing methods, such as batch processing for bulk loads and parallel processing for asynchronous tasks.

Improvements could be made in performance. MuleSoft has integrated more than 170 connectors, however, fine-tuning the runtime engine to handle more records in one go, like around 500,000, would be beneficial. More R&D is needed in the MuleSoft runtime engine for better performance.

I would rate it a nine out of ten.

We have been using Mule ESB for nearly ten years.

The product is very stable; I would rate its stability as nine out of ten.

I can give Mule ESB a scalability rating of nine out of ten. It scales very well.

Technical support from MuleSoft is satisfactory, with a rating of eight out of ten. Their response time and quality of support meet our needs.

Positive

For development, Mule ESB has a simple setup process. You simply download a zip file, extract it, and start using it immediately. However, if you want to deploy it on servers, that's a different case and requires following some standards.

Pricing is on the higher side due to licensing costs. It is more suited for large-cap companies that can afford this cost. I would rate pricing as a seven out of ten.

Spring Integration is one of Mule ESB's main competitors. Others include WSO2, although that is on the lesser side. We also consider Dell Boomi.

The main benefits of Mule ESB are its scalability and reusability. In terms of functionality, everything seems to be in place, yet future needs depend on business use cases.

I'd rate the solution nine out of ten.

Hybrid Cloud

Other

We're using our Mule ESB mostly for integration projects for multinational companies that do business on a B2C or B2B basis. We also work with companies with multiple third-party vendors employed under their payroll. The Mule ESB helps integrate data from third-party systems or vendors with the company's systems and all the different platforms associated with a particular company.

The most valuable feature of MuleS ESB is its API-led architecture. It provides a unique, user-friendly, and scalable architecture for hosting APIs. The platform also gives you visibility into how applications are set up.

The API management capabilities are exemplary. You can apply security policies to most applications, monitor logs, and get analytical data on request reception, response generation time, associated APIs, endpoints, and inbound and outbound messages.

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.

I have been working with the product for five years. 

I rate the solution's stability an eight point five out of ten. 

I rate the tool's scalability a solid nine out of ten. 

The solution's support is quick to respond. 

The initial setup complexity depends on the service chosen. If Mule ESB hosts the runtime services and infrastructure, it's easy. Setting up your runtime infrastructure takes more time. There are cloud-based and hybrid deployment options. The hybrid structure uses runtime fabric to deploy applications in Kubernetes. You can choose based on your company's capabilities and requirements.

The solution is expensive. 

I recommend the tool for enterprises. I rate it an eight out of ten. 

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.

Public Cloud

I use the solution in my company to deal with use cases, like certain developments in webMethods.io. I had used the tool to deal with API implementation, which was something that was related to integration with the help of APIs. We used to provide APIs to our partners as an organization so that they can use our API and the logic we have written under the APIs, which can help them get the information they want based on the APIs.

From an improvement perspective, there should be fewer coding challenges for users in Mule ESB.

I have been using Mule ESB for a year.

Considering the developments that I have dealt with Mule ESB, I rate the product's stability a five out of ten since it lacks a lot of components compared to what webMethods.io provides.

Around 100 to 200 people in my company use the product.

I have experience with TIBCO ActiveMatrix Service Bus. I have fifteen years of experience with webMethods.io.

Compared to Mule ESB, you will find that there are fewer coding challenges in webMethods.io.

The solution is deployed on an on-premises model.

A six to seven-member team, including one or two managers, is required to take care of the technical part of the product.

My company had sought help from an integrator to deal with the product's deployment process.

The product offers a community edition that is free of cost. You will not get any support from Mule ESB's team for the tool's community edition. You can get support with the licensed version of Mule ESB.

My company did evaluate other options in the market, considering that we need to start any integration-related discussions by speaking about how complex integration can be for us before choosing the product that can be better for us.

Mule ESB supported our organization with its archiving capabilities, like the way we used to receive support from webMethods.io. My company used to raise tickets with the support team if we faced any issues with the product. If the product's support team were able to resolve our issues with the tool, they would send our company emails with complete solutions to our issues. The support team also used to try to fix our company's issues with the product through share screen options.

I only use the product's API part, and I haven't seen any issues with the product. Owing to the aforementioned reasons, I can't comment on the product's features that I find to be most effective for our company's integration needs. I like the development part of the product. I can't comment on the stability of the product since I used to use it in the environment as it does not move to the cloud. The development was not that easy in Mule ESB compared to webMethods.io, which offers a flow service.

I would recommend webMethods.io to others since I have a good understanding and knowledge of the tool. If people still insist on looking for other products, I need to involve another person who can provide them with the right judgment. Maybe someone who has worked on both of the products simultaneously can be an intelligent person. If you ask my individual opinion, I would go with webMethods.io.

Mule ESB is more inclined towards Java codes. If you are a new user who knows about Java, then Mule ESB will be easy for you to use. With webMethods.io, you can use it even without knowing any coding language. Considering the aforementioned comparison, I feel that webMethods.io is better than Mule ESB.

I rate the overall tool a six out of ten.

On-premises

I manage a team to handle various integrations using Mule ESB and lead the integration practice. We are a platinum partner of Mule, implementing Mule solutions for our clients.

Mule ESB has provided a centralized control plane for distributed deployment, making it a useful solution.

The most beneficial features of Mule ESB are the control plane and runtime plane. Its centralized control plane has been the most useful for distributed deployments. Mule ESB is also faster and easier to configure than other solutions.

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.

I have been using Mule ESB for two to three years.

Mule ESB is a stable solution with no significant challenges.

Mule ESB is highly scalable, both horizontally and vertically. It is easily scalable if the platform solution architecture is designed properly.

There are challenges in getting consistent and adequate technical support from Mule. Other partners are more flexible and supportive during development times. The education level of the support team sometimes becomes a challenge.

Neutral

We work with various solutions for different clients, including both API and ESB solutions. We have not implemented Mule extensively in the banking sector due to preference for on-premises solutions.

The initial setup is not very difficult, but it requires a strong hold and good design to adapt and implement the new system effectively.

We are a platinum partner of Mule, implementing their solutions in various organizations. We have a large implementation team.

The ROI is lower compared to other solutions due to high licensing costs.

Pricing is higher compared to other solutions, and the licensing costs are high.

We work with multiple solutions, including webMethods.

I would recommend Mule ESB to others. It's important to be aware of the costs and technical support challenges.

I'd rate the solution seven out of ten.

On-premises