In this book chapter excerpt, find a walk through to configuring data in an SAP NetWeaver PI RFC-to-file transfer....
Read tips for monitoring the RFC data transfer process and learn alternative SAP ABAP mapping strategies.
Configuring and monitoring NetWeaver PI RFC-to-file transfers
Based on the objects created in the Enterprise Services Repository, you
can now set up communication between systems A and B in the Integration
Directory. The Integration Directory can be called by Transaction
SXMB_IFR, by a direct link in the web browser, or by following the
Environment • Integration Builder menu path in the Enterprise Services
As with the Enterprise Services Repository, the interface is divided into
two parts; however, the objects are no longer arranged according to software
component versions. Instead, they are arranged according to object
types. Above the directory structure, you’ll see three tabs: Change Lists, Objects, and Scenarios. The Change Lists tab serves the same function
as in the Repository. The Objects tab lists all objects of the Directory by
their type. Except for the scenario, which you will create for all of your
objects in the Integration Directory; this exercise uses all of the elements
listed in Table 4.3.
|Object Type||Sender Side:
|Sender agreement||| SystemA | Z_RFM_
|Receiver agreement||| SystemA | |
SystemB | MI_
|Receiver determination||| SystemA | Z_RFM_MATERIALINPUT_##|
|| SystemA | Z_RFM_MATERIALINPUT_## | |
Table 4.3 Elements in the Integration Directory for the RFC-to-File Exercise
Setting Up the Business Systems and Their Communication Channels
To create the PI_Training_## scenario, use the context menu of an existing
scenario, or click the Create Object icon on the bottom left of the
menu bar. Save the object so the scenario is displayed in the listing on
the left side, select the new scenario, and then restrict the view by clicking
on the Only Display Selected Subtree icon above the list. Creating
a configuration scenario serves the organizational division of configuration
Follow the Communication Component • Business System menu path.
Below the branch, you will see at least two business systems, SystemA
and SystemB, which were declared in the System Landscape Directory
(SLD) during the preparations for the exercises. Click the Assign Configuration
Scenarios option in the context menu of system A, and select the
scenario you just created.
Due to this mapping, this business system and its communication channels
are displayed in your scenario. Repeat this step for business system
B. You need to configure a sending RFC adapter for system A and a
receiving file adapter for system B.
Using the context menu from the Communication Channel path, open
the creation dialog and enter system A as the Communication Component,
the name RFC_Senderchannel_##, and an appropriate description.
In the details window, use the input help to set the adapter type to RFC.
Select the Sender direction for this adapter. In the Transport Protocol
field, choose the RFC entry. For the Message Protocol and Adapter
Engine fields in the upper area, just use the default values.
The RFC Server Parameter area establishes a TCP/IP connection to the
RFC destination on the side of system A. During the preparation of the
exercises (in Chapter 3, Section 3.5.2, Settings for the Use of the RFC
Adapter), you created an RFC connection named SystemA_Sender-##.
This RFC connection is registered on the gateway server of the PI system
and is waiting for a corresponding counterpart.
In the Application Server field, enter the host name of the PI system,
and in the Application Server Service field, enter the gateway service
of the PI system according to the scheme sapgwXX, where XX represents
the instance number. The Program ID follows the scheme SystemA_
Sender-## and, like the two values mentioned earlier, exactly matches
the values entered in the corresponding RFC connection in system A.
The SNC option specifies whether communication over an RFC connection
takes place via a secure network connection (SNC). The Unicode
checkbox must be enabled if system A is a Unicode system.
The RFC Metadata Repository Parameter section is used to identify and
log on to the system that provides metadata about the RFC interfaces
used. This integration is required because the metadata is cross-checked
by the PI system when calling the sending RFC adapter. In this example,
the RFC interface is imported from system A during the design phase.
Enter the Application Server and the System Number of system A, and
your user SYS_A-##, your password, and the corresponding client, before
saving the communication channel. If you enable the communication channel at a later stage, the connection test for the destination SystemA_
Sender-## is carried out successfully from system A.
Figure 4.12 provides an overview of all of the settings for this communication
The receiving communication channel for system B is created with the
context menu from the Communication Channel path. The name of the
new channel should be File_Receiverchannel_##. Select system B as the
In the details window, select the File adapter type using the input help
and specify the Receiver direction. Set the Transport Protocol to the
File System (NFS) parameter, which means that the PI system can use its
own local file system to access the directory the file is created in.
Figure 4.12 Setting Up the RFC Sender Channel for System A
An alternative to the Network File System (NFS) is the File Transfer Protocol
(FTP ), which allows access to the file systems of remote computers.
If you select FTP, you can specify the server and user data to log on to
a remote FTP server. The Message Protocol field should be set to the
File value that causes the written file to be stored in PI format. The File
Content Conversion characteristic, however, lets you write the file as a
list containing several entries.
The File Access Parameters determine the directory to which the file is
written, and the scheme for its name. After consulting your landscape
administrator, we recommend using /tmp for Unix installations or C:\temp for Windows.
You can choose the File Name Scheme . However, you should select the
name xi_output_##.dat for this exercise, where ## represents your participant
number. We will refer to this file during the course of this scenario,
so, if you select a different name, you need to take this into account in
Section 4.1.4, Process and Monitoring (see Figure 4.13).
Figure 4.13 Setting Up the File Receiver Channel for System B
The Processing Parameters on the Processing tab specify how to create
the fi le; that is, if the name scheme specifi ed earlier is used as-is, or if,
for example, a time stamp, a counter value, or the message ID should be
included in the fi le name. Select the Directly write mode and the Binary
fi le type. The write mode, Directly, causes data to be written out without using a temporary file. The file type, Binary, makes it so not only text
can be output.
In addition to the basic settings, you can also dynamically specify the
file storage path by using variable replacement or triggering an operating
system command before or after the message processing. Save the
Creating the Connection Elements
Based on the basics we just created, and the objects in the Enterprise Services
Repository, the integration scenario can be completed using some
connection elements. The first two missing elements you need to create
are the sender and the receiver agreement. They determine how a message
is converted from or to the interface of a specific business system so
the PI system or the receiving system can further process the message.
In the case of the incoming RFC communication channel, for example,
the message must be converted from the RFC adapter format to the PI
Let’s start with the sender agreement, which you can create using the
context menu of the Sender Agreement directory. In the creation dialog,
select business system A as the service. The sending interface is
the RFC interface Z_RFM_MATERIALINPUT_##, which you imported to the
Enterprise Services Repository. In the details window of the new object,
you can specify the communication channel of the sender by opening
the input help and selecting the sender channel RFC_Senderchannel_##
(see Figure 4.14). Save the sender agreement.
As you did for the sender agreement, create a receiver agreement for
business system B and the receiving interface SI_Material_Async_In.
Note that you also need to specify the sending business system A. In
the details window, select the channel File_Receiverchannel_## as the
communication channel of the receiver and save the agreement.
For logical routing, messages in the PI system first need a receiver determination,
which specifies available receiver services for a business system
and interface pair. Create a new receiver determination with the corresponding context menu for the sending business system A and the
Figure 4.14 Creation of the RFC Sender Agreement
In the details window, the Configured Receivers area allows you to
specify various receivers. If the review result of the relevant condition is
true, the message is delivered to this system (see Figure 4.15).
This can also mean that the message is delivered to several systems. For
example, the condition can check elements of a message for specific content.
If none of the configured systems is specified as the receiver, you
can specify a default receiver below the receiver table. In the Communication
Component column of the existing row, select business system
B as a potential receiver. Because the message in this exercise should
always be delivered to this receiver, you don’t have to set a condition.
Save the receiver determination and then look at the lower area, Configuration Overview , which now includes the SystemB entry. Expand
the entry. As you can see, no matching interface determination and no appropriate operation mapping could be determined. Above this listing,
click on the New icon to create a new interface determination .
Figure 4.15 Creation of the Receiver Determination
By calling the creation dialog from this context, all mandatory fields can
be populated; you only need to enter a description. In the details window
of the Receiver Interfaces area, use the input help to select your
service interface SI_Material_Async_In from the namespace. To the left
of it, specify the only operation mapping available for the combination
of the sending and receiving interfaces (see Figure 4.16). Save and close
the interface determination and return to the receiver determination.
Figure 4.16 Editing the Interface Determination for the RFC-to-File Exercise
In the lower area, click the Refresh icon so that the receiver agreement
for receiving system B is also displayed with the target interface and the
matching operation mapping (see Figure 4.17).
Figure 4.17 Editing the Receiver Determination for the RFC-to-File Exercise
Save the receiver determination and activate all newly created objects
using the Standard Change List in the Change Lists tab. You have now
created and activated all objects for this integration scenario.
The folder functionality from the Enterprise Services Repository is also
available in the Integration Builder. Here, you create folders by following
the Objects • New menu path. In the tree on the left, the last point,
Administration, contains the Folder element . Here, it is possible to
create a root folder or assign the new folder to an existing folder as
a subfolder (see Figure 4.18). Working with folders in the Integration
Directory is the same as in the Enterprise Services Repository.
Figure 4.18 Creating a Folder in the Integration Builder
4.1.4 Process and Monitoring
Now that you have created all of the design and configuration objects,
you’ve prepared the integration scenario for the course. Next, you will
monitor the process and examine any possible errors.
Course of the Scenario
Start the configured integration scenario by calling the program Z_PROG_
MATERIALINPUT_##. Log in to the client of system A using your user and
call Transaction SA38; type the name of the program and execute it.
An input mask for basic material master data is displayed. Enter the data
for creating the PI developer manual as a material master record in system
B. This material is just used for test purposes; you won’t use it to
create a production or sales order, for example.
The data corresponds to the mandatory fields of the two views, Basic
Data 1 and 2, from Materials Management (MM) in SAP R/3 or SAP ERP
Central Component (ECC), respectively. Because this data is used in the
second exercise to actually create a material using an IDoc, we recommend
using the data from Table 4.4.
|Material description||arbitrary (for example, »SAP PI developer
|Material type||FERT (Finished product)|
|Industry sector||1 (Retail)|
|Material group||030 (Documentation)|
|Quantity unit||ST (Piece)|
|Gross weight||arbitrary (for example, 1.2)|
|Weight unit||KGM (kilogram)|
|General item category group||NORM (Normal item)|
Table 4.4 Recommended Values for Creating a Test Material
This data works in an Internet Demonstration and Evaluation System
(IDES) R/3 or ECC system without further adaptation. For the second
exercise, you can use the appropriate template files later.
Enter the data in the individual fields and note that the input help displayed
for some fields only returns values of the sending system that
might not exist in the receiving system (see Figure 4.19).
After you follow the Program • Execute menu path, or click the corresponding
Execute icon, you will receive a success message. This message
only notifies you that the function module belonging to the program has
been called successfully. However, it does not confirm that the message
has been successfully delivered.
Figure 4.19 Calling the Program Z_PROG_MATERIALINPUT_##
Correct delivery and processing of the message can be verified in the
PI system . Log on to the appropriate client and call Transaction SXMB_
MONI . Follow the menu path: Integration Engine • Monitoring •
Monitor for Processed XML Messages. This opens a selection mask
that lets you select all processed messages. If the PI system is used only
for training or testing purposes, a restriction is hardly necessary. Otherwise,
you could restrict the selection to messages with the sending server
SystemA, for example.
Execute the message query via the Program • Execute menu path or
the corresponding Execute icon. If your message was successfully delivered
and processed, you should see an entry showing a black-and-white
checkered flag in the Status column (see Figure 4.20).
Figure 4.20 Display of the First Message in Transaction SXMB_MONI
A green flag means that the message is currently being processed, while
a black-and-white checkered flag means the message processed successfully. Most other icons represent an error in our case. You can display
the legend of all possible icons via the Goto • Legend menu path, or the
corresponding Legend icon.
To get the ultimate proof that the message was successfully processed,
look at the created file. You can do this using Transaction AL11 in the PI
system, by clicking on the row of the directory alias DIR_TEMP. In the file
list, search for a file matching the scheme pi_output_##.dat. Double-click
on the file to open it. Because the display is limited to a specific width
and the lines are not wrapped automatically, we recommend using Transaction
ZAPCMD or the file tools provided on the book’s website (find it
Troubleshooting in Monitoring
To find the cause of an error in the message display of Transaction SXMB_
MONI, double-click in any field of the corresponding row. This brings
you to the Display XML Message Versions view (see Figure 4.21).
Figure 4.21 Detail View of a Message
In the case of an asynchronous message, you will see the different statuses
of the message on its way through the central Integration Engine (IE). In the directory structure to the left, navigate to the place that has an
error icon. In the windows on the right side, look for an error message
indicating the cause. In most cases, the error was caused by a mapping
or an object that was inadvertently selected from the input help.
In some cases, however, the error was caused by incorrectly configured
communication channels or adapters. To check this, start Transaction
SXMB_IFR, which is used for calling the PI tools. On the bottom right,
select the Runtime Workbench and logon using your user PI-##.
You will see the options for the Runtime Workbench, most of which
you will become familiar with while working on the following exercises
and the case study. Even though you already know a different way of
displaying a message overview using Transaction SXMB_MONI, you can
use the Message Monitoring menu option to view the message status
in the PI system. First, select Component Monitoring, and display the
components with every possible status.
In the directory structure of the components, follow the menu path:
Domain.XX.<PI-Hostname> • Integration Server • Adapter Engine. A
status view opens beneath the directory structure, providing you with
information about the general status of the Adapter Engine. On the topright,
click the Adapter Monitoring button (see Figure 4.22).
After expanding the namespace http://sap.com/xi/PI/System, a new
browser window opens and displays the selection of all available adapters.
A gray diamond next to an adapter type indicates that a communication
channel for this type hasn’t been created. A green square indicates
that all communication channels of this type have been correctly configured
and that no error has occurred during processing. A red circle,
however, indicates that at least one communication channel of this type
You’ll need to see if an error occurred for the adapter types RFC or File.
For a closer analysis, you can click on the relevant type to list all of
the communication channels. If the communication channel displays an
error, you are presented with a detailed error description to the right,
which you can use to correct the error.
Figure 4.22 Entry Point to Component Monitoring of the Runtime Workbench
4.1.5 Alternative Mapping: ABAP Mapping (Optional)
As an alternative to the graphical mapping that you used in this exercise,
you will learn how to implement the same mapping using an ABAP class.
To do this, you must perform some preparatory steps, and receive authorization
for development in the SAP NetWeaver PI system.
Creating the ABAP Mapping
The ABAP mapping is created as a normal ABAP class in the PI system,
and, in operation mapping, is referred to by the class name. As a result,
the Execute method is called automatically, and does the mapping. This
method must be implemented by you; an ABAP mapping cannot be
imported into Enterprise Services Repository when developing the ABAP
Log on to the PI system and call the class builder with Transaction SE24.
Enter the name of the new class following the schema ZCL_PI_ABAP_MAPPING_##,
and click Create (see Figure 4.23). In the pop-up window, type in a meaningful description for the new class and click Save. If you
haven’t yet entered a developer key for your user, you will have to do
Figure 4.23 Creating the ABAP Mapping Class in Class Builder
Because the ABAP mapping is a normal ABAP class, you must provide
the names of transport requests and of a package for this development
(unless you are planning a local development). Once you do this, the class
builder will open, and you can see your new ABAP class. Click on the
Interfaces tab and choose the ABAP interface IF_MAPPING (see Figure
4.24). This interface contains the Execute method with the corresponding
signature, and thus represents the definition of the new method.1
Figure 4.24 Integration of the IF_MAPPING Interface in the New Class
After integrating the interface, the Methods tab displays the Execute
method that you now must implement. To do this, double-click the
method name and save the changed class. Before developing the actual
coding, let’s look at the XML view of the message (see Listing 4.1).
1 You can find detailed information about the interface in the SAP Help Portal
<?xml version=”1.0” encoding=”UTF-8”?>
<MAKTX>SAP PI Developer Book</MAKTX>
Listing 4.1 XML View of a Message Sent after the Mapping
You can access this view in either the file that is created as the result of
the first exercise, or by testing the message mapping of the first exercise
and displaying the results in the XML view. The only value that is
changed in the mapping is the net weight, which is automatically calculated
based on the gross weight. The structure and the remaining values
are not changed by the mapping, thus keeping the ABAP mapping
You can find the detailed source code of the ABAP mapping in Appendix
A. Copy the source code, replace the placeholder ##, and activate the
method so it can be used later in the operation mapping.
Because a detailed discussion is beyond the scope of this book, we
will only briefly discuss the method. First, the iXML library for ABAP
Objects is initialized, which allows you to simply parse and reassemble
XML documents.2 Then objects for factories and the input stream are
declared. After the definition of the input document, the relevant nodes
are declared and extracted from the input document using the get_elements_
2 Detailed information on the iXML Library of SAP can be found on the SAP Help Portal
After the output document has been declared, it is filled with the values
from the input document; most values can be inserted without change.
Only the net weight is recreated as a node and calculated on the basis of
gross weight. In addition, you must correct the date format from YYYYMM-
DD to DDMMYYYY, so that the file can be transferred into a new
material via IDocs (in the next exercise).
After the node assignments to the new document are completed, a custom
message is inserted into the trace; this lets you see the details of
the execution of the newly-created method in Transaction SXMB_MONI.
Finally, the output stream is declared, and a renderer is created that is
responsible for compiling the output document.
Integrating ABAP Mapping
After creating and activating the new mapping, you must insert it in the
existing operation mapping OM_Z_RFM_MATERIALINPUT_## to_SI_Material_
Async_In, and activate the object again. To do this, simply open the
aforementioned operation mapping, and then switch to change mode.
In the bottom-center section of the screen, change the entry in the Type
column from Message Mapping to Abap-class. Then enter the name of
the created ABAP class ZCL_PI_ABAP_MAPPING_## (see Figure 4.25). The
ABAP mapping cannot be tested in the Enterprise Services Repository.
Save and activate the change; other changes, such as changes to the configuration,
are not necessary.
You can run the scenario once again by calling the program Z_PROG_MATERIALINPUT_##.
The behavior results in the same outcome. By tracing your
message in the message monitoring of Transaction SXMB_MONI, you’ll
find the log entry you specified in the ABAP class (see Figure 4.26).
Figure 4.25 Integrating ABAP Mapping in Operation Mapping
Figure 4.26 Trace Entry of the ABAP Mapping in the Message