webMethods.io Reviews

Clients choose webMethods.io API for its intuitive interface, promoting seamless interaction and quick communication between systems. The platform's focus on rapid deployment expedites time-to-market, while robust governance features ensure control and compliance. Particularly appealing to less mature clients in API management, it offers a strategic toolset for gradual integration advancement, providing both immediate benefits and a pathway for long-term growth.

A potential drawback of webMethods.io API is its adaptability to legacy systems, which can vary in compatibility. This becomes evident when dealing with diverse products within a client's portfolio, requiring significant time and resources for API integration. The challenge lies in the need for a robust team and cost optimization to bridge the gap between legacy systems and modern API standards. Additionally, the time and effort involved in transforming products into API-ready formats can be a limiting factor. While the platform offers comprehensive solutions, addressing these challenges requires careful consideration and a modular approach for optimal results.

I have been working with webMethods.io API for a year.

webMethods.io API is stable, but its maturity may not meet all customer expectations due to the challenges of dealing with large legacy systems. Achieving optimal results takes time and gradual refinement as the platform evolves to address these considerations. I would rate the stability as a seven out of ten.

Scalability is webMethods.io API's strong point. The solution is designed to scale seamlessly, offering flexibility from small to medium and up to enterprise-level clients.

The tech support from webMethods is solid, and I would rate it at nine out of ten.

The installation of webMethods.io API is flexible, offering options for both on-premise and cloud deployment. The customer has the capability to choose either based on their preferences and security requirements. However, a crucial condition for product ownership is having your own cloud infrastructure. Without this, selling the solution may face challenges due to country-specific regulations. It is not just a customer requirement but a regulatory necessity to align with the country's guidelines. The deployment time for webMethods.io API varies based on the scope. For upgrades, it typically takes six to eight months, while total implementations can range from 12 to 18 months. The number of engineers and architects needed depends on factors like chosen modules, domains, and the scale of customer service, ranging from thousands to millions. Once deployed, maintenance is relatively easy.

The solution is on the expensive side in terms of pricing. It follows a yearly licensing model. Clients typically pay for the license only if they have the internal capacity for implementation. However, for a more comprehensive approach, clients often opt for additional services, including implementation, maintenance, and support from the vendor's side, especially when the scale of the project requires a more hands-on approach.

Before choosing webMethods, it is crucial to assess your organization's skill set. The solution is powerful and scalable, especially for large enterprises, but smaller businesses might find it challenging both in terms of cost and resource availability. It is a robust choice for those with substantial needs and the capability to leverage its features effectively. Understanding your organization's scale and capabilities is key to making the most of what webMethods has to offer. Overall, I would rate webMethods.io API as a nine out of ten.

The solution offers a services catalogue that extends beyond monetization, acting as a source for API for external users and entities and monetization.

webMethods API Portal is overall very valuable. It is now a comprehensive API catalogue that serves various purposes, including API assessment and evaluation. The monetization module is particularly robust. It is applied across different sectors, including the government, and is known for its strong performance.     

The improvement needed is related to the model's position. As of now, it seems to be more of a conceptual idea rather than a widely implemented solution. Monetization is currently on the rise, driven by the growing demand for APIs. With everything being provided as APIs nowadays, it's crucial to grasp this concept and establish a robust solution for subscription plans and the price model.

I have been using the webMethods API Portal for the last seven years.

Since webMethods API Portal is regularly used by big enterprises, the performance needs to be the best. There can be no issues whatsoever, so it is stable. 

webMethods API Portal offers extensive scalability. Its primary focus is on catering to enterprises dealing with vast amounts of data or APIs. This solution appears to have certain minimum requirements that enterprises must fulfill to access it or make requests. It seems to be a compatible solution designed specifically for large enterprises managing huge data volumes. I would rate it seven out of ten. 

The support is available 24/7 and they are extremely experienced.

Positive

