Performance Tuning Checks in SAP Exchange Infrastructure(XI): Part-II
Part-II of this series will focus on the Intergation Server component of Exchange Infrastructure as shown in the figure below. The performance checks can be categorized as follows:
1. Messages coming into the Integration Server:
Messages can come either from the AFW or directly, if you are using a Idoc Adapter or a Plain Http adapter as shown in the figure below.
I will focus more on the Idoc Adapter here, as the http adapter is a direct post into the Integration server via a URL. Tuning the Sender Idoc Adapter is entirely dependent upon the Sender SAP System. Below are some of the tuning tips for the messages entering the Integration Server:
A. In the sender system, collect the idocs and send the idocs as packages to Integration Server using a single tRFC call instead multiple tRFC calls. Integraion Server will create individual XML messages for each idoc sent in the package.
B. Register the destination system (XI) in Transaction: SMQS of the sender system and define maximum number of connections for the parameter: MAXCONN.
C. For idoc to idoc scenarios, if possible avoid converting the idoc to idoc-XML. The idoc specific parameters can be set up in Integration engine configuration.
2. Messages in the Integration Server Pipeline Service:
As Shown in the figure below, the pipeline service performs a series of steps to process the messages with in the Integration Server. The first 3 steps are handled by the Inbound Queues and the rest by the Outbound Queues. Below are some of the tuning tips for pipleine processing:
A. Make sure the Integration Server has enough dialog work processes to handle all the tRFC/qRFC communications. The default thumb rule for SAP PI is: Number of dialog work processes = 4 x Number of CPU's. If there are two many dialog processes, they consume CPU and memory which can create a resoruce botteleneck for Adapter engine and Business Process Engine. If there are few dialog processes, then there are not enough resources for qRFC and tRFC communications and the messages are waiting in the queues for a longer time.
B. You can also create a separate RFC Server group in Tr: RZ12 and assign this group to a QOUT (Qin) Scehduler. This server group will be used for processing tRFC calls with the only limitation that this server group will be used for all outbound tRFC calls.
C. Tuning Parameters for Parallel Processing:
1.)EO_INBOUND_TO_OUTBOUND: This parameter defines whether messages with quality of Service Exactly Once(EO) are to be branched(Value:1) or not (Value:0) to a separate queue upon receiver determination. With Value 1, the interfaces can be separated at the business system and the disadvantage is more tRFC overhead. The prerequiste for this parameter is: EO_OUTBOUND_PARALLEL. With Value 0, there is less overhead on the tRFC part and there are chances for blocking situations.
2.)EO_INBOUND_PARALLEL: This parameter is evaluated in the Integration Server inbound channel and in the Integration Engines of the sender and receiver. It determines the level of parallel processing for messages with quality of service Exactly Once (EO). The Subparameter CENTRAL/SENDER/RECEIVER is required. Note the sum of active inbound and outbound queues must be simliar or more than the number of dialog work processes for tRFC. You can also use the related parameter: B_EO_IN_PARALLEL_SENDER to separate specific senders from the rest.
3.)EO_OUTBOUND_PARALLEL: The parameter determines the parallel processing level of outbound processing of messages with the quality of service Exactly Once (EO) on the Integration Server. Use separate subparameters to tune each receiving business system. Note that the outbound queues also does mapping requests pipeline step, where the number of mapping connections must match the number of outbound queues and the j2ee engine must be able to handle the parallel requests.
D. Logging and Tracing: Each time the message is processed in a pipleline step, it creates log and trace entries to the database. To minimize these entires in Production PI Systems, the settings for LOGGING and LOGGING_SYNC must be set to Value '0' and TRACE_LEVEL to Value '1'.
3. Messages leaving from the Integration Server:
Below are some of the tuning tips for messages leaving the Integration Server covering the outbound IDOC Adapter and other adapters.
A. Register the outbound destination in Transaction: SMQS and define maximum number of connections for the parameter: MAXCONN.
B. Create packages of idocs via the design of your interface in the integration repository.
C. If possible, collect single idocs from the outbound queue and send them in one package using one logon and one trfc call to the receiving system which saves a lot of system resources.
D. For other adapters, if possibe allow many outbound queues to process messages in the receiving system via parallel processing. Make sure that there are enough tRFC resources available for parallel processing.
Part-III of this series will cover the Business Process Engine component.
References:
SAP online help documentation.
7 Comments
