webMethods.io Reviews

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.

I have used webMethods Integration Server in a variety of roles over the past eight years, starting as a developer and progressing to integration specialist where my work entailed building enterprise solutions to process a lot of data (millions of records each day) using event-driven architecture.

Our primary use case is retail integration where there are a lot of orders being placed daily, and where all the inventory needs to be updated in the centralized system. It's mainly in the retail and banking sectors, or anywhere transactions may play a crucial role, where I have used webMethods the most in my projects.

Typically, it is used where data has to be going to multiple systems on-the-fly, such that there will be minimal latency. For example, in an event-driven process where there is an action trigger for a piece of data or record to be forwarded to multiple systems when that action has been triggered.

The latest versions I have worked with include 10.5 and 10.3, however at the moment and for the past year I have been working with MuleSoft more than webMethods.

Our infrastructure is mainly on-premises, but we are starting to move to the cloud. Our target is to move everything to cloud, and right now we have a few instances on-premises and a few in the cloud, hosted privately with Microsoft Azure.

As for users, we are not directly exposed to the clients or end-users. Instead, we are mainly part of the middleware layer, whereas many of our customer-facing portals are different and distinct from one another. If we counted from one portal, the users may go into the thousands or even billions sometimes. It depends on the transaction type that is involved. For example, if you take any store of the multiple stores in operation, we will get a daily number of orders and that number of transactions will go through our system. Ultimately, it differs from region to region and client to client, but the numbers on any store can be from thousands to 10,000 or more.

One valuable feature is that it is event-driven, so when new data is available on the source it can be quickly processed and displayed. Integration is definitely another useful feature, and B2B is one area where webMethods has its own unique thing going, whereby we can do monitoring of transactions, monitoring of client onboarding, and so on.

There are many valuable things from an EDA perspective, and webMethods helpfully supports a lot of formats. Considering their market strategies, I think webMethods has it all. And now there is webMethods.io, which is a complete cloud-based solution provider. Unfortunately, they are mainly known in the market for their broker transactions, and this is a perception I believe needs to be overcome.

Lastly, although I'm not too sure about the latest features, I believe they also have a service designer now, where you can work out the particular package that you want. 

The certifications and learning resources are not exposed openly enough. For instance, they have a trial version which comes with only a few basic features, and I think that community-wise they need to offer more free or open spaces where developers can feel encouraged to experiment. Perhaps they can work on maintaining more of a community in order to build up a better knowledge base, which is exposed on the free plans and not tagged to a particular paid version.

Otherwise, I think they have already built all the solutions as an individual component, so what they have currently should be fine. Based on the market, the new features should come up as usual, and I hope to see a lot of connectors become available with regard to NoSQL databases, Salesforce, CRM systems, and so on. And with these, I mean plug-and-play types of connectors, where we can easily experiment and see which products work well in the integration scheme, and which will help us decide whether to go with webMethods or not.

I've been using webMethods Integration Server for over eight years.

Compared to on-premises, the cloud solution is not as stable. These days I see a lot of network issues and cloud servers going down, becoming unreachable for whatever reason.

The cloud plays a major role in its scalability. When it comes to on-premise, it's not that scalable, as you will need to have a server and a standard process around that which will reduce the delay. In general, it's not that easy to get a system scalable when it is on-premise, especially when compared with the cloud as it's much easier to scale a system horizontally or vertically with any number of resources.

Their support is always good. We used to have regular meetings with the vendor where they explained things and gave details about new features and products that are going to be launched down the line. And if there are any product bugs, we align with their support to get things sorted out. We have a good relationship and approach with the vendor, who adheres to their SLAs.

The initial setup was more of an administrator task, so I did not participate in it directly. However, as far as I know, the software that comes with the installer is a complete package so we just needed to install it. It does require a bit of information which needs to be addressed prior to getting installed, though.

When it comes to code deployment, the code and packages that we work on go through the servers with CI/CD pipelines.

We do our implementations in-house only, with the help of automation. The number of engineers needed depends on the requirements for each project. At this moment, there is one person who takes care of the automation and troubleshooting of issues because it's all centralized and we don't have a dedicated team to do the deployments.

As we are all into different sectors, we typically release with all the teams together, and the release window doesn't account only for the team or the tools we're using, but it is also dependent on the complete functionality desired. So when there is a deployment planned with other teams, everyone has to release their code and do a round of testing, and then validate if everything works properly. It has multiple verifications and if something goes down then we have to report it. As such, I don't give timelines because it depends on the release, but typically webMethods' package deployment doesn't take that much time unless there are network issues.

