Create eCATT Scripts in SAP

To create an SECATT you must first create the Test
Script.
After the test script you will create a Test
Configuration.
Goto SECATT
Enter title
Enter component
Click on Pattern button on menu bar
Choose Group value = UI Control
Choose Comman value = TCD (Record)
Enter tcode and press enter to accept the default
interface
Click the green check mark

<<<Record the function you are attempting to
perform>>>
After backing out of the function you were recording
you
will be returned to the SECATT screen and you
should see a
prompt asking if you want to transfer the data.
Answer Yes.
Now double-click on the Interface. In this case the

interface was named PFCG_1.
Using the split screen you must now navigate

through the
various screens you just recorded replacing fixed
values
with import variables. (Look at “VALIN” fields with
the
input values you specified)
This is done by opening the Dynpro menu and going
through
each numbered screen to review your input. In this
process
my SECATT will change the description of a role. So I
will
have two variables: 1) the role name and 2) the
description.
located the Role Name on the first screen by double-

clicking on the menu node named “Field.” You must
then move
over to the third subscreen and tab over to the VALIN
column where you find the actual value you entered
into SAP
when recording the interface. You must then change
that to
a variable .
The variable name is Z_ROLENAME. Once you enter
the
variable name hit the enter key
The default parameter type will be Local. You should
change
this to Import and click on the Yes button.
Note the icon has changed from the green square.
This icon
indicates a variable is present. Now change all the
other
variables in the same manner. When complete click
on the
save icon and save as a local object or place in a
development class if you desire to transport the
SECATT.
Before you can execute the SECATT you must first
create a
Test Configuration. Do this by executing SECATT
transaction
code and entering a name for the Test Configuration
and
clicking on the create icon. This name can be
anything in
the customer name space.
Give the Test Configuration a Name and Component

and then
click on the Configuration tab
Enter the name of the test script you would like to

execute
when you execute the test configuration
Now we need to create the Excel template file to
store the
variable data in. Do this by clicking on the download
icon
or just press ctrl-shift-F11. You will then be prompted
with a Windows “save as” dialog box. Accept the
default
name and directory and click save.
Click on the Yes icon and you should see the

message at the
bottom of the screen “variants successfully
downloaded.”
Now click on the Variants icon.
We must now set the default Mode for each time the
Test
Configuration is executed. Since we will always be
running
the script with an external file choose the External
Variants / Path option.
What Is eCATT?
eCATT is a SAP Testing Tool, which can be used to
automate & test business scenarios in R/3. One can
create and execute the eCATT scripts based on
business processes mapped in R/3. These scripts can
be then tested before go live to Production server. If
needed eCATT can be used in production server also
provided exact functionality of its usage should be
known. After testing, eCATT generates a detailed log
depending on the processes executed. If the testing
is smooth with success mode, this means the
business scenarios mapped in R/3 system are
correct. And if the test results in error than one can
analyze the problems from the generated error log.
Thus helps in analyzing the error.
What Are The Various Ways Of Doing Testing?

Testing can be done by various ways like Manually,
using CATT etc.
Why To Use eCATT?

