SE97 issue with ME22N calling itself

Question

Hi all,
we have created a transaction variant (ZME22N) which calls ME22N. Our goal is just change one field on PO.
As yet indicated in other posts in the forum, transaction variants have some truobles with ENJOY tcodes.
We are in a loop: ZME22N calls ME22N and it seems that, during the navigation, ME22N calls itself again.
I have debugged and found that in code CL_PO_HEADER_HANDLE_MM========CP there is:
CALL FUNCTION 'AUTHORITY_CHECK_TCODE'
Looking at the variables with the debugger, it's clear that the calling transaction is the same as the called one (in both case is ME22N).
Parameter auth/check/calltransaction is equal 2.
This means:
tcode = sy-tcode           | auth/check/calltransaction, default = 2
                           |       0       1       2       3
tcdcouples-okflag = X      |       n       j       j       j
tcdcouples-okflag = N      |       n       j       n       n
tcdcouples-okflag = ' '    |       n       j       n       n
kein Satz in tcdcouples    |       n       j       n       n
Looking into table TCDCOUPLES (with SE16) we have the couple ME22N - ME22N with X flag.
The solutions seems to be easy: just set as N the couple ME22N - ME22N in tcdcouples.
Even if the record for couple ME22N-ME22N in table TCDCOUPLES exists (looking with SE16), we are not able to maintain it with SE97 since the record is not displayed at all.
In a SAP IDES system, we have done a "trick" in order to set as N the couple ME22N-ME22N and all is working as expected: the transaction variant works perfectly.
Now, is there a good reason  for not forcing the flag as N for couple ME22N-ME22N ?
Why SE97 does not show the record when called and calling tcode are the same ?
Andrea
Edited by: Andrea Cavalleri on Jan 14, 2011 6:47 PM
Edited by: Julius Bussche on Jan 14, 2011 6:51 PM
Subject title made more meaningfull

Answer 1

On the right track, but wrong conclusion..
Take a look here --> Authorization missing for tcode ME22N.
Enjoy transactions are different. The transaction is not of much importance, but rather the application objects should be used consistently.
The SE97 mechanism was invented for the application coding to be able to react faster to a "call transaction" scenario than what the kernel functions can (e.g. via the ok-code field) but the check must be at the correct location on the application code - ideally the initialization events.
ME22N does "trust" some transactions (such as ME23N...) but if the tcode called = the current tcode, then it checks it again in the kernel. This special case is described in some SAP Notes (358122 and 1373111 and a few others about "Enjoy" transactions).
That SAP populated TCDCOUPLES for values which the function module reacted to anyway was not necessary (hence removed so that the kernel did not check them either at the time). Later, information type messages were corrected as well so that you could not just hit "Enter".
Conclusion: You cannot use variant transactions to obfuscate security for Enjoy transactions without disclosing that the user must have had some authoritity to get in there in the first place...
Here is a code snippet if you want to protect applications via a transaction authorization, regardless of how the user gets into running any of the code.
* User is calling from the outside...
  IF sy-tcode NE 'ZXITING_TOOLS'.
    CLEAR: sy-msgid, sy-msgty, sy-msgno,
           sy-msgv1, sy-msgv2, sy-msgv3, sy-msgv4.
    CALL FUNCTION 'AUTHORITY_CHECK_TCODE'
      EXPORTING
        tcode  = 'ZXITING_TOOLS'
      EXCEPTIONS
        ok     = 0
        not_ok = 1
        OTHERS = 2.
    IF sy-subrc 0.
      IF sy-msgid IS INITIAL OR sy-msgty IS INITIAL.
* External caller --> tell them to bugger off ... :-)
        MESSAGE i172(00) DISPLAY LIKE 'I' WITH 'ZXITING_TOOLS'.
      ELSE.
* They are on the inside, but should not be... so bugger off against all messages as well.
        MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
           DISPLAY LIKE sy-msgty
          WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
      ENDIF.
      LEAVE PROGRAM.
    ENDIF.
  ENDIF.
* Upfront authority-checks for the subsequent BAPI's, otherwise there is no sense in continuing further..
Cheers,
Julius