We value your privacy

We use cookies to analyze our website traffic and improve your experience. By accepting, you agree to our use of analytics cookies. See our Privacy Policy for details.

IGT Systems

What Is webMethods Integration Server, and What Are Its Core Capabilities?

What webMethods Integration Server is and its core capabilities: installing it on-premises, building an integration flow between two systems, and resolving common errors.

Marek Juračka
Marek Juračka01 Jun 2026 • 9 min read
What Is webMethods Integration Server, and What Are Its Core Capabilities?

Table of contents


webMethods Integration Server is the core runtime of the webMethods platform: the engine that runs integrations, hosts adapters and services, and orchestrates how data moves between systems. Its core capabilities are building and running integration logic as flow and Java services, connecting to systems through a large adapter library, exposing and consuming APIs and services, orchestrating multi-step processes, and acting as the central point for managing and monitoring the integration estate. It runs on-premises, and it is the component most webMethods projects start with.

See how IGT deploys and runs it as part of our webMethods integration services.

The webMethods Integration Server hosts the building blocks of an integration: its services, adapters and packages. The other parts of the platform, such as the API and file-transfer capabilities, build on top of it. It has been the core of webMethods for years, and since 1 July 2024 the platform has been part of IBM, with continued investment behind it.

Core capabilities of the webMethods Integration Server

A few capabilities define what the Integration Server does. It runs flow services and Java services, which let teams build integration logic visually and in code without writing an application from scratch. It connects to systems through a large library of adapters, for SAP, databases over JDBC, messaging over JMS, file transfer over SFTP and many more. It exposes and consumes APIs and web services over REST and SOAP, so the integrations it runs can be reached by other systems. It orchestrates multi-step processes, calling several systems in sequence and handling the logic between them. And it provides the central point for managing, securing and monitoring the integration estate.

Underneath all of this sits the canonical-model approach: systems map to a shared, neutral format on the Integration Server, so a change in one system does not force changes everywhere else.

webMethods Integration Server capabilities at a glance

Capability

What it does

Flow services

Build and run integration logic

Java services

Add custom code where needed

Adapters

Connect to SAP, databases, JMS, files and other systems

APIs and services

Expose and consume REST, SOAP and other services

Monitoring

Track failures, retries, logs and runtime health

Security

Manage access, certificates and secure communication

Installing and configuring webMethods Integration Server on-premises

Installing the Integration Server on your own infrastructure follows a familiar shape, though the exact steps depend on the release you deploy. In outline: check the prerequisites first, namely a supported operating system, a suitable Java runtime, and enough memory and disk for your expected load. Run the platform installer and select the Integration Server and the adapters you need. Then configure the essentials: the ports the server listens on, the database connections it uses for its internal and audit data, the packages that hold your integration logic, and the security settings, including SSL certificates. For production, the server is usually clustered across more than one node so that the integration estate stays available if one node fails.

Because the specifics change between versions, the safest path is to confirm the exact prerequisites and configuration steps against the release you are running.

Building an integration flow between two systems

At its simplest, connecting two systems on the Integration Server follows a clear pattern. You define the source and the target. You create a flow service that receives the source data. You map that data to a shared, intermediate structure rather than directly to the target, then transform it into the format the target expects. You invoke the target through an adapter or an API. Finally you add error handling and logging so that, if something goes wrong, it is visible and recoverable.

The reason for mapping to a shared structure in the middle, rather than wiring source straight to target, is reuse. When a third system needs the same data later, you map it to the shared structure once, and the existing logic does the rest. That is the difference between an integration estate that grows cleanly and one that becomes a tangle.

Resolving common webMethods Integration Server errors

Most Integration Server problems fall into a handful of categories.

•     Memory pressure on the Java runtime, often from heavy load or large messages, can cause slowdowns and pauses.

•     Documents can become stuck or locked when a downstream system is unavailable.

•     Adapter connections fail when a database or messaging system is down, when credentials change, or when a certificate expires.

•     Ports can conflict, disks can fill with logs, and thread pools can be exhausted under spikes.

The way through is observability. The server's own logs and statistics show what failed and when, and the platform's monitoring, retry and replay features let you recover a failed transfer rather than discover it downstream. Building this in from the start is what separates a reliable estate from a fragile one.

How IGT fixed this: a real example

This is exactly what one project set out to fix. IGT rebuilt an enterprise's entire file-transfer estate with the Integration Server as the central management plane, turning a set of opaque, unmonitored transfers into an observable, governed system. Throughput rose by around 50 percent on the same hardware, the estate scaled from 65 interfaces to more than 500, and the cutover happened with zero downtime. The full story is in our Modernizing File Transfer case study.

webMethods Integration Server is a mature, capable runtime, and getting the most from it is as much about how it is configured, monitored and operated as about the software itself. That is where an experienced, EU-based partner earns its place. IGT Systems is an IBM partner, and was a Software AG partner before that, so the platform's roadmap and our delivery sit on stable ground.

Considering webMethods for your enterprise stack? See how IGT Systems approaches webMethods integration.

Read also

•     What Is the webMethods Integration Platform?

•     B2B Integration with webMethods: How It Works

•     What webMethods Enterprise Integration Means

•     webMethods Integration Services for Enterprises

Sources

•     IBM Completes Acquisition of StreamSets and webMethods (1 July 2024)


What is webMethods Integration Server used for?

webMethods Integration Server is used to build, run and manage enterprise integrations. It hosts services, adapters and packages that connect systems, transform data, expose APIs and orchestrate business processes.

Is webMethods Integration Server only on-premises?

No. Integration Server is commonly deployed on-premises in enterprise environments, but webMethods also supports broader hybrid and cloud integration patterns depending on the product version and architecture.

What are flow services in webMethods?

Flow services are visual integration services that define a sequence of steps. They can receive data, map and transform it, call other services or adapters, handle errors and return a result to another system.

What systems can webMethods Integration Server connect to?

It can connect to enterprise systems through adapters and standard protocols, including SAP, databases through JDBC, messaging systems through JMS, file transfer through SFTP, and APIs through REST or SOAP.

How do you troubleshoot webMethods Integration Server errors?

Start with Integration Server logs, service statistics, adapter connection status, thread usage, memory consumption and failed document or transaction records. Common causes include expired certificates, unavailable downstream systems, full disks, exhausted thread pools and changed credentials.

What is the difference between Integration Server and API Gateway?

Integration Server runs the integration logic and services. API Gateway focuses on securing, exposing, managing and monitoring APIs. In many architectures, the API Gateway exposes APIs while Integration Server executes the backend integration logic.

Latest writings

The latest news, technologies, and resources from our team.

View all blogs

Let’s make it click!

Whether you're scaling a startup or streamlining a corporate ecosystem, we help teams launch faster and integrate smarter.

Eva Polcíková

Eva Polcíková

Project Manager

Book a discovery call
IGT Systems

IGT Systems s.r.o.

Sliačska 34, 831 02 Bratislava,

Slovak Republic

+421 902 180 600

click@igt-systems.com

2026 IGT Systems. All rights reserved. Designed by pomasle.studio