ECATT, SECATT or CATT has been a popular method with security consultants to automate various tasks. Its not the only tool used for automation and can be considered to be another option available in our arsenal. Till date I have purposely refrained from adding any post about SECATT as almost everything that you can do via SECATT can be done via LSMW which has been already mentioned on the site. Also, documentation around SECATT is fairly ubiquitous on the internet and I did not think that adding the same information here will make any difference. Recently however, I came to use another feature of the ECATT tool which is not as popular among us security consultants and which can actually let us do things which couldn’t do as easily before. So here goes the first post for the new year…. and Happy New Year 2014 for everyone. May this year be better than the last.
ECATT is short for Extended Computer Aided Test Tool and was introduced as part of SAP R/3 4.7. It added multiple new features from SAP older CATT application which was used till that time. ECATT can be accessed within the SAP system via the transaction SECATT and the terms are used interchangeably by most sources. First and foremost we should realize that ECATT is a testing tool which we are using to make mass updates to SAP data. In production clients, there is a client setting (transaction SCC4) which stops people from running ECATT. This is one of the reasons why a lot of consultants use LSMW instead. Please continue to use which ever option you are more comfortable with as each come with its own features and limitations. Since ECATT is a testing tool, the initial object it deals with is called a Test Script. The screen below shows the ECATT cockpit available in EHP6 and has changed a bit from the earlier ECC 6.0 screen.
To create a test script we specify a name for the script and click the create button. In the next screen, we add some attributes of the script being developed and save it. Since scripts are transportable object, you will be prompted to specify a package to contain the script. I have never transported SECATT scripts as such I always save them as local objects. Once the attributes are saved we go to the more important portion of the test script as shown below.
We start writing a test script by clicking the pattern button. ECATT comes with own coding language which is similar to ABAP but still significantly different. The use of the pattern button is to insert any of the various ECATT statements into our script. Typically, a security consultant using ECATT to automate tasks would use the patterns for recording tcodes or gui key strokes.For tcode recording which has a faster performance, you specify the tcode you want to record (SU01 for example) and go ahead and record the steps in the tcode you want to automate. For many of the patterns including the pattern for TCD recording, ECATT adds something called a “Command Interface” within the script. In general terms the command interface is a wrapper around the data that is used to execute the command. In the case of the more common TCD recording, the command interface, stores details for the various screens that are called by the tcode and the values of the various input fields that are used in those screens.
As promised however we will not use ECATT to record or test a tcode. Instead we would use ECATT to test an ABAP function module. The function module in question is used to change a user’s password when the user first logs into the SAP system. As such for the function module to work, the user in question must be a dialog user and one whose password has been reset, i.e. the password status is initial. Please note the difference between resetting and changing the password for a user. When the password of a dialog user is reset through SU01 or through a transaction recording of SU01, the user would be prompted to change the password during first login. The script we would be building using the function module is meant to change these reset passwords so that users are not prompted to change them when they login. At first look this ECATT script might appear to have no practical implications. But I often run into a situation during integration testing cycles where the same test ids (users) are used by a big team of testers. In such testing cycles, we don’t want each tester to change the passwords for test ids to their own favorite password and create problems for other using the same user accounts. There are also test cases where using service accounts (note that service type users are not prompted to change their passwords during login) is not an option. Its in these cases that the ECATT script under discussion becomes a lifesaver.
Now onwards with the rest of the steps used in creation of the script. To call a function module we use the pattern FUN as shown below. The command interface of the statement is also highlighted.
As can be seen in the screen, the FUN pattern also comes with a command interface which is basically the import, export and table parameters of the function that has been defined during creation of the function module. During script creation we have an option of specifying default values for these function parameters, ECATT internal variables or external parameters. Actual values are specified within single quotes while variables don’t have quotes in their names. Since variables can take different variables during run-time, we use variables for the parameters which would change for each execution cycle of the function module. In the current scenario we use Import Parameters for User Account, the old password and the new password. The screen below, shows the prompt when we try to enter a variable in the command interface.
To see the full set of import parameters or internal variables used by the script, we can use the toggle switch shown below. The toggle switches between the command interface screen to the variables screen.
To test our script, we specify the values of a user account that we would want to change the password for, the old password for the user, the new password save our entries. We would now execute the script by clicking the execute button. This takes us to a screen where we an change different start options for the script. For a simple script like ours we can just keep the defaults and again click the execute button.
After execution, we are taken to ECATT log screen which shows whether our script worked as it should have. If for some reason it did not, please read through the errors as most times, the description of the errors are good enough to troubleshoot what went wrong. Also, I have come across a lot of folks complaining that ECATT doesn’t work properly on EHP6.If you encounter these problems, my suggestion would be to look at service marketplace as there seems to be existing messages around what works and what doesn’t.
At this point, the script should be ready for use. However the main reason why we would want a script in the first place would be to change a number of users in mass, not for the single user as has been tested here. The solution to this is creation of a subsequent “Test Configuration” object for the script we just developed. The process is simple but I would create a follow-up post on that. Most importantly this post doesn’t even attempt to be a comprehensive guide to what all is possible within ECATT. Its just meant to be a starting point so that new users of ECATT can start getting their feet wet. There are huge possibilities of what can be done within ECATT. Its only our imagination which limits the possibilities. Happy scripting!