SAP R/3 форум ABAP консультантов

[admin]

REMOTE FUNCTION CALL:

The character conversion of the data to be transmitted is performed automatically.

Both single parameters and structures are supported for conversion.

The logon for remote SAP partner systems is automatic. The user and password are stored in the table RFCDES.

RFC calls in C are available for communicating with external programs (RFC-SDK). The RFC Generator also helps you when generating RFC programs in C.

If a function module is called remotely, it runs in its own work process (its own SAP LUW) if the remote system is an R/3 System.

The remote destination can be another application server in the same or a different R/3 System, an When you call a function module locally, it runs in the same work process as the calling program.

R/2 System, or an non-SAP system.

Note that the calling program is rolled out for each remote function call, which triggers an implicit database-commit.

You maintain RFC destinations that must specify an ABAP program when calling remote function modules in the RFC sideinfo table RFCDES using Transaction SM59.
For each partner system, you need to maintain one entry in the sideinfo table.

SAP delivers the RFC Library for all current external platforms, in which RFC calls are contained for C programs. After installing the RFC Library on your external platform, you can implement RFC client or RFC server programs using RFC calls.

With synchronous RFC, processing stops in the calling program until the called remote function is processed and its output is returned. Then in the calling program, the processing continues after the call.

In an asynchronous Remote Function Call, the called remote function is started and then continues processing on its own immediately in the calling program. Remote function processing is separate from the calling program. The function output can be received later in the program.

Asynchronous RFC is intended for parallel processing of processes.

Whereas with synchronous and asynchronous RFC each call makes up a single logical unit of work (LUW) in the remote system, you can use transactional RFC to bundle several remote functions into one LUW (with an automatic rollback mechanism in case of error).
With tRFC, generated LUWs are processed independently of each other. This means, the order in which they are processed is not always the order in which they are generated.

To ensure that tRFC-LUWs are processed in the same order as they were generated, you can use qRFC as an extension of tRFC.

qRFC is available as of Release 4.6A and can be used in R/3-R/3 connections as well as R/3-external connections.

Synchronous RFC:

With synchronous RFC, processing stops in the calling program until the called remote function is processed and its output is returned. Then in the calling program, the processing continues after the call.

The statement CALL FUNCTION ... DESTINATION enables you to call remote ABAP function modules or C routines in external server programs.

When you call a function in this way, always include handling for the standard exceptions COMMUNICATION_FAILURE and SYSTEM_FAILURE.

The exception COMMUNICATION_FAILURE is resolved by the system if the specified destination in the sideinfo table RFCDES is not maintained, or if the connection to the remote system cannot be established.

The exception SYSTEM_FAILURE is resolved if the function module or C routine that you want to start in the remote system is not available.

The connection to a remote destination remains intact for as long as the context of the calling program remains active. The function groups addressed in the remote destination remain active for as long as the calling program itself remains active (this is the same as with local calls). This means that if you call two function modules from the same function group one after the other, they can both access the same global data of the function group.

