Simple eCATT Data Migration Example

My first experience with Extended Computer Aided Test Tool (eCATT) wasn’t much fun. In fact, I still cringe when I hear or say “eCATT.”

You don’t have to be a techno-wizard to take advantage of eCATT basics.

It would be fair to say that I still dislike eCATT. But the best SAP Functional folks are the best, in part, because they’re aware of every tool in their kit. And sometimes eCATT is the right tool for the job. In rare cases, it’s the only tool for the job.

You should know a bit about eCATT, even if you plan to avoid it, as I do.

My objective was to create a load program for Site Master Data Migration, and eCATT is the necessary and only tool for that purpose. Four days later I succeeded. Four days! Now I can perform the same task in about 15 minutes, including unit test. With this post as reference, you can do the same!

Example Use Case

eCATT is a generic tool that we can use to load data based on a screen recording. It’s helpful to illustrate generic tools with a specific example. To that end, I’ll use Site Master Data Migration to walk though the end-to-end process, and point out potential pitfalls along the way. You don’t need to read about Site Master Data Migration, but it’s good context for this real-world example.

eCATT Prerequisites

Before getting started, save yourself a lot of aggravation and work though the short list of prerequisites described below. You have to check these in every system-client in which you’ll execute eCATT. And check them again just before executing an actual data load.

The other prerequisite step — so obvious that it’s often overlooked or intentionally skipped — is manually unit testing the scenario before attempting to record it with eCATT. Manual execution is the only way to confirm that dependent configuration and master data are correct in the target system-client.

Basis Prerequisites

Cross-Client Object Changes

eCATT creation is a development activity, so you’ll be prompted for a Workbench Request when creating or changing an eCATT object. But to even get that far, such development activity must be permitted.

Using T-Code SCC4, ensure that Cross-Client Object Changes is enabled for repository changes the client in which the eCATT will be created.

T-Code SCC4: Cross-Client Object Changes

If you don’t have access to T-Code SCC4, then use T-Code SE16N to view table T000. Confirm that field T000-CCNOCLIIND (No Cross Client) is blank for the client in question. Possible values include:

  • Blank = Changes to repository / cross-client customizing allowed.
  • 1 – No changes to cross-client customizing objects.
  • 2 – No changes to repository objects.
  • 3 – No changes to repository / cross-client customizing.
Enable eCATT for the system-client

Using T-Code SCC4, ensure that eCATT is enabled for the client in which eCATT will be executed.

T-Code SCC4: eCATT Restrictions

If you don’t have access to T-Code SCC4, then use T-Code SE16N to view table T000. Confirm that field T000-CCIMAILDIS (CATT Allowed) is marked with an X for the client in question. Possible values include:

  • Blank = eCATT and CATT Not Allowed
  • X – eCATT and CATT Allowed
  • T – eCATT and CATT Only Allowed for ‘Trusted RFC’
  • E – eCATT Allowed, but FUN/ABAP and CATT not Allowed
  • F – eCATT allowed, but FUN/ABAP and CATT only for ‘Trusted RFC’
Enable Scripting on the Application Server
Use T-Code RZ11 to set parameter sapgui/user_scripting

Using T-Code RZ11, you can dynamically enable scripting by setting the profile parameter sapgui/user_scripting = TRUE. The value set using this procedure will be lost when the system is restarted.

Take care to log off and back on again for the change to take effect; the change does not apply to sessions that are currently running.

Basis should edit the application server profile of the SAP System to include sapgui/user_scripting = TRUE. By doing so, scripting will be enabled when the server is restarted.

SAP GUI Settings

User Profile Defaults

SAP GUI > More > System > User Profile > User Data

User Data > Defaults

This setting is important if your eCATT object will use dates or numbers. If your user settings are not the same during recording and execution then SAP GUI won’t interpret values correctly and errors will be raised. Choose consistent settings for creating and executing eCATT.

SAP GUI Security and Scripting

SAP GUI > More > SAP GUI settings and actions > Options

SAP GUI Options > Scripting

Scripting must be enabled for the user. Uncheck the notification options to avoid nag screens.

SAP GUI Options > Security

Disabling security here also avoids nag screens that are displayed when source data files on your local PC are accessed by SAP GUU and eCATT.

eCATT Settings

T-Code SECATT > More > Utilities > Settings

So-called “variants” are the rows of data in source data files. When creating the eCATT, choose a path such as C:\DATA that everybody is likely to have available. Then use that path consistently so that the eCATT need not be changed to accommodate different expected paths.

Strategy and Constraints

You’re going to avoid a lot of trouble by understanding this eCATT Command choice, which must be made up front.

Spoiler alert: Our example requires SAP GUI Recording because transaction WB01 uses ActiveX controls. That’s why eCATT is mandatory for this use case and why Legacy System Migration Workbench (LSMW) is not an option for Site Master Data Migration.

Multiple options exist for recording a T-Code as the basis for an eCATT test script.

From the eCATT documentation, here’s the decision tree:

eCATT help (for Testing Applications) explains which command mode to choose.

The recommendation is to use TCD, especially for those transaction that do not use Active controls. But that option won’t fit our use case.

TCD recording (executed in background) is about 50 times faster to execute than SAP GUI recording, which must be executed in foreground.

In case you’re wondering about foreground performance, I’ll share some metrics. For this example use case, an eCATT based on SAP GUI recording will create about 30 Site Masters in 7 min 6 seconds (426 seconds), which is about 14.2 seconds per site. If you had 2,000 Site Master to create, that would be about 7.8 hours of run time. In this real-world example, we split the input data into two files and ran the same eCATT on two computers simultaneously, finishing in half the time.

Create a Test Script


The eCATT Test Script includes the SAP GUI screen recording, which is called a “Pattern.” It also includes a list of Parameters that will supply values to the on screen fields. Data for the Parameters can be supplied from a list of so-called Variants, which can be supplied by an external data file.

Pattern, Parameters, and Variants. These are likely three new words, but with familiar meanings.

An external data file with rows for each record (Variants) includes fields (parameters) that will be supplied to the screen recording (Pattern) as the screen recording is executed for each row of source data.

Create a Test Configuration


The eCATT Test Configuration points to the eCATT Test Script, the external data file (with its data for Variants), and includes other settings for execution.

Prepare Data for Unit Test

Here’s a tricky bit that caused a lot of frustration until I learned about this eCATT quirkiness.

You’re going to prepare conventional Load-Ready files to serve as input to the data migration process. That means tab-delimited files with a header row consisting of tab-delimited field names.

The field names in the header row match the Parameter names in the eCATT Test Script. The order of the fields in the source data is not important; eCATT will map the source fields to the Parameters by matching the field names and Parameter names.

Conventional tab-delimited data file with field names in first row.

The above image, using Notepad++, shows a typical example of such a tab-delimited Load-Ready file.

Here’s the eCATT quirk: Fields VARIANT and DESCRIPTION must be present and surrounded with square brackets:

eCATT demands that the first two fields are VARIANT and DESCRIPTION and they must be surrounded with square brackets.

These fields are the unique identifier and description for each Variant. In this example, I’ve redundantly populated VARIANT and DESCRIPTION with the Site Number (WERKS), which is the primary key for each variant.

Execute Unit Test


For unit test you execute the Test Configuration.

This example runs in the foreground, not as a background job. There is no other option.

For reliability, reboot your PC and close all programs that could cause a message to appear on screen.

When executing the Test Script, there are a few options that require your attention with respect to UI Control.

Use these UI Control settings when executing the Test Script.

In particular, choose the option for Close GUIs: Do Not Close Sessions with Errors. This ensures that when an error occurs during execution the error remains on screen so that you can see what went wrong.

eCATT example in action

(12:32 Minutes)

Watch a real-world eCATT be created and unit tested in just 12 minutes!