It allows us to to reuse services, meaning, you know, App Bay would have a customer lookup service Appbeat could reuse that service.

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.

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.

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.

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. 

webMethods Integration Server benefited our organization. If it didn't, then we would not be using it.

Integration Server does our business-to-business integrations. It does all of our EDI integrations of passing over our Integration Server and our LAN connects to our internal applications.

Its adapters and connectors provide the fastest way to build an integration. We don't need to create our own implementations because we can use the adapters. We can immediately connect to the backend systems without creating a lot of our own custom code by using these adapters.

The vendor's full support for Integration Server's adapters and connectors brings long-term stability to our services because if something changes to the backend application, we don't need to bother with it. Software AG just adapts the adapter and we get a new version. It's much easier working this way.

Deploying a new application is rather easy. You need a deployer and to build a system. We have built something around it to add it to our continuous integration pipeline, but we have the necessary tools to test our production environments.

We use the same system to modify or redeploy these integrations. If we have a bug we'll adapt our codes and deploy a new version. The code changes need the most time. If it's a small code change, then it goes very quickly. If it's an important bug, it'll take more time. The deployment and build don't take a lot of time.

This solution has improved our productivity and efficiency in pretty much all of our applications. There are some currently-running automation projects where we are going to have to transform data and at the moment, it is being done manually. This is another case where we will implement webMethods to improve productivity.

We automate our sales cycle using API orchestrations. When sales come through, for example, we register them and enroll them in the policy. All of this is done within webMethods and it works well.

With respect to the comprehensiveness and depth of connectors that are available, they have a lot of traditional ones available. They are constantly adding new ones, which is good to see. However, what we found is that we can develop them very easily. Nowadays, pretty much everything is REST so it is easy to develop your own. We do not have a license for many of the connectors. One of them that we have is Salesforce, which was what we had originally envisioned.

Then, what happened when we needed another connector is that we reasoned that rather than buying additional ones, we would instead create our own. Ultimately, we found that it was quite easy to do and in my experience, it is always better to use your own because the out-of-the-box connections have limitations. This is what we found with the connector for SuccessFactors; we were better off building our own because there are no constraints when we do it that way.

This solution encompasses a range of features, which is important to us. We use it heavily for application integration and APIs, somewhat less for data integration, business to business communication, and we are trialing microservices. Although we do not yet heavily use the microservices feature, we do like that it provides it.

We plan to expand our usage of microservices because, in the AWS world, we want to make things auto-scalable. This is what we are playing around with and although we do not yet have it in production, the plan is to use it more.

Modifying and redeploying integrations is easy to do. This has made us more agile and the fact that we can churn things quicker has helped the business.

webMethods provides application integration, data integration, business-to-business communications, APIs, and microservices. We use it for all of those purposes. Having that range of features in a single platform is very important, because that means we have a single platform to learn and use. It reduces training costs. It reduces overall infrastructure costs. It even makes hiring easier because we have one set of resources we need to hire for.

In a very fast moving space—which is weird to say about healthcare, but it has certainly become that in the last few years, and especially in the last year—the ability to move very quickly and to reuse components and to connect to almost anything have become pretty paramount. The solution’s adapters and connectors provide the fastest way to build an integration. The demand curve for integrations goes up daily, so our ability to perform and build integrations is a key core competency.

Clients are mostly using it in order to connect some of their internal systems or to connect to some external systems and some other partner companies. Its benefit is that it's really useful for monitoring and tracking all the activities. And it's important, due to all the flows, all the data, go through this ESB, Enterprise Service Bus. 

We're able to secure our front-end website away from our back-end systems using Integration Server. It acts as a go-between. That way, whether we're requesting things from our website or our IBR or our IPT, we can have multiple interfaces. They're secured in their own ways, and they don't have direct access to our back-end databases.

We're a utility company and before we got this application we would actually send out people to the meters to read them. Sometimes they had handheld devices, but sometimes they had to walk up to the meters. When we switched to AMI meters, we leveraged the ability of the solution to talk to each of the meters on a daily basis, as well as to turn a meter on and off in real time.

Additionally, we use the same application to process payments. Before this solution, we primarily had walk-in centers and a lot of manual processes for receiving payments. Very few payments were done online or via eCheck. Now we can have a whole host of payment options, as well as enable different payment vendors to connect. It has automated a lot of our manual processes.

webMethods Integration Server provides a single hybrid integration platform for all our needs. It provides reusability. We don't have to worry about taking each and every point-to-point integration. Now we are hosting a true enterprise service bus, by having a set of APIs that can really be leveraged and reused by multiple vendors and multiple connectors.

Its adapters and connectors provide the fastest way for us to build an integration. We're able to turn things around pretty quickly. I'm sure there are other faster ways that other people have done, but this meets our needs. 

It's helped us to become more modern. It's allowed us to service our customers in the ways that they want. They can now use on-the-phone payments or website payments or whatever way they want to do it.

Internally, it provides a standard way for us to be able to interface with things. Now, we don't have to have unique ways to do so and much more code and numerous ideas on how to do things. We just end up having a standard.

It provides us with ease of modifying and redeploying integrations. We have been able to do that very successfully. It just makes it easier. We were able to put in an Agile framework, which means that as requirements come up and changes are made, we're able to schedule them on a regular basis. But we were doing that for the long-term before, as well.

Its support for the latest standards make it possible to plug in modern tooling. We've used that in several places, especially for IoT integrations. The result has been reduced costs and improved customer satisfaction.

webMethods provides the ESB backbone for us since more than 8 years without any hick ups

• The time to market is relatively less.
• It's simple to learn for Java users.
• Its administration is easier.
• Extensive toolset: out-of-the-box libraries support.
• DevOps could be better.

Time effective by cutting down development time and resource efficient to developer burden, enhance agility and integration between end-to-end applications, platform

We have a reusable code that we can replicate for any new interfaces.

The MFT component of webMethods, for example, is easy to set up and convenient to use. It handles files very efficiently and it is easy to automate tasks with complex schedules. Monitoring is centralized to MWS which can be used to monitor other products as well (Trading Networks, BPM, MFT, etc.)

When my organization wanted to migrate the front-end applications from a Genesys framework to .NET for various security reasons, webMethods was used for ESB integration. At the time of migration, there was no work being done on the ESB side, which reduced developers' efforts and all the services were re-used as we used Web services to connect the front-end with mainframes.

When my business client  acquired another business and we were integrating the services, as B2B uses standard communication messages, i.e. EDI, the work made the developers' task simpler, in handling all the interfaces.

We moved from EAI to SOA architecture while moving to webMethods. Both of these decisions made the reusable services approach available across the organization.

We used webmethods in an EAI project to integrate transactions from a bespoken HR Portal (e.g bank details change, new hire, salary increase, etc...) to update two different customer ERP systems in the back-end (SAP HR and PeopleSoft) thus providing self service capabilities to end users and reducing the need for manual data entry by agents (prone to errors and systems not being synchronized)

It has enabled us to integrate some systems which needed a form of translation.

Given that you have one integration API in place, it takes very minimal effort to scale it to any other application that might want to use the same. Its flow-based development environment is a breeze and makes it really easy to re-use most of the existing components and build up a new API.

The second most important aspect is managing the components. It’s fairly easy to view, move, and mange access across different components. Different component types are categorized and can be viewed in a web based administration console.

Typically, webMethods Server and Mediator is used as an ESB. webMethods platform is used to build an EAI platform, enabling communication between many internal systems and third-party operators.

We have used webMethods because of its ubiquitous nature to talk to various technology platforms. Also, the solution had a finite life, webMethods provided a quick integration solution since it is relatively easier to implement, and also, it can hold the business logic in itself.

The client was planning to go in for a separate data exchange platform/Business Information Warehouse as a large-scale global project slated to be alive after five years.

It helped to improve the efficacy of production planning to the market demands and it has improved the quality due to faster information on quality issues.

It becomes the only integration platform through which any external/internal data exchange does any web services. Below are more details:

• There are many projects in the organization which need data from external entities and all integration endpoints implemented using webMethods integration platform.
• Departments in the organization currently understand what to exchange and in what type by having an enterprise data model in webMethods integration platform.
• Business users are involved in any integration as approvals have to take place throughout the lifecycle of the service.
• Reports and dashboards give management a big picture of the integration usage and potential bottlenecks.

WM is an enterprise bus which is used for all integrations, bringing all message transfers into one application, and making monitoring and integration of applications easy.

It helps a lot. Most of the work can be more easily done by using webMethods compared to other tools.

It has helped us streamline data from hundreds of non-SAP systems into the SAP system.

It is an integration platform, so it has improved my organization by giving it one common platform to work with multiple systems.

It facilitates

• communication between a lot of applications
• maintainability and security and
• facilitates the integration of new applications.

One to many, or many to one transformation and delivery is the simplest example.