Data is transferred between SAP ERP and SAP APO by means of queued remote function call (qRFC) technology. Faulty queue entries can lead to extended queue blocks and inconsistencies between SAP APO and SAP ERP. You can use CIF error handling to avoid queue blocks of this type during the transfer of transaction data.
CIF error handling ensures that all CIF queue entries are processed during the data transfer. Faulty queues no longer lead to queue blocks. Instead, they are logged in postprocessing records in the relevant target system for the data transfer. You can then call these postprocessing records at a later point in time in CIF postprocessing. Once the error has been corrected you can then send the objects to the relevant target system again.
CIF error handling is not available in the following situations, which means that CIF queues hang when errors occur:
● At the initial data transfer
● At the transfer of master data (initial and change transfer)
● At short dumps or when liveCache is unavailable
● When the target system is unavailable
● When an object is locked in the target system (as before for the repetition of the transfer)
● If errors occur in customer exits or BAdIs that run in CIF inbound function modules during integration
● When posting terminates in SAP ERP inbound. If posting terminates in SAP ERP when transfers are being made from SAP APO to SAP ERP, the CIF queues are processed as before and they are no longer displayed in the queue monitor. Processing by CIF is already complete by the time the data is posted in SAP ERP. Therefore, CIF error handling does not take into account terminations in posting in SAP ERP and does not generate any postprocessing records.
You can find information about restrictions to CIF error handling when using certain applications and functions in SAP Note 602484.
Since not all errors are included in CIF error handling, faulty queue entries may continue to exist once CIF error handling has been activated. Faulty queue entries can also block objects that are resent by CIF postprocessing. Therefore, you still need to monitor CIF queues by using the qRFC monitors for inbound or outbound queues, or by using the SCM Queue Manager. If you want to send a message to the initiator or system administrator when errors occur, you can also use the qRFC alert.
Postprocessing, No Splitting of LUWs is set in the Error Handling column in SAP APO Customizing under Basic Settings → Integration → Business System Group → Assign Logical System and Queue Type (transaction /SAPAPO/C2). The default setting is Strict (that is, CIF error handling is not active as standard).
The setting applies to transfers between SAP APO and the specified logical SAP ERP system in both directions.
1. If a change to transaction data cannot be posted in the target system due to an error, the system creates a postprocessing record with the error status Faulty for the object concerned.
2. The system also creates postprocessing records for all other objects of the qRFC LUW in which the error occurred (dependent postprocessing records). Postprocessing records with the error status Without Errors are created for RFCs without errors from before the faulty transfer. Subsequent RFCs in the same LUW are not processed by the system and lead to the creation of postprocessing records with the error status Object was not processed (ignored). If several objects are transferred within one RFC, all postprocessing records for these objects have the same error status.
3. None of the objects for which the system creates postprocessing records are posted to the target system. However, the CIF queue continues to be processed (that is, a queue block does not occur).
4. For transfers from SAP APO to SAP ERP, the system also checks whether postprocessing records already exist with the processing status Still for Processing and, if so, sets them to Obsolete (automatically set by system). As a result, only one postprocessing record with the status Still for Processing can exist in this processing direction.
5. For the transfer from SAP ERP to SAP APO, postprocessing records that already exist do not automatically receive the processing status Obsolete (automatically set by system). This means that several postprocessing records with the status Still for Processing can exist for one object. These are later retransferred in the original sequence.
6. Depending on the settings you choose under CIF Postprocessing Alert, the system uses SAP Office Mail to inform the initiator of the error or the administrator that a postprocessing record was created.
7. You can analyze the postprocessing records that are created by using CIF Postprocessing. If you choose CIF Postprocessing – Multiple Call, several users can process postprocessing records for the same target system. If you only want to display the postprocessing records, choose Display CIF Postprocessing Records.
8. Remove the cause of the error.
9. Use CIF postprocessing to resend to the target system the object in which the error occurred. For this, the system always transfers the current object status, which means that this may include changes that were made to the object in the meantime.
10. All prerequisite postprocessing records for this postprocessing record are also automatically transferred to the target system. For more information about system behavior when retransferring objects, see Resending Objects.
11. Postprocessing records that have been processed or that are obsolete are not deleted automatically by the system. You can delete them under Reorganization of Postprocessing Records. We recommend that you schedule this program as a regular job.
Note that activating CIF error handling leads to a different approach to the monitoring of integration. If CIF error handling is not active, you first call the SCM queue manager and then the CIF comparison/reconciliation of transaction data. If CIF error handling is active, you first check whether postprocessing records exist, then call the SCM queue manager, and then the CIF comparison/reconciliation of transaction data.