webMethods.io Reviews

By Software AG, we are also using Integration Server, Trading Networks, Active Transfer, Optimize for Infrastructure, My webMethods, and their EDI package. As long as there is product parity between products, it makes sense to continue using multiple products from the same vendor. Obviously, you want to make sure you have a diverse portfolio. Where those products start breaking those links, you want to make sure that you are using the best product for your company in this region.

The fact that we were already using another solution from this vendor affected our decision to go with this particular product, mainly from a cost standpoint. As is any product in this region, the biggest cost is almost always the upfront cost of laying out the solution. Also, there are some costs in having that solution already available: between knowledge of the platform, having the licensing rights, and if you bring in a new solution, then you are now paying for two solutions.

The native integrations between the vendors' products are very seamless. The products interact very well. At times, it's kind of hard to tell where one product ends and the next one starts. As new products come in, the integrations probably take one or two updates before they are fully integrated. However, once products are fully integrated, it is very seamless and easy to hop between one product to another.

Using multiple products from the same vendor creates efficiencies:

1. In terms of knowledge. Obviously, there is a familiarity with the product and how you expect Software AG's products to act and respond. 
2. In terms of operational understanding between end users who are looking for specific data. They know how these products work and how to pull up these reports. 
3. In terms of having administrators overseeing these products.

There is a cost savings for using many of the same products. There are lower training costs. Also, typically, there are a lot of integrations that you ended up needing to build out, whether they be custom or out-of-the-box. Even if they are out-of-the-box, a lot of times that takes a lot of work to get those to work. However, since we are using Software AG products, it's very much like installing a plugin into an Excel program.

There was a reduction in the learning curve because we had already used the vendors' products. The products used work very similarly. In terms of verbiage, key aspects, or three-letter acronyms, you don't have to relearn any of those. There is an expectation of how these products will work. These products always work the same way when Software AG is rolling these types of products out.

We use webMethods Integration Server for two main aspects: 

1. For application-to-application integrations.
2. B2B: The transferring of on-premise data out to other business partners.

As with any integration platform, it is a single pane of glass that allows you to see and interact with transactions as they are flowing. Out-of-the-box, Software AG offers robust monitoring solutions to help you understand if a solution's up or down transactions aren't working, etc. The tool has been invaluable to our organization in terms of understanding where our data is, how it's flowing, and its current status.

Having a single hybrid-integration platform for all our needs is very important. From an IT perspective, it is a way for us to easily troubleshoot and quickly resolve issues. From a business perspective, it's very important because IT is readily available to assist with any system issues which are happening at that time. Anytime that you have applications talking to each other, it is a breeding ground for problems and issues. Having a solution like webMethods Integration Server in place can empower your IT department to be able to resolve issues and roll out solutions quickly as new applications come into your portfolio.

We have been on webMethods Integration Server for 15 years. We just got rid of our mainframe. It works wonders with our mainframe. With SaaS and cloud applications, webMethods Integration Server does not answer this need by itself. This is where you would be looking for APIs or custom plugins to work with those types of solutions. 

We use webMethods.io for the discontinuation of the e-residency project. It is a significant project across the country to automate the complete process from the initiation or issuance of civil ID cards for citizens in Kuwait. This includes residency renewal, issuance of civil ID cards, a new journey for newborn registration, and more. We employ webMethods.io to facilitate full services, starting from sending to the designer, moving on to business process management, etc.

The tool is very good and useful. Especially in the government sector where I work as an IT Director at Public Authority for Civil Information, we have been using Software AG suite components including IRIS, webMethods, Terracotta, Trading Networks, and others. The product is powerful, straightforward, and easy to use. It facilitates the exposure of around 235 services through our platform to feed various government entities across the entire country.

Our use case is our service-oriented architecture transformation which started in 2017. It has been a three-year journey. Before that, between 2007 and 2017, we had not conducted a re-architecting of the SOA. In 2017, we had a big initiative for digital transformation at the bank to make ourselves more flexible, more agile, and competitive with all the startups and the financial industry in general, not only in Indonesia but also in other regions.

One of the critical capabilities included the integration area. That is why, in 2017, we re-architected the SOA to have layered architecture that is related closely to microservices. We are testing a new mobile banking channel to use a micro services architecture as well.

The integration use cases for webMethods involve connecting all of the back-end core systems at the bank so that they use the SOA integration server layer. Everything must go through this layer to speak or communicate with the back-end systems, such as the core banking, HR systems, and the treasury system; all the core systems that sit behind the ESB layer of the Integration Server. All the front-end systems like mobile banking, sales management, the CRM, etc., must go through this ESB layer, the integration server, to communicate with the back-end system. That is the prime use case of Integration Server.

Other than that, we successfully launched a new initiative for API about a year ago. We are commoditizing our financial services to not only be consumed by our channels, but by partners such as startups, FinTechs, InsureTechs, and other companies that would like to partner with us and use our financial services APIs.

When it comes to commoditizing for external parties, the partners, the other banks, or financial institutions that are our subsidiaries, they can connect to it and consume our services through the API Gateway products that we are providing to them. That includes sandboxing to test their applications. If they would like to partner with us, they need to register themselves and make an agreement with the bank regarding what sort of packages and fees that will be applied for the cooperation.

It's deployed on-prem. We are a banking institution. In Asia, regulators for the financial industry prohibit us from hosting financial transactions outside the Indonesian region.

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. There is also webMethods API Gateway and Software AG Apama. (Read my webMethods API Gateway review here.) 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.

One of the improvements is that everything is currently standardized. Previously, each system had its own connection to the core and back-end systems, a point-to-point connection. It created havoc for governance of the integration itself. There were so many connections without any governance whatsoever as to how the communication happened.;

There is also an improvement on our development side. When we have requests for new business requirements, products, business processes, and integrations with partners, Integration Server has dramatically decreased our development time. That's because we have standardized all the communications to the core system in one place.

In addition, we have improved availability of the channel itself.

It definitely gives us flexibility. The first stage, with these products, is the learning and customization. Once these are underway and things run, the performance is meeting our expectations. And when new requirements arise it becomes easier and development speeds up. For each integration service, the development cycle has come down from seven days to three days, maximum. And that's for the complex integrations. We have cut the development cycle by almost 50 percent.

Modifying and redeploying integrations is very easy. It gives us a good, stable, comprehensive, end-to-end development cycle, from development to deployment. It gives us a set of tools for checking the consistency and integrity of the code, which is something we didn't have with previous solutions. When deploying to the production server, it also does validation checking, whether certain libraries are missing, for example. It helps us do consistency checks. Because of that, we have cut down the system integration testing significantly. The user acceptance testing has also been reduced significantly. The reduction in testing time is almost 50 percent, compared to our previous solution. We used to test for five days and now it's just two days of testing for each of the services.

The vendor’s full support for the solution’s adapters and connectors has helped with uptime and availability. We are close to 24/7. And the number of transactions per second, previously, was around 600 to 700. Now, it has almost doubled. We are reaching more than 1,000 TPS. We have more than 2 million transactions. It has given us that type of scalability.

The solution has helped us contribute more to the business, to the expansion of the products and the volume of transactions.

We use it for everything. Three years or four years ago our company was bought. In our original company we used it for EDI, although that has pretty much gone away since the purchase. We do use it for EDI, but we use it for more free EAI, enterprise application integration. It allows us to have plant software talk to SAP. It allows us to interface with external parties through their MFT (managed file transfer) product called Active Transfer. We use it to connect all kinds of systems.

Also, in a company that's big, there are always acquisitions, and before the acquisition can be fully integrated there is always the challenge of getting data in and out of that acquisition. We use webMethods for that too, because we can either use internal network or external network.

It's hosted in Azure, on VMs.

Its adapters and connectors absolutely provide the fastest way to build an integration. An example of the effect of that speed of integration on our business is that when our company was acquired, the acquiring company didn't have webMethods and wasn't interested in it. We were able to build interfaces quickly and show that they didn't need constant babysitting. For example, you can build frameworks. We had built an error-handling framework that can notify people with meaningful error messages when they happen. It never crashes. It always tells people what happened. We were able to build solutions much faster than with the other tools.

Process orchestration is another benefit. Driving towards an event-driven architecture, and not a batch-oriented architecture—which introduces all kinds of time delays and doesn't give a true picture of the end-to-end process—we've used webMethods Designer to design process models that can orchestrate a process from beginning to end. For example, we can get data via SFTP, trigger an event in webMethods to process the data, and load it into a third-party data warehouse database such as Snowflake, which is a new up-and-comer. We can then trigger other processes to move that data and process it in Snowflake. We get responses back and, at the end, we can consume the processed data and send it to a different endpoint. All of that is orchestrated by webMethods. Process orchestration is a very strong point of the solution.

Modifying and troubleshooting are very easy. They have a nice debugging app interface. It's faster than anything else that we've ever used. For example, when we were acquired, we had to keep our legacy SAP system, which was still functioning for the legacy company, synchronized with the acquiring company's SAP system. This was a very complicated task and we were able to do it very quickly using webMethods Integration Server.

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.

There are many use cases for webMethods ActiveTransfer, but the main focus for us is transferring files internally between applications or externally between partners. From a technical point of view, it can be seen a tool for file transfer for A2A (application-to-application), and from a market model point of view, it's also a B2B (business-to-business) tool. In terms of extras, it includes an engine for translation, which comes as an add-on, so that customers can translate files as they send or receive them from external partners. We could, of course, also create a custom interface in order to allow physical users to perform file transfer, but this is not a common use case.

Using webMethods ActiveTransfer, we can create rules for automatic application-to-application file transfers, and one of our customers in Italy is even using it for both file transfers and as an ESB (Enterprise Service Bus) as part of their supply chain infrastructure where there is a very high volume of messages being exchanged (thousands and thousands of messages per day).

If the customer's infrastructure is complex, with high-availability clusters and so on, then we often have to implement not only the basic use case, but also consider other business cases as well, such as in our Italian customer's situation where ActiveTransfer must additionally communicate with their order management orchestrator and other parts of their infrastructure.

There are offerings for deployment on cloud or hybrid as well, but most of the customers who have around 1,000 employees prefer the solution to be situated on-premises.

The core product can be used not only for automatic file transfers between applications, but also as an Enterprise Service Bus (ESB). Internally, it's easy to exchange messages between applications because they have decent integrations of message protocols whether you're using a REST API or MQ. Thus, its core functionality is highly compatible with different methods of exchanging messages between applications.

On the whole, it's a very good product being all at once easy to use, easy enough to install, and easy to deploy new workflows and so on.

We've used webMethods mainly as a full-fledged DSP. We had use cases where all the USP use cases, the deployment pattern, were mainly service-oriented architecture. We had patterns arranged from web services, this protocol, and also transformation use cases to convert from XML to COBAL, or XML to external data on to task format and all the different formats, including limited format. We have used webMethods for all these use cases and even connectivity-wise, for web services, JMS and MQ.

From an organizational productivity perspective, before webMethods we had a different product. We were using another tooling from IBM. That had its own problems. Even though we had our own framework and an SOA-based architecture implemented properly, it was not scalable. Integration Server, from that perspective, actually helped us a lot. In the company, we had a lot of applications serving different protocols, and not all products give all features. Since Integration Server, we were able to customize it so we could use one product as a central item, whereas earlier, we had to rely on multiple products.

After the implementation of Integration Server, we could solve most of the connectivity issues. We did not have a problem even today. The implementation has been there for almost seven years now, and we don't have major problems, at least from the capability perspective. Whatever the product did not support, we had the flexibility to build our own frame, own adapters. From that perspective, it was a very good decision to go with this product.

For any of the APIs developed in webMethods, I can use API Gateway for extension policies and to export them to consumers.

Nowadays, API is popular throughout the world, so the user needs to have a single point of control over an API. It should also have governance on top of it, and it should be possible to apply some security policies to it so that a user can have a mature product and a single point entry in terms of a gateway that can be helpful. Recently, webMethods has turned to an API-based approach, and API Gateway was webMethods' way of converting itself into an API-based tool.