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.
- 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.
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.
- 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.
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.