SAP Basis Tech Supports

Symptom
The note describes different options for generating RFC trace information. This information is needed when analyzing RFC problems.In this case the procedure always depends on the concrete problem constellation.
Other terms
RFC, trace, SM50, SM04, SM59, trace level, SMGW
Reason and Prerequisites
In a complex, distributed R/3 system infrastructure, a large number of RFC communications connections may exist.In cases where errors occur, it may be necessary to selectively analyze the concrete RFC communication behaviour of specific scenarios.To do this, R/3 provides various options for specifically generating RFC trace information.
RFC communication partners may be R/3 application servers or external programs whose RFC communication was implemented with the RFC library.Regarding both types of RFC communication partners, both the generated RFC information as well as the procedure and the variants for generating RFC traces vary.
Solution
Files with RFC trace information
For an individual RFC connection, trace information is usually generated for both types of communication partner (RFC client and RFC server). Therefore this information documents their local view regarding this connection.This information is stored by the respective RFC partner on local files. Depending on the type of partner, these files are discussed in the following.
R/3 application server
RFC trace information of R/3 basically is stored in three classes of files.These files are in the SAP work directory of the application server and can be displayed using transaction ST11.The actual RFC trace files dev_rfc<Workproze?Nummer> are generated for each work process and document the processs executed RFC log. They can be jointly reset in transaction SM59 via RFC->’Delete trace’ and also viewed via RFC->’Display trace’.The developer trace files of the R/3 work processes dev_w<Workproze?Nummer> document, for example, RFC-relevant behavior of selected R/3 components for the individual work processes. Such components include, for example, the task handler or the ABAP processor.They can be jointly reset in transaction SM50 via ->Prozess->Trace->Reset files.The gateway trace file dev_rd of the application server documents RFC-relevant behavior of the R/3 gateway.It can be reset in transaction SMGW via Goto->Trace->Gateway->Reset file.External program
An external program only writes data of the RFC log executed by it to a file which is regenerated for each program run.Under Windows, this file may also be called rfc<number_number>.trc, however, it may also be called dev_rfc.It is written as a default to the directory where the external program runs.This directory can be converted via the environment variable RFC_TRACE_DIR. See note 65325.Activating RFC trace generation
R/3 application server
There are three different variants in R/3 for activating the generation of RFC trace information:for an RFC destination, for a logged on R/3 user and for a work process.For an RFC destination
The easiest and most effective form of RFC trace generation consists in activating this for a maintained RFC destination via the setting of the trace flag and storing in Transaction SM59.This has the effect that all RFC connections of an R/3 System that go via this destination are documented when activated in the respective trace files of the application servers.A precondition for this sort of activation is that you know the destination that comes into question for the problem analysis.You can deactivate the trace generation by resetting the trace flag in SM59 again.For a logged-on R/3 user
You can activate the RFC trace generation for a logged-on R/3 user by selecting the user in question in Transaction SM04 and choosing Edit-> Trace->Trace on (in older releases) or User->Trace->Activate.You can specify the R/3 components that should write trace information via the display components in Edit->Trace->’Display trace’ (older releases) or in User->Trace->Display.For the RFC trace, at least the task handler and the ABAP processor should always be marked here.This activation has the effect that all the RFC links of the user in question are documented in the corresponding trace files of the application server where the activation via SM04 took place.If such a user-specific trace generation occurs, the user is highlighted in yellow in SM04.
With this method you must know the user and the user must also be logged on to the R/3.If, for example, a batch job logs on to the R/3 with a certain user via RFC, you can only trace this connection if the logon occurred so that the user is visible in SM04.Consequently, the RFC connection setup is not logged here.Additionally you must be on the look out for the logon of this batch user in SM04 so that the trace can be activated at the right time.You deactivate the trace generation by choosing Edit->Trace->’Trace out’ (older releases) or User->Trace->Deactivate in SM04.For a work process
You can activate the RFC trace generation for a work process of an application server by selecting the work process in question in transaction SM50 Process->Trace->’Active components’ and setting the trace level for selected R/3 components to 2.For the RFC trace, at least the task handler and the ABAP processor should be marked.This activation has the effect that all RFC connections of the work process in question are documented in the corresponding trace files of the application server.If such a work process-specific trace generation occurs, the work processes in question are highlighted in yellow in SM50.
With this method, activating the trace generation for all possible work processes is always recommend because you can never predict which work process the R/3 applications will be executed on. This type of problem analysis should only be used if the first two alternatives are unavailable due to error scenarios.All activities of the selected work processes are documented in the trace files and this can quickly lead to an overflow in trace files.After the error case occurs, setting the default values and trace generation should therefore be immediately stopped in transaction SM50 via Process->Trace->’Active components’.External program
With an external program you cannot activate trace generation during the program run but rather you must either do this prior to starting the external program or encode the trace generation explicitly in the external program.Trace generation can essentially be activated with an external program for an individual RFC link, for a defined RFC destination or globally for the external runtime environment.In this case, see the documentation of the RFC-SDK.For an RFC link
The trace generation for an individual RFC link can only be set in the source code of the program itself by setting the trace parameter with the RFC-API functions RFCOpen or RFCOpenEx to open the link.As a result, all RFC log information for this link is written to the trace file.For an RFC destination
External programs can use RFC destinations that are defined in the file saprfc.ini.If the the RFC_TRACE=1 is set there for the destination in question, then all RFC links that use this destination are traced in the external programs that are started later.Therefore it is critical how the destination is defined during a program start.Globally for the runtime environment
If the environment variable RFC_TRACE is set to 1 at the start of an external program, then all RFC links are traced for this program.Mode of operation and procedure
When you use the RFC trace generation you should pay attention to the fact that as soon as one of the above mentioned trace mechanisms is active in a program, all RFC links opened by this program are also traced.Therefore trace activation is imparted to all subsequent RFC links.In a distributed system landscape this may lead to a cascaded creation of trace information on several hosts.With this mechanism you can select the most limited starting point for trace generation when you analyze problems and you do not need to do a global generation for all work processes.
With trace generation, a well thought out procedure is recommended where you reproduce a certain error scenario as precisely as possible.For better analysis, the trace files should be deleted in R/3 prior to generation so that they could document only the examined scenario.To do a complete analysis of such a scenario, you always need the trace files of all participating communication partners. When analyzing the work process-related trace files dev_rfc and dev_w, you should also note that it is quite possible for an RFC connection to be distributed and run over several work processes and that several RFC connections may overlap in individual work processes if they are executed and traced consecutively by this work process.