2017-09-14T10:19:00Z

What is your primary use case for webMethods Integration Server?

21

How do you or your organization use this solution?

Please share with us so that your peers can learn from your experiences.

Thank you!

ITCS user
Guest
1212 Answers

author avatar
Top 5LeaderboardReal User

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.

2021-04-07T13:32:00Z
author avatar
Top 5Real User

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.

2021-03-25T13:22:00Z
author avatar
Top 5Real User

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: * In terms of knowledge. Obviously, there is a familiarity with the product and how you expect Software AG's products to act and respond. * 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. * 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: * For application-to-application integrations. * B2B: The transferring of on-premise data out to other business partners.

2020-12-21T06:00:00Z
author avatar
Top 5LeaderboardReal User

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.

2020-11-25T05:25:00Z
author avatar
Top 5Real User

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.

2020-10-27T06:41:00Z
author avatar
Top 5Real User

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.

2020-07-19T08:15:42Z
author avatar
Real User

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

2020-07-12T11:48:45Z
author avatar
Real User

We use webMethods for integrating our applications.

2020-07-02T10:05:56Z
author avatar
Real User

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

2019-06-11T11:10:00Z
author avatar
Real User

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

2019-02-09T20:37:00Z
author avatar
Real User

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

2018-07-30T09:01:00Z
author avatar
Real User

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.

2017-09-14T10:19:00Z
Learn what your peers think about webMethods Integration Server. Get advice and tips from experienced pros sharing their opinions. Updated: June 2021.
521,189 professionals have used our research since 2012.