Show TOC

 Data Transfer Technique

Data is transferred in both directions by means of one or more queued Remote Function Calls (qRFC). The names of the function modules to be called and the relevant transfer parameters are first buffered on the database before being executed asynchronously in the sequence that they were called.

There are two types of buffering:

  1. Outbound qRFC. The data is saved temporarily on the database of the sending system.
  2. Inbound qRFC. The data is saved temporarily on the database of the receiving system.

Each function module call must be attributed with one or more queue names. Using the same queue name for different calls means that these calls must be executed in a serialized way. If the queue names are different, no sequence has been defined for relevant calls, and the calls can be executed either independently one after the other, or at the same time. Depending on the application case, serialization may be necessary for consistency reasons.

Multiple qRFCs can be combined into a logical unit of work (LUW), whereby one LUW on the sending side results in one LUW on the receiving side.

Schematic Presentation of LUWs

This means, on the one hand, that each individual function call into a target system is serialized with other calls by means of its queue name. On the other hand, multiple calls in the sending system can be combined into one LUW independently of the queue names. These calls are also executed in the target system within one LUW. By using the same queue names in calls with different LUWs, these LUWs are serialized among one another. At the end of an LUW in the target system, qRFC management triggers a COMMIT or, in the case of an error, a ROLLBACK. If an error occurs, the LUW gets an error status, but all the call data remains on the database. By using the qRFC technique you can therefore allow the processing of saved function calls to continue after you have corrected a problem without generating data inconsistencies.

Changes to production orders in the ERP system are an example of serialization using queues.Here the use of identical queue names ensures that older data does not overwrite newer data and that the SCM system does not contain obsolete data.

Goods receipt for a purchase order is an example of combining function calls within a process as an LUW. The use of one LUW ensures that stock posting can only be updated when the purchase order is changed in the SCM system. Since in this case more than one queue is used, it must be possible to process all the queues used in the LUW, that is, they must not be blocked, before this LUW can be processed.

When a queue cannot be processed, the problem could be due to technical connection errors (status CPICERR or RETRY) or to errors triggered by the application (status SYSFAIL), for example. Moreover, the user can stop and start specific queues in qRFC transactions, if necessary. In the case of CPICERR/RETRY, the data can, in most cases, be transferred successfully after the connection error has been rectified and the function calls have been executed again. However, in the case of an application error, a more detailed analysis is required. It could be that the function call does not run correctly in the target system with the conditions specified. In rare cases, you may need to manually delete an LUW to allow data that is following it to be processed. This could result in inconsistencies that can be rectified with suitable measures. The measure to be taken depends to a large extent on the problem that has occurred. For this reason standard solutions are not possible. One measure that proves suitable in many cases is the CIF comparison/reconciliation of transaction data (transaction /SAPAPO/CCR). This function is only available if you work with SAP APO.