RFC Transactional RFC (tRFC) queue RFC(qRFC) 概念

Transactional RFC

When using transactional RFC (tRFC), the called function module is executed exactly once in the called system (service property: Exactly Once).

The remote system does not have to be available when the RFC client program is executing a tRFC. The tRFC component stores the called RFC function in the SAP system database under a unique transaction number (TID), along with the corresponding data.

If a call is sent, and the receiving system is down, the call remains in the local queue. The calling dialog program can proceed without waiting to see whether the remote call was successful. If the receiving system does not become active within a certain amount of time, the call is scheduled to run in batch.

Transactional RFCs use the suffix IN BACKGROUND TASK. 

As with synchronous calls, the DESTINATION parameter defines a program context in the remote system. If you call a function module with the same destination several times (or several function modules once), you can therefore access the global data for the called function module in the same context.

The system logs the remote call request in database tables ARFCSSTATE and ARFCSDATA with all parameter values. You can display the log file using transaction SM58. When the calling program reaches a COMMIT WORK, the remote call is forwarded to the requested system.

All tRFCs with a single destination that occur between one COMMIT WORK and the next belong to a single logical unit of work (LUW).

 

tRFC Process Flow Diagram

You can use transactional RFCs, for example, for complex processes that require updating of related database tables during different phases in a transaction.

Transactional RFC processing ensures that all the planned updates are carried out when the program reaches the COMMIT WORK statement.

Function modules that are called transactionally cannot have any EXPORT parameters in their definition, as a corresponding IMPORTING parameter in the calling program causes syntax errors.

Note also that you cannot make asynchronous calls to functions that perform call-backs.

System Availability

If the remote system is unavailable, the SAP System uses the relevant transaction ID (TID) to schedule report RSARFCSE as a background processing variant. This report, which forwards asynchronous calls for execution, is called repeatedly until it succeeds in connecting with the system in question.

When scheduled in batch, RSARFCSE runs automatically at set intervals (the default setting is for up to 30 attempts at 15 minute intervals). You can customize this interval and the length of time the program should carry on trying for. Use enhancement programsTo configure a destination, call transaction SM59, select the screen for a destination and choose Edit ® TRFC Options. This enables you to set the maximum number of connection attempts and the intervals at which they are made.

If the system cannot be reached within the specified amount of time, the system stops calling RSARFCSE, and the status CPICERR is written to the ARFCSDATA table. Within another specified time (the default is eight days), the corresponding entry in the ARFCSSTATE table will be deleted (this limit can also be customized). It is still possible to start this type of entry manually in transaction SM59. 

 

Further Information

●  You can find a description of the statements for tRFC in:

●  CALL FUNCTION IN BACKGROUND TASK 

 

CALL FUNCTION - IN BACKGROUND TASK  

Syntax

CALL FUNCTION func IN BACKGROUND TASK

  [DESTINATION dest]

  parameter list

  [AS SEPARATE UNIT].

Addition:

... AS SEPARATE UNIT

Effect

Transactional call of a remote-capable function module specified in func using the RFC interface. You can use the addition DESTINATION to specify an individual destination in dest. NONEWhen the transactional call is made, the name of the called function, together with the destination and the actual parameters given in parameter list, are registered for the current SAP LUW in the database tables ARFCSSTATE and ARFCSDATA of the current SAP system under a unique transaction ID (abbreviated简称 as TID, stored in a structure of type ARFCTID from the ABAP Dictionary, view using transaction SM58). Following this registration, the program making the call is continued by way of the statement CALL FUNCTION.

When executing the COMMIT WORK statement, the function modules registered for the current SAP LUW are started in the sequence in which they were registered. The statement ROLLBACK WORKdeletes all previous registrations of the current SAP LUW.

If the specified destination is not available for COMMIT WORK, an executable called RSARFCSE is started in the background. This attempts to start the functional modules registered for an SAP LUW in their destination, every 15 minutes up to a total of 30 times. You can make changes to these parameters using transaction SM59. If the destination does not become available within the given time, this is noted in the database table ARFCSDATA as a CPICERR entry. By default, this entry in database table ARFCSSTATE is deleted after 8 days.

Addition

... AS SEPARATE UNIT

Effect

When using the addition AS SEPARATE UNIT, the relevant function module is executed in a separate context, a context in which the global data of the function group is not influenced by previous calls. Each function module that is registered with the addition AS SEPARATE UNIT is given a separate transaction ID. Without the addition AS SEPARATE UNIT, the usual description is applicable for the context of the called function modules. What this means is that, when using the same destination for multiple calls of function modules belonging to the same function group, the global data of this function group is accessed collectively.

