SAP Retail Site Master Data Migration requires using eCATT, which is a mystery to most folks. Not any more!
Whether you’re a master data architect guiding the way, or a technical resource tasked with making it work, this Blog lets you fly past eCATT idiosyncrasies and prerequisites.
The icing on the cake? A 12-minute video demonstrating end-to-end eCATT creation and execution of unit test.
Years ago, I confess that same eCATT took me 4 days to create! Now you can do the same in 12 minutes … or thereabouts.
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.
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.”
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!
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.
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.
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.
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:
Using T-Code SCC4, ensure that eCATT is enabled for the client in which eCATT will be executed.
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:
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 > More > System > User Profile > User Data
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 > More > SAP GUI settings and actions > Options
Scripting must be enabled for the user. Uncheck the notification options to avoid nag screens.
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.
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.
You’re going to avoid a lot of trouble by understanding this eCATT Command choice, which must be made up front.
From the eCATT documentation, here’s the decision tree:
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.
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.
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.
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.
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:
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.
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.
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.
Okumaya devam et...
Whether you’re a master data architect guiding the way, or a technical resource tasked with making it work, this Blog lets you fly past eCATT idiosyncrasies and prerequisites.
The icing on the cake? A 12-minute video demonstrating end-to-end eCATT creation and execution of unit test.
You don’t have to be a techno-wizard to take advantage of eCATT basics.
From 4 Days to 12 Minutes
Years ago, I confess that same eCATT took me 4 days to create! Now you can do the same in 12 minutes … or thereabouts.
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.
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.”
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 paramter 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.
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
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.
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.
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.
Okumaya devam et...