webMethods.io Integration is a powerful integration platform as a service (iPaaS) that provides a combination of capabilities offered by ESBs, data integration systems, API management tools, and B2B gateways.
| Type | Title | Date | |
|---|---|---|---|
| Category | Integration Platform as a Service (iPaaS) | Jul 27, 2025 | Download |
| Product | Reviews, tips, and advice from real users | Jul 27, 2025 | Download |
| Comparison | webMethods.io vs Microsoft Azure Logic Apps | Jul 27, 2025 | Download |
| Comparison | webMethods.io vs MuleSoft Anypoint Platform | Jul 27, 2025 | Download |
| Comparison | webMethods.io vs SAP Cloud Platform | Jul 27, 2025 | Download |
| Title | Rating | Mindshare | Recommending | |
|---|---|---|---|---|
| Informatica Intelligent Data Management Cloud (IDMC) | 4.0 | N/A | 93% | 185 interviewsAdd to research |
| Microsoft Azure API Management | 3.9 | N/A | 91% | 82 interviewsAdd to research |
webMethods.io was previously known as Built.io Flow, webMethods Integration Server, webMethods Trading Networks, webMethods ActiveTransfer, webMethods.io API.
Cisco, Agralogics, Dreamforce, Cables & Sensors, Sacramento Kings
We've used webMethods mainly as a full-fledged DSP. We had use cases where all the USP use cases, the deployment pattern, were mainly service-oriented architecture. We had patterns arranged from web services, this protocol, and also transformation use cases to convert from XML to COBAL, or XML to external data on to task format and all the different formats, including limited format. We have used webMethods for all these use cases and even connectivity-wise, for web services, JMS and MQ.
From an organizational productivity perspective, before webMethods we had a different product. We were using another tooling from IBM. That had its own problems. Even though we had our own framework and an SOA-based architecture implemented properly, it was not scalable. Integration Server, from that perspective, actually helped us a lot. In the company, we had a lot of applications serving different protocols, and not all products give all features. Since Integration Server, we were able to customize it so we could use one product as a central item, whereas earlier, we had to rely on multiple products.
After the implementation of Integration Server, we could solve most of the connectivity issues. We did not have a problem even today. The implementation has been there for almost seven years now, and we don't have major problems, at least from the capability perspective. Whatever the product did not support, we had the flexibility to build our own frame, own adapters. From that perspective, it was a very good decision to go with this product.
From a user perspective, the feature which I like the most about Integration Server is its designer. If you compare it with other open-source platforms like Spring Boot, even though it is lightweight and you can customize the way you want it, as a programmer if you look at it, the designer is the major feature. You can write your logic with basic knowledge of, for example, programming languages like Java. You have that palette feature where you can plug and play and write the logic that you want. That's the feature I like most about webMethods.
It's customizable. You can write your own adapters. We have customer adapters built on protocols like PCP, Plain PCP sockets, as well. You can write your own adapters framework.
The solution is scalable.
The solution can be buggy. If I compare it with IBM, before webMethods, we were using IBM DataPower. To be frank, DataPower had very, very minimal bugs. You may have one or two bugs in maybe a year, whereas with Integration Server, with customizations, it comes with all these caveats. We had to go back to support a bit for help.
Support is expensive.
There is not any capability as a managed service. Maybe a managed service would help people to use it. Or apart from that, I would also say there is a containerized microservices version, yet it is not in a usable format. If you look at a Kubernetes environment, if you want to have a containerized application running in Integration Server, it's still quite very heavy. Maybe webMethods should look at that perspective as well to run a pure proper cloud-native environment. If you look at Spring Boot or maybe a similar open-source application, you can easily containerize and run Kubernetes. In Integration Server, it's not very easy.
I've been using it for around seven years right now.
The solution can be prone to bugs, especially if you customize it.
Performance-wise it was fine. We don't have any problem in that sense. Stability is related to the architecture and all that, so we had to federate it properly so we did not have any performance issues.
When we started with Integration Server, it was around version 27 or something. Right now, it is around version 40. That's an indication of how many fixes there were. Certain headers were not supported. SSL handshakes had some performance issues and things like that. Those were the kinds of issues we dealt with.
The scalability of webMethods integration server is much greater than the solution we used previously, which was from IBM.
I have worked in applications that have millions of transactions coming in, so webMethods scales very well. We have performance tests done. With just one Integration Server, we could scale up to just one service, and 400 TPS are usually supported, or four under transactions per second. With the current implementation that we have, it has millions of users. We have around 100 developers in the company who have been using Integration Server directly.
Maybe five years back, the architecture model that we were following was maybe a service-oriented architecture. We are moving towards microservices right now. In terms of the Integration Server footprint, there is no plan to increase it further.
We also don't have transformation requirements nowadays, since we are moving towards more API or driven-based architecture.
Support is good. Integration Server can be buggy, and we had to go back to the vendor after a bit. The support was very good, and we get the frequent fixes done. That said, the webMethods vendor support is costly.
Neutral
We were using IBM DataPower. It was good in that it did have fewer bugs.
Before DataPower, we had one more product that was again from IBM. That was IBM WebSphere Message Broker. webMethods is far, far better than that from the capability perspective.
From an implementation perspective, it's a heavy component. From an installing perspective, it is faster. That's not a problem. Installation-wise, there are a lot of dependencies. You need to have a database first set up, and then you need to have all that storage-related things set up, and then you have to install Integration Server on top of it. It takes time.
The current deployment that we have, it's all provisioned, and the CI/CD pipelines are all there. With Integration Server, you may not need to redeploy every time, it's an existing item. We have only three or four people deploying packages, so not more than that. That's mainly not related to webMethods, that's due to the maturity of the pipeline, so we don't have a lot of people there. From a support perspective, there are specialists there. It's a team of around ten members.
We do our deployments ourselves with support from the vendor in case there are any issues. The documentation is self-explanatory and it is quite descriptive; it has all the details on how we have to install it and what are the steps involved, so we can do it ourselves. You don't need any second person to help you.
License-wise, we have seen good returns. However, five years back, the quality of engineers was better. We have since saw a dip in the quality of the engineer for the price service we pay, so recently the ROI is not that good.
I don't have full visibility on the licensing aspect. I know it is very expensive mainly due to the size of the company also. In that way, IBM, which we've used before, is also expensive. From a license cost perspective, it is cheaper than IBM. However, from a support perspective, the software is costlier than IBM.
We needed specialized support from the software vendor. The engineering cost was too high.
I'm an end-user. Currently, I'm using the 10.3 version. Previously, I've used an 8.3 and as well as 9.5 as well.
The version which I have been working on is deployed on the server. Recently, the organization is looking toward deploying it in the cloud as well. However, it's in the pipeline.
If you are looking for a full-fledged ESB, then Integration Server is one of the best choices, as it is highly customizable. So if it's an ESB, then you should go for it. If you're looking for a microservice-based architecture, then it may not be a good choice since it is very heavy. It's not easily deployable and is not cloud-native. And it does not come with all the pipeline capabilities like the CI/CD pipeline. It's all right to scratch. As a new company that is trying to implement that, if they're looking for cloud-native, it is maybe not the best choice. If they're looking for a full-fledged service-oriented architecture, a full-fledged ESB, then webMethods is the best choice.
I'd rate the solution seven out of ten.
