Skip to Content

     This past week, I had an interesting “bug hunt” that I thought might be nice to share. Stop me if you’ve heard this one before…”It was working fine yesterday, but…” (haha)… The “it” in this story turned out to be the “process list” for our users. The “wrong” processes were showing up, and the ones that were suppose to be there for testing were not. Now, I covered this long ago in a blog (HCM Processes & Forms: Processes in the Process Selection List…how do it know? ), but a few things have changed in this new “FPM world” of HCM P&F.

     We have a few ways in which our “available process list” is presented to the user depending on where (what iView for example) they use….

    1. traditional HRASR_DT configuration (as discussed in that old blog)
    2. launchpad customizing (via transaction LPD_CUST)
    3. parameters set directly on iView/WebDynpro or passed in URL

     So my first task was identifying “where” they were seeing this “wrong” list. Turns out, it was our regular old “start application”…

/wp-content/uploads/2015/03/startapp_674745.jpg

     I wanted to check configuration on our “good” processes and saw no reason these should not be showing….there was “no restriction” on any of them…

/wp-content/uploads/2015/03/init_no_restrict_674746.jpg

     Everything looked good there, so I continued the hunt. Given that this “start application” is the newer WDA version, I had a little digging to do through layers of FPM UIBBs, but I came down to:

  •      Component: FPM_OVP_COMPONENT
  •      Configuration: ASR_PROCESS_START_OVP_CFG

     ….which has the feeder class CL_HRASR00_SEARCH_FEEDER. Looking into this class, we can see how our process list is built with breakpoint in method, GET_PROCESSES_FOR_EMPLOYEES (pretty obvious name, eh? haha…there is a similar method called GET_PROCESSES_FOR_PD_OBJECTS but I will let you figure that one out haha…another good one within that class is method BUILD_LPD_LIST which builds our launchpads!) Within the method,  the lists of processes are set by another obvious named function:

  CALL FUNCTION ‘HR_ASR_SELECT_PROCESSES’
     
EXPORTING
           pernr        
= iv_pernr
     
TABLES
           process_tab  
= lt_adb_processes
           processes_fpm
= lt_fpm_processes
.


…and this in turn calls the following class/method….


CALL METHOD cl_hrasr00_process_utilities=>get_process_list_for_role
EXPORTING
      application         
= c_application
      object_key          
= object_key
      initiator_role      
= initiator_role
      procgrp             
= procgrp
      procgrp_exclude     
= procgrp_exclude
      is_start_proc_wo_obj
= is_start_proc_wo_obj
      is_mass_start       
= is_mass_start
      message_handler     
= message_handler
      iv_all_form_type    
= iv_all_form_type
IMPORTING
      processes           
= process_tab[]
      processes_fpm       
= processes_fpm[]
      processes_bol       
= processes_bol[]
      processes_mas       
= processes_mas[]
      withoutee           
= withoutee
.


I jumped over to SE80 to check out the class CL_HRASR00_PROCESS_UTILITIES (which actually has several useful methods so it is good to remember this one!)

cl_hrasr00_process_utilities.JPG

     For PA processes, the “magic” happens in method GET_PROCESS_LIST_FOR_ROLE. For OM(PD) processes, there is a similar method GET_PD_PROCESS_LIST_FOR_ROLE called (crazy obvious eh? haha). Looking at the method GET_PROCESS_LIST_FOR_ROLE, I found this very interesting little section in there:

get_list_for_roles.JPG

See anything “interesting” in the developer’s comments?….like the “to do” part? (hahaha) Now a sensible person would think if our configuration looked like…

process A – no restriction

process B – US only

process C – Germany only

process D – no restriction

….then a US initiator would see the process list…

process A

process B

process D

…but no! They see only process B in their list!!!!

     If you look at the code, it first says “do we have a list of “object group processes? Yes, then wipe out our list of “no restriction” processes and move/copy our “object group processes” to that list. No merge…no compare…..nothing…just wipes out the list and copies the other over. This is what the developer means by “object group processes supersedes entries from the valid processes list”. Furthermore (and worse!!!), it only takes one process being assigned to an object group to make all your other processes vanish from the list (so if someone does this in their config and does not communicate it, good luck! haha). Looks like SAP has some more work to do here, but for now, as the saying goes “it is what it is”.

    I went back and checked some of those “odd” processes showing in our list, and low and behold, they were all assigned “object groups” in configuration:

/wp-content/uploads/2015/03/init_objgrp_674749.jpg

ARRRRGGGG!!!!!

     After a little bit of configuration change….unassigned the “bad” processes from the object groups and assigning the ones we wanted to object groups (which we planned to do anyways later in order to set up which processes are shown to which initiators from which countries)…..we re-ran it and viola…..it worked great, and we had happy users once more.

     So I thought I would share this little but of “fun” to hopefully help out anyone else that might come across one like this….and would rather enjoy their weekend instead of sitting at home debugging lines of code and configuration (haha). I hope it helps! As always….I will keep blogging if you keep reading them. Till next time…

To report this post you need to login first.

2 Comments

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

  1. Mukesh Kumar

    Excellent blog ! And Information on the objects (in debugging) to look into for analysis is really helpful. It won’t be wrong if I call you my teacher on HCM Forms & Processes because whenever I was looking for any info, I came across one of your blogs.

    (0) 

Leave a Reply