SE97 issue with ME22N calling itself

[former_member577095]

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

[Former Member]

This is intentional and there is no way around it - you cannot use these "Enjoy" transactions to create variant transactions of them without giving access to the core transaction.

If you turn the SE97 check to 'N' you will see the first screen, but it will issue and error. Any attempt to do anything else will exit the transaction.

This behaviour is a bit otf a pain sometimes but is IMO correct. If you only want to have one variant transaction, then you can consider making a transaction variant for ME22N itself and change that screen. Then ZME22N can use the standard (unrestricted) screen. There are a lot of things to check first though (e.g. batch-input calls, other parameter and variant tcodes, screen exits, etc, etc).

Cheers,

Julius

[former_member577095]

I understand but we do not modify the transaction logic.

Looking at the ABAP, nothing will change except that is not more necessary to have ME22N in S_TCODE user's authorizatons.

We did some tests and everything works perfectly.

Since in TCDCOUPLES exists the couple ME22N-ME22N, it should be possible to modify it.

Andrea

Edited by: Andrea Cavalleri on Jan 14, 2011 7:02 PM

[Former Member]

nothing will be change except that is not more necessary to have ME22N in S_TCODE user's authorizatons.

Well then... you might as well give it to the users then...?!?

Or are you only trying to hide it from some stupid auditors who still check S_TCODE authorizations together with the real authority to use the transaction? I am only asking because I have seen this done often enough...

Cheers,

Julius

[Former Member]

I think there are some entries(TCODE=CALLED) in your TCDCOUPLES table which need to be removed.

check SAP Note: -515130, you can use the report mentioned in it and remove the TCODE=CALLED entries.I personally think SAP should update the solution provided in SAPnote: 410622 (change the entris to N) with the solution in 515130. not sure, may be there might be a better reason why it is still not updated. 515130 explains you why you are not seeing these TCOCDE=CALLED entries from TCDCOUPLES in SE97 for maintainence.

SE97 pulls all entries of TCDCOUPLES with an exception of CALLED equal to TCODE in TCDCOUPLES.that is why you do not see ME22N calling ME22N entry for maintainence in SE97.

Its my understanding that, TCODE=CALLED entries are some of those entries which came into TCDCOUPLES table when AUTHORITY_CAHECK_TCODE(i guess 4.6C) used to populate the missing entries in TCDCOUPLES if there isn't one when AUTHORITY_CHECK_TCODE is encountered during runtime. Later on(after 4.6C), AUTHORITY_CHECK_TCODE was changed not to populate entries in TCDCOUPLES anymore. and SAP provided 410622,515130 to overcome the errors we get because of TCDOE=CALLED entries.

Once the TCODE=CALLED entries are removed using the report, system shouldn't check for ME22N(default behaviour when sy-tcode= tcode, based on 515130)) at the start. but it will certainly check if it is called from some other transaction which is called within ME22N(for example, if you go from ZME22N to ME21N and comeback to ME22N, then system will and should consider ME21N's tcdcouples for ME22N ).

I never tried the report in the SAPnote, so you might have to do some more research or some tests with manually deleting one entry and giving a try.Julius or anybody, Correct me if I am wrong anywhere.

[Former Member]

On the right track, but wrong conclusion..

Take a look here -->

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

[former_member577095]

First of all thanks for your contribution!!

For Julius, our goal is just solve a business requirement. From auditor point of view, we are talking about called transaction. In our case, ME22N will have to be in S_TCODE user's authorizations when start ME22N directly. Consider also that there are 4 more authority check over S_TCODE in ME22N.

In TCDCOUPLES there are thosands of called transaction with flag = N. The auditors should take care of this too.

SAP provides the way to set auth/check/calltransaction parameter = 0. This means that all called transactions are automatically authorized. I will never suggest to set auth/check/calltransaction=0 but, if a customer decide to do it, ME22N (and all Enjoy transactions) must work anyway since this is not a trick. SAP permits to put auth/check/calltransaction=0.

To set the couple ME22N-ME22N in TCDCOUPLES = N is the same action as set auth/check/calltransaction=0 but works for just one tcode (and not all).

Andrea

[Former Member]

Try to set the SE97 flag to "No check" on it's own context and let us know whether that works for ZME22N.

I will eat my hat if it does...

[mvoros]

Hi,

probabl;y you've already done this but are you sure that you have have a transaction variant for ME2XN? There is a standard BADI which usually covers all normal cases. If you are on Netweaver then you can also use enhancement framework.

Cheers

[Former Member]

>

> 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 ?
> 

If you look at SAP note 515130 as already mentioned by Keerti - it states that tcode = sy-tcode check has been deactivated by default as of 4.6 C and you can explicitly activate it for the relevant transaction by making an entry in transaction SE97 with tcode = called and okflag = Y. In your case okflag as N.

Also not sure what trick you used to set it N but the SAP Note anyway gives you a report through which you can remove all those entries where tcdcouples-tcode = tcdcouples-called.

The older note 410622 also gives a report to set okflag to N.

Edited by: Nishant Sourabh on Jan 17, 2011 7:42 PM : Added statement - as already mentioned by Keerti.

[Former Member]

>

> you can explicitly activate it for the relevant transaction by making an entry in transaction SE97 with tcode = called and okflag = Y. In your case okflag as N.

>

I just tried to Modify SE97 to add ME22N as New Called Transaction and it gives error message that is Calling transaction = called transaction is not allowed.

So the statement above will not work in case of tcode = sy-tcode.

[former_member577095]

When I have tried to add couple ME22N-ME22N, using SE97, I have understood that the entry was yet present reading the error message: "I was trying to duplicate an entry".

Using SE16, browsing TCDCOUPLES tables, I have seen that the record was existing.

Using SE16N, if you write the command "&SAP_EDIT" in the command field, you enter in a special view in which you can modify the records. Of course this is a trick and we did it on a IDES system.

In such way, I was able to set the flag as N for ME22N-ME22N.

I did some tests and the transactions variant works as desiderd. Now is no more necessary to authorize the user to the CALLED ME22N.

Andrea

[Former Member]

Are you on 46C?!

That is just the application UI of SE97 warning you that you are about to do something stupid and reacting to it by exiting.

You then promptly did that stupid thing in SE16N. Tools like that in the hands of people without sufficient knowledge to use it is why SAP have removed it again - it seems that there weren't any...

The reason why I say that is because the real check is in the kernel, and neither authorization to debug (your case) nor knowledge to actually use the debugger will help you get past that check at runtime.

Try it on an ECC 6.0 system please? You will get to the first screen of ME22N but you will not get further nor be able to do anything in it.

Cheers,

Julius

Edited by: Julius Bussche on Jan 17, 2011 10:01 PM

Release dependencies added.

[Former Member]

In my opinion using &SAP_EDIT in SE16N to set flag as N is actually not a good idea. If I am not wrong SAP has provided a SAP NOTE to eliminate this feature actually.

I would think using the reports given in SAP NOTE to set it to N (if you are on 4.6C ) or removing the entries with the other report is better and safer option.

just my 2 cents..