webMethods.io Reviews

It interfaces between applications, as well as between the cloud and our existing on-prem applications.

We primarily utilize packaged applications; we don't really have a lot of custom applications. We do have a few custom interfaces, and some vendors may have created a custom interface on their own, but we present a standard integration, a standard enterprise service bus, to connect to.

We're able to secure our front-end website away from our back-end systems using Integration Server. It acts as a go-between. That way, whether we're requesting things from our website or our IBR or our IPT, we can have multiple interfaces. They're secured in their own ways, and they don't have direct access to our back-end databases.

We're a utility company and before we got this application we would actually send out people to the meters to read them. Sometimes they had handheld devices, but sometimes they had to walk up to the meters. When we switched to AMI meters, we leveraged the ability of the solution to talk to each of the meters on a daily basis, as well as to turn a meter on and off in real time.

Additionally, we use the same application to process payments. Before this solution, we primarily had walk-in centers and a lot of manual processes for receiving payments. Very few payments were done online or via eCheck. Now we can have a whole host of payment options, as well as enable different payment vendors to connect. It has automated a lot of our manual processes.

webMethods Integration Server provides a single hybrid integration platform for all our needs. It provides reusability. We don't have to worry about taking each and every point-to-point integration. Now we are hosting a true enterprise service bus, by having a set of APIs that can really be leveraged and reused by multiple vendors and multiple connectors.

Its adapters and connectors provide the fastest way for us to build an integration. We're able to turn things around pretty quickly. I'm sure there are other faster ways that other people have done, but this meets our needs. 

It's helped us to become more modern. It's allowed us to service our customers in the ways that they want. They can now use on-the-phone payments or website payments or whatever way they want to do it.

Internally, it provides a standard way for us to be able to interface with things. Now, we don't have to have unique ways to do so and much more code and numerous ideas on how to do things. We just end up having a standard.

It provides us with ease of modifying and redeploying integrations. We have been able to do that very successfully. It just makes it easier. We were able to put in an Agile framework, which means that as requirements come up and changes are made, we're able to schedule them on a regular basis. But we were doing that for the long-term before, as well.

Its support for the latest standards make it possible to plug in modern tooling. We've used that in several places, especially for IoT integrations. The result has been reduced costs and improved customer satisfaction.

The most valuable feature is its ability to quickly spin up connections between the real-time interfaces, as well as being able to regulate how much traffic moves back and forth between applications. This is important because one of the things that we utilize it for is payments from our customers. We can have multiple customers utilizing the same set of APIs and they can make real-time payments into our system, which is really useful. We don't have to worry about people making duplicate payments or providing incorrect information. And we get that information right away.

Also, the solution has a very comprehensive and versatile set of connectors. I've been able to utilize it for multiple, different mechanisms. We do a lot of SaaS and we do have IoT devices and the solution is comprehensive in those areas. There's a standard utility protocol for talking and several of the applications we have utilize that utility. It's a standard set of APIs, and Integration Server adapted to that right away. For our website we're utilizing standard Wisdom APIs and we were able to create that. The solution is very versatile with all its capabilities and is able to do what we need to do. We even use it for Salesforce.

It provides us application integration, data integration, business-to-business communications, and APIs. We haven't used it for microservices. That range of features is very important to us. It conducts our real-time payment applications, as well as our real-time integrations between our internal applications.

The logging capability has room for improvement. That way, we could keep a history of all the transactions. It would be helpful to be able to get to that without having to build a standalone solution to do so.

I have used webMethods Integration Server for about 12 years.

We haven't had any issues. Everything has been working. We like the new version, the new upgrades. It seems they keep improving upon things. We've put in high-availability and fault tolerant solutions so we have had zero downtime due to the system itself.

We haven't run into any limitations up until now. We utilize it for a lot of different things, but we haven't run into any speed issues or other problems.

We end up talking to our customers using the solution and we have over 250,000 customers. Our internal users don't really even notice it. They just see that everything is up and running and available in real time.

We haven't run into an issue requiring technical support from their side. It's usually something that we have to adapt to or modify. It's usually something internal.

We used eCheck. It was website-based for point to point integrations. We switched to Integration Server to improve speed to market and have a quicker way to turn things around. We also wanted to put in some newer interfaces that would talk to all of our customers.

The initial setup was pretty straightforward. We were able to quickly utilize some templates, things that they already had, to get it up to speed.

We took our time. We developed and deployed our first product in eight months. Then, over the course of time, we were able to add more and more until we had a robust solution.

Our implementation strategy was to look at business needs to prioritize things.

In terms of maintenance, it only requires oversight, nothing too obtrusive. We've got one integration engineer dedicated to all of our integrations and we haven't had any issues yet.

webMethods provided the name of a third-party and then we reached out to them and we got them onboard. The company's name was Kellton Tech and they did a very good job. They're still with us.

We were able to realize ROI fairly quickly because we were able to reduce a lot of the manual work and point-to-point integrations. If you think of truck costs and the amount of gas expense, we don't have to worry about those on a daily basis anymore. Those alone would justify it.

It's a good deal for the money that we pay.

