2/22/26, 6:05 AM

eCATT: Extended Computer Aided Test

| 2025 FPS00

Public

Original content: [Link]

Warning

This document has been generated from SAP Help Portal and is an incomplete version of the official SAP product documentation.
The information included in custom documentation may not reflect the arrangement of topics in SAP Help Portal, and may be
missing important aspects and/or correlations to other topics. For this reason, it is not for production use.

For more information, please visit [Link]

This is custom documentation. For more information, please visit SAP Help Portal. 1
 2/22/26, 6:05 AM

eCATT Tutorial

Use
This tutorial is intended for test developers new to eCATT. By the end, you should be able to use eCATT to create reusable test
cases for testing remote systems.

Prerequisites
You need a system based on SAP Web Application Server 6.40 or higher.

Scripting has been enabled. See Preparing Systems and Computers for eCATT.

Background

When you design an automated test, you need to answer the following questions:

1. What applications am I going to test?

2. What does my system landscape look like?

3. How can I best create an automated test for my applications?

4. What data do I need to feed into the tests?

5. How do I build executable test cases?

6. How can I organize my test cases?

The graphic below shows how the different eCATT objects fit into the test development process.

This is custom documentation. For more information, please visit SAP Help Portal. 2
 2/22/26, 6:05 AM

The first step is to define what you want to test within the scope of your project. Having done this, you create a system data
container in which you map out the system landscape for the project. Without a system data container, you cannot write test
scripts that access other systems. The third step is to create the test scripts themselves.

You then need to consider the data that you will need to run the tests. The data should be arranged in test data containers to allow
the maximum degree of reuse and to eliminate as much redundancy as possible. Finally, you assemble the test configurations
from the other eCATT objects.

Test configurations can be assigned to test catalogs and test plans within the Test Workbench. The configurations can then be
assigned to individual users for testing. The Test Workbench is not part of this tutorial.

Creating Your System Data Container

Use

In most practical test environments, eCATT resides on a central test system and runs tests against remote systems in the test
landscape.

This is custom documentation. For more information, please visit SAP Help Portal. 3
 2/22/26, 6:05 AM

To access these remote systems, eCATT uses standard RFC destinations. However, these RFC destinations are never referenced
directly within a test script - that would minimize the reusability of the test script. Instead, the RFC destinations are assigned to
logical names in a system data container, and it is these logical names that are used in the test script.

Your Test Landscape

For this tutorial, your system landscape consists of a system containing the transaction EC_TUTORIAL_SAPGUI. If you do not
have access to a second system containing this transaction, simply use an RFC destination in the eCATT system that points to the
eCATT system itself.

This is custom documentation. For more information, please visit SAP Help Portal. 4
 2/22/26, 6:05 AM

Prerequisites

In the eCATT system, you require an RFC destination for the system under test. Here we will call the RFC destination TUTORIAL.
This should be an type 3 connection. You can use transaction SM59 to maintain RFC destinations. Make sure that you can log on to
the system using the RFC destination.

Procedure

1. Start transaction SECATT.

2. On the eCATT initial screen, select the System Data radio button and enter a name for your new system data container in
the field beside it. For this tutorial, we will refer to it as TUTORIAL_SDC. You may have to prefix the name (for example, with
Z) if you are in a customer namespace.

This is custom documentation. For more information, please visit SAP Help Portal. 5
 2/22/26, 6:05 AM

3. Choose the Create Object icon as shown above. This will open the editor for the system data container.

4. On the Attributes tab, enter a title for the system data container - for example, System Landscape for eCATT
Tutorial.

5. Change to the System Data tab. You will see a default target system called NONE. However, you are not going to use it in this
tutorial.

6. Append a row for your new target system.

7. Enter a name for the target system (here we use TARGET_1), and use the F4 help to enter the RFC destination TUTORIAL.

This is custom documentation. For more information, please visit SAP Help Portal. 6
 2/22/26, 6:05 AM
