Show TOC

 CIF Error Handling

Purpose

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 recordsin 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.

Restrictions

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.

Note Note

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 .

End of the note.

Prerequisites

Postprocessing, No Splitting of LUWs is set in the Error Handling column in SAP APO Customizing under Start of the navigation path Basic Settings Next navigation step Integration Next navigation step Business System Group Next navigation step Assign Logical System and Queue Type End of the navigation path (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.

You can also activate CIF error handling during production operation. Queues that already existed before activation for transfers to SAP APO are taken into account by CIF error handling. For transfers to SAP ERP, this only applies to queues that are created after error handling has been activated.

If you deactivate CIF error handling during production operation, all postprocessing records must be processed.

Process

  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 LUWin 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.