webMethods.io Reviews

We have an open banking initiative in Indonesia. We are mandated by a regulator's bank in Indonesia to open up our services to other institutions, not only banks, but also financial technology (FinTech) companies and startups as well as eCommerce or other industries.
Thereby, they can consume banking services through an API, such as our funds transfers, mobile banking services, or a bill payment, like electricity, water bills, college, and so on, through an API to their applications. It is not obligatory that you need to download our mobile banking in order to do these transactions, but you can do the transaction using other applications, such as the FinTech or eCommerce application that the customer currently has. Those use cases, for the open banking readiness for Indonesia, utilize webMethods API Gateway and standardized services of API for fund transfer, debit credit transfer, bill payments, and opening up a savings account using online applications. Those are pretty much the use cases for webMethods API Gateway in order for us to connect it with FinTech startups, eCommerce, and other institutions who would like to consume banking transactions through Mandiri.

Since we are a very highly regulated industry, which is a bank in Indonesia, we are not allowed to host any financial transaction outside of the Indonesian region. So, the solution must be deployed on-premise inside of our data center.

Are you using multiple products from this vendor?

We are using multiple products to build the end state of our service-oriented architecture (SOA). This is all orchestrated as a big building house. Those SOAs have many capabilities inside of them on the integration side, such as webMethods Integration Server. (Read my webMethods Integration Server review here.) There is also webMethods API Gateway and Software AG Apama. Those modules inside of Software AG complement the building blocks of SOA.

We also use it to complement other products in the markets outside Software AG, such as Kafka as well as all event processing and streaming. This is in combination with the capabilities (and beyond) of what Software AG stacks can do.

I find the native integrations between Software AG products to be very useful from a plain vanilla standpoint. Though, when we implement native integrations, there needs to be slight customizations to fit them into our core legacy system, and that needs to be integrated with other systems. For plain vanilla capabilities, it is sufficient enough.

The native integrations between Software AG products also have good performance in terms of transactions per second (TPS). These are acceptable in terms of the volume and speediness of a transaction that we can produce as well as being combined with the efficiency of using the hardware, memory, and CPUs.

If you combine the commodity hardware and performance as well as the plain vanilla capabilities of internal products that Software AG has, then there is a good price per value.

It gives you a one-stop service for your integrations area. You can really rely on one vendor, then you don't have to worry about sustainability or support. This is all guaranteed by Software AG as a single stop service from them. Whereas, when you need to combine other vendors, then you need to monitor each of their solutions, sustainability, product roadmaps, etc. Then, this becomes your technology liabilities, which is something that we consider. From the integration, we are selecting a good strategic partnership with one vendor in order to maximize our productivity. Thus, we don't have to worry how we can monitor each respective vendor if we do a best of breed combination of many vendors, just to do an integration.

By selecting Software AG and using multiple products, this saved us about 72 percent, which has definitely given us more agility.

Because we were already accustomed with webMethods Integration Server way before the webMethods API Gateway, they were almost the same. We just converted our knowledge from the prior WSDL into RESTful JSON standard messages. Therefore, the learning curve was very smooth because the environment that the developers use was still the same: My webMethods Console. It uses the IDEs coming from that, saving us a lot of time with the learning curve on new technologies.

Within the new version, webMethods API Gateway gives us an end-to-end lifecycle from the creation of the API up into the development, deployment, and promotion into production/live. The current end-to-end lifecycle of the API gives us enough authority and governance of the API. We know what are currently live services, what is in the testing stage of development, and what version that has been commissioned. So, the full life cycle itself gives us full authority and governance of the API.

You can carefully select what services can be consumed by the outside and what services can only be consumed internally. Also, you can see what the fallback scenario is, if some services are customized and what is the impact analysis, e.g., what is the impact to other services that depends on certain services that we are currently automizing. These are very critical capabilities for API implementation in any organization. You do need to have good API governance for it, not only tools, but also all the procedurals. You will need all the standard operating procedures for starting a development of API up to deployment into production.

webMethods API Gateway provides an engagement platform for managing hackathons. Our last hackathon was in 2019. We developed several services in the cloud using a sandbox environment, so it does not connect with our real life production environment. We created some accumulated transaction behavior, so hackathon developers could connect it with our box services within the sandbox environments. It does provide good freedom to host competition in an isolated environment.

At Mandiri, we divided webMethods API Gateway into two layers, the external API gateway and the internal API gateway. The external API gateway is for Mandiri channels and our core partner channel for feedback, eCommerce, and other institutions. With their channel, they like to connect and consume services. webMethods API Gateway gives you a sense of security and quite adequate minimum security to secure services, e.g., DDoS attacks, man-in-the-middle attacks, and queries for SQL injection. These are already built inside of webMethods API Gateway. 

