1

eCATT Chaining, Parameterization, Creation Of Test Data,Test

Configuration, System Data (PART IV)

The Part I of eCATT Introduction gives the basic details about usage of
eCATT & features involved. In Part II, the creation of eCATT scripts using
TCD mode of recording is explained in detail. In Part III, SAPGUI
recording mode of recording is explained in detail. In Part IV chaining,
parameterization, creation of Test Configuration, Test Data Container,
and System Data Container will be explained in detail and in subsequent
parts the management of eCATT Scripts via Test workbench & other
details of eCATT will be covered.
What Are Parameters:
Parameters are export, import interfaces or local variables of a
script. Parameter name can be 30 char long. The first letter should be
either an underscore or character.
Their visibility within the script is same and outside it is of import
parameter, export parameter or local variable. The visibility can be set
from the parameters list.
 

 
ONLY local variables can be used in the inline ABAP block in the test
script editor. Import & Export parameters CANNOT be used in the inline
ABAP block.
Import Parameters (IP): Import parameters are input values to the
script. They are passed to the script during execution. They are locally
available and test script version independent. Import parameters can hold
default value also.
Export Parameters (EP): Export parameters are outcome of the test
script execution. The result value is passed into the export parameter
when the test returns from the test module. They are test script version
2

independent.
Local Variables (LV): Local variables are used in test scripts for
calculations, or to receive export parameters from referred test cases or
called function modules. They are also used for passing values to and
from inline ABAP blocks & are version-dependent – that is, a local
variable defined in one version is not automatically defined in another
version.
System fields can also be used in command editor. They are read-
only and are available from SYST structure.
There are special read-only eCATT variables, which can also be used
in command editor. e.g. &YEARB, &YEARA, &YEAR, &VARID, &USER,
&TIME, &SYSTEM, &SUBRC, &SCRIPTVERSION, &SCRIPTNAME, &SAPRL,
&REFVERSION, &REFNAE, &REFLEVEL, &OPSYS, &MSX, &MST, &MSN,
&MSI, &MSG, &MS4, &MS3, &MS2, &MS1, &M04, &M03, &M02, &M01,
&LPC, &LOGID, &LANGUAGE, &HOST, &EXCEPTION, &DBSYS, &DATE,
&CLIENT etc.
The status of values, either fixed or parameterized or not define, are
symbolized as follows –

Why Parameterization Is Needed:

After recording of the transaction. Transaction can be checked
without parameterization for errorless recording. Once the successful
recording is confirmed, automation can be parameterized.
Due to parameterization, the recording becomes reusable. Different
sets of data can be passed via parameters and the recorded script can be
used again and again.
This is very similar to concept of Constants in Program (Without
parameterization) and using variables for those values (with
parameterization).
If parameterization is not done than before next execution of
automated script, input data will be checked and changed at Test Script
3

level. Due to this the errorless recording time data will be disturbed.
Hence parameterization is necessary.

TCD Mode Parameterization:

If a transaction is recorded via TCD mode, then the screens can be
simulated via screen simulation. Screen simulation can be used to edit
and parameterize the fields. Screen simulation icon is present in the
command interface of the TCD mode. Using Screen simulation Import
parameters, Export parameters, field check, and values in the input field
can be assigned. To delete the default values space characters (‘ ‘) can
be passed via screen simulation. For parameterization, if the field has any
value, one can clear it.

Fields having mode ‘S’ (Set) under each dynpro of the command
interface contain some value entered during the recording. This is the
value one needs to parameterize as Import Parameter so that with next
run a new set of data will be passed to the recording. And recording
becomes reusable.
 Give the login details. For parameterization, select the Dynpro
whose fields need to be parameterized as Import/Export parameter. Click
on Screen Simulation icon of the command interface. The system will
prompt for the login of recording time target system.

Defining Import Parameters:

 After step 3, the screen simulation window will appear. Select the
field value & click on Insert Import Parameter (F6) icon from the
application toolbar.
4

 One Maintain field entry window appears for the selected field with
its technical name. Give the parameter name & default value in the
Field contents there. Press enter. The parameter will be inserted
into the parameter list. Click on Back (F3) button of the standard
toolbar.

This way one can parameterize all the import values.

Defining Export Parameters:

 The output results of the transaction are assigned to export

parameters. Export parameter are necessary for chaining of
transactions wherein output of one transaction becomes input for
other transaction. Here export parameters can be linked between
the two transactions interacting.
 Fields having ‘G’ (Get) as mode are assigned to export parameters.
Last dynpro in the dynpro list just before the MSG node in the
command interface contains the output messages and other
outcomes. Export parameters can be assigned for these values.
 Follow step 3. After step 3, the screen simulation window will
appear. Select the field and click on the Read field value
(Ctrl+Shift+F3) icon from the application toolbar.

 Read field value window appears. The field with the technical name
appears against which the Param. Name needs to be given. Give the
5

name of the export parameter. Click on enter. Automatically the

name will be included in the Parameters list. Click on Back (F3)
button from the standard toolbar.

This way one can parameterize all the export values.

Defining Field Checks:
One can check whether the runtime value of a field is the expected
value or not. The check value can be a constant or a parameter value.
Follow step 3. After step 3, screen simulation window appears.
Select the field. If the field has already some value, clear the value of the
field.
Click on the Check field (Ctrl+Shift+F2) icon from the application
toolbar.

Maintain field check dialog box appears. Give the name of the
variable in the Param. Name. If it doesn’t exist, it will be created
automatically as import parameter in the parameter list. Give the value
against this field. Click on enter. Click on Back (F3) button from the
standard toolbar.

SAPGUI Mode Parameterization:

Defining Import Parameters:
Import parameters are defined for the input values given during the
6

recording of the transaction. These values are present under the

Processed Screen node of the SAPGUI command interface for the given
screen.
Double click on the command interface of SAPGUI command from
the test script editor from the left side. On right side the command
interface will open. Under the Processed Screen -> UserChangedState
node select the State node of the field, which needs to be parameterized.
Double click on the field number. On the rightmost section, assign the
Import parameter to Value field.

Define this import parameter in the parameter list with the type of the
field & assign the default value.

This way multiple import parameters can be assigned & created.

Defining Export Parameters:
Export parameters are used to link transactions while chaining. i.e.
Export parameter of first transaction becomes the import parameter in
chaining.
Export parameters are assigned to result of transaction. e.g.
Material Created out of MM01 transaction. So the results are captured
from Message node under the Processed Screen node using MESSAGE-
ENDMESSAGE command.
Click on Pattern (Ctrl+F6) button from the application toolbar. From
the Command dropdown, select the MESSGAE MESSAGE …END MESSAGE
7

option. The Interface name is automatically populated by system. Click

on enter.

The MESSAGE-ENDMESSAGE for interface MSG_1 will be inserted into

the test script editor. Place this block around the SAPGUI command from
which the export value will be captured. After that assign the respective
message parameter to the export parameter.

The message variable number can be confirmed from the command

interface from the right side.

Declare this export parameter in the parameter list.

This way multiple export parameters can be declared.

Passing Values To Subsequent Screen: In SAPGUI mode, value from
8

one screen can be passed to the subsequent screen. E.g. system

generated value for an input field on one screen can be passed to
subsequent screen. This can be achieved by assigning an Export
Parameter to the required value. And then passing this export parameter
as input (import parameters) to subsequent screens.
Double click on interface from the SAPGUI command in which the
parameter to be captured exists, in test script editor. On the right side,
the command interface will open. Under the Processed Screen -> Initial
State node, the value will exist. Make sure that the Check, of the topmost
GuiElement branch under which the GuiElement exists which needs to
capture, is blank ‘ ‘ instead of ‘X’.

Under the State node of the GuiElement, which is to be captured,

double click on the number, which appears in square braces. On the right
side, Name & Value will appear. There in Value, write the Export
Parameter name.

Declare this export parameter in the parameter list. And it can be

passed further in same recording to subsequent screens as import
parameter.
9

