ECATT VSDK 3.0 Version 2003/2 19/3/2003.

eCATT VSDK 3.0 Version 2003/2 19/3/2003

Target Group and Prerequisites
Implementation and integration teams Quality managers supervising in-house development Prerequisites Experience of software testing An understanding of the architecture of the SAP Web Application Server (as provided in course SAPTEC)

In this course, you will learn
Course Goals In this course, you will learn What and when you need to test in the SAP Solution Lifecycle The advantages of eCATT for testing SAP systems compared with other automated test tools How to set up your system environment for testing with eCATT How to create test cases to test various different kinds of SAP applications How to create executable tests, and how these can be managed using the SAP Test Workbench How to migrate CATT objects to eCATT

Contents Unit 1 Unit 5 Getting Ready to Test Testing Transactions - I
Testing Transactions - II Unit 2 Getting Ready to Test with eCATT Unit 7 Testing Transactions - III Unit 3 eCATT Scripts and the Script Editor Unit 8 Building Executable Tests Unit 4 Non-UI Testing Unit 9 Advanced Topics

Unit 1: Getting Ready to Test

In this unit, you will learn:
Unit Objectives In this unit, you will learn: When you need to test in your SAP environment The advantages and disadvantages of manual and automated testing Decision criteria for selecting an automated test tool What can be tested using SAP eCATT

Addition and integration of new components In-house developments
Occasions for Testing New SAP installations Addition and integration of new components In-house developments Functional Tests Integration tests with other components Upgrades – regression testing Application of Legal Change Packages Sometimes we hear the question Why do you have to test off-the-peg software at all? Of course SAP tests its software, but the tested state of an SAP system is not the state in which it will be used productively by a customer. Customizing, Enhancements, Modifications, and in-house developments all ensure that each SAP installation is very probably unique – which means that it has to be tested on installation, on upgrade, and whenever new components are added to an existing landscape.