We went through evaluation criteria with three or four vendors and we found this one to be the best. The primary advantages of this solution were the supportability and ease of use. Also, the deployment time was reduced and development was more Java-based.

Start with proofs of concept. Create a few good proofs of concept and get it up and running and you'll be able to escalate things. Make them achievable.

The biggest lesson I have learned from using the solution is that I should have envisioned it a little bit bigger. We had a lot of point-to-point solutions that we could have considered and I think we still have a lot more to go. Also, if the back-end is not available, we should build in some logic that says, "Okay, now that I'm not getting a valid response or any response, I should be able to quickly use a default or turn off some features." We're trying to redesign and re-engineer it for that to happen.

As an overall product and solution, it has met our needs.

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.

One of the most important features is that it gives you the possibility to do low-level integration. It provides a lot of features out of the box, and over the years, it has matured so much that any problem that is there in the market can be solved with this product. We can meet any requirements through customizations, transformations, or the logic that needs to be put in. Some of the other products struggle in this aspect. They cannot do things in a certain way, or they have a product limitation, whereas, with webMethods, I have never faced this kind of problem. When clients come to me with any problem, in about 99% of cases, I say, "Yes, it is feasible to do through webMethods." It has reached such a level of flexibility and maturity. Most of the things are available out of the box, and even if something is not available out of the box, we can customize it and deliver it for a client's requirements.

Version control is not very easy. The packages and the integration server are on Eclipse IDE, but you can't compare the code from the IDE. For example, if you are working on Java code, doing version control and deployment for a quick comparison between the code isn't easy. Some tools or plug-ins are there, such as CrossVista, and you can also play with an SVN server where you have to place your package, and from there, you can check, but you have to do that as a separate exercise. You can't do it from the IDE or webMethods server. You can't just right-click and upload your service. CrossVista came up with a solution, which was with the upgraded version of webMethods, but even that was lagging. CrossVista was a bit delayed in coping with the new versions of webMethods. Many times, we get into a situation where we want to know who made a change, when it was made, and how it was before the change. When something that was working well previously suddenly stops working, we want to go back and see who made that change, but because of these version control restrictions, we have to take a longer path. We have to go to the version control system. There is no direct feature in webMethods for that.

There should be more visibility. Currently, Software AG has multiple tools. They have webMethods, and then they have Terracotta as a different product. They have an API governance tool as a different product. They also have Trading Networks. Some of the tools have a very good UI, and some of them don't. For example, earlier, there was a message broker, and you were able to visualize what is happening to a document on the server. You could plug in a broker and see everything. You could see the number of documents that are there on a broker. You could see different queues and topics created. They then moved to Universal Messaging, which is a nirvana-based universal messaging solution. Now, the plug-in is gone, and from the MWS server, you cannot see what is happening in UM. A different view is created for that in Enterprise Manager, which is a desktop UI application. It is not a browser-based application. So, sometimes to monitor different tools, you have to go to different screens. Everything can't be monitored centrally. If you have MWS, not everything is on MWS. Command Central is a different screen altogether. There should be a centralized UI on which every component can be plugged in so that it's easy to control, view, and monitor everything. That's what I really want to have. The Universal Messaging Enterprise Manager is especially very difficult. Sometimes, it takes time to launch on your desktop. It is basically a desktop application, and you need to have a powerful laptop or hardware to launch it. They should make it a browser-based solution.

Their support could also be improved. They could be more responsive and quicker.

I have been working with this solution for almost 12 years.

Its stability is very high. It is very stable, and I've never seen it crash. In my 12 years of career, there have been hardly one or two instances where there was an issue, but that was also because of some issue in the development where we had memory leakage.

Its scalability is good, but you have to plan it in advance. When you are designing your overall infrastructure architecture and delivery framework, you need to put scalability at the core of it. Once your infrastructure is set up, it's not very easy to scale it up or down.

Most of the time, admins interact with the support because they handle day-to-day installations or upgrades. I have had some experience with them. I don't have much experience. I hardly had one or two instances where I had to interact with them. It was not very smooth. It was okay. I ultimately managed to get support, but it was not very straightforward. The ticket lingers on for two days or three days, and there are multiple reassignments before it reaches the right party. Based on the little experience I have had, I would rate them a three out of five.

I have not got a chance to work a lot with other vendors. The first ESB I used was OpenESB, which is Glassfish-based. It was ultimately owned by Oracle when they acquired Sun. I used it back then. I also got a chance to work a bit on microservices and Apigee. Microservices are based on Spring Boot. So, it is a Java product. Apigee is an API governance tool. It is now a Google product. 

Apigee is a very good tool for API management, but a lot of scripting and coding skills are required. You need to be a genuine coder, and you should have an understanding of JavaScript, Python, or whatever else you are using to work with Apigee, whereas with webMethods API governance, even if you're working as a developer or designer for the integration server, you just need to know the basic concepts of programming. You do not need to know .NET, Java, etc. You just need to know about the integration. You should know how a web service works, how an API works, and how SFTP works. The tool itself is based on Java. It also uses Eclipse IDE. It has similarities with Java. If you feel that something is not achievable through what is provided out of the box or you want to do it in a slightly different or optimized way for your requirement, it gives you an option to write a Java service. There is an option to write Java code, but as the product is becoming mature, the requirement for a Java service is becoming very less. The product is evolving based on the learning of the user experience. It is evolving based on the problem statements and the scenarios where the product was not giving sufficient solutions. They kept including any missing functionalities in the new versions. That's why now the requirement to write a Java service is minimal. In a team of 100, if you have two Java resources, that is more than enough.

