Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

How to deal with generated programs in eCATT SAPGUI recording?

Former Member
0 Kudos

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:

  1. Check InfoProvider data (query, lookup, listcube,...)
  2. Create DAP on InfoProvider
  3. Archive InfoProvider
  4. Check InfoProvider data (query, lookup, listcube,...)  again
  5. Compare results from step 1. and 4. (must match)
  6. Reload archived data
  7. Check InfoProvider data (query, lookup, listcube,...)  again
  8. 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

1 ACCEPTED SOLUTION

Former Member
0 Kudos

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


3 REPLIES 3

Former Member
0 Kudos

Hello Igor,

As I can see , only the program name is changing while the rest of it remains the same.

If somehow you can read the program when it is generated, you can simply pass it to your SAPGUI recording.

What you can do is parameterize the program field in each of the SAPGUI interface where this is being called. Then assign the newly generated program name to this parameter.

Hope it answers your question.

Best Regards

Sheetal

Former Member
0 Kudos

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


Former Member
0 Kudos

Thank You for your advice. It guided me to correct solution for this problem.

Best Regards,

Igor