https://blogs.sap.

com/2012/11/06/message-staging-and-logging-options-in-advanced-
adapter-engine-of-pi-73x/

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.