Here you can see the what points we have to be consider when configuring staging for the different processing steps?
Usage of staging for QoS EOIO
For EOIO staging before the Receiver Determination (e.g. at steps BI or VI) should be avoided whenever possible. Reason here is that staging also has a direct influence on the serialization context of a message. Essentially, after Receiver Determination the receiver component is part of the Serialization Context of a message. If you use BI=1 (MODE_STORE_ON_ERROR) this can cause severe serialization issues in case of message failure during Receiver Determination. Therefore if staging is really required (e.g. to avoid rollback to sender systems) we recommend to use BI=3 to avoid these issues.
1678427 introduces a sequence cache to correlate serialization contexts before and after receiver determination. Depending on the number of parallel EOIO queues it might be necessary to tune this cache. The corrections of this addresses the most critical problems but since the introduced cache for the serialization context mapping is not persisted messages might remain in HOLD after a server node restart. Furthermore there were a number of important fixes in this area to address the most severe issues: 2177278, 2177278, 2172497 and 2167594. Whenever possible we strongly recommend to avoid staging for EOIO interfaces before Receiver Determination (MS) step.
Usage of MODE_STORE_ON_ERROR before receiver determination (e.g. step BI):
Due to a problem in the transaction handling the MODE_STORE_ON_ERROR before receiver determination caused issues. This problem is fixed as described in SAP 1979353.
Impact on MaxReceiver parameter:
With 1493502 a mechanism is introduced to restrict the number of parallel threads per interface to avoid that one interface can consume all available adapter threads or overload the backend system. This maxReceiver parameter for ICO only works once the receiver of an interface is determined. This means that in case you have configured staging before the Receiver determination (step BI) more threads than the number configured in MaxReceivers can be used. This should in general be no problem in case default MS=3 is configured since all expensive steps (like mapping call or call to the backend) happen afterwards.
Staging of messages in case of errors during module processing:
If you are using modules that change the payload of a message during processing you should avoid using MODE_STORE_ON_ERROR as the last staging configuration (e.g. VO=1) for the message processing. The problem is that in case of an error during the module processing or later receiver communication the modified payload will be persisted. If the message is then restarted the module will fail due to an unexpected payload. Hence if you have modules changing the payload avoid using MODE_STORE_ON_ERROR: Use MODE_STORE_AND_RETURN instead to store the message before the module modification.