A siren blares waking you from a sleep as the intercoms crackle "WARNING! WARNING! CODE RED! CONDITION CRITICAL!!!". You jump to your terminal and notice you have over 1000 emails waiting in your inbox and your messenger app has locked up due to exceeding too many message requests at one time. You read quickly through the first 10 or so emails with titles like "OH NO! It's broken!" and "What is going on?!?!" and "You will lose your job for this!". From what you piece together, it seems that process you just just went live with 5 days ago right before payroll ran has actually been giving all employees in the same org unit a bonus when you meant to only give the selected employee a bonus. Uh oh!.......yeh....a BIG "uh oh". So how can we "stop the bleeding"!?!? How can we stop people from using the process until we get this fixed??!? I mean....sure, we can send out a global email that says "please don't use the Bonus Pay process at this time", but then, who really reads all their emails these days?!? We can do a transport to "turn it off", but that will take some time to package up, move to QA and move again....I mean, we do have a process....we have to log it into Solution Manager....set for "approval needed"....then the team lead approves....then BASIS sees the ones set for "approved" and moves them....oh, and that's if our BASIS folks are available right now...and then we must do the same to move from QA to Production. Hmmmmmmm.......good thing we made use of that "process restriction" BAdI!!! You log into Production, type in your custom transaction code, find you process on the screen, turn "off" the process in your custom table, and the bleeding is stopped....for now. Time to correct the affected employees and get to fixing your process! Thanks to SAP for giving us that useful BAdI !!!!!
What's this you ask? "Process Restriction" BAdI? Well yes....SAP was kind enough to give us this "if all else fails", very useful (but very under-used) feature of HCM P&F. Long ago, I blogged about all the many ways we can "filter" our process list ( HCM Processes & Forms: Processes in the Process Selection List...how do it know? ). We can control what processes "show" for a selected employee/object based on "validity dates", process groups, collision checking, etc.But let's say none of those meets your needs. You need something more granular. Well, SAP provides us with the "restriction" BAdi. You can find this in the IMG directly under:
....and in our good ol' Design Time tool in your process configuration as:
If you look at the IMG docs, SAP states:
Set Restrictions for Starting Processes
Use
In this IMG activity you define the settings which you can use to define under which conditions a process can be started. This way you can control, for example, that the process maternity leave can only be carried out by female employees. If you install the Business Add-In (BAdI) in this IMG activity, the system carries out the corresponding checks before starting the process.
Standard settings
SAP delivers BAdI definition HRASR00PROCESS_START_RESTRICT in the standard system. The BAdI uses the variables APPLICATION and PROCESS for the application and process as filter values. The BAdI copies these values from the application that the BAdI implementation calls.
The interface method accepts the parameter OBJECT_KEY and PROCESS and returns boolean value IS_PROCESS_EXECUTABLE. This value specifies whether the process can be started or not.
The enhancement is quite simple.
It uses a very basic interface of which you will create your own class to implement.
The interface has a single method....
....and the method has these parameters....
Then it is simply a matter of reading in the "process" parameter as well as the "object key" (which can be an employee number or org object key) and then using your own logic to determine if the process should be allowed our not.
You can even use the message handler to send back a message/warning/error.
So yes, SAP gave us a pretty good example there....a "Maternity Leave" process that can only be executed for female employees. However, I began with a much more dramatic example (haha). In fact, I did this before for a client (whoa! I don't mean I screwed up and gave all of their employees bonus pay! haha) who wanted the ability to easily turn processes "on" and "off" without having to set hard dates (validity dates) or require the need for transports to add/remove a process in the process list. It was actually a quite simple solution.
First off, I made a simple custom table containing the process name and an "active" field ( X = on , empty = off). You could make this more complex by adding things like country as well, but I digress.With the custom table, the client could then maintain it (nice maintenance transaction created with custom t-code, blah blah blah).
Second, I created my custom class that simply would read in the "process" parameter coming to us, check it against the custom table, and decide whether the process was allowed at that time or not (checking the "active" field in my custom table). If not, we had a nice message back to the user informing them why this was not possible at that time.
Third (and last), I simply created my implementation of the enhancement (just like we do for Generic Services in HCM P&F), assigned my process as the "filter" and assigned my custom class to the implementation. One minor gripe I have with it, is that it uses a "filter" on the enhancement that requires you to pass the process name in it.
Therefore, you would need an enhancement implementation for every process you wanted to check with this. The bright side of this, however, is that you could use the same class in each implementation.
It was a bit of work and yes, we had to "apply" it to each process we had, but once in place, this makes controlling our processes so much easier! You can extend this and seriously check just about anything under the sun that you need to inspect. Really powerful....but oddly enough, I rarely ever see it used (and yet see requirements that scream for it and workarounds to duplicate it because people do not know about it!).
Well, this was another quick one....and I gave away one of my "little secrets", but I do hope it helps others. As always, I will keep blogging if you keep reading! Till next time.....
- SAP Managed Tags:
