Simple eCATT Data Migration Example

blog.masterdataaficionado.com/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

1/9
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:

2/9
 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

3/9
 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

4/9
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.

5/9
 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.

6/9
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

Use T-Code SECATT

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

T-Code SECATT

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.

7/9
 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

T-Code SECATT

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.

8/9
 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!

9/9