Checklist: Making Correct Use of Integration
Processes
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.
Prerequisites
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.
○ Block
○ Wait Step
● Step types with low resource consumption:
○ Control Step
○ Multiple Condition
○ Fork
○ Loop
○ 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. |
|
Define the order in which messages from the integration process are sent. |
|
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:
|
|
Send one message from an integration process synchronously to multiple receivers. The first response message to arrive is to be processed further. |
|
Define 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