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.

Positive

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.

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.

In my company, the solution is used for SAP Integration.

The connectivity that the tool provides, along with the functionalities needed for our company's business, are some of the beneficial aspects of the product.

The feature I found to be most beneficial or valuable for our company's workflows revolves around the area of the broker functionality provided by the product since it has reduced a lot of effort.

The main reason my company decided to replace webMethods.io Integration is because of the integration capabilities in the newer versions of the tool. Whenever there is a new version of webMethods.io Integrations, there is a lot of work to be done by our company since the newer versions don't offer seamless integration. The aforementioned reason can be considered for improvement in webMethods.io Integrations.

With the solution, our company has experienced sudden outages at times. The product's stability is an area of concern where improvements are required.

Not just the cost related to licensing but also the cost of introducing new versions need improvement in the product. When you have an OS like Windows or Apple, in which some new features are installed when you restart your system, after which everything works fine, with webMethods.io Integration, the new features introduced in the tool don't just need you to stop and restart your application but expects you to update the whole application to be able to use the new functionalities, which is something that is good. My company does a business in which we have to create a complete project which costs a lot of money. In the future, I expect to not be paying a lot of money or extra work to be able to update the product, and webMethods.io Integration needs to update the product automatically.

I have been using webMethods.io Integration for three years.

Stability-wise, I rate the solution an eight out of ten.

It is not a very scalable solution.

As webMethods.io Integration is a middleware product, it is difficult to provide a number of the solution's users.

I work with many products other than webMethods.io Integration. It was not my decision to use webMethods.io Integration in our company.

The product's initial setup phase was straightforward, but it was a huge process.

The solution is deployed on an on-premises model.

A technical team of eight members, including developers and administrators, is required to take care of the deployment and maintenance of the product.

The product's deployment process was carried out with the help of my company, DXC Technology.

The scenario where webMethods.io Integration is used to facilitate business process automation includes areas where data needs to be automated and integrated from SAP to third-party systems.

The solution helps me in my company with the integration area for some of the systems or applications, but we plan to replace it with another system.

I don't use the API management capability of the product to enhance your integration strategy.

I recommend the solution to those who plan to use the solution.

For my company's business operations, we use the tool's on-premises integration capabilities only.

I have noticed that the product works as expected, considering the fact that I have seen some improvements in areas like data management and quality since the implementation of the solution in our company.

Not just the cost related to licensing but also the cost of introducing new versions need improvement in the product. When you have an OS like Windows or Apple, in which some new features are installed when you restart your system, after which everything works fine, with webMethods.io Integration, the new features introduced in the tool don't just need you to stop and restart your application but expects you to update the whole application to be able to use the new functionalities, which is something that is good. My company does a business in which we have to create a complete project which costs a lot of money. In the future, I expect to not be paying a lot of money to be able to update the product, and webMethods.io Integration needs to update the product automatically.

I rate the overall product a six out of ten.

Today, we work with many financial organizations worldwide, and sometimes they have Legacy software, so we use webMethods Integration Server in those cases. 

We are not resellers, but we provide solutions to large financial institutions, and sometimes we have to work with a lot of legacy software. Sometimes we have webMethods Integration Server as part of the stack. Sometimes we do consulting, and sometimes we take ownership of parts of the projects that large financial institutions have.

webMethods Integration Server is very similar to every integration product in the world, and in the past, we used to write point-to-point connectors with the concept of ESB. We used hub and spoke architectures, and webMethods Integration Server would be used in that context.

Usually, the way large enterprises work is they acquire different licenses over time, so we check their internal IT asset management software in terms of their licenses. If they already have a webMethods Integration Server license, we use that as part of our solution.

Otherwise, we would make recommendations to them on what to acquire in the open market. If the solution is cloud-based, we recommend that they use cloud-based ESB software to integrate different components of their solution. We choose different software pieces, put them together, and ensure that they add value on top of the integration headaches that come when you work with enterprise software.

webMethods Integration Server benefited our organization. If it didn't, then we would not be using it.

What I like best about webMethods Integration Server is its portfolio of connectors. Every integration product has different components to interact with SAP, Salesforce CRM, etc. My organization includes the type of connectors a product has, apart from license availability, usage, and so on, as the criteria for choosing or recommending a solution.

In terms of the feature set, any integration software you use will have to connect different components of enterprise software. Depending on the enterprise software a financial institution, such as a bank, will be using, my company first checks the available connectors in the product, product maturity, and what other solutions can be integrated with the product before making a recommendation to either reuse the product if you currently have a license for it, or purchase a license if you don't have the license yet.

For example, when an enterprise invests in SAP or Salesforce CRM software, that investment is very significant. When you need a form of interaction to exchange data, that's when you use an integration product, so I'm saying that the actual value of integration software, such as webMethods Integration Server, is its ability to connect with other enterprise software.

webMethods Integration Server is no longer that popular because the market has started moving towards cloud-based ESB solutions from Azure, AWS, and other vendors, so this is one area for improvement.

As I mentioned, the real value for any enterprise integration software, especially a proprietary platform such as webMethods Integration Server, will be in the number, quality, and stability of the connectors it has. That is the most critical aspect of every ESB product in the world. Sometimes, what happens is in case a particular connector is not available between a proprietary component within a bank or a financial institution. My organization would have to develop the software components, so what would be ideal is if there was a core set of software that's open source, which would make it easy for third-party vendors and individuals to build components to fill in the gap. This is what I would recommend.