Each function module called using synchronous RFC forms its own logical unit of work (LUW) (exception:

You can debug function modules called remotely in R/3 - R/3 connections.

If a remotely-called function module uses dialogs (for example, CALL SCREEN,
CALL TRANSACTION or lists), they are executed in the session of the caller (and are fully functional).

Note that RFC dialogs in background processing lead to a program termination with the exception SYSTEM_FAILURE (but you can use RFC within background processing).

Asynchronous RFC:

In an asynchronous Remote Function Call, the called remote function is started and then continues processing on its own immediately in the calling program. Remote function processing is separate from the calling program. The function output can be received later in the program.

Asynchronous RFC is intended for parallel processing of processes.

With the addition STARTING NEW TASK you can call a remote function module asynchronously. You can use any task name.

The function module that you call is executed in its own work process.

You can also use aRFC in background processing. Note, however, that even here, each aRFC call occupies a dialog work process.

In the sideinfo table RFCDES, you can set the number of aRFC calls for each destination using the aRFC options. After these aRFC calls an automatic load check is performed on the target server. If resource bottlenecks are detected, the system waits for a short time for the next aRFC call,
meant for the same remote system, and the client program is rolled out of its work process. It can then receive results from previous aRFC calls.

During the call, you may not specify an IMPORTING addition since the call does not wait for the end of the function module. Here, you can only handle the two system exceptions, COMMUNICATION_FAILURE and SYSTEM_FAILURE for the same reason. The function module output must be received and the function module-specific exceptions must be handled later on in a different place. (See following slides)

Receiving the function module output and handling the function module-specific exceptions are optional, however.

A program can receive output (parameters and exceptions) from a function module that is running asynchronously.

To implement this, when you call use the addition "PERFORMING ON END OF TASK", where the specified subroutine must exist in your program, and through which the output of the function module is received using command "RECEIVE RESULTS FROM FUNCTION . .". When the function module ends, the subroutine is called automatically.

The subroutine must also have a formal parameter with any name you choose. When the subroutine is called, it receives the accompanying task name. This parameter lets you see which aRFC call just ended, and you can receive the relevant
output using the RECEIVE RESULTS FROM FUNCTION command.

The subroutine may not contain any statements that interrupt the program execution (such as CALL SCREEN, SUBMIT, COMMIT WORK, WAIT, RFCs, W or I messages). WRITE statements in this subroutine specially defined for aRFC have no effect.

The subroutine can only be executed automatically if the calling program is in rollout status. -> "WAIT UNTIL" statements (see next slide).

The addition KEEPING TASK with the RECEIVE statement causes the function group context that was loaded remotely to wait until the calling program has ended. This lets you use the old remote context with later aRFC calls with the same task name.

The language element WAIT UNTIL with the addition PERFORMING is only useful with aRFC, and otherwise has no effects.

When the WAIT UNTIL statement is executed, the conditions specified are checked.

If it is fulfilled, the program processing continues directly after the WAIT UNTIL statement.

Otherwise the system waits in rollout status for the output from the aRFCs. If the aRFC output is now returned, the form routine specified during the call is executed and is sent back to the WAIT UNTIL statement.
This check/wait procedure repeats until the WAIT conditions are fulfilled, or until there are no more open RFC calls.

Note that the WAIT UNTIL statement sets the SY-SUBRC. Therefore, store the SY-SUBRC value (set in the form routine by exceptions-handling in RECEIVE RESULTS) in its own global variable before leaving the form routine, if you need this value again later (after WAIT UNTIL).

aRFC is particularly suited for implementing parallel processing in several R/3 Systems.

You can also use aRFC within the same SAP R/3 System, for example, to move some of the processing load to an application server specially used for this.

Enter the RFC destination that refers to the corresponding application server. (You can find this under Internal connections in Transaction SM59.)

You can also use aRFC locally within the same application server to implement parallel processing in several work processes.

Here you do not need to specify a destination.

Note, however, that several work processes will be occupied by your program at the same time.

Load balancing using RFC groups:

You can divided the application servers for an SAP R/3 System into different RFC groups using Transaction SM59.

When calling a function module within this R/3 System, you can specify one of the defined RFC groups using the addition DESTINATION IN GROUP , which selects the server that has the lowest load in order to execute the function module.
Instead of specifying a specific RFC group, you can also enter the word DEFAULT. The server is selected from all the application servers of the R/3 System.

If all the servers of the specified group are overloaded (see next slide), the exception RESOURCE_FAILURE is triggered.

Note that:
- You have to specify the addition DESTINATION IN GROUP after STARTING NEW TASK as opposed to the DESTINATION addition.
- You can only use this addition within the current SAP R/3 System (you cannot have additional DESTINATION entries).

For each server in the specified RFC group, the system checks if the application server has:

- a dispatcher queue load of <> No IMPORTING . . . / PERFORMING . . . ON END OF TASK when calling;
-> No RECEIVE RESULTS FROM FUNCTION . . .

In the source system, you can use the administration transaction SM58 that lets you display and modify tRFC-LUWs.

Execution:

tRFC calls are first stored in the local tRFC tables ARFCSSTATE and ARFCSDATA. The execution status of the LUWs is logged in table ARFCSSTATE, while ARFCSDATA contains the input data for the tRFCs.

If you do not want to execute a remote LUW immediately, rather trigger it at a later time, call the function module START_OF_BACKGROUNDTASK before the COMMIT WORK statement locally. Here, you must enter the date and time of execution.

The COMMIT WORK statement automatically schedules an immediate job or a job set for a later start time to remotely call the LUW. In the job execution, the relevant data is read from the tRFC tables, and the corresponding tRFCs are transmitted. If the remote LUW is executed successfully, the accompanying entries are deleted from the tRFC tables. If an error occurs, an automatic repeat mechanism, or rollback mechanism is activated (see next slide).

If the update is triggered locally because of the COMMIT WORK statement, the tRFCs are only executed when the local update is successfully completed.

When error comes:

If a connection cannot be made to the partner, this is logged in the tRFC status table ARFCSSTATE (which you can see by using Transaction SM58), and the job is rescheduled. You can set in the destination the number of times the system repeats the effort to connect, and the time intervals, by using the tRFC options. The default is a maximum 30 times with a 15 minute interval.

If, after a tRFC-LUW is successfully executed in the partner system in one of the function modules, the program terminates with an A/X-message (MESSAGE A/X...) or triggers an exception (RAISE...),

- all the changes made in the current LUW are automatically rolled back in the remote system, and

- the remote program termination is logged in the tRFC status table ARFCSSTATE (viewable using SM58) in the source system.
The entries relevant to the LUW remain in the tRFC tables and the execution job is not rescheduled. In this case, you can find the remote error using Transaction SM58, and you have to correct the problem in the remote system. Afterward you must trigger the remote execution again also in Transaction SM58.

If you want to cancel and roll back this remote execution from a remote function module of a tRFC-LUW, but you also want to reschedule the job in the source system (for example, because a master record that is to be processed is locked and the LUW must be executed again), call the function module RESTART_OF_BACKGROUNDTASK in the remote function module instead of MESSAGE A... or RAISE...

LUW building:

If tRFCs are transmitted with different destinations before the COMMIT WORK, they are grouped into different LUWs according to their destination.

A tRFC call with the addition AS SEPARATE UNIT is always processed as a separate LUW independently of the other tRFCs.

Each tRFC-LUW is assigned a unique transaction ID (viewable with Transaction SM58).
The function module ID_OF_BACKGROUNDTASK (which is called before the COMMIT WORK) returns this ID.

You can determine the LUW execution status using the function module STATUS_OF_BACKGROUNDTASK under the transaction ID (which is called after the COMMIT WORK).

If you also called the update function modules locally before the COMMIT WORK, tRFC calls are only processed when the local update function modules have been processed successfully.

You can also call transactional C functions. However, you must use the rollback mechanism in the external server program.

Queued RFC:

With tRFC, generated LUWs are processed independently of each other. This means, the order in which they are processed is not always the order in which they are generated.

To ensure that tRFC-LUWs are processed in the same order as they were generated, you can use qRFC as an extension of tRFC.

qRFC is available as of Release 4.6A and can be used in R/3-R/3 connections and R/3-external connections.

To place tRFC-LUWs in a First-In-First-Out (FIFO) queue, you must specify the queue you want to use via the function module TRFC_SET_QUEUE_NAME before every single tRFC call.

You can freely choose the queue name you need to specify, and it can have up to 24 characters
The queue name not start with
- an empty character
- the '%' symbol, or
- contain the '*' symbol

The tRFC-LUWs belonging to a queue are stored in the tRFC tables ARFCSSTATE and ARFCSDATA. However, you cannot maintain or display these LUWs using Transaction SM58. You must use the queue administration transaction SMQ1.

The queue data (queue attributes + pointers to the relevant tRFC-LUWs in the tRFC tables) is stored in the TRFCQOUT table, which you can maintain using Transaction SMQ1.
The following functions are available:
- List queues
- Display queues with a list of accompanying LUWs and function modules including input data
- Start/stop transmitting the queues
- Delete queues

If an LUW error occurs in the remote system, the queue is rolled back there. The relevant LUW and all of the other LUWs in the queue remain in the queue and in the tRFC tables. After correcting the error, you can use Transaction SMQ1 to transmit the queue again.

External RFC:

SAP delivers the RFC Library for all current external platforms, in which RFC calls are contained for C programs. After installing the RFC Library on your external platform, you can use RFC client or RFC server programs with RFC calls.

The connection to the SAP R/3 System is made using the RFC call RfcOpen with the destination and logon data.

RfcCall calls an R/3 function module. RfcReceive receives the output of the function module. This enables you to use an asynchronous call. If you want to use a synchronous call, use RfcCallReceive instead of these two RFC calls.

To close the RFC connection to the SAP R/3 System, use call RfcClose.

The call RfcAccept accepts the incoming RFC connection.

All C routines for the RFC server program, that should be called remotely, must be registered as being remote-enabled using the call RfcInstallFunction.

The call RfcDispatch sends the incoming call to the corresponding C routine.

The call RfcGetData enables the C routine to receive the input sent from the calling program.

The call RfcSendData returns the result to the calling program.

The call RfcClose ends the RFC connection.

You can use the RFC Generator to create an RFC client in C for a remote-enabled R/3 function module. The corresponding remote call for the function module is already implemented in the collection of program files generated by the RFC Generator.

The RFC Generator also supports you when creating an external RFC server program in C. To do this, first define in the SAP System a remote-enabled dummy function module with empty coding and the interface that you want to use in the remote C routine you will be creating. The RFC generator generates an RFC server program in C with the required remote C routine, which is used for the function module. When you start the RFC Generator, select the option 'C Server' instead of 'C client'.

The RFC Generator also creates a text file which contains tips on using the generated program.

The programs generated by the RFC generator are sRFC client or sRFC server. You can also generate aRFC, tRFC, and qRFC for R/3-external connections. For more information, see the online documentation on RFC-API or the sample programs delivered with the RFC-SDK.

Authorization checks for RFC:

The authorization object S_RFC lets you define, for each RFC logon user, in which function groups the user is authorized to start RFC. This user can only start function modules in these function groups with RFC.

This authorization check is active by default. However, you deactivate this default using a profile parameter.

Authorization checks for actions that call a function module remotely (for example, transaction authorization for CALL TRANSACTION) are compared against the user master record of the corresponding RFC logon user.

Authorization objects for S_RFC:

ACTVT : Can contain the value 16 (execute)
- RFC_TYPE: Can contain the value FUGR (function group)

The above examples show the available authorizations for the object S_RFC:
The RFC logon user with the authorization 'ALL' can call all the function modules.
The authorization object S_RFC contains three fields:
- RFC_NAME: Can currently only contain names of function groups
- The RFC logon user with the authorization 'ABCD' can only call function modules from the function group ABCD.

Trust relationships:

You can declare a trust relationship between two SAP R/3 Systems so that you can perform certain RFC logons in the trusting system without a password for released users.

You always declare a trust relationship in the system that is to become the trusting system, which means, it is in the RFC target system.

You use Transaction SMT1 to define a trust relationship.

You can use Transaction SMT2 in the trusted system to display which trusting systems are declared for the local system.

RFC logon with out a password:

A dialog user in the trusted system (RFC source system) can use a specially released user for the RFC logon without a password in the trusting system (RFC target system). To do this, the user requires a trust destination, created using Transaction SM59 (Trusted system = 'Yes'), in which only the name of the remote user is entered, but not the accompanying password.
(Note: You can also use regular destinations (with a password) with an existing trust relationship.

To be able to use RFC logon without a password for a specific user in the trusted system, you need to release a user in the trusting system. This is done by giving an authorization for the authorization object S_RFCACL to the user you want to release in the trusting system.