Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
Showing results for 
Search instead for 
Did you mean: 


Former Member
0 Kudos


What is SM58 transaction used for. Can anyone tell me.


Former Member
0 Kudos


It gives you a log of all the RFC calls made from that SAP system. What date and time this call was done etc etc?



0 Kudos

I knew it was for errors,

but the problem that I had was I'm publishing IDocs to an application and testing it from WE19. However the idocs do not get published and accumulate in SM58. When i execute LUW from Sm58 the idoc is published. What could be the reason.



0 Kudos

anybody knows the solution to this.

0 Kudos

anybody knows the solution to this.

0 Kudos


is possible that your RFC queue scheduler (qRFC) is not correctly configurated (or not conf). Check it on SMQS.




Active Contributor
0 Kudos

You can see the Documentation

Short text

Transactional RFC


In Release 3.0, you can execute function modules asynchronously in a different R/3 System. When you call function modules in this way, they are not executed immediately. Instead, they are stored in an internal table and processed together after the next COMMIT WORK. The calls for each destination thus constitute a Logical Unit of Work ( LUW)).

When a COMMIT WORK statement occurs, the stored calls are executed by the next free work process in the order in which they occurred. If there are updates before COMMIT WORK, the asynchronously called function modules are not executed until the all the update function modules have been successfully processed.

Because the RFC is like a transaction, database operations are either all executed or, if a function modules terminates, all rolled back. If an LUW runs successfully, you cannot execute it again. In some cases, it may be necessary to program the roll back of an LUW, (for example, because a table is locked). To do this, you call the function module RESTART_OF_BACKGROUNDTASK which performs a rollback and ensures that the LUW is executed again later.

The function module ID_OF_BACKGROUNDTASK returns the ID of the LUW. You call this module after the first CALL... IN BACKGROUNDTASK and before COMMIT WORK. You can use the function module STATUS_OF_BACKGROUNDTASK and the ID to find out whether the LUW ran successfully. Normally, the LUW is executed immediately after COMMIT WORK in the specified target system. However, you want it to start at a particular time, you can set a start time with the function module START_OF_BACKGROUNDTASK which must also be called within the LUW, i.e. after the first CALL... IN BACKGROUNDTASK and before COMMIT WORK.

Technical implementation

All the calls are stored in the tables ARFCSSTATE and ARFCSDATA and each LUW is identified by a unique ID. When a COMMIT WORK occurs, the calls attached to this ID are executed in the relevant target system. The system function module ARFC_DEST_SHIP transports the data to the target system and the function module ARFC_EXECUTE executes the stored function calls. If an error or an exception occurs during one of the calls, all the database operations started by the preceding calls are rolled back and an appropriate error message is written to the file ARFCSSTATE. You can analyze this error message with Transaktion SM58.

If an LUW runs successfully in the target system, the function module ARFC_DEST_CONFIRM is called and confirms the successful execution in the target system. Finally, the entries in ARFCSSTATE and ARFCSDATA are deleted.

If the target system cannot be reached because the connection is not active (for example), the report RSARFCSE with the ID as a parameter is scheduled as a background job and called at regular intervals. You can display the standard values for this by selecting ich Info -> System setting in Transaction SM58. If you want a separate setting for each destination, you can specify this with the TRFC options in Transaction SM59. Alternatively, you can use the enhancement SABP0003 (maintain with Transaction CMOD) to override this setting by destination, user name, etc. If no connection is made, the entry in ARFCSSTATE is deleted after a time which you can also specify in the enhancement. To perform the deletion, you schedule the report RSARFCDL as a background job.

Further notes


Call the relevant transaction in debugging mode, select Goto -> Settings and set the selection field In background task:... . If you do this, the LUW is not executed at once and you can use Transaction SM58 to execute it in debugging mode.


You can also execute programs asynchronously in 'C'-implemented function modules (connection type TCP/IP in Transaction SM59). Implementation of the function modules occurs as usual in connection with the RFC API. This contains the function modules ARFC_DEST_SHIP and ARFC_DEST_CONFIRM which call the appropriate functions.


The Windows API does not yet support asynchronous calls.

Executing once must be guaranteed by the implementation of the function module.

Former Member
0 Kudos


SM58 is used in Transactional RFC

where you to specify RFC's destination, function &

Status and you will see all TRFC definations.