It always makes me fall out of my chair when SAP pulls this “oldie but goody”. SAP has this ongoing, seemingly perverse joke where they will throw out something new with the word “role” in it just to send the security folks spinning off into a tizzy and get them all stirred up. It is quite funny to see! I remember when “portal roles” would make security people froth and foam at the mouth when they came out…and then they turned out not being much more than “navigation control”. Good one, SAP! But here we are again. With HCM P&F, SAP came up with another good one…..the “initiator role”!!!! I have yet to be on a HCM P&F project where this new role gets mentioned and the security people don’t perk up and start firing a barrage of questions at me. I have gone through this so much, that I decided it probably best just to blog about it and start referring them here. (haha)
So first and foremost, let’s get this out of the way quick. The initiator role has NOTHING AT ALL to do with security. Again….NOTHING. It is NEVER assigned to a user. It actually should be called “the-process-initiator-process-list-filter-ID”, but that’s probably too long. (haha) In simplest terms possible, the “initiator role” is nothing more than an application parameter “key and value” pair that is used to BEGIN to present the user with the possible processes they can start (review my previous blog HCM Processes & Forms: Processes in the Process Selection List...how do it know? that shows all the ways the process list can be filtered and controlled).
Now that the secret has been told…..the mystery solved….the magic revealed….let’s see how the “initiator role” is used in action. There are really two parts to this:
- Backend configuration – create/configure an initiator role and assign processes to it
- Frontend assignment – pass initiator role as application parameter.
Backend Configuration
As mentioned, first of all, there is the assignment of processes to “initiator role”. The Initiator role is used to control the list of all processes available to a user. For instance, a “HR Admin” might see a very different list of processes than a “manager”. The standard Initiator roles which come from table T5ASRPROCROLE are (note how they used to be called “Agent Role”…SAP joke again? haha):
These are configured in HCM Processes and Forms configuration. You may add custom roles as well as of enhancement package 2. Prior to EhP2, you had to make a direct table update to create your own custom roles. However, now, this is all handled through the Design Time workbench for HCM P&F. To control which initiators have access to which processes, you configure this on the process itself in HCM Processes and Forms configuration. This is found under the Process -> Validity Period -> Process Start -> Role Assignment folder as shown:
You can select the initiator role table cell to get a drop-down list of defined initiator roles or you can add custom “initiator roles” here directly (just type in your own new role name directly such as “ZHRTIME”). The additional table columns allow you to define further restrictions which we won’t discuss here to keep it simple (those are further options for filtering our process list). You will do this for each and every process you want to implement. Therefore, every process where the initiator role equals that which is passed as the WebDynpro parameter INITIATOR_ROLE will be listed on the page of possible processes unless further settings limit that list as well (again, please review the blog HCM Processes & Forms: Processes in the Process Selection List...how do it know? for more information on controlling the process list). My only gripe here is that currently there is not a way to go to defined initiator roles and then select all processes we want from them. You have to go about it the other way. You must go into a process and then assign it to an initiator role. That means that if we create for example a role called “ZOURHR”, we have to go into each and every process to then assign it to our new role. A little “bass ackwards” to me, but oh well…
Frontend Assignment
Now, we need to see how we use our initiator roles that we configured. Again, this is really an application parameter key/value pair. For example,
INITIATOR_ROLE=HRASRA
We have primarily three main ways where you will see this used:
- WebDynpro ABAP “Start Application”
- Homepage Framework configuration
- iView Application Parameter assignment
Let’s start working from the back all the way to the front.
1. WebDynpro ABAP “Start Application”
The actual WebDynpro ABAP application used for HCM P&F is asr_process_execute. If we look at the application, you can see immediately that one of it’s application parameters is, in fact, INITIATOR_ROLE.
If nothing is passed to the application, the default is the HR Administrator initiator role (HRASRA) is used as you can see. Therefore, you will see for the Start Application iView and/or Homepage Framework settings for the HR Administrator, we never have to directly pass this value (dig around in the business package for HR Administrators and you will see this….well, you will see nothing actually….and now you know why. haha). So it should not be a giant leap to see that you could pass your own initiator role value directly to this WDA and have it display the process list as you configured for that role.
2. Homepage Framework configuration
The Homepage Framework is an oddity related to ESS and MSS that began “way back” with ECC5. It allows us to configure a consistent interface for ESS/MSS with little to no web development knowledge or work required. In other words, it “makes” our web pages for us complete with all the little links and what not that we need (again, I have written more than my fair share of blogs on the Homepage Framework and know it well). So, it should be no surprise then that if we are configuring the Homepage Framework to “build” links for us that we can also pass application parameters (ie. query string) in our links. That’s exactly what we do by assigning our Application Parameter in our “URL parameter” when defining our “Resource Key”. For example, let’s look at the standard SAP Resource Key “MSS_HCM_HRAS_START_PROCESSES”:
In this particular image, we can see that we are passing the initiator role for HRASRB (a manager).
3. iView Application Parameter assignment
This is fairly straightforward. Much as we did for our Homepage Framework configuration, we are going to directly define in the application parameter setting of the SAP portal iView which initiator role we wish to use. We can see this in this example:
As you can see, we are again passing the value "HRASRB" which will display the processes we have assigned for the manangers to initiate.
One thing that is important to mention here. With all of the given methods to assign the initiator role as shown above, it is the job of the person defining the portal content to insure the correct method is used for the correct user. In other words, there is nothing that stops us from having an iView for a manager (initiator_role=HRASRB) that is put into some incorrect location like a role for an HR Admin. Worse still, I often see/hear cases where people simple put the iView for "Start Application" into their MSS role with no application parameters assigned in any way and then wonder why they are seeing lists of HR Admin processes in their managers role. I hope you know exactly why after reading this!
I do not know what more can be said. My purpose here....actually purposes...was to: (1) clear up any confusion about what the "initiator role" is (2) show you that the initiator role really is not much more than a fancy filter...and not that fancy even (3) keep your security folks from having heart attacks when they hear that SAP has come out with yet another "role" (haha). I hope I was successful on all fronts. Now, with this information, you should be able to think up all kinds of additional and interesting ways to use the "initiator role".....so go get to it!!!
- SAP Managed Tags:
4 Comments
