BPM Performance: 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.
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 of Different Step Types 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. In general, process steps that generate work items internally are relevant for process performance. Transformation steps (either for message split or merge) also include a mapping step and can be quite expensive. This should be taken into consideration during scenario design.
• ○ 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)
Transactional Behavior of an Integration Process
Use
You can now influence transactional behavior in the definition of an integration process in the process editor. This enables you to improve performance.
Transaction:
A transaction is a sequence of processing steps that are either fully executed, or not executed at all. If the system cannot fully execute a transaction, it rolls back all processing steps within the transaction. This means that the system can return to the state before the transaction was begun.
The transaction control mechanism for integration processes is not a central transaction manager for an entire system landscape. The transaction control mechanism cannot roll back any processing steps outside the Integration Server.
Transaction Boundaries
You have the option of defining the start or end of a block as the boundary of a transaction.
● In the case of the start of a block, you can define that the system is to start a new transaction.
● In the case of the end of a block, you can define that the system is to end the transaction being started (COMMIT WORK). The system ends the transaction that is currently open, regardless of whether it has been started or not. For example, if no new transaction was started at the start of the block, the last transaction started is continued instead.
By making appropriate settings for the start and end of a block you can expand transactions. This means that the database needs to be accessed less often, and enables you to improve system performance
Transactional Behavior for Specific Step Types
At runtime, the system normally creates a separate transaction for each step. The transaction then covers this step only. However, you can influence the transactional behavior of particular step types. In the step properties, you can define that the system is not to start a new transaction when the step is executed. The system then executes the step in the transaction that was started at the time of execution. Consequently, no background work item is created for the step and the database does not need to be accessed. In this way you can improve system performance.
You can influence the transactional behavior of the following step types:
● Send step
You can influence the transactional behavior when sending messages both synchronously and asynchronously, and when sending acknowledgments
• Transformation Step
• Receiver Determination Step
Optimizing Transactional Behavior:
● Memory requirements
Expanding transactions and executing specific steps without creating a new transaction may increase the burden on the main memory. If the burden on the main memory is too great, you must redefine transactions, or define that a new transaction is to be created for the step concerned.
● Troubleshooting in the workflow log
The technical view of the workflow log does not show any detailed information for steps for which no work item was created. If an error occurs, the workflow log displays the error information for the last executed step. The following example illustrates this:
A process contains a transformation step that is executed within an expanded transaction. When the transformation step is executed, an error occurs in mapping and the system rolls back the transaction. Since no work item was created for the transformation step, the workflow log does not have an entry for the transformation step. The error information is entered in the last executed step in the workflow log.
EXAMPLE:
For an example of resource consumption, see the BPM scenario described in the XI sizing guide:
The inbound SOAP messages are handed over to the BPE, which triggers a two-step process consisting of message reception and sending. The processed messages are then sent to a receiver by using the SOAP channel; no mapping.
The SAPS value for this scenario, in which 10 kB messages are processed, is 1300 (processing one process instance each second). A simple XI proxy scenario, for example, requires 140 SAPS process-ing one message each second. This gives you an idea of the resource requirements using BPM.
Example:
In the original implementation, two separate JCBC calls were made to retrieve a sales order document header and the line items. This data then was transformed to the IDoc format of the receiving application using a transformation. Then, using a loop step, one IDoc at a time was sent to the backend application. - This sub optimal design resulted in poor performance caused by following design flaws:
Separate retrieval of header and line items with the JDBC adapter
Transformation within ccBPM to combine retrieved header and line items
IDoc back end connection for one document at the time
In the improved version below, both the JDBC call and the transformation were removed from the ccBPM. The retrieval of the source messages is done via a synchronous call with two mappings in the integration engine of XI that generate the required format for the receiving system. Therefore, it is not necessary to add an additional transformation step in the ccBPM. Additionally, the IDoc adapter connecting to the target system is used to handle multiple IDocs inside one XI message. Therefore, it is not necessary to add a loop operation within the ccBPM either. – In this particular implementation, the described changes resulted in a 20x performance improvement!
IMP LINKS:
3bf550d4-0201-0010-b2ae-8569d193124e.pdf
43e8e190-0201-0010-3ea1-d6f996cb4124.pdf
70ada5ef-0201-0010-1f8b-c935e444b0ad.pdf
c071d7bb-0601-0010-d6b8-f4e4dc7f1e20.pdf
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.