webMethods API Gateway Primary Use Case
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.
This solution is primarily used for protecting our APIs and web services. All of our APIs are exposed to the outside world, so our internal network is protected by the API gateway. Our landscape inside the company is also divided into different domains and if you go from one domain to another domain, we also want the APIs to be protected.
We have two servers with an API gateway and a load balancer in front of it.
We also use this solution for monitoring, to know how many transactions we have had and who is using our API. These are the runtime capabilities.
Another thing we use this product for is governance, to govern the lifecycle of our API services. It will tell us the state of the service, who is responsible for it, what deliverables belong to that stage, and we also have some quality checkpoints inside the lifecycle.
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.View full review »
webMethods API Gateway
Learn what your peers think about webMethods API Gateway. Get advice and tips from experienced pros sharing their opinions. Updated: June 2022.
610,812 professionals have used our research since 2012.