SAP PI Staging and Logging FAQs
Q1: For which runtime is staging/logging relevant?
A1: Staging and logging are only appropriate for the Java-only PI runtime using Integrated Configuration objects. Technically it is also applicable for "classical" PI dual stack scenarios where ABAP and Java runtime is utilized. In such "classical" case a message is already persisted many times (2 times on Java and 3 times on ABAP (per default)). Therefore, no additional persistence on the Java inbound/outbound side should be required. Due to this staging/logging is not supported for "classical" scenarios.
Q2: What is staging?
A2: Storage of an asynchronous message at a runtime stage for later editing/restart of the message from the persisted version. The staged message can be also displayed (monitoring of staged message).
Q3: What is logging?
A3: Storage of any kind of message (asynchronous and synchronous) at some processing step for later displaying the logged message (no editing/restart is possible).
Q4: Where can staging as well as logging be configured?
A4: Staging was initially introduced starting from 7.3. The following is a list which shows you what can be done with which release:
Starting from 7.3:
Staging for async messages can be globally configured by using parameter xiadapter.stage.conf of J2EE service XI Adapter. Logging is unavailable
Starting from 7.31 SP0:
Staging for async messages can be configured globally by using parameter xiadapter.stage.conf and scenario-based in the "Advanced Settings" tab of the ICO Object in the Directory. The logging for sync messages can be configured globally by using parameter xiadapter.logger.conf and scenario-based in the "Advanced Settings" tab of the ICO Object in the Directory.
Starting from 7.31 SP4:
In addition staging and logging for async messages can be configured scenario-based in the "Advanced Settings" tab of the ICO Object in the Directory.
Generally, we advise not altering staging/logging globally since every interface does not have the same requirements and there a few limitations also which apply (see Q10 and Q11 for details). Rather than the configuration should be only done individually per interface based on the business requirements for this interface.
Q5: Explain the difference between staging and logging from runtime perspective?
A5: logging is only an additional persistence step, staging alters the transactional behaviour of message processing. For each staging step a context switch in the processing occurs. This refers to a new message version is persisted, the message is put into the Messaging System queue again and is processed by another Messaging System consumer thread once a free thread is made available. If logging is configured no such context switch will take place. The thread will exist and the message and continue with the processing.
Q6: What is the effect of logging have for message processing?
A6: Each additional logging step will insert the message version into the database. Hence there is additional overhead on the database server and the message processing gets delayed by the time the additional insert statement takes.
Q7: What impact does staging have for message processing?
A7: The database overhead is the same then for logging. Additionally, when putting the message into the queue again the message will be put at the end of the Messaging System queue. In case of a message backlog in the queue, this can lead to additional delay as the message has to wait until processing capacity is made available again.
Q8: Explain the default behaviour for staging as well as logging?
A8: For asynchronous interfaces, each message is utilizing staging post the Receiver Determination step. This corresponds to MS=3 and results in the same behaviour as in initial releases. No logging is utilized for asynchronous interfaces. Synchronous messages are per default not utilizing any logging at all.
Q9: When should you use logging?
A9: Generally, Logging should be used for message processing incase there is a business requirement for storing additional versions of the payload for later monitoring or for tracking related purpose. Logging of synchronous messages is only made available from PI 7.31. From PI 7.31 SP04 onwards logging can also be utilized for asynchronous messages. Some examples have been listed as follows:
Example 1: Tracking of the message payload post mapping
Per default, the message is only persisted prior to the receiver determination. The message is per default not persisted post mapping. Therefore, in case the adapter does not persist the outgoing message there is no possibility to verify the data send to the partner. In such a scenario the level "Log" should be selected for the Mapping (step AM).
Example 2: Logging of synchronous messages in error
Synchronous messages are per default not persisted at all. Also in case of an error the messages are only kept in a cache which is evicted after some time. Therefore, logging of synchronous messages in case of an error is very useful for later troubleshooting related purposes. In such a scenario. all three logging steps would have to be configured with the value "Log on error". Incase the payload is not required due to e.g. the interface is generally failing with connectivity issues the value "Log on error without payload" could be selected.
Example 3: Logging of successful synchronous message processing for testing/troubleshooting
For testing or troubleshooting, productive scenarios logging of all synchronous messages (also successful ones) can only be temporarily activated. This is quite similar to setting the parameter LOGGING_SYNC in the ABAP stack. However, on Java side this can be configured per interface for keeping the impact minimal. for further reducing the overhead (especially on productive systems) user can also select to not persist the payload minimize the overhead. For doing so choose the "Log without payload" for the Mapping (step AM).
Q10: When should you use staging?
A10: Staging should ideally only be used for asynchronous message processing and not for the purpose of synchronous interfaces. Generally staging should be used when the separation of processing steps is essential. Some of the examples have been listed below:
Example 1: Frequent message failures because of unreliable backend connection or e.g. locking issues
In this scenario, the overhead for executing with every retry the message mapping can be averted by configuring staging post mapping the call (by setting AM=3 or "Store" (on ICO level)). By doing this the retry would use the mapped message payload and would only try to resend the message to the receiver system. Be careful by utilizing MODE_STORE_ON_ERROR for such scenarios as listed in A11.4.
Example 2: Another instance would be a long-running receiver determination because of excessive usage of XPath or slow mapping in the Extended Receiver Determination.
If e.g. a sequential adapter like File is utilized this could slow down the overall processing time as the next file would only be polled after the Receiver Determination was completed. For isolating the processing on adapter level from the long-running Receiver Determination the message should be continued directly post the inbound processing (set BI=3 or "Store" (on ICO level)).
Example 3: In this example, IDocs fail in the Receiver Determination as the special conditions in the XPath are not being fulfilled.
With the default staging option like a message would not be persisted in PI, however, would be rolled back on the ERP system. The IDoc would be in an error on SM58 in the ERP system. If such scenarios would fail on PI side user can avoid the rollback by configuring staging post the inbound processing. When doing this the messages would be continued on PI side and the error handling would take place here.
Q11: What all should the user consider when configuring staging for the various steps of processing?
A11)
Usage of staging for QoS EOIO:
For EOIO staging prior to the Receiver Determination (e.g. at聽steps BI or VI) can be avoided as and when possible. The reason is that staging directly influences the serialization context of a message. Essentially, post Receiver Determination the receiver component is a component of the Serialization Context of a message. If you use BI=1 (MODE_STORE_ON_ERROR) this can lead to severe serialization issues in case of message failure during the Receiver Determination. Therefore if staging is essential (e.g. for avoiding a rollback to sender systems) we suggest using BI=3 for avoiding these issues.
SAP Document 1678427 introduces a sequence cache for correlating serialization contexts prior and after receiver determination. Depending on the number of parallel EOIO queues it may be important to tune this cache. The corrections of this Note address the most critical problems however since the introduced cache for the serialization context mapping is not persisted messages may remain in HOLD post a server node restart. A11.2: Usage of MODE_STORE_ON_ERROR prior to the determination of the receiver. (e.g. step BI):
Due to a problem in the transaction handling the MODE_STORE_ON_ERROR prior to the determination OS the receiver caused issues.
Impact on the MaxReceiver parameter:
With Document 1493502 a mechanism is introduced to limit the number of parallel threads per interface for avoiding that one interface can devour all the available adapter threads or overload the backend system. This maxReceiver parameter for ICO only functions once the receiver of an interface has been determined. This refers to that in case the user has configured staging prior to the Receiver determination (step BI) more threads than the number configured in MaxReceivers can be utilized. Generally, this should be no problem in case default MS=3 has been configured as all the expensive steps (like mapping call or call to the backend) takes place later.
Staging of messages in case of errors during the process of module processing:
If you are utilizing the modules which alter the payload of a message during processing the user should avoid using MODE_STORE_ON_ERROR as the last staging configuration (e.g. VO=1) for the processing of messages. The issue is that in case of an error during the module processing or later receiver communication the altered payload will be persisted. Incase the message is restarted then the module will fail because of an unexpected payload. Therefore, if you have modules altering the payload then avoid using MODE_STORE_ON_ERROR: Use MODE_STORE_AND_RETURN instead for saving the message prior to the medication of the module.
Q12: Is it possible to combine logging as well as staging?
A12: Starting from PI 7.31 SP4 Staging and Logging can be put together for asynchronous messages. This can better isolated for instance e.g. the inbound processing by utilizing post inbound processing and permitting logging after mapping for business-related purposes.