The market webMethods Integration Server falls under is a very crowded market, so for the product to stand out, Software AG would need to get traction in the open source community by releasing a new version or a base version and open source it, so people can create new custom components and add it to the portfolio.

I would recommend looking at Apache ServiceMix or Apache Camel, ESB products, or enterprise software products for integration and looking into the open-source mechanism. MuleSoft is another example, as it has an open-source base version and an enterprise version sold to enterprises. Mulesoft has many open-source components but allows third-party vendors and ISPs to create custom components for customers.

This is the feature set I would suggest for webMethods Integration Server because it's what the product needs to survive in the integration space. Otherwise, other solutions, such as Apache Camel, will take over the world.

I've used the webMethods Integration Server on and off for a long time. The product has been around for quite a bit. I evaluated it once my friend sent me a copy of it a long time back and made me a beta tester for the product. I've used it on and off.

webMethods Integration Server has been around for quite some time, so it's a very stable solution. It's much more stable compared to newer entrants in the market.

For software to be stable, it has to be deployed. It has to be created, developed, tested, and deployed in production. Then, it'll be patched and versioned across multiple years, so the more versions a solution has, the more bugs have been removed in the core system, making it much more stable than newer competitors. Again, this is a case-to-case basis, but you can generally use this as a rule of thumb. The longer the software has been there, the more stable it is.

This is why the backend payment systems are written in COBOL in almost every top financial organization or bank you walk into. Even though COBOL is practically a dead language, it's very stable because it's been in production, and it's been tested, verified, and used; plus, its bugs have been fixed over a long period, so you have very, very stable systems that run on COBOL.

Different people view scalability differently, but with webMethods Integration Server, what's happening is that you have cloud-based tools that make the solution far more scalable.

From a webMethods Integration Server point of view, as long as there's a load balancer in front with clustered mechanism, then it should be good to go. Still, the real key is how much of the transformation occurs in integration scenarios, the volume of transactions, the number of transformations, and content-based routing, which affect performance and scalability.

A good example is when you must put a highway to handle the traffic load it is typically expected to serve. You don't need to make it very, very scalable. If you're integrating the product with internal components in SAP or the Salesforce CRM system, you find out how much traffic typically happens, and you double it. Then you create an integration solution, which you benchmark to see whether it can handle that particular load. If it's going to be a cloud-based solution, you again do something similar, but at a much grander scale. That's when you put a load balancer in front and do all your scalability tricks.

One of the senior persons in Software AG is an old colleague of mine, a junior, so whenever I need webMethods Integration Server support, he'll pass me the name of the chief programmer over there, and I'll talk with him on the phone. In general, the software is good. The service quality is also good, and I don't remember any significant instance or problem I faced regarding support.

The complexity of setting up webMethods Integration Server, or any other enterprise integration solution, lies in the data you connect between two enterprise applications.

For example, you have to ask if you have to link ten SAP modules to two Salesforce CRM modules because that's where the complexity comes in. It's not the fault of the webMethods Integration Server if the initial setup is easy or difficult.

The business context would make the setup more complex, and an ESB tool, such as webMethods Integration Server, is just one piece of that puzzle.

Comparing webMethods Integration Server pricing with other solutions depends on the context. The cheapest will always be open-source ESB solutions, such as Apache ServiceMix and Apache Camel. Still, when you compare the quality of support of enterprise software, such as webMethods Integration Server, with open source software, enterprise software usually provides better support quality and higher level solutions versus open source software that typically doesn't have a real support model.

If you're lucky, you'll get someone who will immediately give you support for your open-source solution, but if not, you'll wait for months without any real support. webMethods Integration Server, on the other hand, as it's under Software AG and has an enterprise behind it, can create one-tier, two-tier, and three-tier support mechanisms, apart from providing you with timely support. Hence, you can use the product as part of an ongoing, much bigger integration project. That's where the differentiation and the value come in.

From an enterprise context, the price of webMethods Integration Server isn't that high because Software AG enters a relationship with companies and provides webMethods Integration Server as part of a much larger solution.

I've been in the IT industry for about thirty-two years now. In 1999 or 2000, a Dutch colleague and I created the entire concept of ESB (Enterprise Service Bus), so I have a long history in this particular space, and I've used all ESB products in the past. Right now, I'm the principal architect of a company that provides multiple solutions to financial institutions worldwide. I use ESBs, such as webMethods Integration Server, as part of the solution whenever there's a need.

webMethods Integration Server can be deployed either on-premises or on the cloud. The cloud is a big misnomer, as it's just a server elsewhere. As long as it's connected over a PCP software network, you can take advantage of it.

I'd tell anyone looking into using webMethods Integration Server to talk to the people in Software AG as the vendor has a portfolio of products. webMethods Integration Server is just one offering, so if you can get good value across a portfolio, go for it. However, you need to do the due diligence and create a pro and a con list for different software solutions available in the market. If you're rejecting open-source solutions, you need to have clear business reasons why. For example, maybe you need immediate support, your timeline is short, or your integration project requires a quick turnaround time. My organization is located in Germany, so it's much easier for it and the customers to work with Software AG and webMethods Integration Server, for example.

webMethods Integration Server is as good and bad as other enterprise products I previously worked with in Europe. No significant problems stood out, so my rating for the solution is seven out of ten.