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….
- traditional HRASR_DT configuration (as discussed in that old blog)
- launchpad customizing (via transaction LPD_CUST)
- 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”…
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…
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’
pernr = iv_pernr
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
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
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!)
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:
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…
…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:
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…