Show TOC Start of Content Area

Background documentation Checklist: Making Correct Use of Integration Processes  Locate the document in its SAP Library structure

Using the considerations below, you can check whether integration processes are an appropriate solution to your particular use case and whether your integration processes are appropriately defined.


SAP only recommends that you use integration processes if the following prerequisites are fulfilled:

      Message-based communication

The business systems or applications involved can communicate by means of XML messages.

      Semantic relations between messages (correlations)

The messages that are to be processed in the process are related to each other in some way, for example, a purchase order and the relevant purchase order response.

If this is not the case, check whether you are able to realize the process simply by using just the Integration Server (without integration processes) instead.

      Unique correlations

Correlations can be defined in such a way that they determine messages that belong together uniquely.

      Clear end condition

The process has a clear end condition. No instances of the process should usually last longer than a few days.

To avoid processes that run infinitely, always define a deadline as a unique stopping criterion.

      No user action required

The process does not require any user action.

The Business Process Engine supports the message choreography; however, it is not intended to act as a central workflow engine. If user action is required, check whether you can realize the process by using Business Workflow or Guided Procedures instead.

Using the user decision step type, you can only provide administrators with decision options for certain situations.

Using the Integration Server Efficiently

Integration processes are executed on the Integration Server at runtime by the Business Process Engine. Since the Integration Server is the central resource for message exchange, you must ensure that it is not overloaded; otherwise, this can lead to bottlenecks or performance problems.

See SAP Note 857530 for more information about performance.

Resource Consumption

Every step of an integration process uses Integration Server resources.

      Every message that is sent to the Process Engine is duplicated.

      Every message that is sent from the Process Engine is duplicated.

      A work item is created for the process itself and for every step the process contains.

This means that for a process that just receives one message that is sent without being processed further, four messages and three work items are created.

For this reason, you must ensure that you take Integration Server resources into account when you define integration processes. 

Resource Consumption Per Step Type and Transactional Behavior

Different step types consume different amounts of system resources:

      Step types with high resource consumption:

       Receive Step

       Send Step

Asynchronous send steps with acknowledgments in particular consume a lot of system resources. In the case of synchronous send steps, consumption depends on the target system.

       Receiver Determination

       Transformation Step

In transformation steps, resource consumption is dependent on the mapping called.


       Wait Step

      Step types with low resource consumption:

       Control Step

       Multiple Condition



       Undefined Step

If you design the transactional behavior of an integration process so that the following steps are not performed as separate transactions, you can improve performance significantly:

      Transformation Step

      Receiver Determination

      Send Step (synchronous or asynchronous)

More information: Transactional Behavior of an Integration Process

Do Not Transfer Application Logic

Do not use integration processes to transfer application logic from the application systems to the Integration Server.

No Synchronous End User Communication

Do not use integration processes to connect synchronous end user communication (for example, call-center scenarios).

Sync/Async Communication

To enable the communication between a synchronously calling business system (synchronous outbound interface) and an asynchronously called business system (asynchronous inbound and outbound interface), you have the following options:

      Define a sync/async bridge in an integration process

More information: Example: Sync/Asynchronous Communication

      Set up sync/async communication using the JMS adapter

More information: Configuring Async/Sync and Sync/Async Bridge in the JMS Adapter

No Replacement for Mass Interfaces

Check whether it would not be better to execute particular processing steps, for example, collecting messages, on the sender or receiver system.


If you only want to collect the messages from one business system to forward them together to a second business system, you should do so by using a mass interface and not an integration process.

If you want to split a message up into lots of individual messages, also use a mass interface instead of an integration process. A mass interface requires only a fraction of the backend-system and Integration-Server resources that an integration process would require to carry out the same task.

More information: Mapping-Based Message Packaging

If you want to collect and bundle the messages of one interface or of multiple interfaces, use message packaging for integration processes.

Using Message Packaging Correctly

Message packaging for integration processes helps improve performance by delivering multiple messages to BPE process instances in one transaction.

Message packaging is particularly suitable for high-load scenarios. These are scenarios in which there is a throughput of a large number of messages. For this reason, the user needs to check for each process type, whether it makes sense to activate message packaging. The scenarios that particularly profit from message packaging are the "collect scenarios". The following two scenarios are possible: Collecting and bundling messages from one interface and Collecting and bundling messages from multiple interfaces.

If message packaging is activated, you can use transactions SWF_INB_MON and SWF_INB_ADM for monitoring and administering messages.

More information: Message Packaging for Integration Processes

Typical Scenarios

You would normally use an integration process when you need to save the processing status for message processing within the process. If this kind of stateful processing is not required, check whether you are able to realize the process simply by using the Integration Server (without integration processes) instead.

The following table shows typical examples of where integration processes can be used.

Application Case

More Information

Send a message to multiple receivers and wait for a response message from each of the receivers. The number of receivers is determined at runtime.

Example: Multicast - Multiple Receiver (with Response Message)

Define the order in which messages from the integration process are sent. 

Example: Serialization – Defining the Send Sequence


Collect multiple messages from one interface or multiple interfaces, bundle them into a single message and then forward this bundled message.

These scenarios are particularly suitable for message packaging.

More information: Using Message Packaging Correctly

Example: Gathering and Bundling Messages from One Interface

Example: Collecting/Bundling Messages from Multiple Interfaces

Send one message from an integration process synchronously to multiple receivers. The first response message to arrive is to be processed further.

Example: Sending Synchronously to Multiple Receivers

Define deadline monitoring for the receipt of a response message.

Example: Deadline Monitoring for the Receipt of a Response Message

Further Checklists

Checklist: Making Correct Use of Correlations

Checklist: Checklist: Making Correct Use of Dynamic Processing

Checklist: Making Correct Use of Mappings



End of Content Area