Chaining Of Scripts:
Test case is a series of steps (transactions) involving one business
scenario. Each step is automated and then linked together via chaining so
as to complete the business scenario.
Chaining mainly involves the linking of script by import & export
parameters. The export parameter, which is outcome of first transaction,
is passed as import parameter to second transaction and so on.
Create two test scripts, which are related in a way that output of
one script becomes input to other. E.g. VA01 output of sales order can be
given as input to VA02. Both the scripts should be parameterized as well.
For creating chaining of the scripts, create a new script. Transaction
SECATT. Click on Pattern (Ctrl+F6) button from the application toolbar.

One Insert Statement dialog box will appear. From the Command
dropdown, select REF command. In the Test Script, give the name of test
script, which needs to be linked. Press Enter. The Interface name will be
automatically populated. Press Enter.

The REF command will be inserted into the test script editor.

Double click on the Command Interface of the inserted REF

statement in the test script editor. On the right side the interface will
open with the Importing/Exporting nodes. These Importing and Exporting
node have import and export parameters, which were assigned, while
creation of that script. Double click on importing node. On the rightmost
side, all the import parameters appear under the Element column.
10

Declare all import parameters in the Parameter section above and assign
then in Value column below against the Import parameters.

Double click on Exporting node of the command interface. On the

right side the export parameters, which were created during the script
creation are displayed.

Declare the variables and assign them to the export parameters.

Similar ways include other test scripts also using REF command.
Assign the import parameters and variables to the Importing as well as
Exporting nodes respectively.
The export of one test script will be assigned as import of the next
script using variables.

The import parameter of chained script is assigned to the respective

Importing node element.
11

This ways multiple transactions can be linked together in the final

chained script. The parameter list of this chained script contains only the
import parameters as well as the variables.
Click on Save (Ctrl+S) button from the standard toolbar. By giving
the default values in the import parameters, execute the script and
ensure the correctness of chaining. Once the successful execution of the
chained script is confirmed, TD and TC can be prepared.
Creation Of System Data Container (SD):
System data container contains the list of the target servers, which
can be used at the recording time and/or at execution time. Target
systems with their RFCs are mentioned in the SD.
Creation of RFC for target system:  RFC destination will be created
for the target systems, which will be used as recording time and/or
execution time systems for eCATT scripts. Using SM59 on source system
(where eCATT scripts will be available), create a RFC destination for R/3
system.

Give the necessary details like RFC Destination, Connection Type,

Description.
12

In Logon/Security tab, recommended is to mention the Trusted system

‘No’. This ensures that every time, login window will be prompted when
target system is referred via RFC. Hence secure. After RFC creation, the
server can be added to the SD list.

For SD creation, transaction SECATT. 

In the System Data input field give the name of SD. Click on Create
Object (F5) icon from the application toolbar.

On the create screen, in the Attribs tab, give the Title (mandatory)
for the SD.
13

Under the System Data tab, target system NONE is already present.
Append a new row by clicking Append row icon from the toolbar. In the
Test System column, give the name of the target server. By this name
the target system will be referred in eCATT. Under the RFC Destination
column, select the respective RFC for the target system. The Instance
Description field is automatically filled by system. Click on Save (Ctrl+S)
icon from the standard toolbar.

This way multiple target systems can be added to the system data.
Creation Of Test Data Container (TD):
Test data containers are used for creation of variants. Variant values
are also maintained in TD. Variants created in TD are linked in Test
Configuration. TD is independent of test script. Hence once created can
be used for multiple scripts.
Transaction SECATT.
In the Test Data input field, give the name of the test data. Click on
Create Object (F5) icon from the application toolbar.

On the create screen, under the Attributes -> General Data tab in the
Header Data section, give Title (Mandatory) and Component (Mandatory).
Under the Maintenance System, give the System Data Container as well
as Target System, which is present in the SD.
14

Under the Parameters tab, click on Append Parameter icon and the
new lines will be appended in the parameter list. Add the lines to the
required number of parameters. Add the parameters. The parameters
name & type must match to that of the script to which the TD will be
linked. Click on Save (Ctrl+S) button from the standard toolbar.

