eCATT - An Introduction (PART I)

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

← Start transaction SM31, Maintain Table Views.

← In the Table/View field, enter T000.

← Choose Maintain.

← In the Change View Clients, Overview screen, select the relevant client and choose.
← 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.)

← On any screen, choose Customizing of local layout from the Standard Toolbar.

← Choose Options.

← Choose the Scripting tab.

← Select Enable Scripting.

← Choose Apply.

← Enabling Scripting on application server.

← Start transaction RZ11.

← On the Maintain Profile Parameters screen, enter sapgui/user_scripting.

← Choose Display.

← In the Display Profile Parameter Attributes screen, choose Change value from Application
Toolbar.
← 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.

eCATT Scripts Creation – TCD Mode (PART II)

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 –

← Error Behavior with value S No termination, continue with next script.

← System Data – Name of the system data container, which contains the Target System.

← Target System – Name of the server on which the execution will happen.

← Select the Log Display check box.

← In TCD section of window, select N – Process in background, synchronous local.

← 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.

 eCATT Scripts Creation - SAPGUI Mode (PART III)
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 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:

← 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 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:

← Error Behavior S No termination, continue with next script.

← System Data – Name of the system data container, which contains the Target System.

← Target System – Name of the server on which the execution will happen.

← Select the Log Display check box.

← 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

← Click on Execute button.

← Transaction will start executing, by creating a new session. This requires GUI for playback.

← 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.

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 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.

← 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’.

← 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.

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.

← 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 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 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.

← 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) 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.

← 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.
 eCATT Scripts Management Via Test Workbench
(PART V)
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, 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.

← Without Variants – Only with ECATTDEFAULT.

← All Variants Including Default Variant – All the variants including ECATTDEFAULT variant.

← All Variants Excluding Default Variant – All the variants excluding ECATTDEFAULT variant.
← 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.

← Click on menu Environment->Manage Test 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 application
toolbar.

← 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.

← Click on menu Environment->Manage Test Plans.

← Select the Test Plan, which needs to be executed.

← Click on Test Packages (Ctrl+F9) button from the application toolbar.

← 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 –

← Error Behavior - S No termination, continue with next script.

← System Data – Name of the system data container, which contains the Target System.

← Target System – Name of the server on which the execution will happen.

← Select the Log Display check box.

← Select the Status In TWB check box.

← In TCD section of window, select N – Process in background, synchronous local.

← 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

← Click on Execute button.

← 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.

eCATT Logs (PART VI)

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 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:

← Transaction SECATT.

← Click on Logs (Ctrl+F12) icon from the application toolbar.

← 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:

← The number of test configurations executed. (This information appears if the execution
happens from the test workbench via SCAT).

← The name of the test script or test configuration executed via SECATT.

← The version number of the test script.

← 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:

← 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.
← Messages: Messages during the execution are displayed in the log under messages node.
Messages can also be seen in XML data.

← Multiple Variants: Script can be executed using multiple variants. The variant names appear
one after the other in the log.

← 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:

← Transaction SECATT.

← Click on Logs (Ctrl+F12) icon from the application toolbar.

← 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 application toolbar.

← 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.
 eCATT Scripts Creation Non-User Interface Mode & Rename, Copy,
Delete, Upload, Download eCATT Objects(PART VII)
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 the Part III, the creation of eCATT
Scripts using SAPGUI mode is 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:

← 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 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 application toolbar.

← 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.

← 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.

← 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.

← After the confirmation of error free recording, one can go ahead with the preparation of TD, TC for the
TS.

← 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. (Weblog Part IV).

← 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. (Weblog Part IV).

← Finally the TC can be executed from SECATT directly by giving the required variant name at runtime.
(Weblog Part IV).

← The TC is used in managing the scripts in 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.

← Transaction SECATT.

← Click on Copy Object (Ctrl+F5) icon from the application toolbar.

← 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 application toolbar.

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.

← Transaction SECATT.

← 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.

← Transaction SECATT.

← 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.

eCATT Tips Of Recording, Testing & Links (PART VIII)

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 the Part III, the creation of eCATT
Scripts using SAPGUI mode is 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.

← 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.
← On the Expert tab, in the Controls section select the checkboxes of Show keys in all dropdown
lists & Sort items by keys.

← 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.

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 -

Hello Sapna,

I also think your article is a very good starting point for a beginner in the SAPGUI command, because it supplies a
step-by-step description through the SAPGUI command.

Let me nevertheless comment on three issues:

1. If the tester uses a system data container, I would recommend to use the "Pattern Dialog" instead of the "Start
Recording" button. The advantage of the start with the "Pattern Dialog" is, that you can supply the target system
name in this dialog and this target system is then started by the SAPGUI command.
2. Furthermore, if the tester uses a system data container, he should also check if the data on the dialog with the
question "Do you want to record this new session?" is correct and correct the data if necessary. The background
for this is that the data is coming from the GUI and is sometimes not correct (because the GUI sometimes does
not have all the necessary information about the backend). Incorrect data in this popup leads to the creation of a
new target system in the system data container together with the creation of a new RFC destination in transaction
SM59. Not only that this target system is not necessary, it's sometimes even wrong (because the data used for the
creation was wrong).
3. I wuold not recommend to use the option "Record with Inactive Checks" in the "InitialState" area, especially not
with all checkboxes switched on. The InitialState area is used for reading data from the screen and/or checking
these data. Most of the time you do not need this, because you do not want to read data from the screen. The
disadvantage of this option is that it creates a lot of data (e.g. if you switch it on for menues, the complete menu
is recorded for every screen). And this high amount of data makes your script much slower in the maintenance
(e.g. when opening the script or when opening the command interface) as well as in the execution (all the data
 has to be read and parsed during the execution). I would recommend that you only switch on this option before
you get to a screen where you really want to read or check data - and switch it off afterwards.

I hope you didn't mind me commenting on this. I didn't want to criticize, I just wanted to give you some hints how
you could improve this WebLog. If I had had your e-mail address, I would have sent the information directyl to
you.
←

1. Regarding Pattern button for SAPGUI recording mode, I didnt try but I found it really useful due to the input
option of Target system.

2. The System Data(SD) container usage & the information one recording confirmatin window, what I found is the
details coming from the SD are in display mode. There are quiet a few input enabled field. The values in some of
them is either system defaulted (e.g. Application server or system number) or blank. Are these fields you are
talking about to veirfy before recording.

If so then my query is they have system generated values, won't be they correct.

3. The details mentioned in your third point are covered in blog.

Only the switch on option during the recording for screen fields is not mentioned in this blog. As thi is not possible
due to SAPGUI 6.20. This feature is from SAPGUI 6.40. And the article is prepared by referring WAS6.20, SAPGUI
6.20, Solution Manager 3.20 & SAP R/3 Enterprize 4.7.