Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
ChrisSolomon
Active Contributor


     My disdain for the HCM Processes & Forms (HCM P&F) interpretation of "user event" is pretty well documented. I have let it be know via blogs, forum posts, etc. that I think the way HCM P&F user events are handled is completely backwards from what any developer (especially those with an OO background) would think of them....let alone any person with "walking around sense". I will not "beat a dead horse" and go into that again here. I will just say that I do not like how they are configured, but I have learned how to deal with them when needed through a few tricks of my own.

 

 

One of the major problems with HCM P&F is that all you do is define an "event" and then what fields should be passed to the backend for the event. It then leaves it up to the framework to determine from the fields passed back, what operations/services those fields are used in so that they should be executed. People have come up with clever uses of rules and "flag" fields to help handle some of this. There really is no way to define a "listener" for the event or say "for this event XXXX, I want you to only do this operation from this service"....well, that is until now. I have a few little clever tricks up my own sleeves that I use to handle this. In this way, I can tell exactly WHICH event fired. I can then "listen" for that in my own services and respond to it without the needed for additional rules, "flag" fields or the like.

 

The "Old" Way


    If you are still using Adobe Interactive Forms or anything other than the FPM form options for HCM P&F, this method will apply to you. I am not particularly fond  of this solution as it (1) requires an enhancement to standard SAP code and (2) it relies on memory handling commands. However, it DOES work VERY well.

 

     The first part is an enhancement t to class CL_HRASR00_GENSERV_MAPPER method IF_HRASR00_MAPPER~DO_OPERATIONS that sets/exports to a “memory ID” which can be retrieved later.

 




     If you have it available on your system (came available in a later HR Renewal feature pack), the class CL_HRASR00_PROCESS_EXECUTE method EXECUTE_EVENT_PRIVATE is probably a better location for the enhancement as this would catch the event (and any events) much better. There is an enchancement spot right before the "DATA" statement that you can use just as the example above.




 

     Now, within my own generic service (in initialization, "do operation", help data methods or where ever), I can read this memory ID value and find out exactly what event was triggered.

 



(*note: be careful "freeing" the memory ID if you might need it elsewhere in other services later)

 

So now, I could for example, always read this in my "do_operations" method and maybe have a whole other set of logic for the "user event" but otherwise call my operations as normal or I could just say "if this user event was triggered, do nothing....just leave."  as I would have done with a "rule" before.

 

 

 

The "New" Way


     If you are using the FPM form option with your HCM P&F processes, you are in luck! Because you are using the Floorplan Manager (FPM) framework, you have a whole new world of interfaces and classes available to you. I stumbled upon this quite by accident when actually looking at other standard SAP code that uses several FPM interface classes. I saw one that read the "events" and had a "eureka moment" of my own. I out in similar code into my own backend service and "viola", it worked like a charm!

 

     Now, from anywhere within your own custom generic service, you can now get a "handle" to the FPM instance and "listen" for events. The code is as simple as this....

 




     Now.....to REALLY blow your mind and/or put a smile on your face, we can go a step further. We can now not only say "user event XXXX was triggered", but we can also know exactly which form field triggered this event! Check out this simple code that "listens" for my custom event and also will tell me which field sent it....

 



(*edit: I typically put this code into my custom "common" HCM P&F class so I can call it from all/any of my processes and get the "event name" and control/field that fired it back to me. Very useful! Maybe one day, I will share my "common" class....one day. haha)


(*EDIT: 03/04/2017 - it has come to my attention that many people were just copying the above code without really thinking about what it does ....or understanding?....and in doing so....missed the "hint" I gave just about to make another class to handle all this as well as the "grenade" I left in the code....it will work when you are "playing around" building a process but will "blow up" and never work if you are doing a real process where workflow does your updates....that's another hint by the way......so yes, the intention was to "weed out" the copy-paste folks...but seems many got onto actual projects and are possibly screwing things up which makes HCM P&F projects not look good which eventually affects me haha.....so yes, I am adding this more explicit warning here.....(1) put FPM event checking code into your own class/method to call from all processes/generic services centrally...which you should have been doing....(2) add correct code which checks the results of that method call in your generic service to set the "event" correctly as needed should your class method not pass back an event.....for example....you know....if the FPM framework is not there for some reason....like not bound....you know....hint hint.)


 

Conclusion


     So now, in a round-about / let's-make-it-work-when-it-doesn't-work-normally kind of way, we can define true "event listeners", and we now have the power to respond exactly how we want to an event. Keep in mind, this allows us visibility to not only our "custom" user events, but we can also "see" any of the other standard events as well ("check", "initialize", and many more). This means we can completely handle in code how we want to respond/react and not just execute the operations we have exposed and configured in HCM P&F Design Time. We might have code in "do operations" now that says "if CHECK event, then call operation XYZ for field validation.....however, if user event MY_CUSTOM_EVENT was triggered, don't validate but fill in other help values". I am sure you can come up with SEVERAL use cases of your own (haha).

 

     Well, as always, I hope this helps. I thought it might be an interesting new take on "user events". Heck, I might even be close to saying I kinda like HCM P&F user events now.....I said "might" (haha). I have more blogs planned, so I better get to it. Till next time....


4 Comments
Labels in this area