SAP Basis Tech Supports

Symptom

You send documents using the SAPconnect RFC interface.
Errors occur when data is transferred to the external communication component (for example, fax server). For example, only some of the contents of documents or incorrect contents are received.
To check which data is output by SAPconnect in the interface, this data is to be written to a file.

Other terms

sxdump, error analysis, trace, RFC, Remote Function Call, SMTP, Simple Mail Transfer Protocol, MIME, Multipurpose Internet Mail Extensions

Reason and Prerequisites

You use the RFC interface for sending documents and a Microsoft Windows front end.

If you use the SMTP interface, this note is not relevant. If you use the SMTP interface, you can use the stored MIME document to determine the document content that has been transferred. To set the MIME saving process, you can call transaction SOST and choose “Utilities -> MIME Settings”. To display the MIME saving process, you can use the context menu (secondary mouse button) in a send request.

Solution

This note contains the program sxdump20.exe that writes the data that is transferred from SAPconnect in the RFC interface to a file in the front end. The program is attached as a zip file to this note.
Proceed as follows:
1. Download sxdump20.zip from SAP Service Marketplace.2. Unpack the program and transfer the program to any directory of the front end (for example, c:\).3. Define a new RFC destination for this program in R/3:a) Call transaction SM59 and choose “Create”.b) Enter a name (for example, SXDUMP).c) Enter the connection type T.d) Enter a description.e) Choose “Enter”.f) Select “Start on Front End Work Station”.g) Enter the program name (for example, c:\sxdump20.exe).h) Save your entries and test the connection.4. SAPconnect Administration (SCOT):a) Create a new node that has the same attributes as the node for which the error occurs. Choose a different address area. Enter the RFC destination you previously created (for example, SXDUMP) as the RFC destination.

If you then send a document using this node, the system creates several files in the front end (note the following: To do this, you must manually trigger the send process). On the one hand, the system creates a file with the name sxdumpnnnn.log that contains all transferred data (tables and structures). On the other hand, it creates a file with the name sxdumpnnnn.xxx for each body part that contains the relevant contents. The files are written to the directory where sxdump20.exe has been stored (to do this, the Windows user who is logged on must have write permission for this directory).
Example: sxdump20.exe is stored in the directory c:\sxdump\. You send an e-mail in which the main document is a text and to which a PDF is attached. The system then writes three files:
c:\sxdump\sxdmp0001.logc:\sxdump\sxdmp0001.txtc:\sxdump\sxdmp0001.pdf

If the system does not write these files (for example, because the path was overwritten by the environment variable SXDUMPPATH or because problems occurred when the file was written), you can check the path. To do this, navigate to the overview of send requests (transaction SOST). Use the secondary mouse button to click the title line of a column (for example, “Recipient”) and choose “Show…” from the context menu. In the right subwindow (”Hidden Columns”), select the “Info from Node” option and use the arrow to move it to the “Displayed Columns” subwindow. Choose “Transfer” or “Save layout”. Subsequently, the relevant column is displayed in the list. Among other things, it includes the path information for the message that was sent using sxdump.
Versions and corrections for sxdump20.exe:
Version 2.01 – January, 30, 2003
Document length is taken into account.Version 2.02 – March, 04, 2003
R3O files are processed correctly.Version 2.04 – July 10, 2005
The system outputs receivers.receiver with the full length (1215 characters).

To determine the version, enter sxdump20 -V in the command line.