HRASR00_UI 221 Message

Bratzler, Loren loren.bratzler at nscorp.com
Mon Jan 27 11:03:24 EST 2014 

Greetings Again,

I wanted to post a follow-up to this.  We finally got a resolution to our problem and this is something that you all may want to file away for future reference in case any of you run into this problem like we did.  Sorry for the lengthy explanation below but I wanted to get this out there for everyone to see.  Keep in mind that this problem only affects HR related workitems.

Quick recap:  After applying HR Support Packs in December, we had several users report that they were getting a new authorization error message when they tried to launch an HR Form from the UWL (see the details in my original email below).  We could not reproduce the problem in our QA system so we opened on OSS Message with SAP to get their assistance.  We asked SAP to tell us where this new message was coming from but they did not answer that question.  Instead we spent nearly two full weeks going back and forth with them trying to reproduce the error so that they could debug it.  Finally after many failed attempts to reproduce the error, we finally convinced SAP to tell us where the new message was coming from.

The new message was located in Web Dynpro HRASR00_PROCESS_EXECUTE.  The message was coming from the WDDOMODIFYVIEW method of view PROCESS_START.  They said this new message was added as part of SAP Note 1898458.  Below is the code that was added:

****NOTE: 1898548**** "To check if the user trying to launch the workitem is authorized user or not"
 CALL FUNCTION 'VIEW_GET_CLIENT_STATE'
    IMPORTING
      client_state = client_state.
 IF client_state = 'P'.
  IF wd_assist->url_workitem IS NOT INITIAL.
    CALL FUNCTION 'SAP_WAPI_CREATE_WORKLIST'
      EXPORTING
        USER                 = SY-UNAME
        LANGUAGE             = SY-LANGU
*       IM_STATUS_FILTER     =
        PASSIVE_SUBSTITUTION = 'X'
      TABLES
        WORKLIST             = lt_worklist
        WORKLIST_ATTRIBUTES  = lt_message.

  READ TABLE  lt_worklist with key wi_id =  wd_assist->url_workitem TRANSPORTING NO FIELDS .
    IF sy-subrc <> 0.
      wd_this->is_not_authorized = wd_assist->true.
    ENDIF.
   ENDIF.
  ENDIF.
****NOTE: 1898548 ENDS****

The first thing I noticed was the Client State check.  This new code only gets executed if you are running in a Production client.  This explained why we could not reproduce the problem in QA.  Once we got past that check, I was able to debug function module SAP_WAPI_CREATE_WORKLIST to see what was happening.  This function module builds a list of workitems that the current user should be able to see and launch.  It does this by first identifying what users they are authorized to see tasks for based on the substitution rules.  It then compiles a list of all the workitems that currently exist for those users.

I won't go into all the details, but what I found was that if you have any active "Fill-In" type substitution rules, the list of users you are authorized to open items for does not include your own user-id.  Therefore you are not allowed to open items that are in your own queue!  When a substitute clicks on an item on behalf of another user, that workitem gets "reserved" by the substitute which means it is no longer in the original approver's queue.  It is now in the substitute's queue.  And since the new logic did not identify the substitute's own user-id as one of the users for whom they can see tasks for, it says that they are not allowed to open that particular workitem.

After we shared these new findings back with SAP, they came back and said that we were going to need to make a change to the Personal Workflow Settings for our users.

This can be done in the Business Workplace (t-code SBWP) by clicking on the menu path:  Settings==>Workflow settings==>Personal settings

[cid:image003.png at 01CF1B4B.219F9F40]

This will then open a dialog box where the user would need to check the box labeled "Also Display Work Items of Adopted Substitutions":

[cid:image004.png at 01CF1B4B.219F9F40]

Once this is done, the logic in function module SAP_WAPI_CREATE_WORKLIST takes a slightly different path and the list of authorized users that comes back does include your own user-id along with the "passive" and "active" substitutions as well.  This then allows the user to be able to open workitems in their own queue as well as those in people's queues that they are subbing for.

