The blog post contains,
Transactional RFC is an asynchronous communication method that executes the called function module just once in the RFC server. The remote system need not be available at the time when the RFC client program is executing a tRFC. The tRFC component stores the called RFC function, together with the corresponding data, in the SAP database under a unique transaction ID (TID).We can use function module “ID_OF_BACKGROUNDTASK” to retrieve the TID.
In case target system is down, the call remains in the local queue of source system until a later time. The calling program can proceed without waiting to see whether or not the remote call was successful. If the target 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.
Call function 'Function Module Name’ IN BACKGROUND TASK DESTINATION ‘Destination name’.
As with synchronous calls, the DESTINATION parameter defines a program context in the remote system. As a result, if you call a function repeatedly (or different functions once) at the same destination, the global data for the called functions may be accessed within the same context.
The system logs the remote call request in the database tables ARFCSSTATE and ARFCSDATA with all of its 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 target 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).
Disadvantages of tRFC
• tRFC processes all LUWs independently of one another. Due to the amount of activated tRFC processes, this procedure can reduce performance significantly in both the send and the target systems.
• In addition, the sequence of LUWs defined in the application cannot be kept. It is therefore impossible to guarantee that the transactions will be executed in the sequence dictated by the application. The only thing that can be guaranteed is that all LUWs are transferred sooner or later.
- Transactional RFC
- tRFC process flow diagram
- Common issues and trouble shooting
- Important transaction codes
1. Transactional RFC
Remote Function Call (RFC) is the standard SAP interface for communication between SAP systems. RFC calls a function to be executed in a remote system.Transactional RFC is an asynchronous communication method that executes the called function module just once in the RFC server. The remote system need not be available at the time when the RFC client program is executing a tRFC. The tRFC component stores the called RFC function, together with the corresponding data, in the SAP database under a unique transaction ID (TID).We can use function module “ID_OF_BACKGROUNDTASK” to retrieve the TID.
In case target system is down, the call remains in the local queue of source system until a later time. The calling program can proceed without waiting to see whether or not the remote call was successful. If the target 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.
Call function 'Function Module Name’ IN BACKGROUND TASK DESTINATION ‘Destination name’.
As with synchronous calls, the DESTINATION parameter defines a program context in the remote system. As a result, if you call a function repeatedly (or different functions once) at the same destination, the global data for the called functions may be accessed within the same context.
The system logs the remote call request in the database tables ARFCSSTATE and ARFCSDATA with all of its 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 target 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).
Disadvantages of tRFC
• tRFC processes all LUWs independently of one another. Due to the amount of activated tRFC processes, this procedure can reduce performance significantly in both the send and the target systems.
• In addition, the sequence of LUWs defined in the application cannot be kept. It is therefore impossible to guarantee that the transactions will be executed in the sequence dictated by the application. The only thing that can be guaranteed is that all LUWs are transferred sooner or later.
2. tRFC process flow diagram
3. Common issues in tRFC queue
1. SM58 with status as “Transaction Recorded”
‘Transaction recorded’ is the status when the SM58 entry is triggered for execution at the target and there is no more work process available to process this request.
Check the SMQS to see if the destination CL3RCV003 is registered in outbound scheduler for tRFC processing.
Click on the type field, it will be ‘R’ for registered.
The number of max connections can be seen in SMQS .
Destination CL3RCV003 is Registered (Type "R") on the Outbound scheduler. The "Max. conn." Value is 1 which means that the maximum number of used dialog used for this destination is 1, this may cause a problem so the number can be increased.
To do this, highlight the destination and choose "Edit" and "Registration":
If you are increasing the max conn value, check that there are enough resources available. To do this from SMQS, choose "goto" in the Menu and then "qRFC Resources":
This issue ‘Transaction recorded’ usually happens for Idoc processing and BW loads.
2. SM58 with status as “Transaction Executing”
'Transaction executing' is the status when the SM58 entry is triggered for execution at the target and the source system is waiting for a response from the target system. This status can occur when connecting to another R/3 system or connecting with an external program.
You have to check in target system to see whether there are still running processes transactions (SM66) for the destination user (this is the user you have setup in transaction SM59 on the source system for logging on to the Target system). This user can be found in the"Logon & Security" tab of the used RFC destination.
If there is nothing running in the target that corresponds to these SM58 entries in the source system, is it possible that the network connectivity was lost.
3. SM58 with status TSV_TNEW_PAGE_ALLOC_FAILED
This issue can happen when the applications register a huge number of tRFC calls in the queue on the same TID; with commit when standard program tries to fetch the entries from ARFCSDATA to execute the registrations there can be a state of unavailability of memory.
In SMQ1 you can goto "QRFC" in the Menu and then choose reorganize, this will delete ALL queues in SMQ1. However, if you want to delete selected queues then you could choose "Edit" in the menu and then choose "delete selected objects".
1. Deleting all the queue entries
2. Deleting Selected entries
Check and enhance the calling program in the source system to prevent large number of registrations in the queue, probably you can restrict the entries to a particular number and then do the commit.
4. Important transaction codes
| SMQ1 | qRFC Monitor (Outbound Queue) |
| SMQS | qRFC Monitor(QOUT Scheduler) |
| SMQR | qRFC Monitor(QIN Scheduler) |
| SM66 | Global Work process overview |
| SMQ2 | qRFC Monitor(Inbound queue) |
| SARFC | Server resources |
| RZ11 | Maintain profile parameters |
| RZ12 | RFC server group maintenance |
No comments:
Post a Comment