Several different systems might be involved in a business process that you want to test. Consider a simple scenario:
A purchase order is entered on the first system.
The order is passed to a second system where production is scheduled.
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:
Repository of eCATT objects (test script, test data containers, system data containers, and test configurations)
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 type 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 or H (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, G, or H) that identifies a particular system. For more information, see Specifying Target Systems.
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.