8. Choose Enter. The Instance Description field will be filled automatically.

9. Save your system data container.

Result
You have created your system data container. It does not do anything by itself - you will use it later to enable your tests to run
against the remote system defined in the RFC destination.

Creating Your Test Script

Use

In this section, you will create an empty test script and assign to it the system data container that you created earlier. You will then
execute the test script.

Activities
1. On the eCATT initial screen, select the Test Script radio button and enter a name for your new test script in the field beside
it. Here, we will name it TUTORIAL_TS. Leave the remaining fields empty.

2. Choose the Create Object icon, as shown above, to open the editor for the test script.

3. On the Attributes tab, enter the following information:

Field Entry

Title Testing Transaction EC_TUTORIAL_SAPGUI

Component BC-TWB-TST-ECA

System Data Container TUTORIAL_SDC

This is custom documentation. For more information, please visit SAP Help Portal. 7
 2/22/26, 6:05 AM

4. Leave the Target System field empty. We will not use this field in this tutorial.

5. Save your test script.

You are now able to execute the test script. Of course, since you have not recorded any transactions or entered any script
commands, you cannot expect to see much happening. However, it is worth doing to see a successful execution before the
script becomes more complicated.

6. Choose .

The Start Options are displayed.

7. Accept the defaults but make sure that Log Display has been selected.

8. Choose to execute the test script. The log will then be displayed and should look something like the following:

The green icon beside the test script name indicates that the entire test script has been executed without error.

9. Go back to the test script editor.

Result
You have a test script that you can edit to perform useful testing. The test script was executed in the local system, so the system
data container, though present, was not actually used. However, it the next part of the tutorial, you will record a transaction that is
in a remote system. For that, the system data container will be necessary.

Recording the Transaction

Use

You will record the transaction EC_TUTORIAL_SAPGUI. This transaction has been written to include the active use of controls,
such as the tree control, and is therefore not suitable for recording using the TCD command. The SAPGUI command is designed
for just such a transaction. For simplicity, you will record the complete transaction although this is not a restriction of the SAPGUI
command.

Normally, we recommend that you try out a transaction before recording it. You would then be able to assess which command is
the best to use. Additionally, you would also reduce the number of false entries and thereby reduce the complexity of the resulting
script. Here, just go ahead and record the transaction. If you make too many errors, simply delete all the resulting commands and
try again (of course, eCATT offers more sophisticated ways of reworking a test script).

When you start the recording process, eCATT automatically opens a new session. You will therefore have two sessions open - the
original eCATT session, which provides you with various functions to use during recording, and the session containing the
transaction that you will record.

The Transaction

The transaction is based on the flight data model. You use the transaction to create a booking. The generated booking number is
displayed in a message and also in a field of an ALV grid.

Preparation

Make sure that scripting is enabled on the front end and that the profile parameter sapgui/user_scripting is set to TRUE in
both systems. In many systems, the default is FALSE and automatically reverts to this value when the system is restarted.

Close all sessions except for the one with the eCATT test script editor. This is not for technical reasons - you will be switching back
and forward between the two sessions and it is easy to get confused if you have more sessions open.

Procedure
Starting the Recorder

1. In the test script editor, choose the Pattern function to display the Insert Statement dialog.

2. In the dialog, change the group to UI Control, choose SAPGUI (Record) for the command, accept the interface name, and
select the target system TARGET_1.

This is custom documentation. For more information, please visit SAP Help Portal. 9
 2/22/26, 6:05 AM
The target systems that you can choose from are the same ones that are in the system data container that is referenced in
the attributes of the test script.

3. In the following dialog, specify the transaction ( EC_TUTORIAL_SAPGUI) that you want to record. Additionally, select the
check box that will automatically generate a new SAPGUI command after every screen change (to do this, you must first
deselect manual generation).

By selecting After Every Screen Change, you have chosen a particular recording granularity. However, granularity does not
directly affect how much information is recorded. At one extreme, all the information can be recorded into one command
with a large command interface, and at the other extreme, you can have multiple SAPGUI commands, each with a small
command interface. In practice, the selection of the granularity at this stage is usually not critical because you can change
it in the script later.

4. Choose Start Recording or Enter.

5. A new session is automatically created. You can, and should, switch back and forward between the two sessions using the
taskbar as shown below. Try it now.

6. In the Record SAPGUI Command dialog, confirm that you want to record the new session.

7. In the session containing the test script, you will see a control panel similar to the following screenshot. Leave the settings
as they are for the moment.

This is custom documentation. For more information, please visit SAP Help Portal. 10
 2/22/26, 6:05 AM

In the second session, you see the transaction to be recorded.

The Transaction

1. Expand the Flights tree and choose New Booking from the context menu of a flight date.

2. On the Cust. Details tab, use the F4 help to enter a customer number.

This is custom documentation. For more information, please visit SAP Help Portal. 11
 2/22/26, 6:05 AM

3. Change to the Passengers tab. You will see some information already entered that you will overwrite for this exercise.

Enter the following information.

Field Value

Class First class

Name Smith

Form of adress Mr

Date of Birth 10.10.1972

 Note

This is custom documentation. For more information, please visit SAP Help Portal. 12
 2/22/26, 6:05 AM
During recording, it is important to change the data in fields that you want to set parameters for later in the test script.

Choose Save.

4. Confirm the booking.

5. The message Flight was booked successfully. Booking number <number> appears.

That is the end of the transaction.

Ending the Recording

1. Using the task bar, change to the session containing the test script.

2. Select the Close Recorded GUIs check box and then choose End Recording.

The recorded session closes and you now see the SAPGUI commands in the command editor of the test script editor.
Above the command editor is the parameter list. You can use the button at the top left of this section to toggle between the
display of normal parameters and the command interfaces.

This is custom documentation. For more information, please visit SAP Help Portal. 13
 2/22/26, 6:05 AM

3. Choose Save.

Result

You have recorded a transaction in a remote system.

You have created a test script in the central test system, which can be executed repeatedly using exactly the same values that you
entered during recording.

Executing Your Test Script

Use

When you are developing test scripts, you often want to run them by themselves. You can do this from the eCATT initial screen or
from the test script editor. In practice, your test scripts are usually executed as part of a test configuration - you will do this later in
the tutorial.

When you start execution, you are presented with the start options. You can specify display options, how eCATT reacts to errors,
override default values, and so on. Some options are specific to particular commands - for example, the TCD and SAPGUI
commands. These are grouped on the UI Control tab. You can even specify a different system data container. So long as the names
of the target systems are the same as those use in the test script, you can test a different system landscape.

Procedure

1. In the test script editor, choose .

The start options appear.

2. Change to the UI Control tab.

3. Select the Highlight All Called GUI Elements checkbox. This option is cosmetic but will help you see which elements are
being selected during replay. Leave the other default options as they are.

This is custom documentation. For more information, please visit SAP Help Portal. 14
 2/22/26, 6:05 AM

4. Choose .

The test script executes and the log is displayed.

5. Check the log.

Find the booking number (you can use Edit Find and search for Booking number).

Compare it to the number that you generated earlier. This is a new booking.

Handling Messages

Use
Up to now, we have treated messages passively - if they arrive, they are recorded in the log. However, eCATT offers better ways for
processing messages. The main way is to use the MESSAGE...ENDMESSAGE block.

The simplest function of the MESSAGE...ENDMESSAGE block is to collect all messages that occur from commands enclosed
between the MESSAGE and ENDMESSAGE commands. The MESSAGE command also allows you to specify how eCATT reacts to
particular categories of messages or even to specific messages.

When you recorded the transaction EC_TUTORIAL_SAPGUI and made a successful booking, the system delivered a success
message. Each time that you execute that test script, you want to know that that particular success message occurs. Therefore,
you define a rule, in the command interface of the MESSAGE command, which will cause the script to fail if the message does not
occur.

This is custom documentation. For more information, please visit SAP Help Portal. 15
 2/22/26, 6:05 AM
In the first part of this exercise, you will create a MESSAGE...ENDMESSAGE block that encloses no commands. Using the start
options, you will cause the execution to terminate when the required message does not appear. In the second part of the exercise,
you will position the ENDMESSAGE command so that the block contains the SAPGUI commands that you recorded earlier.
Assuming the transaction replays correctly, the required message will appear and the test script will pass. Finally, you will write a
few lines of code to extract the variable part of the message so that it is available for possible further use.

Procedure

1. In the command editor, double-click the command interface of the SAPGUI command that contains the message text
Flight was booked successfully. If you were careful during the recording, that will be the last SAPGUI command
in your script.

The screenshot above shows the command interface displayed in the easy mode . Beside the Message node are the
message type ( S), message ID ( ECDEMO), and the message number ( 024). The variable part of this message is recorded
beside the Parameter 1 node. You cannot parameterize the message parts of a SAPGUI command interface.

2. Add a few empty lines in the command editor before the SAPGUI commands. Place the cursor before the existing
commands.

3. Use the Pattern function to insert the MESSAGE...ENDMESSAGE block. Accept the default interface name as shown.

This is custom documentation. For more information, please visit SAP Help Portal. 16
 2/22/26, 6:05 AM

4. Double click the command interface ( MSG_1) of the MESSAGE command. The command interface is displayed in the
structure editor to the right of the command editor.

5. Choose and enter the following:

Field Input

MODE R

MSGTYP S

MSGID ECDEMO

MSGNR 024

You have defined a rule that requires a particular message to occur.

6. In the start options, change the error behavior to terminate when an error occurs.

7. Execute the script.

The log shows that the required message did not appear.

This is custom documentation. For more information, please visit SAP Help Portal. 17
 2/22/26, 6:05 AM

8. Go back to the test script and cut and paste the ENDMESSAGE command so that it is after the SAPGUI commands.

9. Execute this test script. This time the log should show only green traffic lights.

As you can see, the required message has occurred. Depending on what you recorded, you may get other messages. As we
have not specified any rules to deal with them, they will be handled by default rules.

10. Go back to the test script editor and add the following lines to the end of the script:

V_MESSAGES = E_MSG_1[1]-MIDX.

E_BOOKINGNUMBER = E_MSG_1[V_MESSAGES]-MSGV1.

LOG ( E_BOOKINGNUMBER ).

The field MIDX of the first row of the ENDMESSAGE command interface always contains the number of messages captured
in the ENDMESSAGE command. Here, you assign that value to a parameter V_MESSAGES. (Instead of E_MSG_1[1]-MIDX,
which was required in previous releases, you can use the special parameter &TFILL).

The second statement assigns the first variable part of the last message to the parameter E_BOOKINGNUMBER. For the
sake of simplicity, we make the assumption that the message is always the last one. More generally, you could loop through
the command interface to find the message that you are interested.

This is custom documentation. For more information, please visit SAP Help Portal. 18
 2/22/26, 6:05 AM
The third statement is just a convenient command to simply show the extracted value being used.

11. In the parameter list, create the export parameter E_BOOKINGNUMBER and the local variable V_MESSAGES. You can use
to toggle between display of parameters and command interfaces in the parameter list.

12. Save and execute the test script.

Result

You have captured a message and read the value from its variable part.

Making Your Script Ready for Data Input

Use
When you define import or export parameters in a test script, the test script is no longer restricted to being a standalone test but
can be used as part of a more complex test. The main uses for import parameters are:

Receiving data from other test scripts. You can reference one script in another.

Receiving data from test configurations.

In the tutorial so far, every time you made a new booking you used the same passenger details. By changing the fixed values
recorded in the test script to import parameters, you enable the test script to use a different set of data for each test run.

