In general Logging used for message processing if there is a business requirement to store additional versions of the payload for later monitoring or tracking purpose. Logging of synchronous messages is only available from PI 7.31. From PI 7.31 SP04 onwards logging can also be used for asynchronous messages.
Some examples are given below:
Example 1: Tracking of the message payload after the mapping:
Per default the message is only persisted before the receiver determination. The message is per default not persisted after the mapping. Hence if the adapter does not persist the outgoing message there is no possibility to verify the data send to the partner. In such a case the level "Log" should be chosen 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 that is evicted after some time. Therefore logging of synchronous messages in case of an error is very useful for later troubleshooting. In such a case all three logging steps would have to be configured with the value "Log on error". If the payload is not needed because e.g. the interface is usually failing with connectivity issues the value "Log on error without payload" could be chosen.
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 be activated temporarily. This is similar to setting the parameter LOGGING_SYNC in the ABAP stack. But on Java side this can be configured per interface to keep the impact minimal. To further reduce the overhead (especially on productive systems) you can also choose to not persist the payload minimize the overhead. To do so select "Log without payload" for the Mapping (step AM).