webMethods.io Reviews

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.

The solution's most valuable features are web services, XML transformations, and adapters.

The solution's release management and JSON services need improvement.

We have been using the solution for 20 years.

The solution is stable. I rate the solution's stability a nine out of ten.

The solution is scalable. We have enterprise customers using the solution. I rate its scalability a nine out of ten.

The solution's technical support needs improvement. It could be more accessible in terms of communication.

Neutral

The solution is easy to set up. I rate the process a seven out of ten. It takes two months to complete. 

I recommend the solution to others and rate it an eight out of ten. It works fast and is easy to adapt.

I'm using the product every day, and I'm working on many different projects. Most use cases are for using webMethods Integration Server as a middleware software or a middleware platform that is connecting to at least two different endpoints. It can be from one side, for example, database, web service, SAP, or any kind of connection, including Salesforce, and the other side can be the same. We are just establishing connections between these systems and doing some transformations and modifications of data in the Integration Server so it can be sent from one side to another.

Clients are mostly using it in order to connect some of their internal systems or to connect to some external systems and some other partner companies. Its benefit is that it's really useful for monitoring and tracking all the activities. And it's important, due to all the flows, all the data, go through this ESB, Enterprise Service Bus. 

The most important thing when using it is that there is a really good community from the producers, Software AG, and the Empower platform, where you can find almost every kind of error or problem that you face. You can find a solution right there in the community.

There is also typical support where you can create a ticket if you are not able to find the issue on your own. If it's something new, then they will approach you and help you in resolving it. 

The best features are these adapters. Software AG developed many different adapters for the usual databases, et cetera. I was not using Salesforce much. However, it's really handy that you have an adapter for these popular platforms. It's just plug-and-play.

When it comes to the user interface, I'm already really used to it. I cannot say anything against it. For me, it's easy to use.

When there is some issue or bug, they work on the development of that. And then, in the next release, they just fix it. I had a few situations when I faced some issues, and then I had to report them. Within the next three weeks, typically, it just gets fixed.

For code version control, you need to use some external software. It would be good to have it just built into the product so that you don't have to use anything external.

The interface could be modernized. 

I've been using the solution for about five years. 

If it's set up properly and if you do it in a good way in large-scale organizations, you need to have a maintenance team that is doing the maintenance and support. If it's working properly and updated properly with the latest versions of updates, then there should be no issues with using it. It is reliable. One of the main benefits of Integration Server is that it is reliable.

Our entire company uses the solution. There might be 100 people using it on a daily basis. 

Scalability is one of the main purposes of the product - scalability meaning that it can adapt to small customers, clients, and even to bigger systems and clients with a lot of data going through the Integration Server. 

Technical support is really good. They are replying really quickly. In a day or two, you can get a response for your issue, or probably even quicker if you mark it as urgent. 

For me, it's fine. I had some contact with Software AG support. They wrote really helpful. And a few times we even had some meetings with screen-sharing sessions so they could help and see the issue. It was really nice. 

I know there are a few really great options on the market; however, I do not have experience with them. 

When it comes to deploying the Integration Server, you just need to follow the documentation, which is really good. The documentation created by Software AG for using and working with each of the products is really nice, and I'm satisfied with that. For the first time you use it, you need to install the Integration Server on Windows or Linux machine or whatever, and if you follow the steps via the documentation, it should not create any issues.

The deployment can be done by one person. It might take an hour or two.

If you are installing many Integration Servers in a cluster, then these things take time to configure the clusters and all other setups related to the network. That said, for the basic product, if you want to use it just for your own purposes, if it's just one instance, it does not take much of your time to get it up and running.

There isn't much maintenance needed after the solution is live. 

The solution was deployed in-house. It's not rocket science. It's easy, and you can do it just by following the instructions. It's a really user-friendly installation.

I'm working in the development part of the company. I'm not aware of the prices.

I would say it's an affordable product. When it comes to big organizations, it's for sure affordable.

We are a Software AG partner.

I'm mostly using the latest version. I was using version 9.9 when I started. Then I was going through all the versions, including 10.1, 10.3, 10.5, and 10.7. Now, 10.11 is the latest one. However, I'm not sure that I started working on that one in any of my projects. 

We are a partner company of Software AG, the producer of webMethods.

New users should look for a list of references and companies that are using this product. 

For a large-scale organization, this is a must-have product. When it comes to Integration Server and the Enterprise Service Bus as the product which needs to be implemented in an organization, it has many benefits like properly monitoring, tracking, and controlling all the flows in the company and outside the company. It's a great product to have.

I'd rate the solution eight out of ten.

Our primary use case for webMethods Integration Server is for our internal application integration. We use it to expose REST and SOAP web services and to connect it with SAP.

We also use it as a bridge to transform web service calls. We'll use an ESB if we want to transform the protocol or the message. It's also used to connect our internal custom-written Java applications with products like SAP, which don't have an open standards interface.

We only use it on-premise. We are considering going to a hybrid setup but at the moment, we don't have it yet. Nevertheless, we still use the Integration Server to integrate our cloud applications. We only have cloud on-premise integrations and not cloud-to-cloud. That is also why we're not focusing on a hybrid setup.

Integration Server does our business-to-business integrations. It does all of our EDI integrations of passing over our Integration Server and our LAN connects to our internal applications.

Its adapters and connectors provide the fastest way to build an integration. We don't need to create our own implementations because we can use the adapters. We can immediately connect to the backend systems without creating a lot of our own custom code by using these adapters.

The vendor's full support for Integration Server's adapters and connectors brings long-term stability to our services because if something changes to the backend application, we don't need to bother with it. Software AG just adapts the adapter and we get a new version. It's much easier working this way.

Deploying a new application is rather easy. You need a deployer and to build a system. We have built something around it to add it to our continuous integration pipeline, but we have the necessary tools to test our production environments.

We use the same system to modify or redeploy these integrations. If we have a bug we'll adapt our codes and deploy a new version. The code changes need the most time. If it's a small code change, then it goes very quickly. If it's an important bug, it'll take more time. The deployment and build don't take a lot of time.

It's a visual tool, so our transformations can be quickly implemented without a lot of fuss. The fact that we have an easy way to expose REST services is also very interesting. It offers the possibility to connect over GMS to synchronize message brokers.

Using an adapter is quite easy. For example, the SAP adapter works very well, and connecting to custom applications is very easy.

We would use MQTT when we need to connect to IoT devices. For the other legacy apps, in most cases, we use the adapters. Acquiring an adapter is quite easy.

Integration Server provides us with application integration, data integration, business-to-business communications, APIs, and microservices. Internally we don't use it for data integration, but it is possible. We don't work with microservices but I know that it's also possible.

It is important to us that Integration Server offers us a broad range of features like application, data integration, and API. It's important to have that kind of broad setup because it's a service burst. It's in the middle of a lot of integrations. It has to be able to have a lot of features

In terms of improvement, it would be better if it adapted quicker to open standards. It took a while for API specification before the last version was available. The spec of version two was rather quick. 

With an integration platform, it sometimes needs to happen faster because you sometimes have clients or providers that already use new specifications.

I have been using webMethods Integration Server since 2011. 

I am very satisfied with stability. It's very stable, we haven't had any issues at all.

We had a lot of issues with our other solution but none with Integration Server.

There are many scalability options, it is possible to add core CPUs to your server or you can add additional servers. Both are possible, both are not complex. The only thing that you need to take into account is then the licensing, but there are no technical issues for scalability.

Technical support is okay. It's comparable with other companies. It of course depends on the kind of issue that you have, but I'm rather satisfied with their support.

We were using IBM before webMethods. We used a combination of the two. When we started we had both webMethods Integration Server only for B2B. We used WebSphere Enterprise Service Bus for internal application integration. It's easier to have only one. That is the reason that we chose one of both. The second reason was also that IBM was deprecating their product and asking to switch to another one. Instead of going through IBM, we figured we could do everything with webMethods which is why we completely switched over.

webMethods had a very good overview of all transactions. That was the main reason we went with them.

The initial setup was of medium complexity. It's new so you need to learn it. A tool like this is never easy. webMethods Integration Server was easier than a different solution that we were using. But it's not a walk in the park. You need to spend time on it. There are configuration settings that can't be avoided. It's a complex feature set. We have had more complex systems also in our landscape. It's not just "click, click, click, done."

I was not involved in the initial deployment. But I know that they upgraded to webMethods Integration Server in a month. It took a few months to learn everything in the system.

We worked with a consultant for the deployment. We worked with a consultant from Software AG which went well. We have also worked with other consultants from consultancy companies that were not directly linked to Software AG but work with a lot of Software AG products. They helped us to set up our webMethods products.

I don't think webMethods is the cheapest but I think the quality is worth it. But it's not cheap.

We're satisfied with our choice and the price is not a reason to look for something else.

It's wise to work with a consultant when you introduce Integration Server because you need to learn about the product. It's better to have advice from someone who already has experience with it.

I would rate webMethods Integration Server an eight out of ten. I'm quite happy and satisfied with it but nothing is perfect.

We use ActiveTransfer to call internal APIs and transfer files from a third party to the cloud for application purposes and from a third party to on-prem. We also send files to the third party sometimes. We have a payments system and transfer files across the system to make customer domains.

We have on-prem, cloud, and hybrid deployments and transfer files across all of them. We're working with webMethods cloud, AWS, and Azure. Our eight-member team is using webMethods MFT and other integrations, and we have a shared team to work on multi-technologies, like web issues, Snowflake, webMethods MFTs, etc. 

ActiveTransfer lets us maintain the file in the staging area before we transfer it. After that, we can remove the file to make sure that the reconciliation process is done. Sometimes we will zip and unzip the files, but if we have a GKB file, we often ignore it. 

Some things could be improved, especially how ActiveTransfer handles third-party file transfers. It would be nice to have a native file-watching mechanism for when you're scheduling jobs with a third-party scheduler. 

Currently, we are using an outside file watcher solution to check the files before the file transfer. It checks the location to see if the file is there. If the file is there, it will prepare it for transfer. If the file isn't available, it will send an email it can create a ticket send it now. We recommended adding this file watcher mechanism. 

Also, when we're dealing with massive files, ActiveTransfer requires huge amounts of RAM, but if would be helpful if we could customize the compression and encryption to squeeze that data and reduce the size to save on system resources.

We have been using ActiveTransfer for six or seven years.

ActiveTransfer is stable.

ActiveTransfer is easy to scale and use also, which is why we recommend it. We have a script-based file transfer, but we use it less compared to MFT.

webMethods' technical support is excellent. When we have issues with third parties, networks, corrupted files, etc. we send the logs and they take care of it.

The difference between webMethods and Control-M is that Control-M schedules automation tools and checks to see if the file is there. Our team is currently using Control-M. 

If you use MFT and you've cleared the MFT events, it has to schedule through Control-M because all the jobs running through the solution end to end. Control-M has an AMF advance remain file transfer, where you can create a source and target profile.

Setting up ActiveTransfer is straightforward. I rate it eight out of 10 for ease of setup. As for maintenance, we have a monitoring mechanism in place and an automated process for large-scale transfer. If the current available space at the target is less than 30 percent, we have an alert.

We do it all in-house based on the customer's request. We'll keep all the files in the staging for one week. If necessary, we will remove it or move it to some other location. This kind of housekeeping and maintenance we do.

I'm not aware of the exact cost. That product team at my company is responsible when we need any maintenance, new products, upgrades, etc. 

I rate webMethods ActiveTransfer eight out of 10. They only need to improve a few minor things to bring it to the current market standard. My recommendation to webMethods is to add more flexibility to the file-watching mechanism to reduce the load on the RAM and CPU to a minimum, which will help when we are dealing with large numbers of massive files, especially in the retail environment.

We used to deal with millions of small files. When you are dealing with these kinds of files, you need to ensure that there is an internal reconciliation process. When you're reading and transferring thousands of files, you use a parallel instead of sequential mechanism to ensure all the files reach a target and that the reconciliation process is done automatically.

We had quite a heavy use case in terms of transactional traffic, and webMethods was quite fantastic in processing all of those workloads.

Some of the key features are the integration platform, query mechanism, message handling within the bus, and the rules engine. We've had a really good experience with webMethods Integration Server.

On the monitoring side of things, the UI for monitoring could be improved. It's a bit cumbersome to work with.

I've been using webMethods Integration Server for about five years.

The current version is in our private cloud, and we implemented the same solution on-premises and in the cloud. So, we have implemented a hybrid solution.

The initial setup was straightforward.

We implemented it through an in-house team, and it took about four weeks.

There are no hidden costs in addition to the standard licensing fees for webMethods.

For corporate organizations, it's a very cheap or fairly priced product, but for growing or small businesses, it's quite expensive. These businesses would probably need to consider an enterprise services bus at some point. Thus, from a pricing point, it closes out non-cooperate businesses.

A slightly watered down version would be nice so that small, growing businesses could afford it.

We tried to use Oracle, and it just didn't do it for us. We explored MuleSoft, but it was a little bit expensive because of their pricing model, which is per transaction. So, it was also not a viable option for us.

You just need to find the right skills. In our country, we don't have people with qualified webMethods skills, so that's a problem for us in terms of resources. Depending on where you are from and if you don't deal with resource scarcity, webMethods could be a good option for you.

On a scale from one to ten, I would rate webMethods at eight. 

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.

The API Gateway and 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 SaaS integration etc.

API Gateways and API Management in general first and foremost standardizes and democratizes the Integration problem across all IT domains. API Gateway specifically allows for centralizing all integration interfaces to a simple style and normalizes the patterns of security, access control, cross-domain compatibility across the enterprise. API Gateways also enable enterprise integration across various public cloud infrastructure and enable Hybrid nature of Enterprise IT.

On the API gateway, I would say the runtime metrics that the gateway collects are definitely useful.

The product provides a lot of insights into the operations of the API itself at runtime.

The cloud version of the solution is very easy to set up.

The stability has been good. The performance is strong.

The scalability is excellent overall.

We have found the technical support to be very helpful and responsive when we have questions.

In terms of improvements, maybe on the API monetization side, having users able to create separate API consumption plans and to be able to throttle API execution against those consumption plans at run time could be better. Those are abilities that might need some improvement.

The on-premises setup can get a little complex, needs to be more simplified.

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

The stability and performance are excellent. 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. We find it to be reliable.

We have found that the solution scales quite well.

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 create tickets with the portal on Software AG through Software AG's support portal. They respond within 24 hours usually, and try to resolve the issue quickly. 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. 

They have a pretty good response time and offer quality service. We're pretty satisfied with the level of support.

In terms of setting up the solution, the solution offers both cloud and on-premises options. The on-premise license and setup can be done yourself. That can be a little complex depending on what is the overall deployment architecture that is needed. 

However, 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.

Typically, while the on-premises setup is somewhat 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. 

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 can fluctuate. I don't have the numbers on hand, however, I can say that they're somewhere in the middle in terms of pricing. They aren't the most expensive or the cheapest. 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 a consultant. I work with a consulting company. 

I'm familiar with API Gateway, API Portal, and Active Transfer.

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, kind of like creating an API management layer, and integration, a hybrid integration layer. 

Both go together, especially in data integration, or in application integration and cloud application integration.

I'd rate the solution at an eight out of ten.