You can use the function module ID_OF_BACKGROUNDTASK to define the transaction ID (TID) of the current SAP LUW, according to a transactional RFC.

The transactional RFC (tRFC) is suitable for realizing LUWs in distributed environments (a typical application is ALE). Here it must be noted that although executing the function modules within a transaction ID is predefined, the sequence of the LUWs on the RFC servers does not necessarily correspond to the sequence of SAP LUWs in the RFC client. To achieve a serialization on the RFC servers as well, the tRFC can be enhanced to queued RFC ( qRFC). For this, you can call function module TRFC_SET_QUEUE_NAME before a transactional RFC.

 

 

CALL FUNCTION - IN BACKGROUND TASK parameter_list

Syntax

... [EXPORTING p1 = a1 p2 = a2... ]

 [TABLES  t1 = itab1 t2 = itab2 ...] ... .

Effect

These additions are used to assign actual parameters to the formal parameters of the function module. The significance of the additions is the same as for synchronous RFC with the exception that no values can be copied with IMPORTING and CHANGING, and no return values can be allocated to exceptions that are not class-based.

 

Queued RFC (qRFC) 

The qRFC (queued Remote Function Call) is an extension of the tRFC. It allows you to serialize tRFC calls using a queue.

The tRFC call is preceded by function module TRFC_SET_QUEUE_NAME, which starts the serialization. The calls are then actually dispatched by a tRFC call.

The qRFC can be made with an outbound queue (serialization at the calling application) and also an inbound queue (serialization at the called application).

This results in the following scenarios for transactional data transfer:

Scenario 1: tRFC

This scenario is appropriate is the data being sent is independent of each other. A calling application (client) in system 1 uses a tRFC connection to a called application (r server) in system 2. In this scenario, data is transferred by tRFC, meaning that each function module sent to the target system is guaranteed to be executed once only. You cannot define the sequence in which the function modules are processed or the time when this happens. If an error occurs during the transfer, a batch job is scheduled, which sends the function module again after 15 minutes.

Scenario 2: qRFC with outbound queue

In this scenario, the sending system uses an outbound queue to serialize the data being sent. This means that mutually dependent function modules are placed in the outbound queue of the sending system. When the data is sent, the exact order is kept to, and the calls are sent to the target system exactly once in order.

The server system coding does not need to be changed in order to process qRFC calls. However, it must be tRFC enabled.

Scenario 3: qRFC with inbound queue (and outbound queue)

In this scenario, as well as an outbound queue in the sender system (client), there is also an inbound queue in the target system (server). If a qRFC with inbound queue exists, this always means that an outbound queue exists in the sender system.

The inbound queue only processes as many function modules as the system resources in the target system (server) at that time allow. This prevents a server being blocked by a client. A scenario with just one inbound queue in the server system is not possible, since the outbound queue is needed in the client system in order to set the order and to prevent individual applications from blocking all work processes in the client system.

More Information

You can find detailed information about qRFC in:

●  Queued Remote Function Call (qRFC)

Queued Remote Function Call (qRFC) 

 

Purpose

The qRFC is an enhancement of the Using Transactional Remote Function Calls that also allows you to send and receive data in a fixed call order.

While the tRFC offers the service quality Exactly Once (EO) (the call is guaranteed to be executed only once), with the qRFC, you can work with the method Exactly Once In Order (EOIO).

The service quality EOIO is important if the data must be posted in the same order in which is was created or sent for business or technical reasons.

Integration

The qRFC is based on the same transactional basic function as the tRFC.  For this reason, qRFC communication can only take place between tRFC-enabled systems.

The qRFC is enhanced by an additional queuing mechanism, which saves the LUWs to be sent or received in an outbound queue or an inbound queue respectively. These LUWs are sent or transferred to the receiver application in the exact order in which they were saved.

Additional Information

For more information about qRFC, see:

The qRFC Communication Model

●  qRFC with Outbound Queues

●  qRFC with Inbound Queue

qRFC Administration

●  qRFC Administration: Introductory Example

●  Outbound Queue Administration

●  Inbound Queue Administration

qRFC Programming

●  qRFC Programming: Introductory Example

●  Outbound Queue Programming

●  Inbound Queue Programming

●  qRFC API