ESS Leave Request: Preselection of Approvers from Backend

[Lukas_Weigelt]

Hi Experts,

I've got a question regarding the Approver-Selection in the ESS Frontend via Name / Employee Number / User.

We use BADI PT_GEN_REQ to distinguish between users that have a certain Backend-Role and those who don't to only display these who have the role. As per IMG, Method Filter-next-processor uses itab CH_PERSDATA_TAB to preselect ALL Users from the respective Backend and leaves us with the choice to further filter this preselection. In ESS a maximum of 150 Users is displayed when using wildcard *, so as I understand ALL Users are selected but only 150 are displayed.

Now here's the coding:

lt_cache_lt_ex_persdata_tab[] = ex_persdata_tab[].
  REFRESH ex_persdata_tab.

*  TRANSFER lv_username to lv_appspath.
*OPEN DATASET lv_appspath FOR OUTPUT IN BINARY MODE.

  LOOP AT lt_cache_lt_ex_persdata_tab INTO ls_ex_persdata_tab.

    CLEAR lv_approverflag.
    CLEAR lv_username.

    lv_username = ls_ex_persdata_tab-user.

*  TRANSFER ls_persdata_tab-user TO lv_appspath.

    CALL FUNCTION 'CRM_ROLES_OF_USER_GET'
      EXPORTING
        user_name          = lv_username
      TABLES
        roles_of_user      = lt_user_roles
      EXCEPTIONS
        no_roles_available = 1
        OTHERS             = 2.

*    IF sy-subrc EQ 0.
    LOOP AT lt_user_roles INTO ls_user_roles.
*      TRANSFER ls_user_roles-role_name to lv_appspath.
      IF ls_user_roles-role_name EQ lv_lea_approver_role.
        lv_approverflag = 'X'.
*          APPEND wa_persdata_tab TO ch_persdata_tab.
*          EXIT.
      ENDIF.
    ENDLOOP.
*    ENDIF.

    IF lv_approverflag = 'X'.
      APPEND ls_ex_persdata_tab TO ex_persdata_tab.
    ENDIF.

  ENDLOOP.

*  CLOSE DATASET lv_appspath.

* Aufruf der Standardmethode # weigelt, lange 24.01.2011 Methode löscht inaktive MItarbeiter aus Tabelle
  CALL METHOD default_impl->if_ex_pt_gen_req~search_for_next_processor
    EXPORTING
      im_approver     = im_approver
      im_user         = im_user    " changed lo_user to _im_user #weigelt 15.12.2010
      im_pernr        = im_pernr
      im_searchstring = im_searchstring
    IMPORTING
      ex_persdata_tab = ex_persdata_tab
      ex_messages     = ex_messages.

  DELETE ADJACENT DUPLICATES FROM ex_persdata_tab COMPARING pernr user name.

What we did expect was:

1. The system automatically preselects all Backendusers into CH_PERSDATA_TAB

2. BADI PT_GEN_REQ is used in Filter Next Processor to erase all users from the table who don't have a certain backend role.

3. The first 150 of validated approvers are displayed in ESS

But what apparently happened was:

1. The system randomly preselects 150 users from Backend, with a convenient amount of users having our approver-role of ZERO.

2. No approvers are displayed in ESS because none have the backend-role.

3. We are confused and think our coding somehow killed the wildcard function.

As debugging the method is near to impossible, we tranferred the contents of EX_PERSDATA_TAB and CH_PERSDATA_TAB several times on several occasions into a file on our application server. First of all there are at most 150 entries in the file, or, in case no approvers are preselected, the file is empty.

MY QUESTION:

Can anyone validate there aren't ALL Backend Users selected as stated in the IMG but only 150 which the BADI PT_GET_REQ ultimately works with? If so, is what we expected (see above) not possible to realize? Meaning ESS-user simply enters wildcard * and gets a vast selection of approvers?

Aside from that. When actually searching for a name/ empno / user, everything just works perfectly well. I just need a verification of my thesis.

best regards and thanks in advance

Lukas

[wp1 · Accepted solution]

Hi Lukas,

yes, this is correct.

While CH_PERSDATA_TAB is created just 150 employees are taken.

You can check note 931144.

This note was created caused by performance problems.

Loading all employees is taking much time.

The responsible coding is here I think:

Class: CL_PT_REQ_SEARCH_NEXT_P

Methode: SEARCH_NAME

Line 74:

maxrows = 150

However, a very old note - so I wouldn't give a guarantee what happen if you modify here.

Kind Regards

Wolfgang

[Lukas_Weigelt · Accepted solution]

Hi Wolfgang,

thanks for clearing this out. That's all I needed to know.

best regards, Lukas