Staging should only be used for asynchronous message processing and not for synchronous interfaces. In general staging should be used when the separation of processing steps is required.
Some examples are mentioned next:
Frequent message failures due to unreliable backend connection or e.g. locking issues:
In this case the overhead for executing with every retry the message mapping could be avoided by configuring staging after the mapping 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 using MODE_STORE_ON_ERROR for such cases as outlined in A11.4.
Another case could be a long running receiver determination due to excessive usage of XPath or slow mapping in the Extended Receiver Determination. If e.g. a sequential adapter like File is used this could slow down the overall processing time since the next file would only be polled after the Receiver Determination was finished. To isolate the processing on adapter level from the long running Receiver Determination the message should be persisted directly after the inbound processing (set BI=3 or "Store" (on ICO level)).
In this example IDocs would fail in the Receiver Determination since special conditions in the XPath are not fulfilled. With the default staging option such a message would not be persisted in PI but would be rolled back on the ERP System. The IDoc would be in error on SM58 in the ERP system. If such cases should fail on PI (Process Integration) side you can avoid the rollback by configuring staging after the inbound processing. When doing this the messages would be persisted on PI side and the eror handling would happen here. Before using this please check A11.2 for details below.