SAP adapter scalability and performance
You can improve performance by configuring the number of listeners on the adapter and the number of additional instances on the message flow to prevent delays when processing synchronous calls from SAP.
The SAP inbound adapter receives synchronous calls from SAP. The adapter has a property called Number of listeners, which controls the maximum number of concurrent calls by configuring the adapter to have a particular number of threads listening to the SAP program ID. The listeners send the input parameters of these calls to the SAPInput node for processing, and the output parameters are sent to the SAPReply node.
When the listener receives a call from SAP, it blocks processing until a message flow instance that contains the SAPInput node is available. When a message flow instance has become available, and has started to process the import parameters, the listener again blocks processing until a message that contains the export parameters is propagated to an SAPReply node.
The amount of time that elapses between the SAPInput node sending the message and the SAPReply node receiving the reply message can be affected by the additional instances property on the message flow. To avoid delays in processing, tune the maximum number of listeners and the number of additional instances for the message flow that contains the SAPInput and SAPReply nodes. You can configure the number of additional instances at message flow level or on the SAPInput node itself.
Restrictions
The number of listeners is limited by the SAP configuration. In SAP transaction SMQS, you can view and change the maximum connections property for each RFC destination. Configuring a number of listeners greater than the maximum number of connections has no effect.
For each additional instance of the message flow, extra resources are used by each node in the flow, depending on the types of node in the flow.
Scenarios
- SAP makes three calls, each of which is received by a listener.
- Each of the listeners sends the input parameters of each call to the SAPInput node in one of three instances of the message flow.
- Each message flow instance sends its message to the target application.
- The target application processes the messages and returns replies to the message flow instances.
- The SAPReply node in each message flow instance sends the reply message to the listener that received the original call.
- Each listener returns the reply message to the appropriate SAP program.
- SAP makes three calls, each of which is received by a different listener.
- Each of the listeners sends the input parameters of each call to a message flow that contains an SAPInput node.
- The message flow puts the message onto a queue for the target application.
- The target application gets the messages from the queue and processes them.
- The target application puts the messages onto a queue.
- A second message flow that contains an SAPReply node gets the messages from the queue and processes them.
- The SAPReply node sends the reply messages to the appropriate listeners.
- Each listener returns a reply message to the appropriate SAP program.
- A single message flow contains an SAPReply node but it is used to reply to several SAPInput nodes. After the message has been propagated to the SAPReply node, the listener sends the reply back to SAP and is therefore ready to receive another call from SAP. However, the current instance of the message flow is still busy processing the nodes downstream from the SAPReply node. In this case, increase the number of instances on the message flow that contains the SAPReply node.
- After propagating to the SAPReply node, other nodes
in the message flow perform extra processing. In this case, increase
the number of instances on the message flow that contains the SAPReply node, even when it
is the same flow that contains the SAPInput node.
This scenario might have an undesirable effect on the integrity of your data. If an exception occurs after the SAPReply node, resources that are updated by the message flow (for example, database tables or IBM® MQ queues) might be rolled back. However, the reply has been sent back to SAP already and cannot be rolled back. If this behavior is not appropriate, you can improve data integrity by ensuring that the SAPReply node is the final node in the message flow.