Table of Contents
EEM Scripts for RFC
In addition to http and sapgui scripts EEM can also handle scripts for the RFC protocol to exercise remote function modules from different locations. A single message in the script corresponds to a single RFC call. The script can be generated either by importing a RFC recording from the SAP client plugin (e.g. recorded for SAP BEx), or by manually adding calls to an initially empty script in the EEM Editor. Independently from the creation procedure the runtime logic is identical after an initial replay.
Create the Script
Create the script in the EEM editor.
Work with Recordings
If you have captured a RFC recording via the client plugin, use the Import Recording function in the context menu of the EEM navigator in the editor. How to create a recording for BEx Analyzer is described here: BEx Analyzer RFC recording.
Start without Recording
If you do not have a recording, e.g., because you want to monitor some individual remote function modules, start with an empty script. Use New -> Script, choose RFC as protocol. This will create a new RFC script with a single message that calls function module RFC_SYSTEM_INFO as an example.
Use the RFC Wizard
Available since Solution Manager 7.10 SP05
To use the wizard the managed system needs ST-PI 2008_1 SP6+ to populate the value help to select RFC enabled modules.
The RFC wizard supports generating RFC messages by fetching metadata about function modules from the tested system. For this purpose, the wizard first prompts for connection data. Then, you can choose the function module to be tested. To retrieve the list of function modules the user needs authorization for authorization object /SDF/E2E which is either in role Z_SOLMAN_READ_620 or SAP_SATELLITE_E2E or in profile S_AI_SMD_E2E or SAP_ALL. Without this permission you have to manually type the name of the function module. The parameters of the module can still be populated in the next step, even without the mentioned permission.
Fill In Login Data
No matter via which procedure you created the script, you first have to enter connection data into the script. For this purpose open the script via double-click, and open script configuration for this script (if it does not show up automatically). On page variables you'll find the connection data stored in a list variable
INSTANCE is a logical identifier for the connection. Every message refers to this connection via the URL of the message. If you started by importing a recording,
INSTANCE will be a string like host_sysno_instance.
Maintain the properties of the list variable
rfc.INSTANCE to contain valid logon data. These properties are pre-populated and must be updated with correct values:
SAP system number
SAP application server
Additional properties may be needed for specific logon procedures, e.g., connect via message server, using logon groups, etc.
SAP message server
Group of SAP application servers
Initial codepage in SAP notation
Fill In Parameters-Run
To get the RFC script set up completely, a test run of the script is needed with a connection to an ABAP backend system to populate meta data correctly. This test run will retrieve meta data about all input and table parameters in the script and generate corresponding input files. The script configuration property
rfc.paramReady indicates whether the script should be run in fill in parameters mode or executed normally. The result status for all messages will be set to UNDEFINED.
The actual function modules are not called during this run.
The fill-in parameters run will overwrite any changes that you have done to the import and table parameters. So double check what you are doing if you force another fill-in parameters run by setting
Bring up the edit message dialog via the context menu to fill input and table parameters for a function module. You will find two table for Input Parameters and Table Parameters. Do not destroy the XML structure, just fill the values into the corresponding XML tags, as shown in the screenshot for the function module BAPI_USER_GET_DETAIL. You can use variables for the actual values of parameters, as shown in the screenshot: The user name is given via a variable Xusername.
Table values are given in the format
The actual parameters (input, output, table inbound, table outbound) can be displayed by selecting the message in the execution log from a replay.
- Response checks have the format field operator expectedvalue.
- Field is a .-separated list of parameter / structure / table attributes. It must start with
EXPORT. Next item is the parameter or table name (upper case mandatory!). For tables there is a pseudo attribute
rowcountthat returns the number of rows as integer. The field defines the path from the root to the value to be checked within the result XML document (except for rowcount and OUTPUT being replaced by EXPORT). If any field in the chain is a table then the check is performed for all rows in the table.
- operator is a comparison operator. The list of valid operators depends on the selected field:
- integer operators: <, >, >=, <=, =, !=
- string operators: ==, !=, contains
- Expectedvalue must have the same data type as the field to be tested.
operatorvalue (operator: <, >, >=, <=, ==, !=)
operatorvalue (operator: int comparison)
- If you want to ensure that no row in a table contains a specific value, then use the negative check box in the checks dialog to invert the complete check and use a check like this: TABLE.TABNAME.COLNAME == value Labels parameters
Test multiple instances of a system
Use case: for all instances of an ABAP system RFC_SYSTEM_INFO should be called. Our test system has a central instance (CI) and two dialog instances (AI1, AI2). We use CI, AI1, and AI2 as names for the instances in the RFC connection dialog:
This name is then automatically used as "URL" for the messages. Rename the messages and corresponding steps to have clear names:
Double-check that the variables are filled like this. To avoid that you have to maintain the password for the user multiple times you can remove all password properties and instead put a property
jco.client.eempasswdref into the list for each connection. It refers to another variable that contains the actual password.
Looking into the advanced configuration section you can double-check which connections are really used:
rfc.connections lists all connections (and thereby corresponding list variables) which are used.
Editor Crash with Java 7
We have seen editor crashes while executing a RFC script when the editor is launched with a Java 7 VM. The problem is located in the JCO native libraries. As work-around please use Java 6 to run the editor.
Input parameters of type RAW/BYTE
Input parameters of type "RAW" / "BYTE" have to be passed as hex values in the wizard for RFC messages. In the XML files for input and table parameters they are then represented base64 encoded. Example: If you want to pass a single byte with value 34 then enter 22 as input value in the RFC wizard. Perform a test run and finish the wizard. In the message properties you will find the string Ig==. If you decode this again this leads to the single character >"< (corresponding to ascii code 34).
Trace RFC Activities
You can activate detailed tracing of RFC and JCO activities by setting the script configuration parameter
rfc.tracelevel. A value of
rfc.tracelevel=5 will yield detailed trace information:
- The file JCO(timestamp).trc contains details on the JCO API
- The file jrfc*.trc contains details on the RFC activities
Both files are written to the replay log folder of the script. When importing an execution from a robot into the EEM Editor these trace files will be included. To display them after import into the editor right-click on the execution and select Explore in File System.