We had different use cases such as point-to-point, and public subscribers. We have some APIs building business Message Broker and we have divisions such as the legacy mainframe.
We pretty much use everything. Most of the integration is done with Message Broker.
Working in retail we get a lot of traffic on Black Fridays and Cyber Mondays, and during that time, whatever serves have been deployed we want to scale them vertically.
We can create multiple nodes within the service itself and when we are not using it, we can stop all of those nodes.
Most of what we have is on MQ for communication, and it integrates well with MQ.
Before the cloud, it was very easy for us to build and it was quick to integrate.
Integration and mapping are easy, which is a major advantage.
It integrates with MQ.
Scaling up and down is easy for us using execution groups and nodes.
It is easy to set up and deploy.
If you want to connect to the database, it provides solutions in India, but you have to purchase it separately. They are not mature enough and we have difficulties using them. They are expensive and not worth the money we are spending on them.
I feel with IBM, when you want certain functions or features, you have to continuously purchase add-ons.
Scalability needs improvement, it was easy to scale before microservices and Docker.
Technical support is good but they could have a better response time.
I think that they should provide us with some kind of capabilities that can be deployed. For example, if they have integration nodes that can be deployed separately instead of having a new, big server that has different components, to give us the capabilities to deploy everything on our own instead of building them up together. It would benefit us when it comes to scaling and building.
We have been using this solution for seven years.
We started with Version 7 and now we are at 10.
We are planning to use Version 11 and move to the cloud. It's still in process.
I would say that it's pretty stable, we have quite a bit running on it. It depends on how we configure it or what kind of infrastructure we are providing. For example, if we migrate from an old version to the new version and it's not done properly, you will experience it crashing every time. We had to build properly around it to achieve the proper results.
If it is being used with a simple deployment or as a server, without doing a proper configuration, then it may not work well.
It was scalable before microservices and Docker. It is now looked at differently. With the new version of Message Broker, it's promising to get capabilities that we can use.
We have a team of 10 to 15 developers, senior developers, and leads who are using this product.
Technical support is really good.
I would rate them an eight out of ten because it goes from level one, two, or three and sometimes it takes time, based on the priority of the ticket that we are creating.
Previously, we were using Profusion. It was along the same lines as IBM WebSphere Message Broker. We ran into many different issues and at one time, we were running two solutions, Message Broker and an Oracle solution. Oracle has a database with different capabilities. It records every question that comes in. It was very difficult to maintain, and it just kept crashing and consumed the memory.
It has so many issues, we stopped using it and went with IBM WebSphere Message Broker.
If you compare it with the previous versions, this was pretty straightforward and easy to set up.
There are always additional fees.
It's a good solution but it's questionable now that microservers have come into it. I can't really comment on whether I would recommend this solution for those who are looking to implement this solution, because everyone has their own use case.
I would rate IBM WebSphere Message Broker an eight out of ten. I had a good experience with this solution, and have not had any issues that we could not fix or handle.
Our primary use case of Fiorano ESB is to expose our core banking APIs. We use Finastra's Fusion Equation, which has its own API layer and runs on an IBM machine. Nowadays, this generation of developers isn't familiar with API structures, so we converted the ESB, which is now working as a middle layer to expose all related core banking APIs via web services. The deployment servers are implemented on-premises, but the configuration is done remotely.
One of the most valuable features is the scalability. Whenever it's required, we can add more servers and scale. We can actually use specific servers for specific stuff. Unlike in other solutions, now we can implement one server purely dedicated to core-banking-related API. This is very important when it comes to the PCI DSS certification.
Fiorano ESB could be improved by becoming more user-friendly. Most of the pages and generated reports on API usage are already there, but they could be more user-friendly. There could be more selections added to generate reports. Overall, though, Fiorano suits all our needs and has good functionality.
I have been using this product for over a year and a half.
This product seems stable, and there haven't been any incidents where I have had to conduct maintenance. We're new to this, so there is still some tweaking we need to do, and there have been some instances when we expose something to the other party and they find it difficult to get the information. So when it comes to fetching information, sometimes they complain it takes time, so we just have to optimize the process. It's an ongoing effort, but we haven't encountered any major stability or performance issues with the product.
We have tried to scale it. We implemented it with two or three servers and we recently added one more. Because of the pandemic, most transactions are happening online. At the moment, we just encourage our business to capture more fintechs to come on board to work with the bank. So to accommodate this, we had to add one server.
There have been some questions and clarifications we have contacted Fiorano's technical team about. They are very helpful and whenever we raise a query, they answer it very quickly.
The initial setup process was very simple—we aren't going to implement anything complex because those are hard to maintain. Since we have limited solutions, we prefer to implement simple processes.
At the moment, there are two people working with Fiorano ESB. They handle integration with other systems. For example, if we want to integrate with our internal system and expose APIs, only two people handle it. Once we expose the APIs, we provide the relevant documentation to the relevant party so that they can communicate with the ESB, and it's done.
We implemented through a vendor team. When we exposed APIs to connect our core banking APIs to web services, we had an agreement on the number of services that would be done by the vendor. A certain amount of API exposure was done by the vendor and another amount by ourselves, so it was a hands-on experience. We handled the rest with the vendor's support.
I don't know the exact numbers, but in our Sri Lankan market, the price is very reasonable. To my knowledge, there was only one other Fiorano ESB implementation in Sri Lanka before our bank. They were keen on working with us because we are a relatively large bank, so they must have given us a better price because of that.
We also evaluated IBM Integration Bus. When it comes to price and usability, we felt that Fiorano was much more suitable for the bank, which is why we implemented it. We have a limited technical team and IT development staff, so we needed a solution that's very easy to maintain.
This solution is for online transactions, so it's working 24/7 at the moment. If you are considering implementation and your core banking or other products are running on an IBM platform, Fiorano is the best partner for the platform.
I rate this solution a nine out of ten because we are satisfied with the product.
We are an IT consulting company and we have built our security on Mule ESB. We work for different customers for whom we develop projects for application integration using MuleSoft.
Our use cases involve connecting backend systems like Salesforce, SAP, and other custom applications. We also expose these APIs to external customers. We have also integrated it with a system of engagement, for example, Qooper.
The most valuable feature for Mule is the number of connectors that are available. There are a lot of connectors to different systems so if you want to connect to SAP or Salesforce, there are readily available connectors that are of great help. It saves a lot of time using this system.
The level of integration that this product offers is quite far ahead of the competition.
They have a very strong developer community, interacting at an informal level on a daily basis.
MuleSoft is not so strong in method-based integration, so they're not so functional in that regard. It seems that it has not been their priority.
We have been working with this product for about a year.
No problems with stability have been brought to my attention, although once the system is in production, a different team handles it.
This product is hosted on the AWS cloud, so it has inherent scalability.
We have implemented this solution for between three and five customers in the past year. It is suitable for medium to large companies, where we have clients in each category including some that are quite big.
They have a wonderful, modern concept of community-based support. It is not a formal meeting. Rather, they often interact using technologies such as WhatsApp. They share problems and get solutions from all over the world. Surely, this is a very strong area of MuleSoft.
Some of my team members have worked on other ESB solutions in the past, but in this organization, we have not dealt with one other than MuleSoft.
One of the products that we are familiar with is a solution by IBM. This competing product is strong in terms of method-based integration.
The initial setup is very simple. The installation probably takes four hours, on average.
Our in-house teams do the implementation for our clients.
From a developer's perspective, it does not require much effort for maintenance. After we develop, the DevOps team takes it over for deployment and maintenance. When it comes to issues in production, my team would not be responsible.
I would rate this solution an eight out of ten.