It depends on what role you are playing. Are you working as a developer or are you working as an admin? For a developer, it's very simple. It's not very complex. You just need an Eclipse-based designer IDE and a browser installed on your machine. That's all. You are all set. However, as an admin, you have to install and maintain all the components. You have to install the patches, and updating these versions is not very smooth. The update manager that they have provided is not very accurate. Sometimes, it fails. If it fails in between, it is very difficult to recover from that failure. So, from an admin's point of view, it is a bit difficult, but from a developer's point of view, there is nothing much.

We generally have webMethods Integration Server on-prem. We are deploying it on-prem, and there is a deployer, and there is also a webMethods IO component, which is more cloud-based. The VM on which it is installed could be hosted somewhere on the cloud, which is a different story, but the product itself doesn't have any cloud capability where you can directly put it on a cloud provider host.

I would rate it an eight out of ten.

The API Gateway and the Portal go together. It's not one or the other. Essentially they're just leveraged for overall enterprise API management facilities, being able to go on the API development life cycle, being able to go on the API run time, API monetization, things like that. Usually, most organizations, most of our customers use APIs to supplement other architectures, typically microservices, based application architecture, and so on.

On the portal, the user management and the API life cycle management are definitely robust. 

They have nominal features for API. They have a self-serve API portal as well. That means consumers for APIs can come onto the portal and learn about various APIs that they can put into the consumption model. 

The initial setup of the cloud version of the solution is very easy.

The solution can scale.

The product is quite stable.

Technical support is responsive and quite helpful.

We have found the pricing of the solution to be fair.

On the API monetization side, being able to create separate consumption plans and throttle all those consumption plans towards the run time. Those are abilities that might need some improvements.

The on-premises setup can be difficult.

I've been dealing with the solution over the last three or so years at least.

The stability and performance are definitely very good. 3G really comes strong on an enterprise-scale in terms of stability and performance. It doesn't crash or freeze. There are no bugs or glitches.

The solution can scale quite well. A company that needs to scale can do so.

API management is all about internally leveraging the software development life cycle, across various domains. Typically, most customers, when they adopt API management, they are delivering it for their entire IT software development organization, not just the integration team. The application team and the database team and so on will also use it. Everybody will be on board. Sometimes we have seen customers onboard about 60, 70 developers and then maybe a few additional external consumers. However, we also see some customers with very small teams of around 10 people. It works well for both.

We've dealt with technical support in the past. There's always that possibility, especially with newer versions, that we might run into some technical issues. However, tech support and issue management are both pretty straightforward. 

You can now create a ticket on an issue with the portal on Software AG through Software AG's support portal. They respond within a day, and at least try to resolve the issue. Sometimes the issues might need a product or a quote fix, which might take a day or two. Otherwise, they might be able to look through the knowledge base and give us a solution immediately. In general, they have a decent response time and a decent quality of service. We're satisfied. 

In terms of setting up the solution, there are two ways. The first is that you can have an on-premise license and set up this conference yourself. That can be a little complex depending on what is the overall deployment architecture that is needed. On the other side, webMethods API also comes in a cloud form, the webMethods.io, and that is just a subscription. Most of our customers can just subscribe to it and they don't really have to worry about the setup. Everything is already pre-set.

Usually, while the on-premises setup is fairly complex, we don't really require people to be continuously monitoring it once it's launched. The setup itself might take less than a week or two, depending on the size of the enrollment. In terms of maintenance, unless there's a lot of APIs subsequently developed and running, you don't really have too much. Once the customer starts developing a lot of APIs and puts a lot of those APIs into production, that's what will contribute to the support and monitoring needs of the team. Typically one person can handle deployment and maintenance. Of course, the cloud doesn't really require the same amount of work. 

The pricing fluctuates. I don't have the numbers with me, however, I can say that they're not the cheapest in the market, and they're not the most expensive either. They fall right in the middle, and they're priced right for their capabilities and the quality of service as well as the stability and performance on offer. They're well priced for their general offering.

We are partners with Software AG. We've been a partner for more than 20 years now.

I'm an IT consultant. We are a consulting company, most of my teams are certified in Software AG technology, and we've worked for a lot of customers leveraging that technology.

We typically deal with the most up-to-date versions of the solution, although occasionally, one or two might be a version behind.

A lot of the API Portal and Gateway form the layer of API management, however, usually, API management does not go on its own. There's typically some level of an integration layer behind it as well. Either a customer is applying an API management layer on top of an existing integration layer, or, if not, a customer is starting fresh and has to apply both layers subsequently, or consecutively. It's kind of like creating an API management layer, and a hybrid integration layer. Both go together, especially in data integration, or in application integration and cloud application integration.

Overall, I would rate the solution at a 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.

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. 

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.

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.