How to deal with generated programs in eCATT SAPGUI recording?

Question

Hi experts and professionals,
I am trying to automate testing of our solutions by eCATTs and so far i have not been able to find solution for following problem.
Whole test scenario is very simple:
Check InfoProvider data (query, lookup, listcube,...)
Create DAP on InfoProvider
Archive InfoProvider
Check InfoProvider data (query, lookup, listcube,...)  again
Compare results from step 1. and 4. (must match)
Reload archived data
Check InfoProvider data (query, lookup, listcube,...)  again
Compare results from step 1. and 7. (must match)
As you can see, one of the required test steps is to check InfoProvider's data in transaction LISTCUBE.
But transaction LISTCUBE generates its program "name" every time it is executed and
I am struggling to find a way how to deal with these generated programs in eCATT SAPGUI recording.
Key is that solution must be generic and work for all SAP BW releases from 7.0 upwards
(having in mind that LISTCUBE can read NLS data from SAP BW 7.3 release).
Error description from eCATT log:
Screen Check Error: Expected Transaction: LISTCUBE, Actual Transaction: LISTCUBE.
Expected Program: GP0KOZE7EFIUBN10MZUFWX90W80, Actual Program: GPBP24INA6VV77SL0XKU5NA642O.
Expected Screen Number: 1000, Actual Screen Number: 1000.
There Is Probably an Error in SAPGUI recording.
ExceptionClass:CX_ECATT_APL_CAPTURE  ExceptionId:SCREEN_CHECK_ERROR
RaisingClass:CL_APL_ECATT_LINE_INTERPRETER  Include:CL_APL_ECATT_LINE_INTERPRETER=CM00J  Line:443
Is there any way how to avoid program check in eCATT script?
Anything that would help me to find solution will be greatly appreciated.
Best Regards,
Igor

Answer 1

Dear Igor,
Your issue is caused by the "screen check" which eCATT processes here.
In General this screen check is a very usefull activity, since is ensures that only those screens are processed by automation, which initially where recorded. This should ensure as much as possible to invoke only intended activities.
Remember, that the driver of the screen flow is still the automated transaction program ( but not the test tool). So application logic decides which screen is send next.
Using screen check the test tool tries to ensure that menu items and buttons and other activities are only automated when the tool "believes" to work on the intended screen.
For generic test scripts and often in context of generated programs the screen check might hurt a bit.
To overcome this, one might try to make the check dynamic (as Sheetal suggests correctly).
If here the name of program cannot be determined for any reason, one can use another method and do following:
- Change the value of ProcessedScreen-Active to 'R'
This will disable/skip the screen-check for this ProcessedScreen.
Sure the solution includes a certain risk, since not checking the correct screen to appear might lead to automation of actions with not desired impact.
Maybe this can improve your solution.
Kind Regards
Jens