CATT will be no longer supported for the creation of
new development. So those using CATT are forced to
update to use eCATT. Comparative to manual
testing, the following are advantages of using eCATT
–
• Due to automation, testing time is reduced to a
large extent.
• Due to automation, less manpower is required
for testing. This helps financially.
• Due to automation, manual errors are reduced
to large extent. Hence results in error free
testing. This helps, as no further problems will
occur while the usage of R/3 system by end
users and hence increases the efficiency.
• Proved to be extremely useful in Rollout
projects.
eCATT Prequisites:
Web Application Server (WAS) 6.20 or more.
SAPGUI 6.20 or more.
R/3 4.6C or more. (Target system must have
sufficient support package level (Details available in
SAP Note 519858) or SAP R/3 Enterprise Release 4.7.
Before creating Test Scripts using eCATT, some

system settings need to be done –
• Maintaining Table T000
o Start transaction SM31, Maintain Table
Views.
o In the Table/View field, enter T000.
o Choose Maintain.
o In the Change View Clients, Overview
screen, select the relevant client and
choose.
o In the Restrictions when starting CATT and
eCATT field, select an entry that allows
eCATT.
• Enabling Scripting at the front End. (Check

whether SAP GUI Scripting component is
installed. There is an option for installing this
component when installing the SAP GUI.)
o On any screen, choose Customizing of local
layout from the Standard Toolbar.
o Choose Options.
o Choose the Scripting tab.
o Select Enable Scripting.
o Choose Apply.
• Enabling Scripting on application server.

o Start transaction RZ11.
o On the Maintain Profile Parameters screen,
enter sapgui/user_scripting.
o Choose Display.
o In the Display Profile Parameter Attributes
screen, choose Change value from
Application Toolbar.
o Enter TRUE in the New value field.
• The R/3 users executing eCATT scripts should

have RFC authorizations.
Features Available In eCATT:

• Test transactions and reports.
• Test remote systems.

• Check authorizations (user profiles).
• Test database updates.
• Set up customizing tables.
• Test the effect of changes to customizing
settings.
• Perform load testing.
• Check system messages.
• Call BAPIs and function modules.
• Integrated with Test Workbench, so allows
proper management of scripts using SCAT
transaction.
• Supports CATT migration to eCATT.
• All eCATT Objects are Repository Objects.
Therefore one can take advantage of Standard
SAP Transport Tools.
• eCATT Objects can easily download & upload in
XML with XSD format.
• There can be several versions of Test Scripts,
which allows different implementations with
different releases.
• The separation of Test Scripts, Test Data &
System Data allows for a considerable degree of
reuse.
Ways Of Doing Testing In eCATT:

eCATT enables to test all mySAP applications,
including those running outside of SAP GUI for
Windows and SAP GUI for Java. There are four
different drivers available in eCATT for this testing
purpose as follows –
• Non-User Interface:
Suitable for testing backend R/3 specific modules like

function modules & BAPIs, Interfaces testing in
mySAP environment, load testing.
• TCD:
Suitable for testing transactions (especially who

don’t involve activex controls), load testing. Doesn’t
require GUI for playback, so offers maximum speed
for testing.
• SAPGUI Scripting:
Suitable for testing transactions, who involve activex

controls. Requires GUI for playback & hence very
slow. Not suitable for load testing.
• Interface To External Tools:
External products, which are certified against BC-

eCATT Interface, can be tested who run under GUIs
(Other than SAP GUI for Windows & SAP GUI for JAVA)
using eCATT.
Transaction For Using eCATT:

• Choose SAP menu-> Test->Test Workbench-
>CATT->Extended CATT.
• Transaction code – SECATT.
Editors Available In eCATT From SECATT

Transaction:
• Test Configuration Editor:
Used to maintain Test Configuration object. Test

Configuration data object contains set of reference to
a Test Script, System Data Container & several Test
Data Containers. It contains all the information
necessary to run an automatic test without further
user interaction.
• Test Script Editor:
Used to create & maintain Test Scripts. There are

some recording functions available in this editor. Test
Script Editor has following areas:
 Application Toolbar.
 Information Area
 Editor Tab –
 Parameter List
 Command Editor
 Structure Editor
 Attribute Tab
Test script data object contains an executable script
& an interface for data transfer.
• Test Data Editor:
Used to create & maintain the Test Data Containers.

Test Data Containers are the data objects, which
contain a set of parameters that can be maintained
independently of a test script. Parameters can be
ABAP simple types, structures, or tables.
• System Data Editor:

Used to create & maintain the System Data
Containers. System Data Containers are the data
objects, which identify instances of SAP systems.
They can be maintained independently of the test
script like Test Data Containers.
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 will be explained in detail. In the
subsequent Parts, SAPGUI recording mode of
recording and other details of eCATT will be covered.
Steps Involved In Creation Of eCATT Test

Scripts:
• Test script is generally series of steps
(transactions) involving a business scenario.

Identification of right transactions for this script,
which prepares the input data for the script and
also covers the planned business scenario,
should be done.
• Recording of test script by selecting proper
recording mode.
• Execution of test script immediately after
recording without parameterization to confirm
the errorless recording.
• Parameterization of the import, export &
variable parameters.
• Preparing variants using Test Data Container.
• Linking Test Script (TS) & Test Data Container
(TD) by Test Configuration (TC).
• Execution of TS using TC for different Variants.
How To Identify Any Transaction For TCD

Recording Mode:
• If the transaction runs under SAP GUI for
Windows or SAP GUI for Java, it can be recorded

by either TCD or SAP GUI mode.
• If the transaction doesn’t have any activex
controls then TCD recording mode can be used.
• If the transaction has activex controls and these
controls are NOT mandatory for the functionality
of the transaction, then also TCD mode can be
used as recording mode.
Key Features Of TCD Recording Mode:

• It is suitable for the transactions not having
activex controls, so it doesn’t require any GUI

playback mode.
• It is very fast.
• It has its own built in screen simulation for
standard screen elements. Hence while
execution, the controls are deactivated and the
user’s actions are simulated by reading the
recorded data flow.
Steps For Recording Using TCD Mode:
• Transaction SECATT.
• Give the name of the Test Script (TS) in Test

Script input box. The Version input by default is
with value 1.
• In the Attributes ->General Data Tab, the value
of the Component will be BC-TWB-TST-ECA for
eCATT.
• In the test script editor, choose the Editor tab.
• Choose Pattern button from the application
toolbar.
• The Insert Statement dialog box appears.
• From the Command Dropdown List, choose TCD
(Record).
• In the Transaction field, enter the transaction
code of the transaction that you want to record,
and choose Enter.
• In the Interface field, a system-generated name

appears.
• Accept the system-generated name or edit it.
• If there is a system data container, you can
enter the target system in the Target System
field.
• Choose Enter. The transaction starts recording.
• Work through the transaction as normal. When
you leave the transaction, the system returns
you to the script editor with the Recording ended
dialog box.
• Choose Yes to transfer the data.
• A TCD command and its associated Command
Interface will be inserted in test script editor of
SECATT.
Execution of Recorded TCD script:

• Once the recording of the transaction is done
and the details of recording are taken back to
the test script editor, script can be executed.
• First of all without parameterization the script
should be executed to confirm the errorless
recording. At the runtime, a Start Options
window appears. Give the following values on
this window –
o Error Behavior with value S No termination,
continue with next script.
o System Data – Name of the system data
container, which contains the Target
System.
o Target System – Name of the server on
which the execution will happen.
o Select the Log Display check box.
o In TCD section of window, select N – Process
in background, synchronous local.
o Click on Execute button.
• Transaction will start executing, which appears

at the bottom.
• If the recording is error free, then success log
will appear. And if there is any error in recording
of the transaction and its replay then error log
with details will appear.
• After the confirmation of error free recording,
one can go ahead with parameterization of the
import, export & variables.
• In SECATT transaction using Test Data (TD),
variants can be prepared for the recorded test
script. In the Parameters tab, add all the
parameters from the test script. This will appear
as ECATTDEFAULT in the Variants tab. Add
multiple variants, as per requirement in the
Variants tab. Test Data is independent of test
script. Hence can be reused wherever required.
• In SECATT transaction using Test Configuration
(TC), the TD & TS can be linked together on the
Configuration tab. On the Variants tab, using
Variant Maintenance Assistant required variants
values from TD could be linked to TC.
• Finally the TC can be executed from SECATT
directly by giving the required variant name at
runtime.
• The TC is used in managing the scripts in
plans/packages using SCAT transaction.

of recording is explained in detail. In the Part III, the
creation of eCATT Scripts using SAPGUI mode is
explained in detail. In the subsequent Parts,
Management of eCATT scripts via Test Workbench
and other details of eCATT will be covered.
Steps Involved In Creation Of eCATT Test

Scripts:
• Test script is generally series of steps
(transactions) involving a business scenario.

Identification of right transactions for this script,
which prepares the input data for the script and
also covers the planned business scenario,
should be done.
• Recording of test script by selecting proper
recording mode.
• Execution of test script immediately after
recording without parameterization to confirm
the errorless recording.
• Parameterization of the import, export &
variable parameters.
• Preparing variants using Test Data Container.
• Linking Test Script (TS) & Test Data Container
(TD) by Test Configuration (TC).
• Execution of TS using TC for different Variants.
How To Identify Any Transaction For SAPGUI

Recording Mode:
• If the transaction runs under SAP GUI for
Windows or SAP GUI for Java, it can be recorded

by either TCD or SAP GUI mode.
• If the transaction doesn’t have any activex
controls then TCD recording mode should be
used. Here SAPGUI mode can also work.
• If the transaction has activex controls and these
controls ARE MANDATORY for the functionality of
the transaction, then only SAPGUI mode can be
used as recording mode.
Key Features Of SAPGUI Recording Mode:
• It is suitable for the transactions having activex
controls, so it requires GUI playback mode.

• It is slow comparative to TCD recording mode.
• It is not suitable for load testing.
Steps For Recording Using SAPGUI Mode:

• Give the name of the test script (TS) in Test

with value 1.
of the component will be BC-TWB-TST-ECA for
eCATT.
• In the Attributes ->General Data Tab, the values
of the SystemDataContainer should be given
which contains all target systems with RFCs on
which the script will be either executed or
recorded & in the TargetSystem the name of
target system (e.g. recording R/3 server) should
be mentioned.
• In the test script editor, choose the Editor tab.
• From the Application Toolbar, click on Record
Test Script (Ctrl+F5).
• One window appears with title ‘Record SAP GUI
Command’, select each check box of the
Automatic Generation section. Click On Start
Recording button.
• Login in to Target System from SAP Logon or

either create a new session on target system.
• One window appears on the newly created
session of target system as ‘Record SAP GUI
Command’. Click on Yes for recording.
• One window with title ‘Recording Running’ will

appear. In the section of Record initial state for
value check, select the Record with inactive
checks radio button. Below the radio buttons,
one table control with the record/ types for GUI
elements is mentioned along with check boxes.
Select all the check boxes. Select the check box
of Closed Recorded GUIs and click finally the
Continue (Enter) button. This recording window
exists till recording ends. Lots of data of initial
state for the mentioned screen element types
will be generated. So one can be selective in
selecting the checkboxes.
• Recording can be started with the transaction

working as normal on the newly generated
session.
• Once the transaction is complete with the
functionality, from the Recording Running
window, click on End Recording button. This will
take the recorded details of the transaction to
SECATT transaction in the test script editor.
• A SAPGUI command and its associated
Command Interface will be inserted in test script
editor of SECATT.
Execution of Recorded SAPGUI script:

• Once the recording of the transaction is done
and the details of recording are taken back to

the test script editor, script can be executed.
• First of all without parameterization the script
should be executed to confirm the errorless
recording. At the runtime, a Start Options
window appears. Give the following values on
this window:
o Error Behavior S No termination, continue
with next script.
System.
o In SAPGUI section of window, select
following options:
 Procg Mode SAPGUI - S Synchronous
GUI Control
 Error Mode for SAPGUI - C Continue
(Continue on Any Error)
 Stop When - N Do Not Stop
 Close GUIs - R Close Generated
Sessions After REF
• Transaction will start executing, by creating a
new session. This requires GUI for playback.
one can go ahead with parameterization of the
import, export & variables.
values from TD could be linked to TC.
runtime.
plans/packages using SCAT transaction.

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 Testworkbench & 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 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,
&REFNAME, &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 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.
 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. Give the login
details.
 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.
• 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 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 recording of the

transaction. These values are present under the
ProcessedScreen 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 ProcessedScreen
-> 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 ProcessedScreen 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 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 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.
o 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 ProcessedScreen -> InitialState
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’.
o 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.
o Declare this export parameter in the
parameter list. And it can be passed further
in same recording to subsequent screens as
import parameter.
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.
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.
• 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.
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.
• 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.
• 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 SystemData Container as well as Target
System, which is present in the SD.
• 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 Data
container (TD). TC is used in scripts
management using TestWorkbench 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
• 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.
• 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.
o 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.
o 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) 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.
 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.
o 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.

Part IV, the parameterization, creation of Test
Configuration,Test Data Container, System Data
Container are explained in detail. In Part V, the
management of eCATT Scripts via Testworkbench will
be explained. In the subsequent parts eCATT Logs &
other details of eCATT will be covered.
Why eCATT Scripts Management Is Required By

Test Workbench By SCAT:
• eCATT scripts can be very well executed via the
transaction SECATT by which the scripts are

created. In SECATT, the script execution can
happen at Test Script (TS) level or Test
Configuration (TC) level. At test script level
execution, the data may need to be changed
depending on the behavior of transaction(s) in
the script. This change will override the default
recording data of the script. If the script
recording is error free then change of the data at
TS level is not recommended. Hence execution
of the script via TC is adapted. In TC, the data is
changed at variant level, which are picked from
Test Data (TD) Container. Changing data in TD
doesn’t affect the default recoding time data i.e.
ECATTDEFAULT. Now even if the execution can
happen via TC, then also clubbing of TCs, which
are related depending on a series of
functionality or the function module or location
against which the test case is being executed, is
not possible via SECATT transaction.
• Moreover one has to maintain the log IDs of the
scripts being executed via SECATT. As script
executes multiple times, the logs are stored
against that script. So which log has generated
during the final regression testing time is
difficult to make out.
• Hence for the Regression Test, the requirement
is that somewhere the log IDs should be present
along with the scripts, which are as a result of
the test carried out during final testing. These
log IDs will be available for future use. So all the
requirements of grouping the scripts on some
defined conditions, availability of log IDs for
future usage will be fulfilled by Test Workbench
SCAT Transaction.
How Scripts Can Be Managed In Test

Workbench:
• Test cases can be managed in test workbench
via Test Catalog, Test Plans & Test Packages.

Also with the Test Workbench test status can be
analyzed. Test status is in terms of traffic lights
for eCATT logs.
• Test Catalog - A Test Catalog is a set of test
cases in a hierarchical hypertext structure. To be
able to use the test catalog to generate test
plans, one must put it in the SAP Application
hierarchy. One can create test plans across
several test catalogs via the SAP application
hierarchy. This procedure allows creating a lot of
small test catalogs, which are easier to maintain
than one large test catalog.
• Test Plan - A test plan is a set of test cases,
which must be tested, in a particular period for a
particular purpose. The relevant test cases can
be divided among several test catalogs.
• Test Package - A test package is a person and
period-oriented view of a test plan. It contains all
tests, which a tester is to perform in a specified
period.
• After a test, the tester sets the test case status,
e.g. ‚Pass‘ or ‚Fail‘. one can get an overview of
the status of all test cases of a test plan with
Status analyses.
Creation Of Test Catalogs:

• Transaction SCAT or Tools->ABAP Workbench-
>Test->Test Workbench->Test Organizer-

>Manage Test Catalog.
• Click on menu Environment->Manage Test
Catalog.
• Click on Create (F5) icon from the application
toolbar.
• Test Catalog Information window appears.
• Give the name of System Data and Target
System in the eCATT section. System Data
container should contain the RFC for the Target
System on which the script will execute.
• In Test Catalog Header Data section give Title.
The title is the name of the catalog by which it
will be referred in the Test Plans.
• In the Responsibility section, Name contains the
logged in user name by default.
• Click on Save (Ctrl+S) from the standard toolbar.
The Test Catalog is created. Now the Test

Configurations need to be added to this test
catalog.
• Select the Test Catalog created in step 8 and
click on Change (F6) icon from the application
toolbar.
• Under the Structure, name of test catalog will
appear.
• Select Test Catalog name and click on the button
As Subnode (F5) from the application toolbar.
• Insert Nodes window appears. Here we are

adding the Test Configurations to the test
catalog. So select the second radio button of
Test Case. Give the value from the dropdown list
as E eCATT Test Configuration.
• In the Test Case Key, click on F4 help. Select the
Test Configurations from the system. As the
grouping of the scripts is on the basis of the
location against which the test is carried out, so
all the scripts, which will be specific to this
particular location, should be selected.
• In the Variant Selection, select the Special
Variant radio button. Click on F4. Now in the list
shown by system will show only the common
variant to all the select Test Cases from step 13.
If in case the scripts are selected which don’t
have common variant names then only the
variants of first test case appears in the list.
o Without Variants – Only with
ECATTDEFAULT.
o All Variants Including Default Variant – All
the variants including ECATTDEFAULT
variant.
o All Variants Excluding Default Variant – All
the variants excluding ECATTDEFAULT
variant.
o Special Variants – Only for the selected
variants from the list, which are common to
all the selected test cases.
• Select the variant for the location against which
testing is carried out and press enter. All the
selected scripts along with the variant name will
appear under the Test Catalog name.
• Click on Save (Ctrl+S) button from the standard

toolbar..
• In order to use the test catalog in Test Plans,
test catalog must be present in SAP Application
Hierarchy. To achieve this, click on button
Library (Ctrl+F12) from the application toolbar or
click on GOTO menu -> Library.
• Select path as follows => Test Organizer Library

-> Application Components -> BC -> BC-TWB
Test Workbench -> BC-TWB-ORG Test Organizer
-> BC-TWB-ORG-CTL Test Catalog. With the Test
Catalog selected, click on Nodes (Insert Nodes
F5) button from the application toolbar.
• One small window of Create Link appears. Click
on (Find) Test Catalog button. Give the name of
Test Catalog created in step 16 in the
Description field. The name will appear in the
search help output window. Select the catalog
and press enter.
• One Information popup appears ‘ The two

structures are from different mySAP
components’. Press Enter. The catalog will be
added under the Test Catalog node.
• Click on Save button from the standard toolbar.
Now the catalog is present in the application
hierarchy.
This way multiple test catalogs can be prepared
depending on some defined conditions like
different locations against which the testing will
be carried out. These test catalogs then can be
used for the preparation of test plans.
Creation Of Test Plans:

• Transaction SCAT.

Plans.
• Click on the Create (F5) icon from the application
toolbar.
• Create Test Plan window appears. In the
Template, select Application Component
Hierarchy. Under the Test Plan & Header Data
section, give the Test Plan Title. With the Test
Plan Title, the plan will be referred. In the eCATT
section, give the name of System Data Container
& Target system on which the scripts will
execute. Click on Enter.
• The system will take to Crate Test Plan screen

where the Test Organizer Library is displayed.
Here from this SAP Application Hierarchy, select
the test catalog. This test catalog is the one
whose scripts will be pulled in the test plan and
then subsequently in test package of that plan.
Scripts from multiple test catalogs can be taken.
Select path as follows => Test Organizer Library
-> Application Components -> BC -> BC-TWB
Test Workbench -> BC-TWB-ORG Test Organizer
-> BC-TWB-ORG-CTL Test Catalog. Select the
scripts from single or multiple Test Catalogs as
per the requirement.
• Click on Generate (F8) button from the

application toolbar. After the plan is generated
save it.
Test Plan is ready now. One can prepare the

Packages from this plan by some defined
conditions like scripts of foreground execution,
background execution or different tester or
different target systems at execution time.
Creation Of Test Package:

• Select the test plan created in step 6 above.
Click on Test Packages (Ctrl+F9) button from the

• Test Organizer – Test Package Management

screen comes. Click on Create Test Package
button.
• It will display all test catalogs under that test

plan. Select the scripts from the required test
catalogs depending on the condition on which
that package is planned. After selecting the
scripts, click on Generate (F8) button. The
Create Test Package window for title appears.
Give the name of the package in the title. By this
name the package will be referred always. Click
on Enter.
• Once the package is prepared, select the

package name and click on Status button for
refresh. Once the refresh is done, the right panel
will show the number of scripts against that
package under the Error/No Result/Ok columns.
The package is also now ready. This way
multiple packages can be prepared which will
involve all the scripts of the plan in totality.
Execution Of Test Cases Series Via Test

Workbench:
• Test Cases can be executed via different ways at
different levels in test workbench system. Test

Cases can be executed at Test Catalogs
level/Test Plan level or even at Test Package
level.
• The scenario depicted here is by creating a pool
of test cases in Test Catalogs. Then from those
test catalogs preparing Test Plans depending on
some defined conditions. From these plans again
preparing Test Packages. And finally executing
these Test Packages which give the transparent
picture of how the testing was planned and
carried out.
• So transaction SCAT.
Plans.
• Select the Test Plan, which needs to be
executed.
• Click on Test Packages (Ctrl+F9) button from the
• Select the package. Before the execution, the
status in traffic light for each of the script will be
untested.
• For the mass execution of the complete

package, select the package. Then click on
Automatic Test button from the application
toolbar.
• Test Case Selection window appears. If in case
all the scripts need not to be executed at a given
time, then select the required once. By default
all the scripts under the package are selected for
execution. Click on Enter.
• One window with title ‘Start Options (eCATT
Mass Start)’ will appear. Select the following
options –
o Error Behavior - S No termination, continue
with next script.
System.
o Select the Status In TWB check box.
o In TCD section of window, select N – Process
in background, synchronous local.
o In SAPGUI section of window, select
following options -
 Procg Mode SAPGUI - S Synchronous
GUI Control
 Error Mode for SAPGUI - C Continue
(Continue on Any Error)
 Stop When - N Do Not Stop
 Close GUIs - R Close Generated
Sessions After REF
• On execute button click on Start Options

window, the system prompts for login &
password window of Target System. Give the
login details and execution of scripts will start in
series.
• Once the execution is completed, the logs are
taken back to test workbench and the status of
traffic light will either change to green for
success or red for error.

Part IV chaining, parameterization, creation of Test
Configuration, Test Data Container, and System Data
Container are explained in detail. In Part V, the
management of eCATT Scripts via Testworkbench is
explained. In Part VI, the eCATT Logs will be
explained in detail & in the subsequent parts other
details of eCATT will be covered.
What Are eCATT Logs:

• eCATT Logs are generated every time a test
script or test configuration is executed either by

SECATT or SCAT transaction.
• The log is hierarchically structured according to
the test script used, and displayed as a structure
with nodes. Each test script in turn may contain
one or many recorded transactions. This also
includes any inline ABAP code or any other
eCATT commands if used.
• Each of the eCATT log shows the execution
status of each of the step executed for the given
test script along with necessary details like
unique log ID, executed variants details,
Import/Export/Local parameters details, Target
System details, Source System details, Test Data
container, time taken for each step of
automated steps as well as total execution time
in seconds, execution mode like With
Interruption (Foreground for TCD & with user
intervention for SAPGUI) or Without Interruption
(Background for TCD & without user intervention
for SAPGUI) etc.
Advantages Of eCATT Logs:

• eCATT log stores all the steps of the test case
along with lots of other useful information about

systems, variants etc.
• These logs help in analysis of the business
process. As all the system messages are stored
in the logs, which are generated during
execution of the given script, it becomes simple
to analyze the result set.
• The expiry date of logs can be changed. So they
can be maintained for the defined time frame.
And hence the results of one regression testing
can be used as reference for next regression
testing. This helps in rollout projects.
• In case of errors, system prompts the relevant
messages, which help in understanding of the
process that has gone wrong. After necessary
corrections, the script can be again executed
and the new log will be generated. The success,
error or execution status is depicted by colors in
logs. So it becomes much more user friendly to
analyze.
How To Look In eCATT Log From Log ID:

• Click on Logs (Ctrl+F12) icon from the

• Under the Log Selection section, in Currt.

Procedure No. Input field give the log ID.
• Remove the values from the Starter & Start date
input fields. They are not necessary in this case,
as Log ID is known. In case log ID is not known &
one wants to analyze all the logs generated on a
particular date by a particular tester then give
these input fields. Other input fields include Test
Configuration, Test Script, Expiry date, which in
this case are not mandatory. Different input
combinations can be made for eCATT logs
depending on what kind of input is in hand. In
absence of eCATT Log ID, the combination of
other input fields becomes useful.
• Click on Execute (F8) button.

• eCATT Log with the Log ID in title appears in
next window. By click on Expand All Nodes (F5)
button, all the nodes will be drilled down till end.
And the detailed view of log will be displayed.
How To Look Into eCATT Logs From Test

Workbench:
• With the assumption that test package is
executed, logs from test package will be

analyzed here.
• Transaction SCAT.
• Menu Environment -> Manage Test Plan.
• Give the name of test plan. Click on Status
Analysis button from the application toolbar.
• The execution status of the package is in terms
of traffic lights under the Status column with
description under Status Text column.
• Click on the traffic light of the required test

configuration. After click, Status Maintenance
window appears. This window contains Test Case
details, Status of execution etc. Click on Log
(Shift+F1) button from the application toolbar.
• Detailed eCATT Log is displayed against that test
configuration with unique log ID.
Analysis Of eCATT Logs:

• Top Level Information: The first line of the log
displays the log identification number.

Depending on the tests, other information is also
displayed:
o The number of test configurations executed.
(This information appears if the execution
happens from the test workbench via SCAT).
o The name of the test script or test
configuration executed via SECATT.
o The version number of the test script.
o The execution mode i.e. With Interruption
(Foreground for TCD & with user
intervention for SAPGUI) or Without
Interruption (Background for TCD & without
user intervention for SAPGUI) .
• After the top line following information is

displayed in one line: System, Client, User,
Language, Release, ApplicationServer, Operating
System, Database System, Date of exeuction,
Time of execution.
• Script Details:
After the detailed systems information, the test
script details like test script name, version,
description & execution time taken by the
complete script is displayed in seconds. The
system Data Container as well as Test Data
container are also displayed. The status of
execution of scripts is depicted by colors either
green background color for success or red
background color for error.
Successful Script
Script in Error
• Maintenance System:
If a test script has a maintenance system, the
RFC destination is displayed and the detailed
component information is shown below it.
• Comments, Duration, IF-ENDIF structure:

To display comments, duration time in seconds
in the log, click on Settings…(Shift+F7) icon from
the application toolbar. Select the check boxes
of Disp. Duration, Display Comments. Press
Enter.
The log with the comments, duration time will be
displayed. If the IF-ENDIF structure is executed,
it is displayed with green color otherwise not.
• Errors, Multiple Variants, Messages, Navigation:

o Error: If a script contains one or more errors,
it is in error with background red color. If a
node is marked as containing an error, the
node above it in the hierarchy is also
marked as containing an error with red
color. Error message is immediately
displayed after that step and even after the
script details.
o Messages: Messages during the execution

are displayed in the log under messages
node. Messages can also be seen in XML
data.
o Multiple Variants: Script can be executed

using multiple variants. The variant names
appear one after the other in the log.
o Navigation: By clicking on the hyperlinks

from the log, one can navigate to the test
script, system data or test data etc. When a
recorded transaction uses a print function
that sends a document to the spool, a
message is recorded in the log.
• XML Data:
XML data is generated when testing function
modules and transactions. To view XML data,
click the hyperlink name of the XML data in the
log.
Here is an extract of XML-DATA-01 from the log

shown above.
How To Change Expiry

Dates/Deletion/Archiving Of eCATT Logs:
• Click on Logs (Ctrl+F12) icon from the
• Under the Log Selection section, in Currt.
Procedure No. Input field give the log IDs by
clicking on the Multiple Selection button.
Multiple Selections For Currt. Procedure No.
window appears. The entire log IDs should be
given here. Click on Execute (F8) button.
• On the Log Selection window, the multiple

selection button will show green status for
having multiple values of Log Ids. Click on
Execute (F8) button.
• Logs from the selection screen are displayed in

the tabular format with the details like status,
start date, end date, starter, expiry date, test
script, test configuration etc.
• Select all the logs by clicking on Select All icon
on left top of the grid. Click on Change Expiry
Date (Ctrl+F8) button from the application
toolbar.
• Date change window appears. Set the required

expiry dates to the logs. Click on Enter. The
Expiry date will change for the all the selected
logs to this new value.
• When the expiry date reaches for any log, the

log is automatically deleted. If the automatic
deletion is not required, explicitly also the log
can be deleted from the menu Log Selection-
>Delete (Shift+F2).
• Also the logs can be archived. Select the log
from the list, from the menu Log Selection ->
Archiving On/Off (Ctrl+F7).
How To Find Database Tables For eCATT Logs:

• Transaction SARA.
• In the Object Name input field give value

ECATT_LOG.
• Click on Database Tables button from the
• On the Tables & Archiving Objects window, in

the Tables from which data is archived section,
tables are displayed for eCATT Log. These are
the tables in which the log is stored in the
database. Select the All Tables radio button.
Sapna Modi is a Software Engineer.

explained in detail. In Part IV chaining,
parameterization, creation of Test Configuration, Test
Data Container, and System Data Container are
explained in detail. In Part V, the management of
eCATT Scripts via Testworkbench is explained. In Part
VI, the eCATT Logs are explained in detail.
In Part VII, creation of eCATT Scripts using Non-User
Interface mode will be explained along with the
details of Copy, Rename, Delete, Upload and
Download of eCATT objects. In the subsequent Part,
tips & l inks of eCATT will be covered.
Key Features Of Non-User Interface Recording

Mode:
• The non-user interface can be used for testing
back-end R/3-specific modules, such as function
modules and BAPIs.
• It should be the preferred driver for interface
tests in the mySAP environment.
• It is fast, efficient, and suitable for load testing.
Steps For Recording Using Non-User Interface

Recording Mode:
• Give the name of the Test Script(TS) in Test

with value 1.
of the component will be BC-TWB-TST-ECA for
eCATT.
• In the Attributes ->General Data Tab, the values
of the SystemDataContainer should be given
which contains all target systems with RFCs on
which the script will be either executed or
recorded & in the TargetSystem the name of
target system (e.g. recording R/3 server) should
be mentioned.
• Click on the Pattern (Ctrl+F6) button from the
• From the Command dropdown, select FUN. In
the Function Module give the name of the
function module/BAPI, which needs to be tested.
Click on enter. The Interface name will
automatically appear (E.g. Here
BAPI_MATERIAL_SAVEDATA is used). Click on
enter.
The FUN with the function module/BAPI name

along with the command interface will be
inserted into command editor.
• Double click on the Command Interface (e.g.

BAPI_MATERIAL_SAVEDATA_1) from this FUN
syntax in the command editor. On the right side,
the command interface will open in a window.
The command interface will have all the
IMPORT/EXPORT/TABLES/EXCEPTIONS parameter
of the given function module/BAPI.
• Under the
IMPORTING/EXPORTING/TABLES/EXCEPTIONS
node, all the import parameters, export
parameters, tables & the exceptions belonging
to that function module/BAPI are present. These
parameters can be parameterized.
If the function module or BAPIs are called in the
ABAP Program then the way the values are
passed to those parameters, similar ways values
will be passed here in terms of Parameterization.
The declaration of these parameters will happen
at the Parameter List as either
Import/Export/variable.
The output message variables, like the other

recording modes, can be captured from the
Exporting node.
• All the parameters needed for the execution of

the function module/BAPI will be declared in
parameter list and then parameterized.
• In the current example, BAPI is used for Material

create and saving this data. Before this a unique
material number is generated by system using
another BAPI. This is written in ABAP-ENDABAP
block. After the number is generated, this newly
generated number is assigned to a variable. As
import and export parameters cannot be used in
inline ABAP code. So the variable is used. This
variable is then passed as import parameter to
BAPI, which is to be tested via this recording.
• Once the parameterization is done. The script is

ready for execution. There is no specific Start
Options mode available for Non-User Interface
mode at execution time. It always executes in
Background mode.

• Analyze the generated log (weblog Part VI).
Following is the log generated for the example
mentioned here. It shows Import, Export
parameter along with the execution mode and
time taken for each of the individual step and
complete execution.
• Inline ABAP code is also shown in the log. It
shows the results also.
• The function module/BAPI is also shown in log.

The Importing/Exporting parameters along with
the message generated.

one can go ahead with the preparation of TD, TC
for the TS.
(Weblog Part IV).
values from TD could be linked to TC. (Weblog
Part IV).
runtime. (Weblog Part IV).
plans/packages using SCAT transaction. (Weblog
Part V).
How To Copy, Rename & Delete eCATT Objects:

• One can copy all the eCATT Object i.e. Test
Configuration, Test Script with Version, Test

Data & System Data.
• Click on Copy Object (Ctrl+F5) icon from the
• Copy dialog box appears with the copy detail for

the eCATT Object whose radio button was
selected on SECATT.
• For Test Configuration copy, give the name of
the new TC and click on Copy button. The new
test configuration will be ready.
• Similar way, for Test Data and System Data, give

the new names and click on Copy button.
System Data Copy-

• For copying Test Script, system gives one
Version input field on Copy dialog box. If this
field is left blank then all the versions are copied
to new name. Otherwise only the specified
version is copied.
• Rename eCATT Object: Similar to copying the

eCATT objects, renaming can be done. On the
application toolbar of SECATT transaction, click
on Rename Object (Ctrl+F6) icon from the
Depending on the eCATT object selected, the

Rename dialog box will appear. Give the new
name and click on Rename button. The object
will be renamed.
Similar ways all other eCATT objects can be

renamed.
• Deletion Of eCATT Objects: Similar to Copying &
Renaming, all the eCATT objects can be deleted.
Click on Delete Object (Shift+F2) from the
application toolbar of SECATT transaction.
Confirmation Prompt dialog box will appear.

Click on Yes for the deletion of object.
There is no dependency on objects for deletion.

Meaning deletion of TC won’t affect the TD & TS
inside it. In case of Test Scripts deletion, to
delete specific version mention it in the
transaction. If the version field is left empty, all
the versions are deleted. Similar way all the
other eCATT objects can be deleted.
How To Download eCATT Objects:

• eCATT objects can be downloaded in XML & XSD
format. These files can be further uploaded to

any system. Hence the reuse of objects and their
transfer amongst the R/3 system is facilitated.
All the objects i.e. Test Script, Test
Configuration, Test Data & System data can be
downloaded via SECATT transaction. For a script
to work successfully, the entire linked object
should be present along with it like System Data,
Test Configuration & multiple Test Data
containers. This linking of objects can be known
and the entire related object could be
downloaded in one shot.
• Give the name of Test Configuration or Test
Script or Test Data or System Data, which needs
to be downloaded.
• Menu Goto -> Reference List.
• One List Of Referenced Objects screen comes.

Object Type & Object Name automatically
appears depending on the selected eCATT object
on SECATT screen.
• Click on Execute (F8) button from the application
toolbar. List of referenced objects will appear.
• Click on Download All Objects (F5).
All the objects from the referenced list will be

downloaded at the path given in the Browse For
Folder dialog box. Click on Ok.
The files will be downloaded at the given

destination in XML XSD format.
• Downloading Individual eCATT Object: Individual

objects can also be downloaded instead of the
complete reference list from transaction SECATT.
Give the object name and click on the Display
(F7) icon from the application toolbar. From the
menu <eCATT Object>-> Download, the given
object can be downloaded.
Similar way other eCATT objects can be

individually downloaded.
How To Upload eCATT Objects:
• eCATT objects i.e. Test Script, Test Data, Test
Configuration as well as System Data can be

uploaded via SECATT transaction from the XML,
XSD files. The prerequisite is that both the XML
& XSD files should be present in the same folder.
• Menu eCATT Object -> Upload.
• Select Files For Upload dialog box appears.

Select the file and click on Open button.
• Change eCATT objects to be uploaded window
appear. Select the eCATT object, give the target
object name if not present & click on Enter. The
object will be uploaded and directly taken to
SECATT window.
In case of Test Script, the Target Version (TV)
number can be given.
This way multiple objects can be uploaded.
System Data Container Upload/Download:

When uploading or downloading system data
containers for copying to another system, the name
of an RFC destination remains unchanged in the RFC
Destination field. However, in the new system, this
name might not exist or might be that of a different
RFC destination. In this case, RFC destination needs
to be maintained.
Sapna Modi is a Software Engineer
explained in detail. In Part IV chaining,
parameterization, creation of Test Configuration, Test
Data Container, and System Data Container are
explained in detail. In Part V, the management of
eCATT Scripts via Testworkbench is explained. In Part
VI, the eCATT Logs is explained in detail. In Part VII,
creation of eCATT Scripts using Non-User Interface
mode is explained along with the details of Copy,
Rename, Delete, Upload and Download of eCATT
objects. In the Part VIII, tips & links of eCATT will be
covered.
Tips To Be Followed Before or During
Recording:
• Test case is generally a series of transactions
pertaining to one business scenario. Before

