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.
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.
- Defining Import Parameters:
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.
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.
SAPGUI Mode Parameterization:
- Defining Import Parameters:
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.
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.
- 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.
The REF command will be inserted into the test script editor.
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.
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.
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.
- 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.
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.
- 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 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.
- Variants from Test Data Containers: