Preparing to Test the System Landscape

PDF download from SAP Help Portal:

http://help.sap.com/saphelp_erp2004/helpdata/en/d0/e3933f09a5fb47e10000000a114084/content.htm
Created on November 08, 2014

The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help Portal.

Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.

2014 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose
without the express permission of SAP SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP SE
and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by
SAP SE and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be
liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express
warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other
SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and other
countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.

Table of content

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 1 of 6

Table of content
1 Preparing to Test the System Landscape
1.1 Creating System Data Containers
1.1.1 System Data Editor
1.2 Specifying Target Systems
1.3 Using System Data Containers

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 2 of 6

!--a11y-->

Preparing to Test the System Landscape

Introduction
Several different systems might be involved in a business process that you want to test. Consider a simple scenario:
1. A purchase order is entered on the first system.
2. The order is passed to a second system where production is scheduled.
3. The second system passes information to a third system where a table is updated.
You want to test the transactions and check the table updates. eCATT enables you to create and manage the tests in a single system, and execute the
appropriate tests against the various target systems.
The systems under test usually change over the time. For example, you start by using eCATT to test a certain release of a system under test. Once you have
developed your tests, you may want to use them again to test later releases of the system under test. By using a central test system for your test tool and test
objects, and by testing the systems under test remotely, you can upgrade or even exchange the systems under test without modifying your test objects.
For the description of a (network-) path to a system under test, you use system data.

Central Test System

The central test system contains:

eCATT
Repository of eCATT objects (test script, test data containers, system data containers, and test configurations)
Logs
RFC destinations for the target systems

The applications under test reside on the target systems. The central test system can also be a target system. Communication with the target systems is by
normal RFC. Depending on the application, it may be an R/3 connection or an HTTP connection.

System Data Container

The system landscape under test is represented by a system data container.
The system data container contains a list of target systems. Each target system has attributes which describe the communication channel between the eCATT
system and the system under test. Possible attributes are RFC destinations of type 3 (destinations to SAP systems) and of type G (HTTP destinations).

As with other eCATT objects, the system data container has mandatory attributes (title, package, and person responsible) as well as attributes containing
administrative information.
In the system data container, each RFC destination is paired with a logical name that you specify. It is the logical name of a target system that you use in the test
scripts, and not the name of the RFC destination itself. The task of the system data container is to resolve the logical name used in the script into the RFC
destination (of type 3 or type G) that identifies a particular system. For more information, see Specifying Target Systems.

RFC Considerations
You define RFC destinations in transaction SM59. Here you can specify the user credentials required to log on to the relevant systems. If the logon information
specified in the RFC destination is incomplete, you usually need to enter the relevant information when a test tries to access the system. That means that tests
cannot be left to run unattended when using RFC destinations with incomplete logon information. To get round this problem, we recommend making the central test
system a trusted system of each of the systems in the test landscape. This eliminates the need to store a password in the RFC destination but allows unattended
logon. For information about how to set up a trusted and trusting relationships, see SAP Note 128447.
!--a11y-->

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 3 of 6

1.1 Creating System Data Containers

Procedure
1. On the Extended Computer Aided Test Tool: Initial Screen , select System Data and enter a name for the system data container.
2. Choose
.
The system data editor appears.
3. Choose the Attributes tab and maintain the attributes. The required fields are Title and Person Responsible .
4. Choose the System Data tab.
The target system NONE already exists.
5.
6.
7.
8.

For each target system that you want to create, choose

.
In the Test System field, enter a name for the target system.
In the RFC Destination field or HTTP Destination field , enter the name of an existing destination or one that you want to create.
Choose Enter .
The Instance Description field is filled automatically.
If the destination does not yet exist, a message is displayed in the status bar. You can choose Change destination (
to create the new destination.

9. Choose

) or double-click the destination name

!--a11y-->

1.1.1 System Data Editor

Use
You use the system data editor to create and maintain system data containers.
For an explanation of target systems, see Preparing to Test the System Landscape and Specifying Target Systems.

Downloading System Data Containers.

You can download a system data container as an XML file. Such files can be uploaded in the eCATT initial screen.

Modifying RFC or HTTP Destinations

You can spring to the maintenance screens of the RFC or HTTP destinations by selecting the destination and choosing
using the same destinations.

. Of course, this will impact anyone else

!--a11y-->

1.2 Specifying Target Systems

In a test script, the RFC destinations are not specified directly. You specify the RFC destinations in a system data container, where you assign them to target
systems. You create the names of the target systems yourself, and it is these names that you use in the test script.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 4 of 6

In a system data container, you could have:

Target System

RFC Destination

TARGET_A

RFC_1

TARGET_B

RFC_2

TARGET_C

RFC_3

In a test script, you could have:

TCD ( <transaction code>, <command interface> , TARGET_A ).
TCD (<transaction code>, <command interface> , TARGET_B )
CHETAB ( <table>, <command interface>, TARGET_C ).
WEBDYNPRO ( <command_interface>, TARGET_A ).
The advantage of this separation of test script and RFC destinations is that you can change the systems under test without having to change the test script. You
can simply assign a different system data container, containing a different set of RFC destinations, to the test script. You can do this in a test configuration, or in
the start options when executing the test..

Procedure
1.
2.
3.
4.

Create RFC destinations for the systems in the test landscape (use transaction SM59).
Create a system data container.
Create a test script and assign the system data container in the attributes of the test script.
Assign target systems to individual commands. You can do this in several ways but it is common to select the target system when entering the command
using the Pattern function in the test script editor.

!--a11y-->

1.3 Using System Data Containers

In Test Scripts and Test Data Containers
By specifying a system data container in the attributes of a test script, you can access remote systems at design time to record transactions or to access the
definitions of function modules, classes, methods and data types there.
It also allows you to specify a target system for a parameter reference in the parameter list. You can then retrieve metadata from the specified system at design
time. This information will be used at runtime without again contacting the remote system.

Maintenance System
A maintenance target system can be specified in the attributes of a test script or test data container. This system is accessed during script development, if no
other system is specified, for:

Recording of TCD, SAPGUI and WEBDYNPRO commands.

Creating FUN, SETTAB, GETTAB, CHETAB, BCSET, and CALLMETHOD and other ABAP Objects commands.
Execution of a test script started within the eCATT script development environment (if not overwritten by start options).
Checking the syntax of inline ABAP (when using Test Script Check Extended) .
Retrieving metadata for parameter references.

Referenced Test Scripts

Test scripts can be referenced from other test scripts as shown below.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 5 of 6

Even if each test script has its own system data container for maintainance, only the system data container of the topmost script is used when it is executed.
Therefore, a valid system data container has to provide an RFC destination for every logical target system of every script referenced (in the above example, for
R3, CRM, X, Y, A, B, FU and Hugo). It is permitted to contain more destinations than required for the scenario.

In Test Configurations
The system data container in the test configuration overrides the system data container of the referenced test script during execution.

Start Options
You can override the system data container and target system in the start options when executing a test script or test configuration. For execution of a:
Test script from the eCATT development environment, the default target is the maintenance target system.
Test configuration, the default is the target system of test configuration. The maintenance target system of the script is irrelevant.
Commands having a specific target stated at the command will be executed in that system. If the target system is not defined in the system data container or not
available physically, an error will result.
Commands without a specific target system will be executed as follows:
In the master script, the commands will be in the default target system.
In referenced scripts <script_ref> depending on the call itself:
REF ( <script_ref>, <interface>, <target>). in the system <target>.
REF ( <script_ref>, <interface>). in the default target system of the calling script.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 6 of 6