It has a good role definition and scope for its services. Expected channels can only access what type of services, and we can define those as per our contract with prospective partners. So, it boils down to the architecture: How do you like to architect the integration and partnering with other institutions? It depends on that. However, the system itself gives you that flexibility.

webMethods API Gateway gives us a set of rules and good security for securing outside work to connect with our services. It has good minimum security measurements built-in. However, webMethods API Gateway itself has very minimum API governance. You need to have a central site in place to have full-fledged governance, which is one of their modules.

The solution provides a fully customizable portal that has built-in testing and collaboration capabilities. Because it is similar with other well-known products in the market, the process doesn't have specific requirements. We do have a good adoption rate. We only have two weeks of learning and customizing the behavior to developers. By the third week, every developer can actually develop by themselves.

Previously, we had some difficulties with end-to-end lifecycle management of APIs because the product was not yet mature enough. Two years ago, it was not yet mature in terms of the capabilities, which were still separated and not yet consolidated. There were several modules of webMethods API Gateway which needed to be consolidated into one webMethods API Gateway. Previously, they had two separate modules for API management as well as others. 

One of the improvements that need to be added into future releases is the ability to support other third-party monitoring tools. I know that they already support Jenkins, but in Mandiri. We use Bamboo for the deployment as well as part of Jenkins. We also install other monitoring tools, such as AppDynamics, for collecting information on performance and the problems of API Gateway hosting services. 

With performance, there is room for improvement in regards to if we would like to put another extra layer of security on it, such as SSL. This is affecting their performance quite significantly. They need to improve the process of managing the SSL and other things inside their solutions, so there will not be quite such a significant impact to the performance.

With their API-Portal, you need to have flexibility when changing the layout and teams, giving more flexibility to rearrange and do some type of UX/UI that fits into your organization. The API-Portal that comes from Software AG has some of those limitations, with only certain parts that can be fully customized.

We have used it for almost three years, since 2017.

How do you get money from selling or offering your financial services to the other partners or institutions? It comes down to monetization. How do you monitor usage of certain particular protection or usage of services? I do see a lack of capabilities inside of the monetization area for them. They have a cloud infrastructure that is pay per use type of a thing. If you already use 1,000 transactions per se, then you can be charged and billed. I see room for improvement there for their side on that particular capability of the monetization.

We have evaluated other solutions, such as Apigee and MuleSoft, back in 2016. but since we already have Enterprise Service Bus that is using the integration server, which is collecting and managing all the integration services inside, we wanted to see the end-to-end picture of the service itself. It was very logical that you need to have end-to-end monitoring and trend deployment from the service deployment, up into exposing the external world using webMethods API Gateway. We see those advantages from using webMethods compared with other solutions, such as Apigee or MuleSoft, because of the continuation of the architecture. We would also like to expand those into our separating stacks.

In every implementation of webMethods API Gateway, I strongly suggest that you need good API governance. webMethods has their API governance all built inside of your license. It is a continuation between the services using the webMethods Integration Server and webMethods API Gateway, exposing those services into the outside world. You need to have good governance for that.

I would rate this solution an eight (out of 10).

I am using webMethods Integration Server for integrating services mainly, enterprise services bus (ESB). It is a platform for the integration of different systems.

The solution can be used in many industries and different IT systems, such as internal and external databases. We have many dedicated auditors for common projects.

The most valuable feature of the webMethods Integration Server is its reliability. It has a lot of great documentation from the service providers. Additionally, it is easy to use.

This is a great solution and the vendor could improve the marketing of the solution to be able to reach more clients.

I have been using the webMethods Integration Server for approximately six years and I use it daily.

I use the latest version and sometimes older versions.

The solution can be deployed on the cloud or on-premise.

The stability of the webMethods Integration Server is good.

webMethods Integration Server is a scalable solution. There are Microsoft Windows and Linux versions available.

We have more than 10 customers using this solution.

I have used the support from webMethods Integration Server and they have been helpful. The support was able to find the solution to my problems with a fix.

The installation of the webMethods Integration Server is straightforward.

The length of time it takes for the implementation depends on the architecture and how many instances we need to install for the client. However, it typically takes a couple of days.

The implementation process starts with downloading a load that connects to the software. A server takes on the needed components, such as an integration server or universal messaging. You need to follow the integration steps.

We do the implementation of the solution.

There is a license needed to use the webMethods Integration Server.

I would recommend this solution to others.

I rate webMethods Integration Server an eight out of ten.

We use it mainly for policy implementation and securitization when we're exposed outside the internet.

They should develop clear visibility for the onboarding. They could also improve the clustering.

We have been using this solution for three years.

it is a stable solution.

It is scalable and can adapt to third-party integration. We have more than 500 users.

I've worked with MuleSoft, and webMethods API Gateway is the most stabilized tool with a robust integration server. It's a good tool, and it has a stable messaging broker. In addition, from the infra point of view, it is always compliant and not complex. You can integrate everything with webMethods API Gateway.

The initial setup was straightforward and not complex. I rate the setup an eight out of ten.

I do not have details about the pricing. However, it is cheaper than APG.

I rate this solution an eight out of ten.

Currently, we're using this solution for the integration server which helps us to integrate with the mainframe.

This solution could be improved by offering subscription based licensing.

We have been using this solution since 2012. 

This is a stable solution.

This is a scalable solution. 

I would rate the initial setup of this solution a three and a half out of five. 

I would like to have training for my team members, but the training offered is a little bit expensive.

When we started using this tool, we compared it with different tools like IBM message broker and Method. 

Some who consider this solution often avoid it due to its price. Overall, webMethods offers a good user experience and is easy to use for our company. 

I would rate this solution an eight out of ten. 

We have some common services, like REST-based services. We have applications, general social services, and application services. We'll use the solution as a utility to share across the applications selected.

When an organization is, for example, a bank, it can't use an open-source solution - even though open-source solutions are providing more current features. They need to go for a vendor-based solution like this product. 

It's a well-settled, mature platform.

The stability is good.

It can scale. 

We'd like for them to open up to a more cloud-based solution that could offer more flexibility and maybe a better rules engine or more integration with rules engines. The rules should also be more centralized. 

We'd like to see more documentation. We feel like we may be missing some things and would like some documentation to lay out the entire product better. We need better use cases. They don't offer many examples to showcase their product's capabilities. 

I've used the solution for more than a decade. It's been 12 to 14 years at this point. 

The solution is very stable. They have the flow language. We've been using it since version 6.0 and we haven't had any major issues. It's pretty seamless. 

For what we need, it scales quite well. We don't have to worry about having to scale too large as our organization, a bank, is not a very big bank. That said, scalability has never been a problem. 

It's a solution that is generally used by the IT department, not everyone in the company. Maybe between five and ten people use it in total. 

We have to use technical support sometimes. We do, for example, during migrations. We incorporated a business process from webMethods. We are now changing the process in terms of where we were using the database to control the business processes. It is more or less now using the RED METHODs PPM. When changes need to happen we contact them and work with them. 

While they do help, the documentation could be better. 

Positive

The initial setup is very simple and very straightforward. 

That said, open-source solutions are easier. However, we like to have a contractor come in and take care of everything.  

Everything to be set up must be done carefully and properly. Certain changes cannot be incorporated so easily. There might be certain dependencies across certain applications. We take a pretty careful approach every time we are migrating.

We had a third-party assist us with the implementation. It makes everything very easy.

I'm a user of the application. I don't directly handle the licensing. 

I'd warn potential users that, if you get into the ESB sort solution, once you get into it,  coming out of it is very difficult. The dependencies are very high and you are running it in the middle of your architecture. It becomes something you have to budget for and allocate every year. 

I'd rate the solution a seven out of ten due to the complicated installation process. 

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. 

I am an integrator of the solution. Our use case is for integration factory for SAP. It is mostly for SAP integration.

The solution is deployed on-premise. We are one version 7.

I am not satisfied with the solution because it takes too much effort to migrate and add new information. The migration could be easier. There's a lot of rework that needs to be done if you go to a newer version.

I have been using this solution for one year.

The solution is stable.

For supporting the solution and installing things, we have maybe 10 or so users. We have no plans to increase usage.

The solution is scalable.

Before using webMethods, I used a different cloud data migration solution for other customers. 

It's a running system, so I haven't had any experience with the installations.

The pricing is a yearly license.

I would rate this solution 8 out of 10.

I would recommend this solution, but it is old fashioned.

webMethods Trading Networks is a good solution for interacting with outside of the organization. We can integrate the solutions with multiple outside the organization. 

We can create multiple users and different types of documents. The same document type we can process to the different kinds of partners. They are reusable, we can map to the respective document type.

I have been using webMethods Trading Networks for approximately eight years.

I have found webMethods Trading Networks to be stable.

webMethods Trading Networks is scalable.

For smaller organizations, I would suggest they use the rest APIs and the API gateway approach.

Technical support is very good and user-friendly. For example, if any B2B interface fails we can easily go into the My webMethods Server, where we can see all of the transactions. There we can find the document type or the partner name or receiver's name. If they provide an invoice number, we can use that invoice number, to find the logs to investigate the issue. Additionally, we can find out the resolution after our investigation.

We had a good experience setting up webMethods Trading Networks, it was simple. We did not face any large challenges. However, My webMethod completely depends on the backend table. That table should be properly installed. If it is properly installed, there are no problems configuring My webMethod server.

webMethods Trading Networks is a bit costly compared to others solutions.

This is a good solution for EDA integrations, I would recommend it.

I rate webMethods Trading Networks a nine out of ten.