EEM_Scripts_for_RFC

Table of Contents

EEM Scripts for RFC

Overview

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

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 rfc.INSTANCE. 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:

Additional properties may be needed for specific logon procedures, e.g., connect via message server, using logon groups, etc.

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.

Edit Parameters

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

<TABLES>
<ADDITIONAL_DATA>
 <item>
  <FIELD1>X</FIELD1>
  <FIELD2>X</FIELD2>
</item>
 <item>
  <FIELD1>Y</FIELD1>
  <FIELD2>Y</FIELD2>
</item>
</ADDITIONAL_DATA>
</TABLES>

View Output

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

• Response checks have the format field operator expectedvalue.
• Field is a .-separated list of parameter / structure / table attributes. It must start with TABLE or EXPORT. Next item is the parameter or table name (upper case mandatory!). For tables there is a pseudo attribute rowcount that 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.
• Examples:
  • EXPORT.PARAMNAME.stru.stru.field operator value (operator: <, >, >=, <=, ==, !=)
  • TABLE.PARAMNAME.rowcount operator value (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

Examples

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.

Troubleshooting

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. 

Invalid response check: parameter or field not found?

Maybe this is a helpful hint to create a valid field path