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

The following diagram illustrates a basic scenario, where the number of listeners is equal to the number of additional instances of the message flow; in this case, the scenario has been configured with three listeners and three message flow instances.
This diagram illustrates the following steps.
  1. SAP makes three calls, each of which is received by a listener.
  2. Each of the listeners sends the input parameters of each call to the SAPInput node in one of three instances of the message flow.
  3. Each message flow instance sends its message to the target application.
  4. The target application processes the messages and returns replies to the message flow instances.
  5. The SAPReply node in each message flow instance sends the reply message to the listener that received the original call.
  6. Each listener returns the reply message to the appropriate SAP program.
The SAPReply node can be in the same message flow as the SAPInput node, as illustrated in the previous example. However, in the following scenario, the SAPReply node is in a different flow from the SAPInput node. The SAPReply node must be deployed in the same integration server as the SAPInput node.
  1. SAP makes three calls, each of which is received by a different listener.
  2. Each of the listeners sends the input parameters of each call to a message flow that contains an SAPInput node.
  3. The message flow puts the message onto a queue for the target application.
  4. The target application gets the messages from the queue and processes them.
  5. The target application puts the messages onto a queue.
  6. A second message flow that contains an SAPReply node gets the messages from the queue and processes them.
  7. The SAPReply node sends the reply messages to the appropriate listeners.
  8. Each listener returns a reply message to the appropriate SAP program.
In this scenario, the message flow has low latency compared to the time taken by the entire scenario. Therefore, you can limit the resources that are used by the message flow containing the SAPInput node by configuring fewer additional instances for this message flow. One instance of the message flow, as in the example, can service many listeners because the message flow propagates the import parameters quickly for processing.
The following scenarios are also possible.
  • 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 WebSphere® 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.

For information about how to tune the SAP adapter, see Tuning the SAP adapter for scalability and performance.