2020-12-15T08:57:00Z

What is your primary use case for webMethods API Gateway?

Julia Miller - PeerSpot reviewer
  • 0
  • 61
PeerSpot user
7

7 Answers

IH
Real User
Top 20
2023-09-20T09:24:00Z
Sep 20, 2023

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.

Search for a product comparison
Bahaa Farouk - PeerSpot reviewer
Real User
Top 5
2023-04-19T12:28:00Z
Apr 19, 2023

The webMethods API Gateway is utilized to assist our banking clients in integrating with the bank via the API.

KA
Consultant
Top 20
2023-03-22T06:09:38Z
Mar 22, 2023

One of our clients is a chain management company. They have many APIs which do a lot of integrations, including B2B integrations. For that particular client, our APIs are on APIs check and handing the deals and restock. Everything is hosted on our API gateway. They can use a scan and access those APIs and do operations for sales orders and invoices.

Rajkumar Panneerselvam - PeerSpot reviewer
Real User
Top 10
2022-11-14T21:07:15Z
Nov 14, 2022

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

RK
Real User
2021-06-03T10:01:07Z
Jun 3, 2021

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.

DV
Real User
Top 20
2021-04-12T13:10:00Z
Apr 12, 2021

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.

Learn what your peers think about webMethods API Gateway. Get advice and tips from experienced pros sharing their opinions. Updated: March 2024.
765,234 professionals have used our research since 2012.
RF
Real User
2020-12-15T08:57:00Z
Dec 15, 2020

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.

Once your APIs are “out there,” hackers have a “way in” to your business. Lock that door! Protect your data, applications—even your company’s reputation—with robust API runtime security. The right API gateway will keep out wrong-doers and welcome only authorized consumers. With cybercrime costs surging to $2 trillion by 2019, look for the most impermeable API gateway you can find. You’ll need basic security features, like authentication, authorization, digital encryption and digital...
Download webMethods API Gateway ReportRead more