We couldn't ask all 47,000+ users in our system to make this setting change so we had our security team do a mass update to all users to set the user parameter.  For those who are interested, the parameter id (PID) is "WLC" and the parameter value must have an "X" in the 14th byte of the parameter.  Below is a screen-shot from SU3 showing the updated parameter.  The layout for this parameter's value can be seen in structure SWLUSERPAR.

[cid:image005.png at 01CF1B4C.78DE4210]

Couple of final notes:

SAP Note 1898458 has not been officially released yet.  It is a security note that was applied without our knowledge during our HRSP upgrade.  SAP said that this only happens with Security notes that they deem are necessary.

We asked SAP why this new logic was created.  They said that a security breech was found where users could manipulate the URL of a task and change the workitem-id by trial-and-error and manage to reserve and lock a workitem that they should not have access to.  By introducing this code, the UWL will always be checked and the user will only be able to reserve and lock workitems that they have been authorized for.

We have asked SAP to create a Knowledge Base Article related to this note so that customers will know to check this if they run into issues with substitution and HR forms.


Loren Bratzler
Norfolk Southern Corporation



From: Bratzler, Loren
Sent: Wednesday, January 08, 2014 2:28 PM
To: SAP Workflow Users' Group
Subject: HRASR00_UI 221 Message

Hello WUG Community!

Back in mid-December, we installed HR support packs.  As part of that installation, a new error message was added to Message Class HRASR00_UI.  It is message number 221:

[cid:image001.png at 01CF1B44.8BDD83B0]

Message number 223 was also added as part of these support packs but it is message 221 that we are concerned with.

Immediately after the support packs went into production, we started having users reporting to us that they were getting this error message 221 raised when they tried to launch the approval task for a Personnel Action form from the Universal Worklist.  We have already opened an OSS Message with SAP but have not gotten any response yet of what the issue might be.  In fact, they have not even been able to tell us yet where and why this new message was added to the system!

Upon doing our own research we discovered that one thing all the users who were having the problem have in common is that they are all designated as a "passive" UWL substitute for someone in the system.  Further experimenting found that if we had the users either de-activate the passive substitution rules or just convert the passive substitutions to active substitutions, the problem went away.

So my questions are:

Has anyone had any experience with this new error message?  If so, were you able to determine what the criteria are that cause this message to occur?

Is there any good documentation anywhere that explains the relationships between the back-end and front-end substitution tables?  I know that on the backend, we have the HRUS_D2 and the TWFS tables.  On the Portal front-end, there is the KMC_WF_SUBSTITUTE table.  Is there anything out there that explains how these tables work together?  Does anyone know what a MODE value of "S" means on the KMC_WF_SUBSTITUTE table?

[cid:image002.png at 01CF1B44.8BDD83B0]

And finally, has anyone successfully developed an Admin tool for maintaining these tables and keeping them in sync?  We constantly get requests to create substitution rules for users who are unexpectedly out of the office.  We have used t-code RMPS_SET_SUBSTITUTE to create the rules on the back-end but there is no tool for maintaining them on the front-end.  Because of this, the front-end and back-end tables are out of sync for many users.

Loren Bratzler
Norfolk Southern Corporation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20140127/c95fe023/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 22926 bytes
Desc: image001.png
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20140127/c95fe023/attachment-0005.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 8560 bytes
Desc: image002.png
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20140127/c95fe023/attachment-0006.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 39890 bytes
Desc: image003.png
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20140127/c95fe023/attachment-0007.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 38503 bytes
Desc: image004.png
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20140127/c95fe023/attachment-0008.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 25060 bytes
Desc: image005.png
Url : http://mailman.mit.edu/pipermail/sap-wug/attachments/20140127/c95fe023/attachment-0009.png

More information about the SAP-WUG mailing list