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.
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.
ESB is middleware for interacting with multiple heterogeneous systems. Our most critical use case is ensuring the connection is ready, systems are interacting seamlessly, data conversion is happening, and the business logic is being applied.
The solution is the middleware between the producer and a consumer, and we ensure that the producer is creating the data according to the consumer's requirements. If any orchestration or any transformation is necessary, then MuleSoft performs that.
I'm not using ESB directly. It is the integration layer, so it's running under the hood. However, the conversion and transformation performance is excellent. Anypoint Enterprise Security is also solid.
I've been working with ESB for two years, but I'm not exposed to the coding or developing aspects. It is part of the integration layer, and I deal with middleware integration testing.
Mule ESB's stability is also good.
We have a four-person DevOps team that performed the initial setup, so I wasn't involved, but I think the deployment would be smooth and straightforward because it's on the cloud.
Nine out of 10. It's one of the better open-source tools for development. It provides seamless support and transition. I give it a high rating because most organizations are using MuleSoft.
IBM and Oracle are also in the middleware market. MuleSoft is open-source and readily available, so people can meet their needs easily with this tool. We have a REST API with minimal integration and configuration, so we can easily use this solution.
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.
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 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.
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.
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:
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:
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 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.