eCATT Chaining, Parameterization, Creation of Test Data, Test Configuration, System Data (PART IV)

  
Home / Community / Blogs + Actions
eCATT Chaining, Parameterization, Creation Of Test

Data,Test Configuration, System Data (PART IV)
April 18, 2006 | 2,004 Views |
Former Member
Retagging required
sapna modi
share 0 share tweet share
Follow RSS
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
Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
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.
1. 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.
2.
3. 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.
4.
5. 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.
6.
7. 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.
8.
9. System fields can also be used in command editor. They are read-only and are available
from SYST structure.
10.
11. 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.
12.
13.
The status of values, either fixed or parameterized or not define, are symbolized as follows –
Why Parameterization Is Needed:
1.
2. After recording of the transaction. Transaction can be checked without parameterization
for errorless recording. Once the successful recording is confirmed, automation can be
parameterized.
3.
4. 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.
5.
6. This is very similar to concept of Constants in Program (Without parameterization) and
using variables for those values (with parameterization).
7.
8. 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.
9. Hence parameterization is necessary.
TCD Mode Parameterization:
1. 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.
2.
1. 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.
2.
3.
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.
1.
2. Defining Import Parameters:
1.
2.
After step 3, the screen simulation window will appear. Select the field value & click on Insert
Import Parameter (F6) icon from the application toolbar.
1.
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.
1.
2. Defining Export Parameters:
1.
2. 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.
3.
4. 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.
5.
6.
Follow step 3. After step 3, the screen simulation window will appear. Select the field and click
on the Read field value (CtrlShiftF3) icon from the application toolbar.
1.
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.
1.
2. Defining Field Checks:
1.
2. 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.
3.
4. 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.
5.
6.
Click on the Check field (CtrlShiftF2) icon from the application toolbar.
1.
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:
1. Defining Import Parameters:
1.
2.
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.
1.
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.
1.
2. Defining Export Parameters:
1.
2. Export parameters are used to link transactions while chaining. i.e. Export parameter of
first transaction becomes the import parameter in chaining.
3.
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.
1.
Click on Pattern (CtrlF6)+ 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.
1.
2. 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.
1.
2.
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’.
1.
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.
1. Declare this export parameter in the parameter list. And it can be passed further in same
recording to subsequent screens as import parameter.
2.
Chaining Of Scripts:
1.
2. 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.
3.
4. 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.
5.
6. 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.
7.
8.
For creating chaining of the scripts, create a new script. Transaction SECATT. Click on Pattern
(CtrlF6)+ button from the application toolbar.
1.
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.
1.
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.
1. 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.
2.
Declare the variables and assign them to the export parameters.
1. 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.
2.
3. The export of one test script will be assigned as import of the next script using variables.
4.
The import parameter of chained script is assigned to the respective Importing node element.
1. 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.
2.
3.
Click on Save (CtrlS)+ 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):
1.
2. 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.
3.
4. 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.
1.
2. For SD creation, transaction SECATT.
3.
4.
In the System Data input field give the name of SD. Click on Create Object (F5) icon from the
application toolbar.
1.
On the create screen, in the Attribs tab, give the Title (mandatory) for the SD.
1.
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 (CtrlS)+ icon from the standard toolbar.
This way multiple target systems can be added to the system data.
Creation Of Test Data Container (TD):
1.
2. 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.
3.
4.
Transaction SECATT.
1.
2.
In the Test Data input field, give the name of the test data. Click on Create Object (F5) icon from
the application toolbar.
1.
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.
1.
2.
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 (CtrlS)+ button from the standard toolbar.
1. 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.
2.
1.
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 (CtrlS)+ button from the standard
toolbar.
Creation Of Test Configuration (TC):
1.
2. 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.
3.
4.
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.
1.
2.
For TC creation, transaction SECATT.
1.
2.
Give the name of TC in Test Configuration and click on Create Object (F5) icon from the
application toolbar.
1.
On the create screen, give the Title (Mandatory) & Component (Mandatory).
1.
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.
1. 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.
1.
2. 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 (CtrlS)+ button from the standard toolbar.
This way multiple variants can be directly added to Variants list.
1.
2. Variants from Test Data Containers:
1.
2.
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.
1.
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.
1.
2.
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:
1.
2.
Click on Save (CtrlS)+ icon from the standard toolbar. And Test Configuration is now ready to
execute or to link to TestWorkbench depending on the variant selected. </li>
</ul>
Alert Moderator
7 Comments
You must be Logged on to comment or reply to a post.
Former Member
April 19, 2006 at 1:02 am
Sincere and dedicated efforts!!! This article is very informative and useful. Even a layman can use this article to understand
eCATT. The flow of the information throughout the article is very nice. The author has taken lot of efforts to explain difficult
concept in a simple manner.
Thanks for such a nice article…Keep it up!!!
Regards,
Mangesh Vingkar
like (0)
Former Member
April 19, 2006 at 1:30 am
The document is very much informative,simple & understandable even for beginers in eCATT.
like (0)
Former Member
May 3, 2006 at 8:35 pm
This weblog is too good, all steps given very nicely.
like (0)
Former Member
June 1, 2007 at 5:17 am
The details in the documentation and the efforts in creating them are an example to high quality work.
They serve as exhaustive information to a beginner and a reliable reference to the experienced.
Examplary work.
Complements,
Gopidas
like (0)
Former Member
October 12, 2007 at 6:41 pm
With reference to “Passing Values To Subsequent Screen” as mentioned above, I do not find check nor do I find the
InitialState node in my ecatt version.
Can u please elaborate on this plz….
By making it blank at the check can we make a field optional even after it is parameterized???
Kindly reply back to the following queries I have too ..
1) Is there a way where in I can make a parameterized field optional?

Ex : Ship-to-party can be made optional. If I parameterize this field, I would then force a value to be sent into the field everytime.
Can a parameterized field be made optional??
2) Explicit mention of time (sec) in wait command often seems too long and fails utterly in the performance and speed (of execution)
of the script. Are there any alternate ways wherein I can wait without a mention of time ??
I find that using…. BAPI_TRANSACTION_COMMIT (IMP parameter WAIT = ‘X’) does not actually wait properly nor does COMMIT
WORK AND WAIT.
These methods fail whenever a select query is involved (retreival of data from database) as they actually do not wait till the DB is
updated. Any suggestions ??
3) I have a structure (LIPSD) which is not used in any of the DB tables. I have a requirement to fetch the Del.Qty and equate it to
Pick Qty (Vl02n)…. and later to do post goods issue.
As structures do not store data … only DB does … how do I select and update the corresponding fields for a given item of the sales
order.
In short, How does one select and update data into a structure (which is not used in any of the database tables of SAP) ???
4) I realize that ABAP code cannot be debugged in eCATT (SECATT) interface. Is this possible or have I overlooked ??
like (0)
Former Member
September 18, 2010 at 11:15 pm
Thank you very much for your kind help, it’s really helpful for me..
like (0)
Former Member
June 15, 2011 at 8:19 pm
Hi Sapna,
This note of thanks to you is long due as I’ve successfully completed a project on eCATT with the help of your Blog,
Your work is complete guide on eCATT and even a novice can work wonders with the help of this document.
Best Regards
Chandrasekhar
like (0)
Share & Follow
Privacy
Legal Disclosure Terms of Use
Trademark Copyright
Sitemap Cookie Preferences
Newsletter

eCATT Chaining, Parameterization, Creation of Test Data, Test Configuration, System Data (PART IV)

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

eCATT Chaining, Parameterization, Creation of Test Data, Test Configuration, System Data (PART IV)

Hochgeladen von

Copyright:

Verfügbare Formate

  

Home / Community / Blogs + Actions

eCATT Chaining, Parameterization, Creation Of Test

share 0 share tweet share

Why Parameterization Is Needed:

TCD Mode Parameterization:

2. Defining Import Parameters:

This way one can parameterize all the import values.

SAPGUI Mode Parameterization:

1. Defining Import Parameters:

This way multiple import parameters can be assigned & created.

Declare this export parameter in the parameter list.

Declare the variables and assign them to the export parameters.

Creation Of System Data Container (SD):

Creation Of Test Data Container (TD):

For TC creation, transaction SECATT.

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

April 19, 2006 at 1:02 am

Thanks for such a nice article…Keep it up!!!

April 19, 2006 at 1:30 am

May 3, 2006 at 8:35 pm

This weblog is too good, all steps given very nicely.

June 1, 2007 at 5:17 am

October 12, 2007 at 6:41 pm

Can u please elaborate on this plz….

Kindly reply back to the following queries I have too ..

1) Is there a way where in I can make a parameterized field optional?

September 18, 2010 at 11:15 pm

June 15, 2011 at 8:19 pm

Share & Follow

Legal Disclosure Terms of Use

Das könnte Ihnen auch gefallen