I am not involved in the licensing side of things.

Whether you decide to use webMethods largely depends on the architectural landscape that the customer is looking at, and in particular what kind of flow data they want to process. It's always a matter of first getting the customer requirements, and then going with the tool that is easiest to implement and use.

Overall, I would rate webMethods Integration Server a seven out of ten.

We use it to manage and secure APIs. It is particularly useful when dealing with a large number of APIs from various systems like banking, government validation, and more. It makes sure data is accurate and protected and helps systems work well together.

What I like the most about the solution is that it comes with ready-made tools like handling security tokens and OAuth. API Gateway does the hard work of keeping things secure and managing who can access what, making it easy and safe without lots of custom work.

One area for improvement in webMethods API Gateway is orchestration. Currently, API Gateway lacks built-in orchestration capabilities, so organizations may need to rely on other applications for this purpose. For example, if you are calling two services and one of them fails, you may need another application to handle the rollback or recovery process. Improving orchestration within API Gateway could simplify complex service interactions.

I have been using webMethods API Gateway for almost two years.

The technical support is a bit slow. It took them more than two weeks for a single ticket. I would rate it a seven out of ten.

Neutral

Setting up webMethods API Gateway can be easy or complex. It depends on what your company needs.

It is an expensive solution and not very suitable for smaller businesses.

My advice to people who are considering using the solution is to keep in mind that if you have a background in software development, especially with Java, you will likely find it easier to work with the platform. Overall, I would rate webMethods API Gateway an eight 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.

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.

We had multiple integrations in our internal applications. The webMethods Integration Server is integrated internally, plus we have integrated it with external entities depending upon SOAP, and REST. Additionally, there is some legacy system we have connectivity with.

The most valuable feature of the webMethods Integration Server is the built-in monitoring, auditing, RETS, and SOAP services.

I have been using webMethods Integration Server for approximately two years.

webMethods Integration Server is stable.

The scalability of the webMethods Integration Server is good. You can scale out by purchasing extra licenses in the new nodes.

We provide a public service, we have more than 1,000 users using this solution.

The support is good but they could improve by being faster and more knowledgeable. I only have one incident in which I needed support. However, I fixed it myself because it was taking too much time for the agent to understand my issue. The agent was not able to handle the issue. During the communication, I found out about the issue, and I fixed it myself.

I rate the support of webMethods Integration Server a four out of ten.

We were using MuleSoft previously. We move to webMethods Integration Server because there was no local presence for MuleSoft.

The initial setup of the webMethods Integration Server is not easy but it gets easier once you know it. It is tiresome but not difficult.

We deployed webMethods Integration Server for our development and staging, and then we moved on to production. Regarding development and staging, there are single servers for production and we have multiple nodes for each.

We did the deployment of the webMethods Integration Server in-house. We have a team of eight that does the deployment and support of the solution. One is an administrator for the management and the others are developers.

webMethods Integration Server has a very good API gateway. It will help your development become easier, because most of the services, we do not have to make any extra changes. We can do it by the gateway. I recommend that the portal which is on the front-end be the gateway, and on the back-end is the integration service.

I rate webMethods Integration Server an eight out of ten.

I like the solution's policies, transformation, mediation, and routing features.

The product should provide more customization options. Application of policy management is not easy. We have to do a lot of customization and configuration. Documentation is also a problem. Understanding the overall architecture is difficult.

I have been using the solution for five years.

I rate the solution’s stability an eight out of ten.

I rate the scalability an eight out of ten. Ten people in my organization are using the solution.

I rate the ease of setup a seven out of ten. The installation is pretty much easy, but there are some obstacles. The interoperability of the components is not that easy.

The time taken for deployment depends on the knowledge of the people deploying the solution. Three to four people from our organization took about a month to set up the entire stack. It had a lot of components. It had an API portal, Command Central, CentraSite, Trading Networks, and Active Transfer.

I rate the pricing a ten out of ten. The product is very expensive.

I am using the latest version of the solution. The improvements depend on the vendors. MuleSoft has got different areas of improvement. Software AG has different areas of improvement. We are planning to move the product to the cloud. My advice for the product users depends on their business model, the scale of their business, how much volume they have, and what kind of transaction management they need. Overall, I rate the product an eight out of ten.