Procedure
This is custom documentation. For more information, please visit SAP Help Portal. 19
 2/22/26, 6:05 AM
1. In the test script editor, use the search function to find the name Smith that you record earlier. The search result
indicates which command interface to parameterize.

2. Open the command interface in the structure editor and expand tree as shown below.

3. Double-click the ' Smith' node so that the value appears for editing on the right.

4. Change the value to I_NAME (without inverted commas because it is a parameter name).

5. Choose Enter.

6. In the Parameter Maintenance dialog, select Import and choose Yes.

This is custom documentation. For more information, please visit SAP Help Portal. 20
 2/22/26, 6:05 AM

7. In a similar manner, replace ' Mr' with I_TITLE, and ' 10.10.1970' with I_DOB.

The parameters are automatically entered in the parameter list with the default values that you recorded earlier. The values
are without inverted commas, which is different to the treatment of fixed values in the structure editor.

Result

You have created import parameters and assigned them default values. Each time the script is executed, the defaults will be used
unless other values are supplied.

Creating Reusable Test Data Sets

Definition

You can to a limited extent enter data values directly into test script and, as you will see later, in test configurations. However, that
is not the sensible way to handle your data in most cases. With real-world testing, much of the data is identical in many different
test cases. For example, currency conversion values. What is more, when these values need to be changed, you would like to be
able to change them in one place and affect all the test cases. In eCATT, you achieve this by storing your data in test data
containers, and then referencing the test data from within test configurations.

Test data containers consist of parameters and variants. The parameters describe the interface of the container and the variants
store the data. You define the parameters in the same way that you define the parameters in a test script with the difference that
there is no Visibility field - that is, defining the parameters as import or export makes no sense here.

Procedure

1. On the eCATT initial screen, create a test data container TUTORIAL_TDC.

2. On the Attributes tab, choose the General Data tab and enter the following information:

This is custom documentation. For more information, please visit SAP Help Portal. 21
 2/22/26, 6:05 AM

Field Entry

Title Test Data for eCATT Tutorial

Component BC-TWB-TST-ECA

3. On the Parameters tab, create the parameters I_NAME, I_TITLE, I_DOB. Accept the default types.

4. We have chosen to use the same names as we used in the test script. This make it easier for us to remember how they are
intended to be used. You will see later that it can make the assignment of data in test configurations easier. However,
parameters need not have the same name as the parameters in the test script to which the values will be assigned.

5. Change to the Variants tab and create the following variants:

Variant I_NAME I_TITLE I_DOB

VARIANT_1 Jones Mr 12.10.1961

VARIANT_2 Harris Mrs 13.10.1965

VARIANT_3 Singh Miss 14.10.1973

6. Save your test data container.

Result

You have created a test data container with several sets of data.

You created the parameters manually in order to emphasize that they are independent of any test script. However, you could have
created the parameters by importing them from your test script (or any other script or data container with suitable parameters).
Also, if the variants had been stored in External Variants, you could have imported them, rather than entering the data manually.

Assembling Your Test Configuration

Definition

Although you have executed a test script directly, the normal test case is represented by a test configuration. The test
configuration references other eCATT objects to combine them into a test case. At the core of the test configuration is the test
script. The importing parameters of the test configuration are those of the test script.

This is custom documentation. For more information, please visit SAP Help Portal. 22
 2/22/26, 6:05 AM

Normally a system data container is referenced, which overrides the system data container in the test script. Optionally one or
more test data containers are referenced and, to these test data containers, you make links from the variants in the test
configuration.

Procedure

1. With your test script open in the test script editor, choose Utilities Test Configuration Create Test Configuration .
This is the quick way to create a test configuration.

2. In the dialog box, save the test configuration.

3. You are now in the test configuration editor.

4. Choose the Configuration tab. You see your test script and the system data container are already referenced.

