Most of our applications are business applications we support, customer lookups, and what methods provide those services that have calls to our apps that needed that infrastructure. We are a combination of of Rantor Docker web methods. 

I have used webMethods Integration Server in a variety of roles over the past eight years, starting as a developer and progressing to integration specialist where my work entailed building enterprise solutions to process a lot of data (millions of records each day) using event-driven architecture.

Our primary use case is retail integration where there are a lot of orders being placed daily, and where all the inventory needs to be updated in the centralized system. It's mainly in the retail and banking sectors, or anywhere transactions may play a crucial role, where I have used webMethods the most in my projects.

Typically, it is used where data has to be going to multiple systems on-the-fly, such that there will be minimal latency. For example, in an event-driven process where there is an action trigger for a piece of data or record to be forwarded to multiple systems when that action has been triggered.

The latest versions I have worked with include 10.5 and 10.3, however at the moment and for the past year I have been working with MuleSoft more than webMethods.

Our infrastructure is mainly on-premises, but we are starting to move to the cloud. Our target is to move everything to cloud, and right now we have a few instances on-premises and a few in the cloud, hosted privately with Microsoft Azure.

As for users, we are not directly exposed to the clients or end-users. Instead, we are mainly part of the middleware layer, whereas many of our customer-facing portals are different and distinct from one another. If we counted from one portal, the users may go into the thousands or even billions sometimes. It depends on the transaction type that is involved. For example, if you take any store of the multiple stores in operation, we will get a daily number of orders and that number of transactions will go through our system. Ultimately, it differs from region to region and client to client, but the numbers on any store can be from thousands to 10,000 or more.

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.

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.

This is an integration tool along with its having IoT applications and data integration applications.

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.

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.

Today, we work with many financial organizations worldwide, and sometimes they have Legacy software, so we use webMethods Integration Server in those cases. 

We are not resellers, but we provide solutions to large financial institutions, and sometimes we have to work with a lot of legacy software. Sometimes we have webMethods Integration Server as part of the stack. Sometimes we do consulting, and sometimes we take ownership of parts of the projects that large financial institutions have.

webMethods Integration Server is very similar to every integration product in the world, and in the past, we used to write point-to-point connectors with the concept of ESB. We used hub and spoke architectures, and webMethods Integration Server would be used in that context.

Usually, the way large enterprises work is they acquire different licenses over time, so we check their internal IT asset management software in terms of their licenses. If they already have a webMethods Integration Server license, we use that as part of our solution.

Otherwise, we would make recommendations to them on what to acquire in the open market. If the solution is cloud-based, we recommend that they use cloud-based ESB software to integrate different components of their solution. We choose different software pieces, put them together, and ensure that they add value on top of the integration headaches that come when you work with enterprise software.

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.

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.

We use the solution for application-to-application integration and B2B integration.

We had multiple integrations in our internal applications. The webMethods Integration Server is integrated internally, plus we have integrated it with external entities depending upon SOAP, and REST. Additionally, there is some legacy system we have connectivity with.

We don't use webMethods Integration Server directly, but we use another offering from one of our vendors. They have built a layer on top of the webMethods Integration Server and that's a solution we have been using.

webMethods Integration Server is the underlying component, but our software vendor, has made some enhancements to the webMethods Integration Server and they offered it to us. That's what we are currently using along with some of the other solutions in the supply chain space.

Their offering is more of an integration framework across all their systems and this is how we have been using the system. webMethods Integration Server is our primary integration tool across all the solutions that we have in our supply chain.

We're a healthcare technology organization and that space has a great deal of integration work, so we use webMethods to help us manage and develop integration solutions for various healthcare-related needs. Those include HL7 messages, the new interop messages, the new CMS directives for data blocking, Affordable Care Act integrations, and integrations with other health systems.

Our particular product is a SaaS, multi-tenant environment that's on-prem but moving to cloud. It is used by hundreds of healthcare providers to run their businesses.

We primarily use it as an integration server. We have integration use cases, including B2B, et cetera.

By linking apps and services, the webMethods Integration Server allows you to automate processes.

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

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.

We are using it to orchestrate and configure our APIs.

I believe we are using its latest version.

It interfaces between applications, as well as between the cloud and our existing on-prem applications.

We primarily utilize packaged applications; we don't really have a lot of custom applications. We do have a few custom interfaces, and some vendors may have created a custom interface on their own, but we present a standard integration, a standard enterprise service bus, to connect to.

We are looking to use webMethods as part of our business process management solution. We have a mainframe and it facilitates connectivity with our database.

The tool helps with the integration between multiple entities at the same time.

• Traditional ESB solutions using multiple adapters
• API development and management.

I've been developing with SAG webMethods in Telco industries for integrating provisioning (CRM) end-to-end Billing, BSS and OSS, Banks/Insurance/Finance integrating bancassurance, provisioning, Switching&Allocation and Government Instance (Oil and gas) integrating B2B oil company to government reporting.

We're using it for managing secure file transfers for the company.

webMethods, in my current client's environment, is used to provide solutions based on SOA (web services) and BPM (Business Process Management).

We use the solution for logistic purposes.

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.

The primary use of the webMethods platform is to communicate with multiple applications and integrate them. webMethods provides business process integration, B2B partner integration, and also uses Web services to connect software applications. My client acquired another company and we are integrating the partners of the acquired company with their clients, using various data communication standards like EDI, EDIFACT, and Rosettanet messages. 

In my previous project we used it to bridge communications between a front-end application and the back-end, connecting them with Web services through SOAP requests and SOAP responses, using JMS queues and broker.

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.

This product is used for application integration. I have implemented this solution for many clients across the world.

Primary use case is to provide ESB for legacy and SOA services, Business Process Management with BPMS and API Gateway for external partners.

We use webMethods for integrating our applications.

Our primary use case is for communication between different systems and automation of business processes.

webMethods is primarily used to integrate applications. While one can always do the same by building APIs (Java, .NET, etc.), webMethods provides a robust, scalable, and easy to manage platform to do so.

The need is primarily felt when integrating multiple application for a large enterprise. To list a few, one can use webMethods to integrate web-based, file-based, database-based applications. Of course, this is just the tip of the iceberg. It has multiple modules for specific integration types, like a Trading Networks module for business to business integrations, business process models for graphical representations for executing business processes. One can also build small Web-based application using CAF and DSP.

Used for intra-company application-to-application integration and for intercompany B2B integration (order to cash, procure payment, HR, and banking functions).

We develop EAI applications using webMethods using broker, TN, and IS. 

We use a Publish/Subscribe mechanism in every interface which we develop, because we have found this approach to be the best for every scenario.

Our customers use webMethods Integration Server to integrate their retail solution, the frontend with the backend. 

This is a middleware tool from Software AG, so when there is a need for EAI/ESB, or B2B; the use cases and implementations are plenty and can vary according to business and enterprise architecture.

For example, an internal application like SAP sends data which is received and transformed by webMethods to EDI, XML, or another user-requested format, and sent to an external business partner (via jms/FTP/WS call).