Coming October 25: PeerSpot Awards will be announced! Learn more
Julia Frohwein - PeerSpot reviewer
Senior Director of Delivery at PeerSpot (formerly IT Central Station)
  • 0
  • 184

What is your primary use case for webMethods Integration Server?

How do you or your organization use this solution?

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

Thank you!

PeerSpot user
12 Answers
Dries Vanmarcke - PeerSpot reviewer
Technical Architect at Colruyt
Real User
Top 5
07 April 21

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.

Enterprise Architect at a computer software company with 1,001-5,000 employees
Real User
Top 10
25 March 21

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.

IT Manager at a manufacturing company with 5,001-10,000 employees
Real User
Top 10
21 December 20

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.

Rully Feranata - PeerSpot reviewer
Enterprise Architect at PT Bank Mandiri (Persero) Tbk.
Real User
Top 5
25 November 20

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.

A. Smart - PeerSpot reviewer
Enterprise Architect at a energy/utilities company with 1,001-5,000 employees
Real User
Top 10
27 October 20

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.

Ameer Alhadidi - PeerSpot reviewer
Senior Integration Developer at ROP
Real User
19 July 20

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.

Learn what your peers think about webMethods Integration Server. Get advice and tips from experienced pros sharing their opinions. Updated: September 2022.
633,952 professionals have used our research since 2012.
it_user1008537 - PeerSpot reviewer
Regional Integrated Platforms Tech Lead at a insurance company with 10,001+ employees
Real User
12 July 20

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

Middleware Technical Specialist at a manufacturing company with 5,001-10,000 employees
Real User
02 July 20

We use webMethods for integrating our applications.

IT Project Manager at a maritime company with 10,001+ employees
Real User
11 June 19

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

Siva Subrahmanyam Chavali - PeerSpot reviewer
Lead Developer - webMethods, Oracle SOA Suite at American Electric Power
Real User
09 February 19

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

Sr. Software Developer | Systems Integration Specialist | Project Manager | EDI Technical Lead at a energy/utilities company with 5,001-10,000 employees
Real User
30 July 18

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

PeerSpot user
Integration Engineer at a consultancy with 51-200 employees
Real User
14 September 17

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.

Related Questions
User at Nuvision Consulting
Jan 26, 2022
Hi, I'm working at a consulting company and I want to understand the pros and the cons of Red Hat Fuse vs webMethods Integration Server. Please advise. 
See 2 answers
Dave Koffij - PeerSpot reviewer
Information Technology Architect, Cloud and Security at a tech services company with 51-200 employees
29 July 21
With webMethods Integration Server, you have the power to connect anything faster, thanks to open, standards-based integration. Make custom, packaged and mainframe applications and databases—on-premises and in the cloud—interoperable and assure the fluid flow of data across your automated processes. Mapping and transformation functions are built-in. pro's; Easy scalability, 300+ connectors, Faster integrations, "Lift & shift" integrations, Mapping and transformation & iPaaS integrations in the cloud Where Red Hat Fuse, pros; Hybrid deployment, Built-in iPaaS with low-code UI/UX, Container-based integration & Integration everywhere supporting 200 included connectors. Red Hat Fuse, based on open source communities like Apache Camel and Apache ActiveMQ, is part of an agile integration solution. Its distributed approach allows teams to deploy integrated services where required. The API-centric, container-based architecture decouples services so they can be created, extended, and deployed independently.
PaulPerez - PeerSpot reviewer
Integration Architect at Pymma consulting
26 January 22
Hello Andhika Please read Dave's reply first and understand that WebMethods offers many features that you will not find in RedHat Fuse. I would like to add one more architectural point of view. WebMethods provides a nice business process engine that helps you orchestrate your services. Fuse is not able to provide this kind of service.  If your processes are simple and map information, for example, use Fuse.  If your business processes are complex and require balancing, I recommend an integration tool with a business process engine (BPEL or BPMN). WebMethods, Oracle SOA Suite or OpenESB offer these types of tools.  If you plan to design complex processes, you should not hesitate to choose WebMethods.
PeerSpot user
Information Technology Manager at a tech services company with 11-50 employees
Aug 11, 2017
Sonic ESB was a leader in ESB market in the past. Now Aurea Sonic ESB is shown as 13th position. Can it pick-up market in future? Our company Ikas Technologies is doing ESB support services for many years now. Would like to know what ESBs will lead the market in the coming years.
2 out of 7 answers
PeerSpot user
Consultant at Software AG
10 August 17
Recent days Mulesoft ESB, JBoss fuse were picking it up due to open source and considerable connectors etc . Licence copy of software AG ESb , tibco licence cost is high and consideration support facility were available . Depends upon budget and volume of payment transaction etc are considered for choosing the ESB.
PeerSpot user
Technologist at a insurance company with 1,001-5,000 employees
10 August 17
Esb is going to be obsolete in near future because of companies moving to cloud.
Download Free Report
Download our free webMethods Integration Server Report and get advice and tips from experienced pros sharing their opinions. Updated: September 2022.
633,952 professionals have used our research since 2012.