For APIs and gateways, I have experience with various platforms such as IBM MessageHQ, Microsoft Remote, and an Apache tool. In the case of IBM, there was a registry and certain tools that stood out, particularly the initial versions of the API gateway. These early versions were rather basic and targeted more toward experts or developers familiar with the system. While not the most user-friendly at the time, I believe IBM has likely evolved its offerings to include more advanced and user-friendly solutions. However, I acknowledge that my feedback might be somewhat outdated.

The initial setup is straightforward, but it requires extensive knowledge about the product.

The solution is deployed on-premises.

I don’t have much idea about prices, but webMethods API Portal is not cheap. 

The suitability of the webMethods API Portal depends on the organization's size. It's not appropriate for small or medium enterprises; rather, it's intended for larger enterprises. This is particularly in cases like ours, where it's utilized for managing big data APIs. As an example, we employ it to oversee the government's resources and permissions on a daily basis. This illustrates the significant volumes of data and APIs we handle regularly.

This is an integration tool along with its having IoT applications and data integration applications.

The main benefit of this product is the speed of the development process and the speed of the business. It has a good integration server and a very good API portal. WebMethods has the tools to develop everything you need and the custom code is relatively easy. It makes the development, the product, and the business more efficient. This is a very strong and useful tool.

The orchestration is not as good as it should be and needs to be improved. 

I've been using this solution for three years. 

The stability is very good. 

Scalability is very good on the cloud but a little difficult for the on-prem version because it requires the creation of one integration server and booking the code on a second integration server, and creating a cluster between them. 

I've contacted technical support many times. Their response is very fast and they provide good service. We've only ever had one time where they were unable to solve an issue we had. 

The initial setup is easy. We deploy both on-prem and cloud, and both are straightforward taking less than 10 minutes. For on-prem implementation, there is a deployer and for the cloud, we use OpenShift. The deployment requires one person and the product doesn't require any specific follow-up maintenance. 

When compared to other solutions, we found the task engine to be better in webMethods along with the ease of development. 

I recommend this solution and rate it nine out of 10. 

The webMethods API Gateway is utilized to assist our banking clients in integrating with the bank via the API.

The solution has helped improve our organization by recommending APIs and providing easy-to-use security controls. Additionally, it identifies similarities between multiple cases, thereby avoiding redundant code and implementation.

The developer portal is a valuable feature.

The gateway server itself can improve the message queue implementation by considering the top ten web security controls.

I would like to request the integration of response caching into the memory database, which would eliminate the need to construct logic within the API itself, and instead implement it directly in the gateway.

The price has room for improvement.

I have been using webMethods API Gateway for a couple of years.

I give webMethods API Gateway a ten out of ten for stability.

I give webMethods API Gateway a seven out of ten for scalability. We can scale the solution, but it is a bit complicated since it is not saved in a Microsoft architecture, which would make scaling much simpler.

We previously used Open API and Google Apigee but our organization technically and commercially preferred to go with webMethods API Gateway.

I give the initial setup a seven out of ten. The deployment took a couple of weeks. The deployment required one solution architect and two technical consultants.

The implementation was completed by Software AG.

The price is high and I give it a five out of ten.

I give webMethods API Gateway a seven out of ten.

We currently have 40 people and four developers using webMethods API Gateway.

We plan to increase our usage tenfold within the next few years.

I would advise a POC to see if there is a business case. I suggest starting small and scaling out as required.

We primarily use it as an integration server. We have integration use cases, including B2B, et cetera.

It is reliable and works very well. 

The integration with platforms is great.

It's straightforward to set up. 

Technical support has been responsive when we need assistance.

It is a very stable product.

The solution can scale as required. 

We're fine with the product offering.

It is quite expensive. 

I've used the solution for more than a decade. 

The solution is very stable. I'd rate the stability ten out of ten. There are no bugs or glitches. It doesn't crash or freeze. 

It is highly scalable, to my knowledge. The organization has used it for almost two decades without issue. I'd rate the scalability nine out of ten. 

We have about 100 users on the solution. 

We do not have plans to increase the number of users, to my knowledge.

We've used technical support, and they have been fine. They are very responsive. 

Positive

I had used other products previously. I use this solution since it has a lot of use cases, and the organization chooses to use the product. 