To create variant, minimum one parameter should be present in

parameter list. Under the Variants tab, the column titles are Variant,
Description & after that the parameters from the parameters list.
ECATTDEFAULT variant will be present as default. This variant contains
values from the Parameters under the Parameters tab.

To add new variants, click on Append Variant icon. Give the details
of new variant with values. Add required number of variants this way.
Click on Save (Ctrl+S) button from the standard toolbar.

Creation Of Test Configuration (TC):

Test Configuration contains reference to one Test Script (TS), one
System Data container (SD) and can contain reference to multiple Test
15

Data container (TD). TC is used in scripts management using Test

Workbench in R/3 system.
One more Advantage of using TC is that for any given script, without
changing data at TS level, the script can be checked for different sets of
data using Variants of TC. In turn these variant values are captured from
TD. Hence the errorless recording time data is always maintained in TS.
And the Last Changed script attribute (Attributes tab -> Extras tab ->
Administration Data) will contain only the details of the person who has
made changes to script and not to the data.
For TC creation, transaction SECATT.
Give the name of TC in Test Configuration and click on Create
Object (F5) icon from the application toolbar.

On the create screen, give the Title (Mandatory) & Component

(Mandatory).

Under the Configuration tab, give the System Data Container, which
contains the Target System. Also give the name of Test Script. Test Data
and an Alias can be added to Test Data section using Append Row icon.
The Alias is an alphanumeric name up to three characters. Multiple test
data can be given if required.
16

Variants can be added from Variants tab. The TC references the

import part of the data interface of the test script. Variants can be
prepared either manually by clicking the icons Append Variant/Insert
Variants or from the wizard using test data containers referenced in the
Configuration tab.
Manually Creating Variants:

  In the Test Configuration editor under Variants tab, click on the

Append Variant icon. This will insert a new line for variant under
ECATTDEFAULT.

In the Variants field, give the name of the variant. Under each
parameter either give value or leave the field blank. Click on Save
(Ctrl+S) button from the standard toolbar.

This way multiple variants can be directly added to Variants list.

Variants from Test Data Containers:

Prerequisite for this option is that Test Data Containers should be

maintained under Configuration tab. To create variants from the Test
Data containers, click on the wizard icon (Variant Maintenance Assistant)
17

under the Variants tab.

The Variant Maintenance Assistant window appears. The left half of

the screen displays the variants belonging to a test data container. The
right half of the screen displays the variants belonging to the test
configuration. Scrolling between the multiple variants of Test Data is
available. Select the variant from the Test Data & click on Attach as
variant button. The variant will be copied to Test Configuration side.

Only the parameters in the test data container that match those of
the test script are appended. The value in a field is determined by the
following syntax: <parameter name>(<alias>, <variant>) where the
parameter name, alias, and variant all refer to a test data container.
Click on enter. Variant will be added to Variants list in TC. The links
will be present for the values of the parameters from TC to TD. Any
changes done at TD side will be referred dynamically in TC. This way
multiple variants can be created.
Linking single field of Test Data variant to Test Configuration
variant: Select a field belonging to a test data container. Select an empty
field belonging to the test configuration. Choose Link individual field. The
field belonging to the test configuration is filled. The value in a field is
determined by the following syntax: <parameter
name>(<alias>,<variant>) where the parameter name, alias, and variant
all refer to a test data container. Click on enter. The field will be
dynamically linked.
18

Linking multiple fields in Test Configuration column to a single field

of Test Data variant: Select a field belonging to a test data container.
Select a field belonging to the test configuration. Choose Insert in
column. All the empty fields in the column are filled. The value in a field
is determined by the following syntax: <parameter
name>(<alias>,<variant>) where the parameter name, alias, and variant
all refer to a test data container. Click on enter.

Click on Save (Ctrl+S) icon from the standard toolbar. And Test
Configuration is now ready to execute or to link to TestWorkbench
depending on the variant selected.