Over my years working with HCM P&F now, I have often been asked if it is possible to start a process from “something” outside of using the “Start Application” (ie. a user…employee, manager, admin,etc… actually kicking off a process). Now with the advent of Ehp6 and HR Renewal, that functionality got a lot easier (although I *gasp* have not got to “play with that functionality just yet….but I bet this solution will even find use in the EhP6+ world). Prior to this, there was nothing standard to allow you to start a process without a user actually manually executing the “Start Application” outside of starting a process from recruitment via PI integration (lots of config!). In the past, I had played with a few ideas I had. Tried to prototype some things. Looked at the standard workflow tasks for things like “check form” in the background to get some clues. But usually, the client changed requirements or something happened that turned the focus away from coming up with a “auto-initiate” solution and just got back to the work at hand….straight, out-of-the-box HCM P&F configuration and development.
That all changed for me recently however….in two ways. First off, the one specific process I was given to complete hinges on the fact that the process can be kicked off from “elsewhere” (actually, from a workflow triggered by a whole other event outside of HCM itself). The fallback when/if the process does not get initiated is that the user can also start the process manually (as usual). Secondly, due to the clues given to me by the wise sage of a consultant (and friend), Rudy Blanco, who has been doing SAP development for about as long as anyone, I got pointed in the right direction. At last, I found THE solution for starting a process from anywhere…..and the solution was in technology that has been around for at least as long as the “good ol’ days” of PCR’s (the precursor to HCM P&F)….the ISR framework!!!
The first step is creating our own custom class in which we will create our custom method to trigger from workflow. Now because we are using this class in workflow, there are some things we have to do (using the IF_WORKFLOW interface and implementing the interface methods correctly) but that is outside the scope of this discussion not to mention there are plenty of online tutorials on how to set this all up if this is foreign to you.
Let us assume all those steps have been done and now our focus is on our new custom method….
For this example, I know that my initial form in my process is very simple as it is not meant to actually be used except in case of an error where our workflow for some reason does not start it and we need to manually initiate the process. In my case, I need only the employee PERNR (the same as if our user were selecting it manually) and a record ID (to look up the record needed for the rest of my process), so those are my only form fields.
Those fields will then be the only parameters I need for my custom method. We define them with the same types as our form fields.
Inside our method, we need some very basic code. Let’s walk through it…..
First, you see that we need to set some basic information that you would expect if you were telling “something” what process you want to start.
Next, we fill in some of the “special” fields (although you will see we do this again).
Now we get to the real magic….
Yep! We call the good ol’ ISR framework to do our bidding. (*note: oddly enough, I had used this in the past to allow mobile users to do approval steps in a process but had not thought to try to use it to start a process…doh!) You might wonder why we are looping twice here. The first loop, we send the “event” parameter as empty/blank. This is equivalent to telling our process to “initialize”. The ISR call returns our structures full of our initialized fields and data. So then we set our form field values to what we want them to be (just as if we were keying them into the form), and we set our “event” to “send” at this point. When it goes into the second loop then, it has our fields with the data in them, and we are telling it to “send”…which is like our HCM P&F “send” step after “check and send”. Therefore, our process will be started just as if someone had been sitting there running the “Start Application” as we are all quite use too by now. We could get “fancy” here and add some code to the end to write to the log on errors or some such (look at how the standard “check form” or “save form” background workflow tasks do this), but we do not need this for now.
But now, where do we put this? How do we use it?
First, we create a new custom workflow “standard task” (via transaction PFTC_INS). Within our task, we assign our custom class and method to be used.
Now we have to use our task somewhere. Let’s consider a simple workflow…..say we have the following existing workflow in place…..
….within our workflow, we add a new step and assign this our new custom task. We set up our bindings so that the workflow passes the information we need to our method.
….now, when the workflow gets executed and at some point hits our task, our process is initiated…just as if someone had run it manually from the “Start Application”. The first step in our processes’ workflow sends our manager an “edit” task to his UWL….so look what shows up “magically” in our UWL?
The initial workflow that triggered our process and its workflow may be still running or ended, but our process workflow is now off doing its thing just as usual.
That is about all there is to it….write your own class, have a public method that can accept whatever parameters you need as input to set for your form fields In the form scenario “start step”, call the ISR “process event” function module and viola….you have your very own process” trigger” that can be used in any number of ways. Imagine the following possible scenarios….
- Start process from report :
Imagine if some sales department administrator ran a “top sales people of the month” report and this report checked if certain sales people met their quota and such and if so, it could call your class method and would fire off a start “Monthly Bonus” process for each sales person that met the criteria. Auto-magically! (haha)
- Start process from mobile device :
So you are a manager on vacation and find out your ace employee just left the company. You need to fill that position fast! Sure wish you could start a recruitment process from your lounge chair on the beach eh? Well, if you can write an app or a simple web “form”, you can send that information right over in any number of ways…plenty of examples around…but there is nothing stopping you from calling your class method “trigger” in there too!
- Start process from WebDynpro :
Imagine that an employee is changing or adding an address using their ESS WebDynpro ABAP app. In that WDA, you have some checks in place that will see if the new/changed address has tax implications. If so, it calls your class method and initiates the “Employee Change of Address” process which allows other admins to check/change/correct any tax related settings for the address. Otherwise, the change happens immediately and the employee is none the wiser….nor does an HR Admin get notified every time someone changes their address.
- Start process from web service :
Imagine if we have some web service…maybe, say something we have written for integration to other products…like say SuccessFactors….maybe when a change of some sort occurs in SF, our web service gets called via PI integration and kicks off our own nice on-premise HCM process. Triggering HCM P&F from SF? Yep! BOO-YAH!!!!
- Start process from another process:
The examples for this almost write themselves. How many times have you want to trigger another HCM P&F process to start while in the workflow of another process? Yep…you can do <insert your scenario here> now.
…and I am sure you good HCM P&F folks can think up even more use cases!!! 😉
So that’s it. Now you know. You have the power in your capable hands. Go forth! Blaze a trail as you put this new found knowledge to use! Take HCM P&F into the farthest reaches in ways never imagined! Make me proud! (haha) In the meantime, as always, I will keep blogging as long as you keep reading. Till then…