5. Choose the Variants tab. You will see a default variant with parameters and data from the referenced test script.

This is custom documentation. For more information, please visit SAP Help Portal. 23
 2/22/26, 6:05 AM

6. Create a new variant and enter the following data:

Variant I_DOB I_TITLE I_NAME

VARIANT_1 10.10.1971 Mr. Smith

The problem with this manual method is that the values are part of the test configuration. As mention above, the preferred
method is to reference data in test data containers.

7. On the Configuration tab, enter the name of your test data container TUTORIAL_TDC and give it an alias TD1.

8. On the Variants tab, choose the .

9. You see two panes. On the left pane are the variants in the test data container, and on the right pane are the variants in the
test configuration.

10. Select the three variants that you want to add to the test configuration and choose Attach as Variant(s).

11. The new variants appear in the right pane.

12. Choose , then save your test configuration.

This is custom documentation. For more information, please visit SAP Help Portal. 24
 2/22/26, 6:05 AM

Observe how the test data from test data container is referenced not by the name of the test data container but by the alias
that you entered earlier.

13. Now execute your test configuration. In the start options you will see there is a Variants tab where you can select variants
to be executed, override default data, and so. Do not make any changes just now.

Result

The test script is executed once for each set of data.

Use

Improving the SAPGUI Recording

Use

This is custom documentation. For more information, please visit SAP Help Portal. 25
 2/22/26, 6:05 AM
You have recorded a transaction but now you decide that the recording is not exactly what you want. You could simply delete the
recorded commands and start again. However, you may have invested considerable effort in recording and parameterizing the
transaction and you do not want to lose what you have already done.

What you can do is use the SAPGUI (Attach) option. You execute the test script until it reaches the part where you want to add the
new commands. There are several ways to make the execution stop at the relevant part (for example, using breakpoints), but for
this exercise, we will use a simple method that is easier to demonstrate.

For this exercise, you will read the value of a screen field, of the Customer Details section, into a parameter. During the original
recording, you did not try to record the initial value of the field, nor did you use the GETGUI command. Now you want to enter a
GETGUI command in the middle of the transaction.

Procedure

1. Open the test script TUTORIAL_TS in the test script editor.

Comment out the commands after the place where you want to enter the new command.

If you have used too coarse a granularity and the desired place is part way through a command, you can split the command
first.

2. Choose .

3. In the start options for the SAPGUI command, select Do Not Close Created Sessions.

4. Choose .

The transaction replays to the end of the script then stops. Both the eCATT session and the session where the replay took
place remain open.

5. In the eCATT session, go back to the test script editor and place the cursor where the new command is to go - that is, after
the last uncommented SAPGUI command.

6. Use the Pattern function to create the SAPGUI (Attach) command.

7. Select the recording granularity. As you are only going to enter a single GETGUI command, the granularity is not important.

8. In the Select Sessions dialog, select the session to be recorded - there should only be one displayed.

9. Choose Enter.

The Recording Running dialog box appears.

10. Choose Insert GETGUI Command.

11. Go to the other session and click on the field that you want to get the value of.

The Selection of Properties and Methods to be Recorded dialog opens.

12. Expand the Get node until the value from the field is visible.

13. Select the Text checkbox.

This is custom documentation. For more information, please visit SAP Help Portal. 27
 2/22/26, 6:05 AM

14. Choose Insert and Exit.

15. In the Recording Running dialog box, select Close Recorded GUIs and then choose End Recording.

16. Open the command interface of the GETGUI command and double-click the Text node to display the Value node for editing.

17. In the value field enter the parameter name V_CUSTOMER and create it as a local variable.

This is custom documentation. For more information, please visit SAP Help Portal. 28
 2/22/26, 6:05 AM

18. In the command editor, enter LOG ( V_CUSTOMER ). This is just to demonstrate that the value read from the field is
available for other commands to use. Uncomment all the commands.

19. Execute the test script.

20. Expand the log to view the GETGUI node.

