Sending and Executing tRFC LUWs (SAP Library)

Sending and Executing tRFC LUWs

The tRFC Managers in both systems (tRFC client and tRFC server) use synchronous RFC to communicate. This occurs in two phases:

Phase 1: Function Shipping

· All LUW data is sent to the partner.

· If CPIC errors occur, the transfer can be repeated (using transaction SM59).

· The tRFC server uses the TID to check whether the LUW has already been executed (inserted into the database table ARFCRSTATE).

· The tRFC server informs the tRFC client that the LUW has been executed successfully.

· The function ARFC_DEST_SHIP executes this phase.

Phase 2: Confirmation

· The tRFC client sends a confirmation to the tRFC server.

· The tRFC server deletes the TID in the TID table.

· The tRFC client deletes all LUW data that belongs to this TID.

· The LUW has been executed successfully.

· The function ARFC_DEST_CONFIRM executes this phase.

This graphic is explained in the accompanying text

This graphic is explained in the accompanying text

Note that the destinations NONE and SPACE can have different meanings:

· SPACE LUW is executed on any application server.

· NONE LUW is executed on the same application server as the caller.

· SPACE is interpreted as NONE.

· NONE is interpreted as an internal destination (such as pwdf0211_AX4_15).

· Each tRFC call with a separate unit is a sub-LUW (separate TID).

· All tRFC calls that use the same destination are assigned to a sub-LUW.

· All sub-LUWs and the main LUW are handled as a single LUW (in accordance with commit/rollback).

· Each sub-LUW is handled as a separate LUW (while it is sent and executed in the target system).

· RSARFCRD: tRFC Monitor (transaction SM58)

· RSARFCSE: Restart an LUW (background job)

· RSARFCEX: Restart tRFC LUWs (background job)

· RSQOWKEX: Restart QOUT qRFC LUWs

· RSQIWKEX: Restart QIN qRFC LUWs

· RSARFCSE: Delete an LUW (background job)

· RSARFCER: Delete various LUWs

Continue by reading the following: