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.

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.

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 have a lot of use cases for this product. Initially, when we bought this product from Software AG, it was only for a specific project. But, we did watch for other opportunities where it could be used for integration and that's what happened.

Our business model has many verticals, so it's used across the enterprise. The main function is to provide application integration within the company. We have more than 60 applications and at the moment, it's talking to more than 30 applications and integrating them. In this context, it is used by our sales team and in a lot of automations.

Our second use case is to provide Write as a Service. We write any custom service using webMethods and then expose it to others as a REST service.

Another thing that we use this solution for is managed file transfers.

We have this solution deployed in a hybrid environment. It is available in our private cloud, where it is installed in AWS, and we also have it in our data center.

This solution has improved our productivity and efficiency in pretty much all of our applications. There are some currently-running automation projects where we are going to have to transform data and at the moment, it is being done manually. This is another case where we will implement webMethods to improve productivity.

We automate our sales cycle using API orchestrations. When sales come through, for example, we register them and enroll them in the policy. All of this is done within webMethods and it works well.

With respect to the comprehensiveness and depth of connectors that are available, they have a lot of traditional ones available. They are constantly adding new ones, which is good to see. However, what we found is that we can develop them very easily. Nowadays, pretty much everything is REST so it is easy to develop your own. We do not have a license for many of the connectors. One of them that we have is Salesforce, which was what we had originally envisioned.

Then, what happened when we needed another connector is that we reasoned that rather than buying additional ones, we would instead create our own. Ultimately, we found that it was quite easy to do and in my experience, it is always better to use your own because the out-of-the-box connections have limitations. This is what we found with the connector for SuccessFactors; we were better off building our own because there are no constraints when we do it that way.

This solution encompasses a range of features, which is important to us. We use it heavily for application integration and APIs, somewhat less for data integration, business to business communication, and we are trialing microservices. Although we do not yet heavily use the microservices feature, we do like that it provides it.

We plan to expand our usage of microservices because, in the AWS world, we want to make things auto-scalable. This is what we are playing around with and although we do not yet have it in production, the plan is to use it more.

Modifying and redeploying integrations is easy to do. This has made us more agile and the fact that we can churn things quicker has helped the business.

There are a few things about this product that we definitely like. It is very robust. If you build it nicely, you can't go wrong with it. It's rock solid.

The development is very fast. If you know what you're doing, you can develop something very easily and very fast.

For the latest services, the product is lacking in terms of connectors. For example, there are a lot of SaaS providers and if you look for the connectors out-of-the-box, they are definitely not going to be there. They have a lot of traditional options but they are basic. If you have an advanced use case then you are better to build your own.

For the most part, this solution supports the latest standards and makes it possible to plug in modern tooling and third-party products for automation and innovation. However, there are some things that it doesn't support and we find ourselves having to wait for a newer version. For example, when we were using version 9.10, it did not support OAuth.

In general, I would like to see the vendor release newer features sooner. Or, it would be helpful if we can use a newer feature but don't have to upgrade the entire product.

The UI for the admin console is very old. It hasn't been updated for years and is pretty much the same one that we started with. This is something that could be refreshed and made more modern.

We have been using the webMethods Integration Server for almost six years.

I would rate the stability very high. Once it is running, it's very stable.

The webMethods Integration Server is a tier-one application and if it's down, impacts pretty much everything. When it runs, no one knows about it but if it goes down, everyone screams. It is very crucial.

With our current licensing, it's very easy for us to scale. With our older licensing model, it was very hard. This is definitely something that I would highlight. I'm very happy with our current setup because we can scale and it's more of a constraint of your commercials rather than a product constraint when it comes to scalability.

We purchased a premium support package but to this point, we have not greatly depended upon it. In our day-to-day business, we haven't had to deal with them very often, which is a good thing. We generally resolve things within our team and don't generally need to rely on others. There are only a few issues that we have contacted technical support about, such as when we were having issues with the upgrade. Also, if there is something that we can't find then we will contact them.

In general, when I compare their support with other vendors, I would not rate them high. The customer experience with support is an area that needs improvement. The reason I say this is that regardless of the issue you raise, even if it is not necessary, they ask a lot of questions.  

Prior to webMethods, we were not using an integration solution. We were a .NET shop and we were using it to accomplish the same tasks. However, it was not to the full extent that webMethods is doing because its capabilities are less.

The reason we adopted webMethods is that a new project was coming and when we estimated the cost, we found that developing everything in .NET was cumbersome. At that point, we started to look for a tool and settled on webMethods.

We chose webMethods over MuleSoft because of how quick and easy it is for developing. It is simple and easy to use. The commercials is definitely another reason that we chose it. This was the product that was recommended after the technical evaluation was complete.

We also use webMethods.io, although that does not fall under Integration Server.

The initial setup is of medium complexity, although it depends on your scenario. If you have a simple use case to just integrate, it's easy. The actual installation is very straightforward but we had some complexity because of the zones.

We had multiple DMZ zones and we have a PCI zone. This meant that there were a lot of firewall rules that needed to be created. It was a greenfield project, so we had to build everything in addition to the webMethods aspect. The project was definitely complex. However, the webMethods setup in isolation was very straightforward. If you just focused on, "Okay, this is the one that you have to install." It's straightforward. If you know what you're doing, it's easy.

Upgrading is something that we can't do in a very fast manner. It's not like we are going to upgrade every six months. We have to wait a while. On the other hand, that's where the microservices architecture is good because anytime something new is released, we can upgrade to the latest.

We completed the initial setup in-house.

We evaluated MuleSoft and webMethods. There may have been others but these were the top choices. When we asked for demonstrations, these were the products that we looked at.

This product provides us with a single hybrid-integration platform for all of our integration needs. We do have another product but it is for a very specific use case, and it is separate because of the licensing. Otherwise, webMethods is our go-to for integration.

On the topic of development time, this product can save you time but it depends on what you're comparing it to. For example, if you are comparing it to having no platform, where all of the integrations have to be developed from scratch, then this product will definitely save you a lot of time. The undertaking would be massive. If instead, you are comparing it to another product such as MultSoft, then it will be a different answer. It is tricky to estimate because it depends on the tool.

This is a product that the vendor keeps adding things to. Sometimes, we have to wait until the next version comes out before there is support for what we want to do, but there hasn't been anything major.

My advice for anyone who is implementing this solution is to spend some time thinking about how it will be used. I have seen instances where the product was being used and didn't work properly. If it is designed nicely then it will work wonders, so spend some time thinking about the design and how it will be used and it's never going to have any issues.

I would rate this solution a nine out of ten.