Result
You have taken an existing recording and added a new command to it. You used a GETGUI command to read the value of a field into
a parameter.

This is custom documentation. For more information, please visit SAP Help Portal. 29
 2/22/26, 6:05 AM

Testing a Transaction Suitable for TCD (Record)

Use
You can use the SAPGUI command to test the same transactions that the TCD command can test. So why learn to use a second
command? For those transactions that TCD can test, it is much more efficient to use TCD than SAPGUI (perhaps fifty times faster),
which can make a considerable difference to the execution time, especially when the transaction is called repeatedly.

Procedure
Create a new test script using the following information:

Field Entry

Title Testing Transaction EC_TUTORIAL_TCD

Component BC-TWB-TST-ECA

System Data Container TUTORIAL_SDC

Recording the Transaction

1. Using the Pattern function, choose UI Control, TCD (Record). Choose the target system TARGET_1. Enter the transaction
code EC_TUTORIAL_TCD and accept the automatically generated interface name.

2. Choose icon to start the transaction.

3. Use the F4 help to enter an airline and a flight number then choose Displ. Flights.

This is custom documentation. For more information, please visit SAP Help Portal. 30
 2/22/26, 6:05 AM

4. Select a flight and choose Create Booking.

5. Use the F4 help to choose a customer number.

6. Change to the Passengers tab and enter a name, title, and date of birth for the passenger.

7. Choose Save.

This is custom documentation. For more information, please visit SAP Help Portal. 31
 2/22/26, 6:05 AM
The success message appears with the booking number.

8. Leave the transaction by choosing Exit. The following popup appears.

9. Choose Yes, then save your script.

Look at the command interface of the TCD command.

Here, you can see the screens of the transaction listed under the DYNPRO node.

Executing the Transaction

Execute the test script. Choose the option Process in background in the TCD start options. Notice how much faster it executes
than the similar transaction that you recorded earlier with SAPGUI command. Execute the test script again. This time, choose
Process in Foreground. With this option, you can see interact with the transaction during execution.

Parameterizing the Command Interface

1. In the structure editor, expand the command interface to show the fields of the first screen.

2. Double-click the Fields node to display the fields for editing.

This is custom documentation. For more information, please visit SAP Help Portal. 32
 2/22/26, 6:05 AM

3. Replace the recorded values 'LH' and 0400 in the VALIN column with the parameter names I_AIRLINE and
I_FLIGHT_NUMBER respectively. In the dialog box that appears after you choose Enter, make the parameters input
parameters.

A field mode 'S' denotes that the field will be set with the value in the VALIN column.

4. In the structure editor, expand the node for the second screen.

5. Double-click the field node to display the fields for editing.

6. Change the mode of field [5] to 'G' (for get) and then enter the parameter name V_CITY_FROM in the VALIN column.
When you run the test script, the actual value will be read into the parameter and be available for use elsewhere in the
script.

This is custom documentation. For more information, please visit SAP Help Portal. 33
 2/22/26, 6:05 AM
7. Change the mode of field [6] to 'C' ( for check) and then enter the name V_AIRPORT_FROM in the VALIN column. When
you create the parameter make it a local variable and make sure the default value is FRA. When you execute the script, the
actual value will be checked against the value of the parameter. If the values are different, the script will fail. You can try this
later either by changing the value of the parameter or by entering an airline that does not fly from the airport.

8. In the command editor, enter LOG ( V_CITY_FROM ).

This is only to demonstrate that the value read from the TCD command interface is available in the parameter for use by
another command.

9. Save and execute the test script.

Summary

You have seen that you can use TCD to record a transaction, and replay it in background mode for fast execution.

You always use the VALIN column of the command interface to parameterize fields of the transaction. You need to make the field
mode 'S', 'G', or 'C', if you want the parameterization to have the effect of setting, getting, or checking a value.

This is custom documentation. For more information, please visit SAP Help Portal. 34