Manual or Automated Testing
Manual Testing Requires a group of testers who must Have lab space to work in Be trained Be released from their other duties (internal) or “bought-in” (external) Is time-consuming Offers little potential for reuse of test resources But does have the advantage that manual testers spot errors and issues that are beyond the scope of the test plan Automated Testing Requires fewer people and resources Execution takes less time Parameterization of fields allows replay with any number of different sets of values Offers considerable possibilities for reusing test scripts Makes it easier to reproduce errors that occur during testing There are two ways to perform functional testing on a system – manually or automatically. Manual testing has the advantage and disadvantage of using real people. Advantage because people have common sense, and can see beyond the boundaries of the test case that they are working on, but disadvantage because people make mistakes, especially if they are under pressure (the product is being rolled out next week) or bored (I'm re-testing this function for the 8th time). Automated testing offers a range of options for speeding up your test execution and making it more flexible and reliable. However, it will never be able to identify or foresee problems that lie outside the scope of the test case.

The Economics of Testing
Automated testing requires good planning and modeling Learning to use a new test tool takes time An automated test script will only give you maximum ROI if it is reusable A switch to automated testing requires investment and commitment Not every test scenario has to be automated If it doesn't have to be repeatable, it doesn't necessarily have to be automated Automation is a means to an end, not an end in itself. If it is taking too long to automate the last 5% of your test scenario, consider running that part manually! Automated testing is not a magic solution to your testing requirements. A good test automation project requires careful planning, commitment from the test team, and support from management. In the early stages of test automation, you will not see much in terms of concrete results. Much effort will be devoted to modeling the test cases and creating the relevant scripts. The real benefits of automated testing become apparent when you find that your carefully-crafted scripts are reusable in the future! The decision to switch to automated testing does not mean that you have to automated 100% of your test activities. Some applications will be automation-resistant for one reason or another.

Choosing an Automated Test Tool – External Tools
Classic automated test tools can test an SAP System by driving the SAP GUI... Automated Test Tool Script SAPGUI Window Frontend ... But treat the SAPGUI Window as a standalone desktop application: Generally not aware of the multiple tier solution No access to what is happening on the application server or the database Backend Various test tools currently on the market can support SAP testing by driving the SAP GUI. However, they often cannot provide total support for the full range of user interface controls that are used in later SAP GUI versions (particularly the controls that belong to the SAP Control Framework). Test tools that drive the SAP GUI are unaware that the SAP GUI is only one layer in a multiple-layer architecture. As such, they do not provide you with access to the application server or the database.

Choosing an Automated Test Tool – SAP CATT
CATT – Computer Aided Test Tool Available from Release 3.0 Advantages Shipped free with SAP Basis System Most effective testing method for SAP transactions Disadvantages Control technology not fully supported No support for tabular parameters of function modules Only limited support for distributed system environments Only limited support for external applications SAP has long had its own functional test tool – the Computer Aided Test Tool (CATT). CATT is part of the standard SAP Basis (SAP Web Application Server) installation and can be used at no extra cost. Using the SAP Batch Input Interface, CATT allows you to record and replay transactions running in the SAP GUI for Windows or Java. However, because of this technical background, it is unsuitable for testing transactions that were redesigned in the Enjoy SAP initiative (Release 4.6B and higher) and contain controls such as the SAP List Viewer, SAP Tree Control, and so on. Due to this and various other limitations, CATT is no longer a suitable tool for testing in a mySAP environment.

Choosing an Automated Test Tool - SAP eCATT
The Extended Computer Aided Test Tool (eCATT) is the successor to SAP‘s CATT. Its design aims were to Enable as many SAP transactions as possible to be tested automatically Provide a simplified concept for testing in a complex system landscape Allow reuse of test data by storing it in separate container objects Leverage the benefits of the existing CATT eCATT is available with Release 6.20 of the SAP Web Application Server With it, you can remotely test any mySAP.com solution that is running R/3 Basis Release 4.6C or higher (see note for details of required support packages) Given the limitations of CATT, SAP decided to develop a new tool, called the Extended Computer Aided Test Tool (eCATT). eCATT is contained in Release 6.20 of the SAP Web Application Server, and is therefore available as part of R/3 Enterprise and the SAP Solution Manager Release 2.2 and 3.1. eCATT allows you to test not only locally in your 6.20 system but also in remote systems with Release 4.6C or higher. Consequently, by installing a SAP Web Application Server 6.20 as part of your existing system landscape, you can use it to test your SAP systems that are running on SAP Basis releases 4.6C, 4.6D, and 6.10, as well as your 6.20-based systems.

What Applications Can Be Tested Using eCATT?
. . . Using Built-In eCATT Means Transactions in SAP GUI for Windows Transactions in SAP GUI for Java Function Modules and BAPIs . . . Using eCATT Together With a Certified External Tool Web-based Transactions In order to test different kinds of applications, eCATT provides a range of test drivers, each one suited to a particular kind of application. Function modules, BAPIs, and transactions running under SAP GUI for Windows and SAP GUI for Java can be tested using built-in eCATT drivers. External applications that run on the Windows Desktop or in a web browser can be tested using eCATT together with a certified external tool. Desktop-based transactions

What Does Testing an Application Mean?
Making the test reusable Setting checks on the application to make the test react to different circumstances Parameterizing the application to allow it to be replayed with varying values Recording the application so that it can be replayed The most basic test case involves simply recording an application so that it can be replayed. However, such a test case will only be of limited use, since it is restricted to replaying the application with the same data as you entered during the recording, and does not provide any analysis of the results. Having recorded an application, you need to be able to parameterize it, that is: Assign variable values to its input fields Retrieve values from its output fields and assign them to variables in the script You also need to be able to evaluate the results that the application returns by setting checks. These might be Simple checks where the value of an output field at runtime is compared against a check value Complex checks, where a value is incorporated in a larger plausibility check involving several field values and complex calculations The effort of automating a test case can only be justified if the test case is reusable. This should be one of your most important design considerations.

What Systems Can Be Tested Using eCATT?
You require at least one SAP Web Application Server 6.20 to operate as a test server From this central test system, you can test any other system that is running the component SAP_BASIS with Release 4.6 Support Package 32 or higher R/3 Web AS 6.20 eCATT CRM APO eCATT is designed to be used within a central test system. This system must be running on the SAP Web Application Server 6.20 and could, for example, be: An R/3 Enterprise System A SAP Solution Manager System (Release 2.2 or higher) A standalone SAP Web Application Server 6.20 All of the eCATT objects that you create are stored in this system. The eCATT runtime, which is necessary for test cases to run, is also located here. The actual applications that you want to test can be located in any other system in your system landscape that is Running software component SAP_BASIS with Release 4.6C or higher Accessible from the central test system by RFC

In this unit, you have learned
Unit Summary In this unit, you have learned Some of the issues you have to consider in deciding a test strategy The functional test tools that are available from SAP The scope of eCATT The applications that you can test with it The system landscape in which you can test

Unit 2: Getting Ready to Test With eCATT

Unit Objectives In this unit, you will learn: How a finished eCATT test case is put together The different object types used in eCATT How to set up a system for use with eCATT Some of the security aspects that you need to consider

Test Configuration Archive
A Finished Example Test Configuration Test Instructions System Landscape Description Data to drive the test Results Archive A finished test case – the test case that a user will see in their worklist in the SAP Test Workbench – consists of A set of instructions that describe the test case One or more sets of data with which the test case will be executed A description of the system landscape in which the test is to be performed. The result of each test run is a log. The log contains detailed information about the test environment (system – including technical platform information and release, user, time and date) and the commands that were executed during the test. You can also see the data that was fed into the test case, and the results that it returned. Logs can be either archived or deleted using periodic background jobs. On the next slide, you will see the different eCATT object types corresponding to the different elements of a test case.

The Different Object Types
Test Script The set of commands that forms the test System Data Container A list of systems that are addressed during the execution of a test script Test Data Container Reusable sets of data that can be used to run tests Test Configuration A test script, combined with data from one or more test data containers, plus a system data container that describes the correct system landscape A test script is the set of commands that describes a test. Typically, this will include a recording of one or more transactions with the associated checks and calculations required to evaluate the results. In order to address different systems, you need a description of the system landscape. This is contained in a system data container. Each entry in a system data container describes one target system. Unlike CATT, eCATT separates test instructions from test data. The test instructions are contained in a test script. Test data is stored in test data containers. By separating the test data from any particular test case in this way, it should be easier to reuse data in a variety of test cases. None of the objects test script, system data container, or test data container is executable from the Test Workbench. A complete automated test case requires a combination of one test script to provide the instructions, one system data container to describe the relevant system landscape, and one or more sets of data (variants) with which to execute the test. This combination is called a test configuration. The variants that are used may be entered manually or may be drawn from one or more test data containers.

Constructing an Automated Test Series
What applications am I going to test? What does my system landscape look like? How can I best create an automated test for my applications? What data do I need to drive the tests? How can I organize my test cases? Test data container System data container 1 2 3 4 5 Test Workbench The graphic shows how the different eCATT objects fit into the test development process. The first step is to define just what you want to test within the scope of your project. Having done this, you must 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. Once you have finished your test scripts, you need to consider the data that you will need to run the tests. These data need to be arranged in test data containers to allow the maximum degree of reuse and to eliminate as much redundancy as possible. Finally, when you have finished creating your components, you can move on to assemble the test configurations and assign them to test catalogs and test plans within the Test Workbench. The configurations can then be assigned to individual users for testing. Test script

Support Package Levels
Setting Up the System Support Package Levels Each system in which you want to test must have at least the following support package level 4.6C: Support Package 32 4.6D: Support Package 21 6.10: Support Package 17 Client Settings In each client in which you want to test, you must ensure that the CATT/eCATT flag is set to allow tests to run GUI Scripting In order to use the new GUI Scripting functions, the following settings have to be made: Profile parameter sapgui/user_scripting must be set to TRUE SAP GUI must be Version 6.20 with patch level =>18 and GUI Scripting installed Before you can start testing, you must prepare your various systems. Each of your target systems must have the appropriate support package level as shown above. In each client in which you want to test, you must ensure that eCATT is allowed. To do this, start transaction SCC4, pick the relevant client and ensure that the Restrictions when starting CATT and eCATT option is set to CATT and eCATT allowed. To use the SAPGUI command (see unit 6), you must ensure that GUI Scripting is active in the central test system and in any target systems that you may require. To do this, start transaction RZ11 in the relevant system, enter profile parameter sapgui/user_scripting and choose Display. If the current value is FALSE, change it to TRUE. You must log off and back on again for the change to take effect.

Mapping the System Landscape
Web AS 6.20 eCATT Test CRM transaction Check table entries in R/3 Run transaction in R/3 Call function module in APO RFC CRM R/3 APO The first step towards an automated test is to map the system landscape in which you will be working. There are two main considerations here: The applications that you want to test are generally not present in your central test system, so you must test remotely. The business process that you want to test may extend across system boundaries, so you need to be able to test in several different remote systems. In order to test remotely, you use Remote Function Call (RFC). However, in an eCATT test script, you do not address target systems directly using an RFC destination. Instead, you assign a logical system name to each system in your landscape, and it is this name that you use in the test script. Resolving the logical name, as used in the script, into an RFC destination that identifies a particular system is the task of a system data container. Business Process

Defining RFC Destinations
Source System Target System RFC Destination Target Transaction Client: 100 Lang: EN User: tester Pwd: letmein Direct but unsafe Client: 100 Lang: EN User: <current> RFC Destination Target Transaction Safe but cannot run unattended The RFC destinations that you use in eCATT are normal R/3 -> R/3 destinations that you define in transaction SM59. In each RFC destination, you can specify not only the location of the system that you want to address, but also the user credentials that will be used to log onto that system. The logon to the remote system can only take place unattended if the logon data is complete (client, user, and password). Storing passwords in RFC destination definitions is, however, not to be recommended. If you do not store a password, the logon data is incomplete, and a logon screen will be displayed when time your test case tries to enter that system. Consequently, the test case can no longer run unattended. The way around this problem is to establish a trusted/trusting relationship between systems, in which the target system trusts calls that are made by the central test system. This eliminates the need to store a password within the destination definition but ensures that the logon can still run unattended. For details of how to set up a trusted/trusting RFC relationship, refer to SAP Note

Function of System Data Containers
Test Script Command With Logical Target System Data Container Target System Target < -- > RFC Dest. The logical target describes the function of the system – for example R/3. The system data container maps the logical name to a particular RFC destination. The task of a system data container is to map the logical names that are used in a script to a particular RFC destination that specifies the system, client, and user that the test case is to access. You can assign the logical names yourself. As a rule, they should reflect the function of a system and should not relate to a particular release or system name – they should remain relevant beyond the lifetime of a particular release or system. Consider the following example: Your R/3 System has Release 4.6C and has the System ID P01. Possible logical names for this system might be: R3 R3_46C R3_P01 P01_46C Now consider the situation after an upgrade to R/3 Enterprise: Your system no longer runs under Release 4.6C and may have moved so that the system is no longer called P01. Any logical name that refers to either the release or the system name is therefore obsolete: In our example, only R3 is still relevant.

Creating a System Data Container
SAP Web AS 6.20 System under test Relationship described by RFC destination XYZ System Data Container Target system RFC Destination . . . R3 XYZ To create a system data container, start transaction SECATT, select the System data container radio button, enter a name for your system data container, and choose Create. On the next screen, you must maintain various attributes for the system data container – in particular, it must have a title, an application component, and a package. On the System data tab, you will see that the default system NONE is already present. This refers to the default RFC destination NONE, allowing you to refer to the current system at any time. To add a new system to the container, choose the Create icon. eCATT appends a new row to the table. In it, you must specify a logical name for your system and, in the third column, assign an RFC destination that already exists (you can use possible values help to display all relevant RFC destinations). In the second column, you may enter a description of the system. Repeat the previous step for each system in your system landscape.

Advantages of System Data Containers
Consistency One container can serve a whole project The RFC destinations can contain the client, language, and user name for the logon – eliminates sources of errors Access to SM59 and the authorization to create system data containers can be restricted to project leads Reuse Using logical system names in a script means that the execution environment of the script can be changed by switching system data containers. Changes in the script coding are not required. System data containers help you to achieve greater consistency in your test activities. You can create a single system data container for a test project (or subproject). Since the RFC destinations behind the logical destinations contain a full set of logon credentials, you can be sure that your test developers and testers are using the correct systems, clients, and users. System data containers also improve the stability of your scripts. In a script, you only ever refer to a particular target system by its logical name, which remains constant. The actual system to which that logical name points is dependent on the current system data container. Thus you can execute a script against a completely different system landscape simply by linking it with a different system data container, and you never have to change the script coding.

Unit Summary In this unit, you have learned The different object types with which you work in eCATT How these object types support you in the various stages of planning an automated test project How to set up a system to enable eCATT How to define secure RFC destinations How to create a system data container

Unit 3: eCATT Scripts and the Script Editor

In this unit you will learn:
Unit Objectives In this unit you will learn: The structure of an eCATT script The essential features of the eCATT script editor The main aspects of the eCATT scripting language How to work with parameters

Design Considerations for a Script
Definite Goal Before you write your script, work out exactly what you want it to do Reusability Try to create small self-contained script modules. This will make them more easily reusable. Although it is impossible to make general rules about how to write the perfect script, there are two guidelines to consider: Have a definite goal! Before you start writing the script, make sure that you know exactly what you want it to do. Aim for reusability! There is little point in packing an entire order-to-cash scenario into a single script, because it contains many parts that you might be able to reuse in other test scenarios. You should therefore aim for smaller test scripts – it is very easy to create one "master script" at the end that does nothing other than call a series of smaller scripts.

Test Script Attributes Parameters Importing Exporting Commands
Structure of a Script Test Script Attributes Parameters Importing Exporting Local variables Commands In terms of its structure, a test script is similar to a function module. It contains various attributes, an interface in the form of importing and exporting parameters, and the commands that actually form the test. Scripts may also contain local (private) variables for use within the coding.

Script Attributes Administrative data about the script Search terms:
Can be used in Infosystem Attaches system data container to script, allowing access to other systems When you create a script, you must first maintain certain attributes. The following attributes are mandatory: Title, package, person responsible, application component. The maintenance system attributes are important. It is here that you can assign a system data container to your script. You can then address any of the systems listed in the system data container from your script. In addition, you can make any one system from this system data container the default target system by entering its logical name in the target system field. On the Versioning Data tab, you can specify the validity of the current version of your script. You will learn more about versioning in Unit 9. The Restrictions tab contains optional documentary attributes. You can, for example, specify that the test script applies to a particular locale or platform. Note, however, that these attributes are not evaluated by eCATT when you run a script. You can only use them as useful search terms.

Parameter List Structure Editor Command Editor
The Script Editor Parameter List Structure Editor Command Editor The script editor has three areas – the command editor, where you enter the script coding, the parameter list, where you can create importing and exporting parameters, as well as local variables for your script, and the structure editor, where you can edit any structured parameters within the script. A structured parameter can be A structure An internal table A command interface (interface of an eCATT command)

CHEVAR ( I_IMPORT <> 'UA' ). . . .
Simple Parameters Creation Use I_IMPORT = 'LH'. CHEVAR ( I_IMPORT <> 'UA' ). . . . You create parameters in the parameter editor section of the script editor. Each parameter must have a name, a type, and be defined as an Importing parameter, an Exporting parameter, or a local Variable. Parameters can have any data type except for String and XString. The default data type is C with length 128. You can also type a parameter with reference to an ABAP Dictionary type (either simple or structured). Parameters may also have a default value, which you enter in the Value field. In the command editor, you work with parameters in the same way as you would work with variables in any programming language – you can use them freely in assignments and logical expressions as shown above.

Structured Parameters
Use I_STRUCTURE-CARRID = 'LH'. I_ITAB[2]-CONNID = '0400'. GETLEN ( I_ITAB, VAR ). As well as elementary parameters, you can also create structured parameters – that is, structures or internal tables. To create a structured parameter, the reference type must be a structure in the ABAP Dictionary. To create an internal table parameter, the reference type must be either an internal table type in the ABAP Dictionary or a structure type followed by opened and closed square brackets, for example SPFLI[]. To address a component of a structure, you use the same notation as in ABAP, that is <structure>-<component>. To address a particular component of an internal table, you use the notation <table>[index]-<component>. The eCATT command GETLEN allows you to find out the number of entries in an internal table. Its syntax is GETLEN ( TABLE, VARIABLE ). which places the number of lines in table TABLE into the field VARIABLE. If you assign whole structures using the form struc2 = struc1, the assignment uses MOVE-CORRESPONDING logic.

Script Language Recording and playback of applications Conditions
Checks Loops Calculations Simulation of Customizing settings Reading table values Blocks of ABAP coding eCATT has its own scripting language. It is similar to ABAP, but nevertheless a different language. It allows you to record and replay applications, perform checks, and use various common programming control structures.

Commands for Recording Applications
Recording and playback of applications FUN calls a function module TCD allows you to record and replay SAP transactions SAPGUI allows you to record sequences of screens containing controls An interface allows you to integrate test tools from third-party vendors with SAP eCATT There are four different ways of testing applications. Each of them is appropriate for a particular kind of application that you might want to test. It is important to remember that no single way is suitable for testing everything. For this reason, you should always take care to pick the correct driver before you start to record your script. On the next page, you will learn how to pick the correct driver for a test.

Choosing the Right Driver
Is the application a function module or BAPI? No Does the application run under SAP GUI for Windows or Java? No Use ext. tool Yes Use FUN Yes Does the application use controls? No Use TCD No Yes Are the controls essential within the transaction? No single driver provides the best solution for every application You can use the graphic to help you choose the right driver to test a particular application. When it comes to testing applications using the TCD and SAPGUI drivers, you should bear in mind that the TCD command is the most efficient in terms of runtime, because it runs in the background with no SAPGUI window attached. The SAPGUI command has the overhead of having to instantiate the SAP GUI window. Consequently, it should only be used for transactions where TCD cannot be used. Yes Use SAPGUI

&MSX – Number of messages returned by a transaction &USER – User name
Special Variables &SZBRC - Return code &TIME - Current time &DATE – Current date &YEAR – Current year &YEARA – Next year &YEARB – Last year &LPC – Loop counter &MSX – Number of messages returned by a transaction &USER – User name &CLIENT – Current client eCATT has a range of special variables, similar to the sy- fields in ABAP. A full list is available in the eCATT documentation. You can also use sy- fields in eCATT scripts. Note, however, that sy- fields always relate to the local system, and that special eCATT variables always relate to the target system. So, for example, if you are logged onto the test system as user SMITH, but the RFC destination that connects to the target system logs on as TESTER, sy-uname will have the value SMITH, but &USER will have the value TESTER.

Pattern Function The Pattern function is similar to the statement pattern in the ABAP Editor. It allows you to build individual eCATT commands. A command consists of: The command keyword Argument (the target object) Interface (parameters that need to be passed) Target system The pattern function allows you to create eCATT commands quickly and easily. The first step is to pick a command. Once you have done that, you must supply the argument – for example, the function module you want to call or the transaction you want to record. Next, the system proposes the name for the command interface. You can accept the default, or change it if you like. Finally, you specify a target system. You can use any system that is defined in the current system data container. If there is no system data container attached to the script, you can only execute the command locally.

Most eCATT commands have a command interface, which corresponds to:
The interface of a function module (for FUN) The screen and field structure of a transaction (for TCD) A list of user interactions (for SAPGUI) The importing and exporting parameters of a referenced script Command interfaces are stored in XML format in the local system, even if the object that they describe only exists in a remote system. Command interfaces represent the input/output interface of the command to which they belong. They are always displayed in tree form in the structure editor. To open a particular command interface in the structure editor, double-click its name either in the parameter list or in the eCATT command in which it is used. You can assign literals or variables to parameters in the command interface. Literals must be enclosed in single quotes. If you use variables, you must remember to declare them as script parameters in the parameter list.

Unit Summary In this unit, you have learned The various areas of the eCATT Test Script Editor The features of the eCATT script language How to create eCATT parameters How to use the pattern function in the eCATT Script Editor Which driver to use for various kinds of applications

Function Modules and BAPIs Table Operations Inline ABAP
Unit 4: Non-UI Testing Function Modules and BAPIs Table Operations Inline ABAP

Unit Objectives In this unit you will learn: How to test function modules and BAPIs How to read from and test against the database How to use blocks of ABAP coding to enhance your test scripts

Is the application a function module or BAPI? Yes Use FUN

Non-UI Testing: Function Modules
Unit Test Function Module Whole Backend Process Function Module Transaction Utility Within a Script There are various situations in which you might need to test function modules: As a unit test, where you test a single function module As a backend process, where you test a string of function modules that make up a whole process, passing the results of one module onto the next As utilities within a script, for example, to retrieve data from the database that you want to use in transactions, or to perform a complex plausibility check for which you know that a function module already exists.

Testing Function Modules
FUN ( <function module>, <interface>, [<target>] ). Command Interface Function Module Importing Exporting Changing Tables Exceptions In the graphic, you can see the syntax of the FUN command. The FUN command interface is split into the same sections as you find in the definition of the function module itself – Importing, Exporting, Changing, Tables, and Exceptions. To pass a value to the function module, assign the relevant literal or variable to the correct parameter in the command interface. Do the same thing to receive an exporting parameter into a script parameter.

Parameterizing the Interface
or INTERFACE-IMPORTING-PARAMETERNAME = value. INTERFACE-IMPORTING-STRUCTURE-FIELDNAME = value. INTERFACE-TABLES-TABLE[idx]-FIELDNAME = value. As well as assigning parameter values using the structure editor, you can also address parameters programatically within the script editor. This is particularly useful if, for example, you need to assign values dynamically. The syntax for addressing components within a command interface is shown above. It is similar to the ABAP syntax for addressing complex structures. Note that if you are working with internal tables, you must specify the relevant table index in square brackets.

Interface Interface Trapping Exceptions Exceptions DATA_INCOMPLETE
CREATE_FAILED Exceptions Interface DATA_INCOMPLETE CREATE_FAILED Exceptions Interface Sometimes, the aim of a test will be to make a function module trigger an error. In such a case, you will want the test case to be marked as successful if an exception is triggered. eCATT, however, normally handles function module exceptions as errors and, as shown in the top half of the graphic, will mark the test case red in the log. To define an exception as “successful”, you must assign it the value ‘X’ in the command interface. If the exception then occurs, the script will not fail. Defining an exception as successful does not mean that the script will fail if the exception does not occur. If you want this to happen, you must query the special eCATT variable &EXCEPTION yourself in the script. For example, in the above example, you would write CHEVAR ( &EXCEPTION = ‘DATA_INCOMPLETE’).

Test Script Database Application Table Customizing Table
Table Operations Test Script Database GETTAB ( TAB, INTF, [DEST] ). Application Table CHETAB ( TAB, INTF, [DEST] ). SETTAB ( TAB, INTF, [DEST] ). RESTAB ( TAB, [DEST] ). Customizing Table The GETTAB and CHETAB commands allow you to read and check single database table entries. Each has a command interface with the structure of the table line. In the structure editor, key fields are marked with (K). In both commands, you enter values in the command interface that should be used to make the database selection. If the GETTAB statement finds a corresponding row in the database table, it places the contents of that row into the command interface. Note that if you do not specify the full table key, the single record returned by GETTAB may not be the only one that matches your key specification. If you want to retrieve multiple lines from the database, consider using a function module or writing a SELECT statement in an Inline ABAP block. The CHETAB command searches for a table entry matching the key (plus any other non-key fields) that you specified. If it finds one, the command is marked as successful. If it does not find a corresponding table entry, the statement fails, and with it, the script. Note that you must assign values to all key fields in the CHETAB command. If one or more key fields are not relevant to your query, assign them the value *. The SETTAB and RESTAB commands allow you to simulate changes to Customizing settings within a script. You can only use them on tables that are defined as Customizing tables in the ABAP Dictionary. SETTAB makes temporary changes to a Customizing table. With RESTAB, you can roll back these changes at the end of the script. Do not use SETTAB for extensive Customizing modifications. Business Configuration Sets are far better suited to this task.

Name Description Value I/E/V Ref Type
Using Inline ABAP ABAP. * Any ABAP Coding that is allowed in a subroutine * may appear here ENDABAP. Parameters Name Description Value I/E/V Ref Type V_TAB SFLIGHT-table <INITIAL> V SFLIGHT[] ABAP. SELECT * FROM sflight INTO TABLE v_tab WHERE carrid = ‘LH’ AND connid = ‘0400’. ENDABAP. Expecting a result set of more than one line. No corresponding function module available. “Once-off” query There are cases where the eCATT scripting language may be insufficient for your needs. For example, you cannot Test classes and methods Read multiple lines from the database in a single command For cases such as these, you can use blocks of ABAP coding in your script. Each block is introduced with the keyword ABAP and ends with ENDABAP. Inside each block, you can use any ABAP coding that is valid in the default target system of your script. Technically the blocks are compiled into FORM routines. This means: You cannot define your own FORM routines within an ABAP block Any data objects that you declare using the DATA statement are not visible beyond the end of the block. Within an ABAP block, only the local variables of the script are visible. Consequently, if you want to use an importing or exporting parameter of the script in an ABAP block, you must first assign it to a local variable.

In this unit you have learned:
Unit Summary In this unit you have learned: How to test function modules and BAPIs How to read from and test against the database How to use blocks of ABAP coding to enhance your test scripts

Unit 5: Testing Transactions - I
Testing conventional transactions using the TCD command

Unit Objectives In this unit you will learn: What transactions are suitable for testing using the TCD command How to record a transaction using the TCD command How to set input fields, read output fields, and perform fields checks with the TCD command

Is the application a function module or BAPI? No Does the application run under SAP GUI for Windows or Java? Yes Does the application use controls? No Use TCD No Yes Are the controls essential within the transaction?

Characteristics of the TCD Command
The TCD command is the recording technique that was used to test transactions in CATT It is based on the Batch Input Interface It allows you to record a transaction, parameterize its input fields, and read or set checks against its output fields

Background: The Batch Input Interface
Background: Data-consistency checks in SAP transactions are often implemented within the coding of the screen flow logic (Process After Input) Batch Input is a technique originally developed for data transfer from legacy systems into an R/3 System that processes transactions in the background CATT used this technique for unattended transaction testing. It is a very efficient testing method, and has consequently been retained in eCATT

TCD ( transaction, interface, [sys] )
The TCD Command TCD ( transaction, interface, [sys] ) Same system Different system To record a transaction that does not contain controls, use the TCD command. It is easiest to insert the command by choosing the TCD (Record) entry from the dropdown list box. You will then be prompted to enter a transaction code. From this, the system generates a proposal for the command interface name. You may also specify a target system (as long as you have entered a system data container in the script attributes). Once you have filled out the arguments in the statement pattern, eCATT starts the transaction, and you can work through it normally. The system records all of your entries. When you leave the transaction, control passes back to eCATT, and you will be asked whether you want to use the data you have just recorded. Choose yes. If you now double-click the name of the command interface in either the parameter list or the command editor, the structure of the transaction will appear in the structure editor. From here, you can assign parameters to individual screen fields.

How TCD Really Works - Recording
ENTER FIELD VALUE KUAGV-KUNNR 1280 VBAP-MATNR P BDC_OKCODE SICH FIELD VALUE VBAK-AUART AF VBAK-VKORG BDC_OKCODE ENT2 The TCD command is based on the batch input technique. When you record a transaction, the recorder is triggered each time you choose a function (such as pressing Enter, choosing a menu entry, clicking a pushbutton, and so on). At this point, it collects all of the field contents from the screen and stores them in a table, along with the function code of the function you chose.

How TCD Really Works - Replay
No SAP GUI session FIELD VALUE . . . BDC_OKCODE Field values FIELD VALUE KUAGV-KUNNR 1280 VBAP-MATNR P BDC_OKCODE SICH VBAK-AUART AF VBAK-VKORG 1000 TCD commands are replayed without the transaction having any contact with a SAP GUI instance. The batch input system is able to replay transactions using just the field contents and function codes. While this provides quick playback for scripts containing TCD commands, it makes TCD unsuitable for transactions that make extensive use of controls, since controls, in order to behave properly, must be alive at the frontend both during both recording and playback. ENT2 Function code

The Command Interface Transaction Screen Field
The command interface of a TCD command divides the transaction into screens, and the screens into fields. Each screen may be either active or inactive. Fields are identified by a name. This is the same name as appears under the Field description for batch input when you display the technical information about a screen field ( F1 followed by the Technical Information icon).

Parameterizing Input Fields
You can replace the recorded values with either literals or variables Field name Value Double-click The input and output fields on screens can be parameterized. To assign a value to an input field, open the field list of the relevant screen by double-clicking the "Field Mode Name Valin" row beneath the screen number in the tree display. The field list opens to the right of the tree. Find the field that you want to set and ensure that its mode is set to 'S' (set value). Enter the new value (either a literal or a variable) in the VALIN column.

Reading and Checking Output Fields
To... Read a value Check a value MODE must be... 'G' 'C' Field name in VALIN column Will contain value from output field at the end of the transaction Contains the value that must be present in the screen field at runtime With the TCD command, there are two options for parameterizing output fields – you can either place the value from an output field into a variable in your script, or you can check the value against a predefined check value. To read a value, you must set the Mode of the field in question to 'G' (Get value). Then enter the name of a parameter in the VALIN column. At runtime, eCATT will place the value from the screen field into the script parameter. To check a value, you must set the Mode of the field to 'C' (Check value).Then enter either a literal check value or the name of a parameter containing the required check value. At runtime, the screen field will be checked against the value that you specified. If the values do not match, the script will fail.

Number of messages &MSX
Message Handling TCD Command Interface Location of message (program and screen) Message attributes (type, ID, number) MSG Internal Table Message variables (up to four) Full text of message (in logon language) Number of messages &MSX All of the messages sent by a transaction are stored within the command interface in an internal table called MSG. MSG has the following fields: TCODE –transaction code from which the message was sent DYNAME –program name DYNUMB –screen number MSGTYP –message type MSGSPRA – language of the message MSGID – message class MSGNR – message number MSGV1 … MSGV4 – variables (optional) that replace placeholders in the message ENV – not used (batch input-specific) FLDNAME – the text of the message in full The number of messages sent by the transaction is contained in the eCATT system variable &MSX.

Reading Message Contents
Addressing the Last Message <interface>-MSG[&MSX]-<component> Looping Through All Messages DO &MSX. <interface>-MSG[&LPC]-<component> ENDDO. Using &MSX, you can find any given message. To retrieve the last message, you address MSG with index &MSX. The precise syntax is <interface>-MSG[ &MSX ]-<component>. To loop through messages, you can use &MSX as the count for a DO statement. The following example shows how you could use a loop to check whether a particular message appeared during the transaction: DO &MSX. IF ( command_interface-MSG[ &LPC ]-MSGID = message_class AND command_interface-MSG[ &LPC ]-MSGNR = message_number ). * Do something. ENDIF. ENDDO.

Require that a particular message is sent
Testing Messages Require that a particular message is sent ON_LAST_MESSAGE_CHECK ( 031 ). TCD ( EC_TUTORIAL_TCD, EC_TUTORIAL_TCD_1 ). Tolerate all messages ON_LAST_MESSAGE_CHECK ( * ). TCD ( EC_TUTORIAL_TCD, EC_TUTORIAL_TCD_1 ). The ON_LAST_MESSAGE_CHECK command allows you to specify before a TCD command the number of a message that must occur during that command. In the first example above, the message with number 031 must be sent by the subsequent TCD command, otherwise the script will fail. To tolerate all messages (including errors), use the command ON_LAST_MESSAGE_CHECK ( * ). This allows you to implement your own message analysis after the TCD command. Note that this command will be superseded in Release 6.40 by a new rule-based message handling mechanism. This has already been implemented for the SAPGUI command, and you will learn about it in the next unit.

Troubleshooting the TCD Command
By default, the TCD command runs in the background. Consequently, you do not see anything between clicking the Execute button and the appearance of the log. The start options of the TCD command allow you to troubleshoot it by running it in the foreground (mode A). In this mode, the transaction is played back screen-by-screen so that you can analyze the various field contents and establish where things are going wrong. Another useful troubleshooting mode is mode E. In this mode, the transaction is played back in the background, but switches to foreground processing if an error occurs.

In this unit you have learned:
Unit Summary In this unit you have learned: What transactions are suitable for testing using the TCD command How to record a transaction using the TCD command How to set input fields, read output fields, and perform fields checks with the TCD command

Unit 6: Testing Transactions - II
Testing control-based transactions using the SAPGUI command

Unit Objectives In this unit, you will learn: Why the TCD driver is not suitable for testing all transaction types How GUI Scripting works How to use the eCATT SAPGUI command to record a transaction How to set input fields, read output fields, and perform field checks in a SAPGUI recording

Is the application a function module or BAPI? No Does the application run under SAP GUI for Windows or Java? Yes Does the application use controls? Yes Are the controls essential within the transaction? Yes Use SAPGUI

Why TCD Cannot Test Everything
Control ALV Tree Calendar OCX control under Windows Bean under Java SAP GUI Window Frontend Action leads to local processing in SAP GUI New recording component Action leads to event handler on application server TCD Recorder eCATT Backend Application Logic The TCD command and batch input interface only work for applications that are programmed using "classic" SAP dialog programming – that is, where the transaction is controlled exclusively by using Process After Input (PAI) and Process Before Output (PBO). New transactions, or transactions that were redesigned in the EnjoySAP initiative (Release 4.6B), frequently use the SAP Control Framework to implement part of their user interface. Examples of Control Framework controls are the SAP List Viewer, SAP Tree Control, SAP HTML Viewer, SAP TextEdit Control, and so on. One of the principal characteristics of these controls is that their features and functions are implemented locally within the SAP GUI. Further functions are implemented by the application using the control in the form of event handler methods. Functions that are implemented in these ways do not form part of the standard PAI/PBO logic, and therefore cannot be recorded by the TCD recorder. The only way to enable these applications to be tested was to implement a new testing driver at the frontend as part of the SAP GUI that works by intercepting the actions that a user performs on a screen, regardless of whether those actions belong to a conventional screen element like a pushbutton or an input field, or to a control such as the SAP List Viewer.

Introducing GUI Scripting
Scripting host in GUI (Requires SAP GUI 6.20) eCATT at backend The SAPGUI driver in eCATT is based on the GUI Scripting function in Release 6.20 of the SAP GUI. GUI Scripting allows you to create scripts that automate the SAP GUI in much the same way that macros allow you to automate Office applications. GUI Scripting is a standalone feature of the SAP GUI that you can also use independently of eCATT. For full details and a range of documents on the subject of GUI Scripting, use the search function on the SAP Service Marketplace ( to search for the term "SAP GUI Scripting". A scripting host within the SAP GUI intercepts the actions that you make on a screen. If you are using GUI Scripting on its own, the actions are translated into VB Script or Java Script. If you are working with eCATT, the actions are transferred to eCATT, where you can see them as the command interface of the SAPGUI command.

Recording the SAPGUI Command – Procedure
1. Select SAPGUI(Record) 2. Set the scripting granularity The procedure for recording the SAPGUI command is slightly more complex than when you record a transaction using TCD. A TCD command always contains a single transaction, and all of the input and output is recorded. With SAPGUI, both the granularity of the recording and the amount of data to be included is variable, and you have to specify this at the beginning of each recording. This page and the next are intended to give you a general overview of the recording procedure. We will return to each step in more detail later on. To start a SAPGUI recording, use the Pattern function and select the command SAPGUI (Record). The next thing that you have to do is to specify how you want the recorded data to be arranged in your script.

Recording the SAPGUI Command - Procedure
3. Confirm that you want to record 4. Pick the relevant initial states to record After you have set the granularity of your recording, eCATT opens a new window of your chosen target system and asks you if you want to record in it. Choose Yes at this point. You now have to specify the kinds of user interface elements for which you want to record the initial state. Recording the initial state allows you to extract the contents of output fields. Having done that, you are ready to record.

Scripting Granularity
Action Session Action Transaction Action Screen S T S As we have already seen, a TCD command has a defined structure based on the fact that TCD can only ever record a single transaction. That transaction is broken down into screens, and each screen contains fields. Because the SAPGUI command works at frontend level, it only recognizes actions. One consequence of this is that, unlike the TCD command, you can use the SAPGUI command to record a part of a transaction or, indeed, several transactions. It also means that there is no predefined granularity as is the case with the TCD command. The first thing that you have to do when you start recording a SAPGUI command is to define the level at which you want the system to generate new commands. This can be at various levels: Session level, which means that all of the actions performed in a SAPGUI window (and that could encompass several transactions) are combined into a single SAPGUI command. Transaction level, in which the system generates a new SAPGUI command for each new transaction Screen level, where a new SAPGUI command is generated each time there is a screen change during recording User interaction level, where a new SAPGUI command is generated each time the token is exchanged between frontend and backend. In deciding on a granularity level, you must take into account the size of the generated command interfaces. If you record at session level, for example, you will have a single command with a huge command interface. If you record at user interaction level, the command interfaces will be smaller, but you will have a large number of commands. Generally speaking, it is easier to work with command interfaces that are not too big. Screen level is often a good level at which to work. T: New Transaction S: New Screen

Making Sense of the Command Interface - 1
One ProcessedScreen node per screen Every SAPGUI command interface contains details of the actions that you performed on that particular screen. The command interface is split up into ProcessedScreen nodes – one for each screen within that particular command interface. Below the ProcessedScreen node is a section called UserChangedState. This section contains a list of the actions that you performed on the screen during recording. It is here that you can parameterize fields, as you will see on the next page. UserChangedState describes the user actions on the screen

Parameterizing an Input Value
Field name Enter parameter name in this field Double-click Each GUI element with which you interacted during recording has its own GuiElement node under the UserChangedState node. A blue arrow pointing towards an attribute name in the State node denotes a set parameter. To parameterize the value of a field, find the relevant field and double-click the Text attribute. In the grid that appears, enter the name of a variable against the Value element. Do not change the Name field. You can only set values of fields with which you interacted during recording. No other fields are recorded. The methods of controls are denoted by a pair of square brackets [ ] (not shown in the example above). Underneath the method node are the individual parameters, which you can also parameterize. Within the UserChangedState section of a command interface, you can only set values. Furthermore, to set the value of a field, you must have changed the value of the field during the recording. You cannot retrieve the values of output fields. This is the task of the InitialState section, which you will learn about on the following pages.

Recording the SAPGUI Command – Initial State
By default, the SAPGUI command only records the actions that you perform in an application. This means that only the entries that you make in fields, and not the field contents that are displayed in output fields, are recorded. To access the contents of output fields, you must record their initial state. You do this by setting the appropriate options in the dialog box shown in the graphic above. Since recording initial states increases the volume of data transferred from the frontend to eCATT, you can restrict the initial state recordings to certain types of user interface element – for example, input/output fields. Once you have selected the initial states that you want to record and decided whether to record with active or inactive checks, choose "Activate mode for initial states". This communicates your selection to the frontend. You can now start recording in the new window that eCATT opened.

Active and Inactive Checks
Record the initial states of the selected screen element types On replay, check that the values in the fields correspond to the recorded initial states Inactive Checks Record the initial states of the selected screen element types so that they can be placed into script parameters and used in the rest of the script When you record initial states, you can choose whether to record them with active checks or inactive checks. If you choose active checks, the field contents at runtime will be compared with the field contents that were present during recording. If they do not correspond, an error will occur. If you choose inactive checks, all of the necessary information to perform a check is recorded, but the check is deactivated. The options in this dialog box activate or deactivate checks for the whole of your recording. Later, when you edit the command interfaces, you can activate and deactivate checks for individual fields.

Making Sense of the Command Interface - 2
One InitialState node per processed screen Are checks active? Field name Field value during recording The InitialState node gives information about the contents of screen elements at the beginning of each ProcessedScreen node. If checks are active, the value of a particular GUI element during playback will be compared with its value during recording. You can parameterize the check values. A check will only be performed if the Check option is set along the whole path of the tree from the top of the InitialState node down to the element in question.

Retrieving an Output Value
Enter parameter name in this field Double-click A blue arrow pointing away from an attribute name in the State node denotes a get parameter. To retrieve the value of a field from the SAPGUI interface, find the relevant field in the InitialState section of the interface, and double-click the Text attribute. In the grid that appears, enter the name of a value against the Value element. Do not change the Name field.

Activating and Deactivating Field Checks
In the InitialState section of the SAPGUI command interface, you have the opportunity to enable or disable field checks. For a check to be active, all of the Check attributes between the top of the current ProcessedScreen and the element that you want to check must be set to 'X'.

Message Handling – MESSAGE
Stipulate that certain messages must/must not occur in order for the script to be a success Find out what messages occurred during a particular block of SAPGUI commands An important part of testing an application can be to analyze the messages that occur when the application is replayed. The SAPGUI command supports you in this in two ways, allowing you to: Specify rules as to what messages are allowed, which are prohibited, and which should be tolerated Analyze the messages that actually occurred during script playback, along with their contents. To work with messages that are sent during the course of SAPGUI commands, you enclose the SAPGUI commands between the eCATT commands MESSAGE and ENDMESSAGE. Both have a command interface: The MESSAGE command interface contains rule definitions The ENDMESSAGE command interface contains a list of messages that occurred during replay.

Message Handling - ENDMESSAGE
MIDX MODE MSGTYP MSGID MSGNR MSGV1 MSGV2 MSGV3 MSGV4 <n> F E ECDEMO LH 0400 2 A E ECDEMO 021 3 A S XY 100 E_MSG_1 E_MSG_1[1]-MIDX contains the total number of messages in the table The command interface of the ENDMESSAGE command is similar to the MSG table in the command interface of the TCD command – it contains a list of the messages that have been sent since the opening MESSAGE command. The MIDX field contains the index of the current message, except in the first row of the table, where it contains the total number of messages contained in the table. You can access details of the individual messages using the following fields: MSGTYP – Message type MSGID – Message class MSGNR – Message number MSGV1… MSGV4 – Variable parts of the message The ENDMESSAGE command interface always contains details of the messages sent during the application, regardless of whether you specified any rules in the MESSAGE statement.

Creating Rules in the MESSAGE Statement
Rule = What to do + Message qualification What to do R: Require E: Expect A: Allow F: Fail Mode Exit Continue processing or jump directly to ENDMESSAGE? Message qualification Any combination of Message Type Message Class Message Number In the MESSAGE statement, you define rules for message processing. There are two aspects to each rule – the mode and the object. There are four possible modes: Require – The message or messages that you specify in the object must occur for the script to succeed Expect – At least one of the messages specified in one of any number of rules defined with this mode must occur for the script to succeed Allow – Messages specified in the object will be tolerated Fail – The message or messages specified in the object must not occur. If they do, the script will fail. In addition to the mode, there is a parameter Exit. This specifies what should happen if an incoming message satisfies the rule: Exit = ' ': Carry on processing as normal Exit = 'X': Jump directly to the ENDMESSAGE command. The object of a message can be any combination of message type (S, I, W, E, A, X), message class, and message number.

Some Sample Message Rules
“Tolerate all error messages” Mode Exit MSGTYP ID Number 'A' 'E' “Fail script and jump to ENDMESSAGE on error message ZJM 001” Mode Exit MSGTYP ID Number 'F' 'X' 'E' 'ZJM' '001' Above are some sample message rules. The first is very general, specifying that all error messages (only the type is specified – no message ID or number) are to be allowed. The second rule is far more specific – its mode is to fail the script and exit if error message ZJM 001 occurs. The order in which you define rules is crucial. As soon as eCATT has successfully applied a rule to an incoming message, no further messages will be processed. In the case of the rules above, it would mean that the first rule would always overshadow the second, because message ZJM 001, when sent as an error message, will satisfy the first rule and consequently be allowed. If you define rules that conflict (as is the case here), the more specific rule must come before the more generic rule.

Default Message Handling Rules
User-defined Rules Success Information messages Warning Allow Error Termination messages Dump Fail and Exit As well as rules that you define, there is also a set of default rules in the MESSAGE command: Success, information, and warning messages are allowed Error, termination, and type X messages cause the script to fail The default rules are always processed after your own user-defined rules. Consequently, if you create a rule of your own that conflicts with a default rule (for example, you choose to allow certain error messages), your rule will take precedence over the default rule.

Look up in user-defined
Message Processing Look up in user-defined rules Look up in default rules New Message Discard Process according to rule  Process according to rule  When a new message arrives, eCATT first checks it against your rules. If a rule is satisfied, the script continues according to the rule definition and no further rules are processed. If none of your rules are satisfied, the default rules are processed. Again – if a rule is satisfied, the script continues according to the rule definition and, once again, no further rules are processed. Since your rules are processed before the default rules, any rule that you define that conflicts with a default rule will take precedence. Since no further rules are processed once a particular rule is satisfied, you must pay particular attention to the sequence in which you define your rules. The more specific the rule, the higher it should be in your list. Generic rules, such as “allow all error messages”, should come near the bottom of the list.

The SAPGUI Command Interface 4
System Information The system information part of the command interface contains three important nodes – the ConnectionId and SessionId, and the ResetGUI option. The ConnectionId and SessionId nodes determine the window in which the command will be replayed. Essentially, the precise values in these fields do not matter, but what is important is that all SAPGUI commands that you want to replay in a single window must have the same ConnectionId and SessionId. SAPGUI commands will only replay properly if each successive command starts at exactly the same point at which the last command stopped. Everything that you record in a single attempt will, of course, fulfill this condition. However, if you record a script in sections – for example, a transaction at a time – it may be that your starting point for a new section does not match the end point of the previous SAPGUI command. If this is the case, you can use the ResetGUI option. If you set ResetGUI to ‘X’, eCATT performs the equivalent of ‘/n’ before starting the transaction in the next ProcessedScreen section of the command interface. Do not use ResetGUI within a transaction.

Activating and Deactivating Screens
Active = ‘X’: Screen active Active = ‘ ’: Screen inactive Active = ‘O’: Screen optional Screen 1 Screen 2 Screen 3 You can activate or deactivate individual ProcessedScreen nodes within SAPGUI commands. The Active node can take the following values: ‘X’: The screen is active and will be processed ‘ ’: The screen is inactive and will not be processed ‘O’: The screen is optional. It will be processed if it appears, but ignored if it does not. When you deactivate screens, you must be aware that subsequent screens may depend on information from that screen. “Join” OK?

Troubleshooting in the SAPGUI Command
Set automation queue behavior Run commands with stops at various granularity levels There are various start options that you can set to help you troubleshoot problems that occur with the SAPGUI command. Processing mode: This allows you to disable the automation queue, a helpful diagnostic tool if a control is causing errors. Error Mode: This specifies whether the SAPGUI command should terminate or continue when an error occurs. Stop When: This option allows you to run a SAPGUI command with stops at various levels of granularity. For example, you can stop before each screen is processed. The granularity levels available range from transaction down to individual method call. You can also stop before each SAPGUI command, regardless of the granularity at which it is recorded. Close GUIs: This option allows you to specify whether eCATT should automatically close generated GUI sessions at the end of a script (the default setting) or whether they should be left open. This would allow you to inspect the state of the application at the end of the script. Close GUI sessions or leave them open for inspection

In this unit, you learned:
Unit Summary In this unit, you learned: Why the TCD driver is not suitable for testing all transaction types How GUI Scripting works How to use the eCATT SAPGUI command to record a transaction How to set input fields, read output fields, and perform field checks in a SAPGUI recording How to activate and inactivate screens in a script, and the things that you have to consider when doing so

Unit 7: Testing Transactions - III
Testing Web- and Desktop-based Applications Using an External Tool

Unit Objectives In this unit, you will learn: When to use TCD and SAPGUI, and when you have to use an external tool Why SAP chose to work with external tools The advantages of the external tool integration How the integration works

Is the application a function module or BAPI? No Does the application run under SAP GUI for Windows or Java? No Use ext. tool

Configuring The System for an External Tool
Run function module SET_EXTERNAL_TOOL in test mode Run program ECATT_GENERATE_ET_USER to generate service user Before you can use an external tool with eCATT, you must perform the following configuration steps: Declare the external tool to eCATT by running the function module SET_EXTERNAL_TOOL using the test mode in transaction SE37. If you execute the function module without entering any field values, the default values will be used. These default values set up the system to work with Compuware TestPartner. Run program ECATT_GENERATE_ET_USER from transaction SE38. This generates a service user that the external tool requires in order to communicate with eCATT. Regenerate the authorizations in role SAP_ECET. To do this, start transaction PFCG and open role SAP_ECET in change mode. On the Authorizations tab, choose Change authorization data. On the next screen, place the cursor on the role name and choose Authorizations -> Generate. Regenerate authorizations in role SAP_ECET

External Tool Integration - Architecture
Application Server Database eCATT Script with Attributes Scripts stored in SAP database Frontend External Tool Physical script commands Application Under Test When you create a script in eCATT, you can specify on the initial screen that the script should be created using an external tool. Scripts that you create in this way are the same as any other eCATT script – they are Repository objects, can be called from other scripts, and so on. However, within eCATT itself, you can only maintain the attributes of the script. To create or edit the script, you must start the external tool (by choosing the Script function from the script editor). Once the external tool has started, you can use it as normal to record and edit a script. When you have finished, you upload the external script to eCATT, where it is stored in the SAP database.

Using Compuware TestPartner to Record a Script
Checks VBA Functionality Parameterization Recording There are four steps to creating a script using Compuware TestPartner: Record the application Parameterize the input/output fields of the application Add any necessary VBA coding to the script Implement any necessary checks for your test case

Passing Arguments To and From TestPartner – Argument Container
eCATT Argument Container Script TestPartner scripts do not possess importing and exporting parameters. To pass data between eCATT and a TestPartner script, you use an intermediate object called an argument container. The argument container allows you to define importing and exporting parameters for a TestPartner script. You do this in TestPartner under the menu entry Tools -> SAP eCATT ->Argument Container. The importing and exporting parameters that you define in the argument container form the interface of the script. When you call the TestPartner script from within eCATT, you have the opportunity to fill them with values. TestPartner

Passing Arguments To and From TestPartner – Script Coding
Argument Container Name Type Direction ... I_Name String IMPORT ... E_Value String IMPORT ... Script: VBA Coding Sub Main () Dim ImportParam As String, ExportParam As String ImportParam = GetEcattArg("I_NAME") . . . SetEcattArg "E_VALUE", ExportParam End Sub Once you have defined importing and exporting parameters in the argument container, you can use them in your TestPartner script. To use an importing parameter from the argument container, you must assign it to a variable in your script using the following function: GetEcattArg( Name as String) As String To return an exporting parameter from a script variable to the argument container, use the function SetEcattArg Name as String, Value as String

Uploading Scripts Projects for upload Script name and version
Administrative settings When you have finished recording, editing, and testing your script, you can upload it to eCATT. Choose Tools -> SAP eCATT -> Save BLOB -> Save and Goto eCATT. In the dialog box that appears, select the projects that you want to upload. The entire contents of the project or projects that you select are stored within the script that you created in eCATT. Since this means that one eCATT script can contain several TestPartner scripts, you must select a primary project and primary script – that is, the script that will actually be executed when you call the external script from within eCATT. Choose Save to upload the resources to eCATT.

Calling External Scripts
REFEXT ( SCRIPT, INTERFACE, VERSION ). To call an external script from another eCATT script, you use the command REFEXT. In the REFEXT command, you specify the name of the script and its version. The command interface of the REFEXT command contains the importing and exporting parameters of the external script as you created them in the argument container within TestPartner.

In this unit, you have learned:
Unit Summary In this unit, you have learned: When to use TCD and SAPGUI, and when you have to use an external tool Why SAP chose to work with external tools The advantages of the external tool integration How the integration works

Unit 8: Building Executable Tests
Calling Other Test Objects Test Configurations and Test Data Containers The Test Workbench

Unit Objectives In this unit, you will learn: How you can modularize tests at script level The difference between a test script and a test configuration How to create test configurations How to manage test data

Modularization at Script Level
There are two reasons for modularization: To split up parts of a process into separate eCATT scripts to increase the possibility of reusing them To allow the integration of non-eCATT objects, that is External scripts Existing CATT procedures eCATT contains a range of commands that you can use to call other script objects. These can be divided into three kinds of scripts: eCATT scripts External scripts CATT procedures The fact that scripts can call other eCATT scripts allows you to build up a library of reusable scripts, each of which covers a small part of a business process. You can then create "master scripts" that call all of the elements necessary to test an entire process. eCATT scripts can also call existing CATT procedures. This gives you flexibility in deciding how and when to migrate your existing CATT procedures to eCATT.

Scripts can call other scripts: REF ( SCRIPT, INTERFACE, [TARGET]).
Create Order REF ATP Check REF REF REF Manufacturing The REF command allows you to call another eCATT script. In it, you specify the name of the script and a default target system if required. If you do not enter a default target system for the script that you are calling, the default target system of the current system will be used instead. The command interface of the REF command contains two sections – one for the importing parameters of the called script, and one for its exporting parameters. Billing

From eCATT, you can call CATT procedures residing in the same system:
REFCATT From eCATT, you can call CATT procedures residing in the same system: REFCATT ( CATT, INTERFACE, [TARGET] ). REFCATT ( CATT, INT, TGT ). TGT CATT Procedure REFCATT allows you to call an existing CATT procedure that is stored in your central test system. You may specify a target system in which the CATT procedure is to be executed. The command interface of the REFCATT command allows you to pass data to and from the CATT procedure. The results of the CATT procedure are contained in a CATT log. The log of the eCATT script that called the procedure contains a link to this log.

You can also call CATT procedures that reside in a remote system:
REMOTECATT You can also call CATT procedures that reside in a remote system: REMOTECATT ( CATT, INTERFACE, TARGET ). REFCATT ( CATT, INT, TGT ). EXE CATT Procedure in TGT REMOTECATT is similar to REFCATT, but allows you to call a CATT procedure that resides in a remote system. In the command, you specify the name of the CATT procedure and, in the TGT argument, a destination pointing to the system in which the procedure is stored. Within the command interface of the REMOTECATT command, you can specify a third system, in which the CATT procedure will be executed. This third system must be a logical target system from the current system data container. The RFC destination attached to this logical target system does not have to exist in the central eCATT system, but must be defined in system TGT (where the CATT procedure resides).

Script Test Configuration Data - Variants Importing Parameters
System mapping System data container Command <interface>, <target>. Although it describes the substance of a test, a test script on its own does not form a complete automated test. A complete test case is represented by a test configuration, which is based on a test script, but also contains a system data container, which tells the script where to execute the various commands, and one or more variants – sets of data with which the test script will be executed. To create a test configuration, choose the Test configuration radio button on the initial screen of transaction SECATT, enter a name, and choose Create. Test configurations must be assigned to a package and an application component.

Quick entry for a few variants
Manual Variants Quick entry for a few variants Cut and paste possible from delimited text file (Excel) Variants bound to a single configuration – not reusable On the Variants tab of a test configuration, you will see a grid. There is a column in the grid for each of the importing parameters of the script that you assigned to the configuration. Each row in the grid represents a single variant. You can enter variants manually. Equally, you can cut and paste variants from an external file into the grid. Note, however, that this only works 30 rows at a time.

Reusing Test Data: Test Data Containers
Variants Test data container Importing Parameters Script System mapping System data container Command <interface>, <target>. If you enter variants manually, they cannot be reused with any other configuration. You may also find that you are entering a lot of repeated field values. The alternative to this is to store data separately from test configurations in test data containers. These allow you to store data once-only in a central location, allowing you to reuse it in any number of test configurations that require that data. They also eliminate the redundancy caused by entering the same values in multiple variants because a single set of data, once entered, can be reused in any number of variants within the same configuration.

Test Data Container Parameters Variants
Name Value Ref System ABAP Type Length Airline LH S_CARR_ID Date D Variants Variant Description Airline Date Var1 Data AA Var2 Data LH Test data containers consist of parameters, which describe the interface of the container, and variants, in which the actual data are stored. You define parameters in the same way that you define script parameters in an eCATT script. Each variant contains a value for each parameter in the test data container. For data from a test data container to be assigned to a test script automatically, the source parameter in the test data container and the target parameter in the script must have the same name.

Test Script Test Data Container
Managing Test Data 1 Test Script Parameters P1 P2 P3 Test Data Container Parameters P1 P2 P3 The simplest use of test data containers is to create a separate one for each test script. However, this does not provide you with any of the advantages of reuse, and, compared with CATT, only doubles the number of objects of which you need to keep track.

Test Data Container Parameters P1, P2, P3, P4, P5, P6
Managing Test Data 2 Test Script Parameters P1 P2 P3 Test Script Parameters P1 P4 P5 Test Script Parameters P2 P5 P6 Test Data Container Parameters P1, P2, P3, P4, P5, P6 An alternative approach might be to have a single test data container that contains the parameters required by a whole series of scripts within a single application or sub-application. However, this can lead to very high numbers of parameters in the test data containers, making the whole thing hard to manage. You may also find that it does not eliminate the redundancy of data – one of the principal aims of test data containers.

. . . Test Script Test Script Test Script Test Data Container
Managing Test Data 3 Test Script 20 Parameters Test Script 15 Parameters Test Script 24 Parameters Test Data Container Parameter Group 1 Test Data Container Parameter Group 2 Test Data Container Parameter Group n The best approach to test data management is to analyze your test project and try to divide up the required data into logical groups. You can then create a whole series of test data containers for your project. You can link any number of test data containers to a test configuration and create variants by merging data from several sources. . . .

Configuration Variants
Variant Wizard Start variant wizard Test Data Container Configuration Variants Variants Variants In the variant wizard, the variants in the test configuration are displayed on the right-hand side. On the left-hand side are the various test data containers that you have assigned to the configuration. You can drag variants from a test data container and drop them into the configuration variants. The variants in the configuration contain references to the values in the test data container. Consequently, changes to the variants in the test data container are automatically applied to the corresponding variants in the configuration. The arrow buttons in the left-hand pane of the variant wizard allow you to scroll between the test data containers that you assigned to the configuration. To merge data from a test data container into an existing variant in the configuration, select one line in the left-hand grid, one line in the right-hand grid, and choose Add to variant.

Managing Test Data - Example
I_CARRID I_CONNID I_FLDATE I_FARE I_CURR I_TYPE I_MAX_E I_MAX_B... LH EUR LH EUR LH EUR QF AUD QF AUD Consider the example above – it is a transaction based on the flight data model for creating a new flight in the database. The user must enter a flight number, followed by details about the flight such as the date, fares, and type of aircraft to be used. From the grid in the graphic, you can see that much of the data can be combined into groups of parameters, and much of it is redundant. To avoid this, we can store the data in reusable test data containers as shown on the next page.

Managing Test Data - Example
Test Data Container AIRLINES Test Configuration Data for a particular test case Maximize reuse Minimize redundancy Test Data Container AIRCRAFT By storing the data required for tests in test data containers, you can Maximize reuse: The test data containers can be used with any scripts that require that particular data Minimize redundancy: If you look at the grid on the previous page, the entry ‘LH 400’ occurs several times. If you are using a test data container, you only need to store the combination ‘LH 400’ once. You can then reference it any number of times. If you needed to change the data for any reason, you would only have to change it in one place.

Modularization at Test Organizer Level
Test Catalog Test Plan User Test Package Test Configuration Test Configuration The Test Organizer is SAP's tool for creating and administering test projects. It is divided up as follows: A test catalog is a basic pool of test objects for a particular project. These might be eCATT test configurations, CATT procedures, manual test cases, or documentation objects. A test plan is a concrete test project, consisting of elements taken from one or more test catalogs. A test package is a subset of a test plan. It contains one ore more test elements, which are assigned to a user for execution. When users open their test worklists, they see test packages. From these test packages, they can either execute test configurations individually or execute the entire package. In this case, all of the test configurations in the package will be executed automatically one after the other.

In this unit, you have learned:
Unit Summary In this unit, you have learned: How you can modularize tests at script level The difference between a test script and a test configuration How to create test configurations How to manage test data

Versioning of Scripts Migrating CATT Procedures
Unit 9: Advanced Topics Versioning of Scripts Migrating CATT Procedures

In this unit, you will learn
Unit Objectives In this unit, you will learn Why script versioning is necessary How to create different versions of a script How the system picks the correct version of a script for execution How to migrate CATT procedures to eCATT

Versioning For different implementations of the same test (for example, transaction with / without controls), you can create different versions of the same script. There are many conditions that can invalidate a test script. For example: Changes to the screen sequence of a transaction Addition of new obligatory fields in a transaction Changes to the interface of a function module Re-implementation of an application (introduction of controls, implementation as a web application) When this happens, you must recreate your test script. However, instead of creating a new script, it is now possible to create a new version of the previous script.

How Versioning Works Test Configuration R/3 EC_DEMO EC_DEMOSYSTEMS R3
Version 1: SAP_APPL 46C Version 1: SAP_APPL 46C Script EC_DEMO Version 2: SAP_APPL 470 Sys. Data EC_DEMOSYSTEMS Target Sys. R3 Release? 4.6C R/3 Rel. 4.6C When you call a test script from a test configuration or using the REF command, you never have to specify the script version that you want to be used. Instead, eCATT interrogates the target system to find out its software components and releases. Based on this information, it chooses the relevant version to be used.

Specifying the Validity of a Version
Target System When you create a new version of a script, you must specify the software components (for example, SAP_BASIS) and releases (46D, 610, and so on) for which it is valid. eCATT uses this information to find the most appropriate script version when it executes a test configuration or a referenced test script. As soon as you have more than one version of a script, you must specify, individually, all of the releases for which it is valid. The only exception to this is that one script version may have the vaildity *. This makes it the default version, which is taken if there is no version that is explicitly valid for the actual release of the target system. Only one version of a script can be used for a particular release. eCATT cannot execute a script in a system with a release that has not been entered in the validity range of one of the script versions. For example, if version 1 of a script is valid in 4.6C and version 2 is valid in 6.20, the script will not run in a 6.10 system. The import and export parameters of a script are constant across all versions. The local variables of a script are version-specific.

Backup Versions Version 1 Version 2 Version 2 Version 3 SAP_BASIS 610
 Version 3 SAP_BASIS 620 You may, in order to preserve a change history, want to keep multiple versions of a test script that are all valid for the same release. Normally this is not allowed – there can only be one version of a script that is valid in any given release. Old versions of scripts that you want to keep but that have been superseded by a new version that is to be valid in the same release can be marked as backup versions. You do this by setting the Backup flag in the versioning attributes of the script. Once you have done this, a further script version can have the same validity as the script you flagged as a backup. Scripts marked as backup scripts are not considered for execution when eCATT determines the correct version to be used.

Test System Target System ‘X’
Migration Test System eCATT Migration Function Target System ‘X’ CATT Module CATT Module New eCATT Script eCATT contains a migration function that you can use to migrate existing CATT routines to eCATT scripts. In the simplest case, the CATT module resides in the eCATT system, and can be migrated “locally”. Equally, however, it is possible to migrate CATT modules from other systems. To do this, you must specify a system data container and target system in the migration dialog box. eCATT then looks in that system for the CATT module you specified. The migrated eCATT script is always stored in the eCATT system, regardless of where the original CATT module was located. Migrating a CATT module does not change or otherwise invalidate it. New eCATT Script With target system X

New eCATT Script with target system X
Migrating Variants Test System Target System ‘X’ CATT Module Variants New eCATT Script with target system X Test Configuration Script Target System X Variants If an existing CATT module contains variants, you can migrate them into a test configuration. The migration tool creates the test configuration with the same name as the new eCATT script and the same parameters as the CATT module.

Test System Target System ‘X’
Recursive Migration Test System Target System ‘X’ CATT Module REF… REF… New eCATT Script with target system X REF… New eCATT Script New eCATT Script with target system X When you migrate a CATT module, you can choose to migrate all other CATT modules that it references at the same time. If you do not choose this option, the existing modules are referenced from the new eCATT script using the REMOTECATT command. Remember that if you subsequently migrate the referenced CATT modules, you must change these REMOTECATT commands to REF commands manually. It is therefore a good idea to select the recursive migration option when you migrate the main CATT module.

Unit Summary In this unit, you have learned Why script versioning is necessary How to create different versions of a script How the system picks the correct version of a script for execution How to migrate CATT procedures to eCATT

In this course, you have learned
Course Summary In this course, you have learned What and when you need to test in the SAP Solution Lifecycle The advantages of eCATT for testing SAP systems compared with other automated test tools How to set up your system environment for testing with eCATT How to create test cases to test various different kinds of SAP applications How to create executable tests, and how these can be managed using the SAP Test Workbench How to migrate CATT objects to eCATT

Copyright 2005 SAP AG. 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 AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any form or for any purpose without the express prior written permission of SAP AG. This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document contains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. Please note that this document is subject to change and may be changed by SAP at any time without notice. SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the information, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence. The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages

Copyright 2005 SAP AG. Alle Rechte vorbehalten
Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Form auch immer, ohne die ausdrückliche schriftliche Genehmigung durch SAP AG nicht gestattet. In dieser Publikation enthaltene Informationen können ohne vorherige Ankündigung geändert werden. Die von SAP AG oder deren Vertriebsfirmen angebotenen Softwareprodukte können Softwarekomponenten auch anderer Softwarehersteller enthalten. Microsoft, Windows, Outlook, und PowerPoint sind eingetragene Marken der Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, und Informix sind Marken oder eingetragene Marken der IBM Corporation in den USA und/oder anderen Ländern. Oracle ist eine eingetragene Marke der Oracle Corporation. UNIX, X/Open, OSF/1, und Motif sind eingetragene Marken der Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, und MultiWin sind Marken oder eingetragene Marken von Citrix Systems, Inc. HTML, XML, XHTML und W3C sind Marken oder eingetragene Marken des W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. Java ist eine eingetragene Marke von Sun Microsystems, Inc. JavaScript ist eine eingetragene Marke der Sun Microsystems, Inc., verwendet unter der Lizenz der von Netscape entwickelten und implementierten Technologie. MaxDB ist eine Marke von MySQL AB, Schweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver und weitere im Text erwähnte SAP-Produkte und -Dienstleistungen sowie die entsprechenden Logos sind Marken oder eingetragene Marken der SAP AG in Deutschland und anderen Ländern weltweit. Alle anderen Namen von Produkten und Dienstleistungen sind Marken der jeweiligen Firmen. Die Angaben im Text sind unverbindlich und dienen lediglich zu Informationszwecken. Produkte können länderspezifische Unterschiede aufweisen. The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any form or for any purpose without the express prior written permission of SAP AG. This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document contains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. Please note that this document is subject to change and may be changed by SAP at any time without notice. SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the information, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence. The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages

ECATT VSDK 3.0 Version 2003/2 19/3/2003.

Similar presentations

Presentation on theme: "ECATT VSDK 3.0 Version 2003/2 19/3/2003."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

ECATT VSDK 3.0 Version 2003/2 19/3/2003.

Similar presentations

Presentation on theme: "ECATT VSDK 3.0 Version 2003/2 19/3/2003."— Presentation transcript:

Similar presentations

About project

Feedback