It's easy to deploy. It has its own deployment tool, which makes it very fast. We can use it both on the cloud and on-premises. 

We have a 13 to 17-member team of developers that can handle the deployment. 

We handle the initial setup in-house according to the government model. Our IT team handles the process. 

I can't comment on the exact ROI; however, it is a very useful product.

The solution has a yearly licensing fee. It is very costly.

I'm not sure if there are any extra costs involved in using the solution. 

I'd recommend the solution to others, depending on the use case. There are many factors that would be highly dependent on its success. 

I'd rate the solution ten out of ten. 

One of our clients is a chain management company. They have many APIs which do a lot of integrations, including B2B integrations. For that particular client, our APIs are on APIs check and handing the deals and restock. Everything is hosted on our API gateway. They can use a scan and access those APIs and do operations for sales orders and invoices.

The most valuable aspect of this solution for me has been the configuration-based UI. Once you get the hang of it, it enables you to easily develop an API. In addition, it has many in-built policies that are quite handy. We are also able to write our custom policies. I also like the daily logging option. Another handy feature is Kibana with the dashboard, which outlines the day-to-day operations in great detail.

There are things that could be improved with the webMethods API gateway. One thing is that it's too attached to the integration service and we'd like it to be a little bit more independent. We would like for them to separate operations so that it doesn't rely on the bulky integration server and so that it can be used everywhere. I would like for this to be included in the features since the client I work with always tends to avoid the solution. And if the client does not have existing interfaces with it, they choose not to proceed. 

I have been using this solution for more than 30 years.

I would rate the stability of this solution a 10, on a scale from one to 10, with one being the worst and 10 being the best.

My impression is that this solution is scalable. I wouldn't say auto-scalable because of the on-premises part.

I would rate their technical support a seven, on a scale from one to 10, with one being the worst and 10 being the best. The reason for this rating is that they are good, but they could still be improved. There is no premium support, and the regular support responds within a day or so.

Neutral

I would rate the initial setup process a six, on a scale from one to 10, with one being the worst and 10 being the best. I would say it's not too easy, but also not too difficult. It can be complex if you don't have experience with it and, in that case, you will not find the setup easy. 

For us, the deployment was fast; it took maybe a couple of minutes. One person can do the deployment on their own. The maintenance is done I think quarterly or every six months through patching.

Our model of deployment is on-premises.

I would rate the pricing plan of this solution a seven, on a scale from one to 10, with one being the worst and 10 being the best. The licensing is on a yearly basis.

This solution is a good fit for small, medium, and larger enterprise companies.

I would advise other people looking into this solution to get it because it adds an additional feature to the capabilities of your web method templates. Also, it uses existing web flow services to enable you to leverage your existing services that are already paired on your on-premises system or into the traditional system of your work method.

Overall, I would rate this solution an eight, on a scale from one to 10, with one being the worst and 10 being the best.

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.

The tool helps us to streamline data integration. Its BPM is very strong and powerful. The solution helps us manage digital transformation. 

webMethods.io needs to incorporate ChatGPT to enhance user experience. It can offer a customized user experience. 

I have been working with the product for ten years. 

The solution is stable.

webMethods.io is scalable. 

webMethods.io's technical support is amazing. They have different mediums for communication, such as chatbots, emails, and phones. The response is based on the incident severity. They respond in a day even if the incident is of low severity. 

Positive

I have used IBM Message Broker and Apache. The product is much easier, and you do not need to have extensive knowledge. 

webMethods.io's deployment is not difficult and can be completed in a few hours. 

The tool is worth its money. 

webMethods.io is expensive. We have multiple components, and you need to pay for each of them. 

The product incorporates different layers of security, ranging from denial-of-service protection to IP denial and other features aimed at enhancing security. Given the importance of safeguarding information from exposure and unauthorized access, maintaining strong security measures is our key priority.

The solution focuses on low-code and zero-code approaches. This means users don't need extensive technical expertise. Instead, they can use drag-and-drop functionality.  I rate it an eight out of ten.