Skip to Content

There is a complex exit-handler in the IQS0 code that runs the standard IW22 transaction.  The reason why this exit-handles is complex is as follows.

 

1) In configuration, you can define a custom tab for IW22 and place from 1 to 5 custom subscreens on this tab.

2) There is a dynamic loop in the SAP exit-handler which “knows” how many subscreens you’ve placed on the custom tab, and loops the correct number of times to call the each subscreen in succession.   This loop fires during output, so the PBO for each subscreen is called in sequence, and also fires during input, so the PAI for each subscreen is called in sequence.

 

OK – so suppose you have an input-enabled field on subscreen 1 with an edit of this field in the PAI for subscreen 1;

You deliberately place bad-data in this field and then click on a different tab than the one the subscreen is on – i.e. one of the standard SAP tabs for IW22.

 Here’s what happens:

 

3) your custom edit detects the bad data that you’ve entered in subscreen 1 and fires the “E” error message, which appears correctly at the bottom of the main screen.

4) But when you hit “enter” to clear the error message, the system automatically pops the tab that you selected – it doesn’t give you a chance to correct the data.  (It doesn’t leave the bad data – it just replaces it with the default data … you can see this is true because when you return to the custom tab after visiting the standard SAP tab that you selected, the bad data is gone.)

 

Now … I can understand why (3) and (4) are happening – after the PAI of subscreen 1 fires, SAP detects the fact that you’ve selected a different tab … so when control  returns to the SAP exit-handler loop, this loop does what it’s asked to do – it takes you to the tab you’ve selected. 

Becaue the SAP loop doesn’t know or care that there’s an error condition on subscreen 1 that has to be reset – it only knows it’s been asked to switch tabs.

Suppose I’m correct in the above analysis, and that there is no way to adjust your custom code to prevent the SAP code from operating the way it does,

Does SAP owe its customer base a free-fix of the apparent over-sight in the SAP exit-handler?

Or would SAP be within its rights to say – “hey – this is a customization issue – you’ve got to pay for the fix” (even though the oversight/error is only in SAP code)?

What do you think?

To report this post you need to login first.

9 Comments

You must be Logged on to comment or reply to a post.

    1. David Halitsky Post author
      to respond exactly as it is.

      Also, there is another subtlety to this problem which may actually help to clarify it.

      The case I outlined results from the user choosing to switch tabs before hitting ENTER after entering bad data into the field.

      But there is a second similar case that can be fixed because the code is under my control, not SAP’s.

      Suppose instead of choosing a different tab, the user hits a pushbutton on custom subscreen 2 of the custom tab (not the same subscreen as the input field is on – that’s custom subscreen 1.)

      Furthermore, suppsoe this pushbutton pops the full-screen SAPScript editor.

      Then if I don’t code anything special, the system will respond the same way as described above – it will pop the error message and then when you hit ENTER to reset the message, the system will pop the SAPScript editor.

      Now in this case, the PAI code for subscreen 2 is under my control, so I can prevent the odd behavior by setting a flag when the error condition is detected on subscreen 1 (in the PAI for subscreen 1) and then checking this flag in the PAI for subscreen 2 – if the flag is “on”, then I exit instead of popping the editor and everything is fine.

      But in the case initially described, processing of the user request to switch tabs is under SAP control (not mine), so I can’t do anything similar without getting an access key and hacking the SAP code … which I have sworn to never do as a consultant …

      Of course, if I was like a lot of consultants out there, that’s exactly what I’d do … if only to guarantee a future maintenance call-back …

      Best regards as always …
      djh

      (0) 
  1. Dushyant Shetty
    …and would love to know SAP’s take on this…
    But the ABAPer in me is itching to ask you some more questions on this, let me keep this simple,
    I assume the Tab switching user action is handled(as usual) through evaluation of the Function Code of the Tab(clicked by the user), in which case:
    1) The OK_CODE should contain the FCode of the chosen Tab and
    2) tabstrip-activetab should still contain the Fcode of the previous Tab(the one on which the error was detected)

    Can you not, just before you use the ‘E’ message,
    programmatically set OK_code back to the old value?

    ok_code = tabstrip-activetab.
    The tabstrip should then behave as if the user clicked on the same tab, as the one on which the input error lies…

    Sorry if I missed the point altogether :-p

    Regards,

    Dushyant

    P.S. I did not really look at the screen and assumed the names OK_CODE and TABSTRIP…

    (0) 
    1. David Halitsky Post author
      I have been discussing a related problem with this tab/subscreen exit down in ABAP General, and I told him that after the code moves to QA (yesterday), I will try his suggesation for that problem in BFD.

      I will also try your suggestion for this problem, but here is why I am doubtful.

      Moving from tab to tab is under SAP control, not control of the code in the user exit.

      So I actually am not sure if tabstrip-activetab is actually made available to the user exit.  If I look at the exit parameters, there is only a data table being passed to the user exit.  (I get the other data the exit needs by calling the generic SAP function READ_NOTIFICATION_BUFFER.)

      If tabstrip-activetab is not available to the user exit, then the exit code cannot get it even if it is declared as a global in the “TOP” of the IQS0 or MIW0 function groups – because the exit code fires out of the XQQM function group that contains all the exit includes.

      But if tabstrip-activetab is some kind of system global available at any time while IW22 is executing, then your method might work.

      Although I will try it and report back the results here, the question still remains as to whether this is an issue that the customer needs to solve by a “hack” such as the one you suggest, or whether SAP should step up to the plate and rationalize the process.

      I’ve been told by a member of the functional team that the SAP PM functional classes are full right now, indicating that more clients are getting more actively involved in PM. 

      If this is true, then there may, of course, be more chance of SAP fixing various minor oversights in PM, of which there are a number.

      Not to mention the old SO_OBJECT_MANAGER code, for customers whose non-URL PM attachements are still in table SOFFCONT1.  In the course of stealing some of this code, I found a note from an SAP programmer which read something like:

      “hack to compensate for known bug in KPRO”

      Doesn’t exactly give you a warm fuzzy feeling, does it ????

      But meanwhile, the “beat goes on”, so maybe all these problems will go away once the PM IW transactions are all converted to WDA/J and SOA services for back-end data-retrieval … heh heh heh …

      (0) 
    2. David Halitsky Post author
      …if SAP DID make tabstip-activetab available for customer manipulation in an XQMM exit, since this would imply that customers could hack the standard SAP IW22 navigation any way they wanted.

      And I would be amazed if allowing customers to hack standard SAP navigation inside an SAP transaction is an objective that SAP really wanted to achieve by providing the low-level subscreen exit capability inside XQQM.

      Regards
      djh

      (0) 
    3. David Halitsky Post author
      As I suspected, “tabstrip” is not available to the exit code in XQQM.

      But – sy-ucomm IS available, so here’s what I did.

      In the scenario I described, sy-ucomm reads ’10\TAB02′ at the time the error check fires – this is the standard SAP tab that the user wants to go to.

      So I changed this to ’10\TAB19′, which should tell SAP to stay on the custom tab where the error is encountered.

      And guess what – SAP did NOT recognize the change !

      So there appears to be no possible customer hack along the lines you suggested.

      But even if I could change sy-ucomm and get it to work, I would fire myself off the contract if I actually did so … and I hope everyone else feels the same way.

      Regards
      djh

      (0) 
      1. Dushyant Shetty
        Hmm I realized that later…
        Actually after I posted the earlier comment, (which I posted before my morning coffee!), I realized we’re dealing with Customer Exits here and the tabstrip would be inaccessible to our code.
        And yes, like you, I am not comfortable about changing the SAP delivered flow, at any cost… unfortunately I don’t find many others who think the same way, for most developers I have met, a Modification Key is just another string!

        Good luck,

        Dushyant Shetty

        (0) 
        1. David Halitsky Post author
          In fact, we just had a case at my current client where a contractor (not from the company I work for) convinced the client to give him a key for an SAP include and the client wound-up having to pay SAP Consulting for a day or so of “find it” time.

          In the words of Pete Seeger, the old “Commie” folksinger from the US …

          “When will they ever learn?
          When will they ever learn?”

          http://www.arlo.net/resources/lyrics/flowers-gone.shtml

          (0) 

Leave a Reply