This article lists the main guidelines for setting up your eCatt scripts. Topics you are bound to experience for yourself, high level and detailed, with a short explanation of how and why. First of all, there should be a clear understanding of how scripts are best set up. The best way to work is differentiate in high-level scripts or master scripts and detailed step scripts. The detailed steps can be executed as seperate blocks, reusable in several master scripts. So: a script can call (reference) a script can call a script (up to about 6 or 7 levels). It's thus not very difficult to turn an eCatt script into a very complex monster....
The following guidelines should help you develop healthy eCatt scripts:
Master scripts
Always work with an overall script or master script which calls (references) lower level scripts. It's an effective way to ensure the overview, even for longer scripts. Master scripts should stand out utilizing naming conventions (e.g. use the word MASTER or MSTR).
Stop derailed scripts
When your script has performed a step with an unexpected result, make sure the rest of the script is not executed. Avoid problems using the EXITstatement. This will make pinpointing the problem easier and this will also ensure the right problem gets all the attention.
Checking data
lot of the problems your test script will be exposed to is going to be about missing test data or incorreclty set up master data. The specific requirements on your test data can be checked in a bit of ABAP coding, which is a very effective way to put knowledge about the test data in your script. Thus instead of a derailed script, you can report a message stating that the data is not set up as expected. The check script is typically an ABAP coded script that performs a suite of checks.
The error message
However great the eCatt logs are, its generally a good idea to have all scripts and subscripts work with an error message. A simple variabele stating what went wrong, which will of course be available on the eCatt log as well. Leave the error message blank if nothing went wrong !
Actual testing: keep track of the eCatt log number
As eCatt's are run from the development system, the eCatt log number is all you need when someone wants you to look at eCatt results. This number is golden and should be the very first thing made available to you when problems are brought to your attention. Also: when test results are logged in a system other than SAP, the eCatt log number is the key.
Create your master data
When you're familiar with Idocs and they are utilised on your project, you can use Idocs to create your test date "On the fly". Prepare an Idoc in ABAP memory, fill in all required segments & fields (again in ABAP memory), feed the result to function module IDOC_INBOUND_WRITE_TO_DB to store it as an Idoc and start inbound processing for the Idoc by calling IDOC_START_INBOUND. If Idoc processing is set to "Process immediately" the Idoc should have created your document withing 15 seconds. Simply look up the EDIDS message to determine e.g. the purchase order number that was just created. When Idocs are not processed immediately, transaction BD87 should run to move the Idoc from a status 64 to status 53 (or 51). Alternatively, base your TCD on program RBDAPP01 or set up a SUBMITfor it ..
Waiting for it
For a lot of steps, the system will consume some time. So making the script pause for a few seconds is never a big deal. The eCatt WAIT statement is your friend, please use it wisely. Don't bother with reading locks or checking table updates in a loop (in ABAP), just pause using the ABAP WAIT UP TO xx SECONDS statement. Remember: the performance of an eCatt is a whole different ball game compared to the performance of actual ABAP developments.
Keep the status bar alive !
When running an eCatt, the status bar will keep you up to date on progress. When ABAP coding is executed - you can inform your end user using function module SAPGUI_PROGRESS_INDICATOR. Especially when main function modules are called (Idoc processing modules or BAPI's) or when a WAIT UP TO xx SECONDS statement is called, make sure it's preceded by a call to SAPGUI_PROGRESS_INDICATOR.