recording of the script via eCATT, work with the
script on R/3 system directly with a given set of
valid data for the entire script. Execute the script
manually directly on R/3 for at least 2-3 times
with the same set of data. On 2nd time onwards,
system may prompt some error messages,
warning messages etc. Correct the data only for
the error messages and let the warning
messages & popup be as it is. This way the data
is ready which gives all possible behavior of the
transaction. Now record the script with this data.
Recording will now include the extra popup,
warning messages, which normally don’t come.
Make these screens optional in SAPGUI mode.
After recording, without parameterization check
for the errorless recording by execution. If the
recording is successful, then only go for
parameterization otherwise do the corrections
by rerecording if needed.
• There can be some default settings for the
parameters values on the user ID by which the
recording is done. Make sure that before
replaying those recorded eCATT scripts, the
default user ID settings are done on the system
on which the final execution will happen.
Following such prerequisites in terms of user ID
settings or some behavior of transaction of first
run, in same session with some default data etc.
always help in the successful execution of the
scripts.
• If the transaction to be recorded on R/3 involves
dropdown list box, do the following setting
before recording of that transaction. Due to
following settings, the keys will be assigned to
each item in the dropdown in sorted manner and
recording will happen for these keys values. This
helps in replaying the transaction successfully.
o Log on to target R/3 system. On any
transaction, click on Customizing Of Local
Layout (Ctrl+F12) icon from the application
toolbar. Select the Options -> Expert.
o On the Expert tab, in the Controls section

select the checkboxes of Show keys in all
dropdown lists & Sort items by keys.
o Transaction with dropdown without keys

setting –
Transaction with dropdown keys settings –

• If the recording includes, adding some value to
the table then don’t scroll up to blank line. Use
directly the Create Item icon and then add the
new values. Scrolling fails at the time of replay.
• If the recording includes searching some value

from ALV grid and the value is known then don’t
scroll and look for the value. Use the Search icon
from the ALV toolbar for searching. Once the
search item is found, then click on the item for
further processing.
• It happens at times that the screen size reduces

at the time of recording in width and height. In
such scenario if the field to be captured during
recording is present somewhere at the bottom,
then don’t scroll. Use the TAB key till that field is
reached. Due to Scroll functionality possibility of
script failure becomes high.
• It is not possible to capture the value from a
dynamically generated list. If the recording
includes a dynamically generated list and one
value (which is not known until execution) from
this list needs to pass to the subsequent step in
recording then use foreground mode of
recording for this dynamically generated list. Use
WAIT XXX statement after its recording. During
this WAIT XXX seconds, capture the value from
the generated list manually and pass it to the
next recording.
SAPGUI & TCD Recording Modes:

• Error messages can be recorded and replayed by
Only SAPGUI recording mode and NOT by TCD

mode.
• Warning messages are automatically handled by
TCD mode but in SAPGUI recording mode they
need to be handled if they require user
intervention for further processing. (E.g. Pressing
and enter key will enable all the fields after
warning message)
• Screens can be made Optional for execution in
SAPGUI mode. This optional screen will be
handled automatically at runtime even if not in
the screens flow. But in TCD screens can’t be
made optional which may or may not occur
during execution. Rather in TCD screens can be
made active or deactivated in the cases where
depending on some input values, the recording
can be reused. The screens sequence should be
known well in advance in TCD for making any
screen active or not.
• Only local variables from the eCATT Parameters
can be used in Inline ABAP code. Import and
Export parameter are not allowed.
• Passing values to subsequent screens at runtime
is only possible in SAPGUI and not in TCD mode.
• SAPGUI Confirm Popup:
In order to avoid the following popup for SAPGUI
recording, option is available in R/3 System.
Click on the icon with tool tip Customizing Of

Local Layout (Alt+F12) in the standard toolbar
on any transaction of R/3 system. Select the
Options menu.
From the Options -> Scripting, uncheck the
check box of Notify when a script attaches to a
running GUI. Click on Apply -> Ok. The popup
won’t appear onwards.
• Making SAPGUI Screen Optional:

It is possible in SAPGUI recording mode to make
screens optional.
Double click on the screen or message popup,
which needed to make optional on the left side
in the command editor. On right side, the
interface will open. Under the ProcessedScreen
node, first option is Active 'X'.
Change Active 'X' to 'O'.
'X' - Active (Compulsory will execute)

'O' - Optional (will execute only when it will be in
execution flow).
eCATT Commands:
• An eCATT script consists of individual eCATT
commands. Each command begins with a

command word and ends with a period.
Comments (*) and assignments (=) are
exceptions to this rule.
• There can be several commands on the same
line. Comments (*), assignments (=), and inline
ABAP are exceptions to this rule.
• E.g. of eCATT Commands are -
*, =, ABAP, CHETAB, CHEVAR, CLEAR, DO, ELSE,
ELSEIF, ENDABAP, ENDDO, ENDIF, ENDMESSAGE,
EXIT, FUN, GETTAB, IF, LOG, MESSAGE,
ON_LAST_MESSAGE_CHECK, REF, REFCATT,
REFEXT, REMOTECATT, RESTAB, SAPGUI,
SENDEXT, SETTAB, TCD, WAIT,
WAIT_ON_DYNPRO
• There are examples involving these eCATT
commands, which can be found from the menu
Goto-> Use Of Command.
• On the next screen eCATT – Search Of eCATT

Commands in Test Script, in the Command input
field, give the name of the eCATT Command
from the F4 help.
And click on Execute (F8) button from the

application toolbar. List of examples will be in
the output.
Key Points Can Be Followed For Successful

Testing Via eCATT:
• Analysis of transactions with different behaviors
for different sets of data. Finally selecting the set

of data, which gives maximum possible
messages/popup for the given transaction.
• Automation along with the verification before
final regression on Quality Server.
• Preparation of variant files with details having
comments on each value, which helps in
preparation of data for the scripts before
execution.
• Analyzing the behavior of transactions for the
background/ foreground execution mode.
Accordingly preparation of packages for
background & foreground execution.
• Preparing the prerequisites for the regression as
a whole considering the user ID settings. Also
the transaction settings for those user IDs.
• Maintaining the results in scorecard with log IDs
for each location the scripts being tested during
regression on Quality. This helps for future
reference of script results. Scorecard can be
something like as follows -
eCATT Weblog Links From SDN:

• eCATT An Introduction (Part I)
https://www.sdn.sap.com/irj/sdn/weblogs?
blog=/pub/wlg/3334
• eCATT Scripts Creation - TCD Mode (Part II)

blog=/pub/wlg/3418
• eCATT Scripts Creation - SAPGUI Mode (Part II)

blog=/pub/wlg/3464
• eCATT Chaining, Parameterization, Creation Of

Test Data, Test Configuration, System Data (Part
IV)
blog=/pub/wlg/3497
• eCATT Scripts Management Via Test Workbench

(Part V)
blog=/pub/wlg/3483
• eCATT Logs (Part VI)

blog=/pub/wlg/3489
• eCATT Scripts Creation Non User Interface Mode

& Rename, Copy, Delete, Upload & Download
eCATT Objects:
blog=/pub/wlg/3519
• eCATT - Creating A Test Case For WebDynpro:

blog=/pub/wlg/3154
eCATT Links From SAP Help:

• Online SAP Help For eCATT:
http://help.sap.com/saphelp_nw04/helpdata/en/2
0/e81c3b84e65e7be10000000a11402f/frameset.
htm
• TCD Parameterization:
http://help.sap.com/saphelp_erp2004/helpdata/e
n/b5/c5f60a2b5bc74f8ca0eef40158806c/content
.htm
• TCD Command Interface:

n/82/fc193c66f5dc1ce10000000a11405a/frames
et.htm
• Setting Field Values Dynamically In TCD:

n/05/33384162316532e10000000a1550b0/fram
eset.htm
• SAPGUI Command Interface:

n/bc/6d7290f64c11489f2c9b03458ef53f/framese
t.htm
• Execution Start Options:

n/bc/6d7290f64c11489f2c9b03458ef53f/framese
t.htm
eCATT Links From SAP Service Marketplace:

For accessing site from SAP Service Marketplace,
user ID & Password is required.
• eCATT Details On Service Marketplace:
https://websmp204.sap-ag.de/~form/sapnet?
_FRAME=CONTAINER&_OBJECT=011000358700
003012112003E
• eCATT Frequently Asked Questions:

https://websmp104.sap-
ag.de/~sapidb/011000358700003021722003E#
availablesince
• eCATT Security Guide:

https://websmp204.sap-ag.de/~form/sapnet?
_FRAME=CONTAINER&_OBJECT=011000358700
003043282003E
Useful eCATT Links From SDN Forum:

• How To Find eCATT Version:
https://www.sdn.sap.com/irj/sdn/thread?
forumID=117&threadID=133916&messageID=1
501467
• eCATT Error - ‘Error In Control Details:
18406
• eCATT Error – ‘Control Data Obsolete’ Details:

341439
• Testing Custom Report Output Using eCATT:

314407
• eCATT - Problem With ME21/MIRO/MIGO:

250733
• eCATT Error – Screens Smaller When Replayed &

Caused Error:
172785
• eCATT - Executing Several Variants At Once:

136307
• eCATT – Creating Summary Report Based On
Logs:
250664
• eCATT Error -GUI Recording Not Working With

VA01 (RE) Return:
160394
• eCATT – Which Dynpro Of Recording

Corresponds To Which Screen Of Transaction:
145386
• eCATT – Running eCATT Scripts In Batch:

120564
• eCATT – SAP’s Best Practice For eCATT:

89737
• eCATT – Updating Automatic Execution Result In

Solution Manager:
18452
• eCATT – Testing eCATT Scripts In Multiple

System:
114139
• eCATT – Meaning Of Transactions Containing

Controls (SAPGUI):
14172
• eCATT – Workflow Testing By eCATT:

09375
• eCATT – SAPGUI Mode – Making Screen Optional:
09306
• eCATT – Parameterize The Input Date As System

Date:
109073
• eCATT – Impact Of Solution Manager Version
Upgrade On eCATT:
1963
• eCATT Error - Problem In Recording ME5J/ME53N:
2111
• eCATT – Security Testing Via eCATT:

24748
• eCATT Error: Problems Due To Changed

Configuration & Master Data:
95800
• New To eCATT:
6225
• eCATT – Uploading Data From Excel:

6488
• eCATT – SAPGUI Recording Queries:

7802
• eCATT Error – Testing Webdynpro Logon Error:

367122
• eCATT – TCD Mode – Dynamically Assigning

Parameter Value –
454221
• eCATT - Difference Between CATT & eCATT:

131919
• eCATT - RFC Functions In eCATT:

404040
• eCATT Error – eCATT Not Supported In SAPGUI

For JAVA:
411441
• eCATT – Log Export RFC Function Module:

https://www.sdn.sap.com/irj/sdn/thread?forumID

Create eCATT Scripts in SAP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Create eCATT Scripts in SAP

Uploaded by

Copyright:

Available Formats

To create an SECATT you must first create the Test

Click the green check mark

Now double-click on the Interface. In this case the

Using the split screen you must now navigate

located the Role Name on the first screen by double-

Give the Test Configuration a Name and Component

Enter the name of the test script you would like to

Click on the Yes icon and you should see the

What Are The Various Ways Of Doing Testing?

Why To Use eCATT?

Before creating Test Scripts using eCATT, some

• Enabling Scripting at the front End. (Check

• Enabling Scripting on application server.

• The R/3 users executing eCATT scripts should

Features Available In eCATT:

• Test remote systems.

Ways Of Doing Testing In eCATT:

Suitable for testing backend R/3 specific modules like

Suitable for testing transactions (especially who

Suitable for testing transactions, who involve activex

External products, which are certified against BC-

Transaction For Using eCATT:

Editors Available In eCATT From SECATT

Used to maintain Test Configuration object. Test

Used to create & maintain Test Scripts. There are

• Test Data Editor:

Used to create & maintain the Test Data Containers.

• System Data Editor:

The Part I of eCATT Introduction gives the basic

Steps Involved In Creation Of eCATT Test

(transactions) involving a business scenario.

How To Identify Any Transaction For TCD

Windows or SAP GUI for Java, it can be recorded

Key Features Of TCD Recording Mode:

activex controls, so it doesn’t require any GUI

• Give the name of the Test Script (TS) in Test

• In the Interface field, a system-generated name

Execution of Recorded TCD script:

• Transaction will start executing, which appears

The Part I of eCATT Introduction gives the basic

Steps Involved In Creation Of eCATT Test

(transactions) involving a business scenario.

How To Identify Any Transaction For SAPGUI

Windows or SAP GUI for Java, it can be recorded

controls, so it requires GUI playback mode.

Steps For Recording Using SAPGUI Mode:

• Give the name of the test script (TS) in Test

• Login in to Target System from SAP Logon or

• One window with title ‘Recording Running’ will

• Recording can be started with the transaction

Execution of Recorded SAPGUI script:

and the details of recording are taken back to

The Part I of eCATT Introduction gives the basic

What Are Parameters:

variables of a script. Parameter name can be 30

• ONLY local variables can be used in the inline

Why Parameterization Is Needed:

can be checked without parameterization for

TCD Mode Parameterization:

 Fields having mode ‘S’ (Set) under each dynpro of

• One Maintain field entry window appears for the

This way one can parameterize all the import

assigned to export parameters. Export