I have yet to be on a project, talk to a client or prospective client, or hear about other projects where at least one person was not under some kind of assumption that HCM Processes and Forms simply worked "just like regular old HR" especially in regards to user exits, dynamic actions, change pointers, and the like. Please check those expectations at the door! Or as happens to me often, this invokes my Monty Python response...."And now for something completely different....."
Horses Before the Cart
I think the most basic reason for this misunderstanding is the very lack of a clear direction (or at least one that's been communicated well) by SAP for HR (HCM) in the future. I don't mean from what HCM offers and where it's headed. I am talking "under the hood" which is how all of those nifty new features, products and functionality will be working. I mean, the "pieces" are there. I just don't think they have been explained and communicated quite fully. At the heart of this is the Decoupled Infotype Framework (confusing on it's own but equally confusing when it's also referred to as the "Detached Infotype Framework" in a lot of SAP's own documentation too).
The Decoupled/Detatched Infotype Framework was *new* as of ECC5.0. Most people's first experience and exposure to it will most likely come from ESS when hunting down the dreaded "Grouping Value" error. That error is related, in fact, to another new feature as of ECC5.0....the "concurrent employee". Now, to follow this six-degrees-of-separation-Kevin-Bacon connection further, Concurrent Employment is tied to the Decoupled Infotype Framework. Viola! There we are. So, although you might not be using concurrent employment, you will inadvertently use the Decoupled Infotype Framework at least for ESS (and HCM P&F as we will soon see). For those actually using Concurrent Employment, they will actually be already using the Decoupled Infotype Framework via PA20/30/40 unlike the other folks not using it who will run the "old" PA20/30/40. But what is this framework we are talking about and why should you even care if you are not using or planning to use concurrent employment? Because THIS is where SAP is heading, so we need to understand what THIS is.
The Decoupled Infotype Framework does not depend on HCM P&F, but HCM P&F does depend on it! I can not tell you how many discussions or "knowledge transfer workshops" with prospective client about HCM P&F I have had that get derailed and sidetracked off for several minutes if not an hour or more simply discussing what the Decoupled Infotype Framework is, why it is, how it works and where it is headed.....All things I very much would not like to discuss in order to keep the original conversation in focus. But I almost have to because (1) it is almost a "cart-before-the-horses" situation if I don't bring it up (2) if I don't talk about it and explain it in detail, then it becomes perceived as "oh that's a HCM P&F thing" or "that's a MSS thing" which connotes some inherent, dependent limitation of the solution and could not be further from the truth.
So before I go off into that same long-winded discussion about the Decoupled Infotype Framework, I will just try to keep it as brief as possible, In a nutshell, it is a new way in which SAP handles infotypes. Unlike in the past where the actual data structure was very closely tied (ie. tight-coupling) to it's actual appearance on the screen (PA20/30/40...ever do all that IMG config for screen control per infotype? per country? haha), this new framework allows us to completely un-tie (ie. decouple) the front-end appearance (presentation) from the backend (data structure).
To try to make this simpler.....hold your hands up like you are going to karate chop something. Think of that hand on the left as your "presentation structure". The hand on the right is your "data structure" (which is in fact all the same database tables and structure you are use too). Now, see all that space in the middle between your hands? That is where your "conversion classes" live. These allow you to write special code for both information coming in (input) from your screen structure to your data structure as well as data going out (output). For our standard infotypes, a lot of this data checking is handled in that "space" in the conversion classes. We can also write our own custom versions of these classes as well as new ones for our own infotypes. In this way, any time a program uses our screen structure, it will go through our conversion classes (much like the idea of a BADI but taken a bit further). So, besides the obvious fact that we no longer have our presentation layer depending on our data structure, why else would we want to do this? Well, because we can also define multiple presentation structures (that might even hold several infotypes' fields to map too) and then via our "in between classes" we can handle how those get mapped to our backend data. This allows us to have many different "views" to access our data and yet, we can share the same input/output conversion code.
(* more info about the decoupled infotype framework:
http://help.sap.com/saphelp_erp2005vp/helpdata/en/43/a503b963161bbfe10000000a1553f7/content.htm
and a really great wiki related to ESS and the framework,
)
So why all this fuss over the decoupled infotype framework? What does it do for us really? Why are we even bothering? Looking ahead, the thought is that any interaction with our infotypes will be through the decoupled infotype framework via classes. In that way, our frontend applications can be pretty much anything as long as we are going through the decoupled infotype framework. That means....to be blunt....PA20/30/40's days are numbered at least as we have known them up till now.
But what does this mean for us....for the HCM P&F folks?!?!?! I guess this is where we can really get into the point of this blog (*see there, I went on and on about the decoupled framework much longer than I wanted.Doh!) .......
User Exits
Straight to the point....HCM P&F processes do NOT call any of your user exits. For example, you might have all kinds of user exits you implemented for PA30/40. Those will not be called at any point using HCM P&F SAP_PA operations. Sorry, they just won't. Let's face it, user exits are old news....old hat....going (if not gone) the way of the dinosaur. They had their time. They ran their course. For the most part, user exits are just "holes" in a program that allow your to put in some custom code. In the "olden" days of SAP (Chris shakes his cane wildly as he exclaims "I remember the days when we use to call it R/3, and we were happy with our 3-tiered architectures!"), everything ran under one server, so we could pretty much assume that the same program would be used to perform the same operation over and over and over. No need to have 2-3 programs all doing the same thing. But times change and access comes from multiple places and in multiple ways now. The problem with those old user exits is, that custom code only gets called when that one program (or include if we want to get right to it) is used. If you use some other program to achieve the same result, it won't magically call your user exits or even know they exist. That's exactly what happens with HCM P&F (and more so, SAP_PA). SAP_PA uses the Decoupled Infotype Framework. Therefore, any of that code you had in your user exits really should be in that "space" (conversion classes) in the Decoupled Infotype Framework for you specific infotypes. So yeh...long story short....user exits called from HCM P&F? No dice.
So what do we do in the HCM P&F world then in regards to these user extis? We have two choices:
(1) If we know that in all cases we will need that same code/logic whenever working with our infotypes either for input or output, then it is best to put them in a central location where everything feeds through them. *hint hint* That custom user exit code of yours should really be migrated/ported/merged into the Decoupled Infotype Framework. That's really outside of HCM P&F itself (again, the Decoupled Infotype Framework does not depend on HCM P&F, but HCM P&F does depend on it!) , but HCM P&F uses the Decoupled Infotype Framework to process operations.
(2) Our other option, should we hold off on putting our code in the decoupled infotype framework, is to simply reproduce our needed code/logic within generic serivces to be used in our HCM P&F processes. Yes, I said it reproduce/redo/port that code. Not fun, but has to be done.
Dynamic Actions
Ahhhh good ol' dynamic actions....or as I like to think of them, SAP's cruel joke on the functional folks to make them actually believe they are programmers! (haha) What seems to have begun as a simple marco-like language to provide some added flexibility to HR config, now seems in some cases I have seen to have become this overblown crutch that many companies rely on in order to achieve their HR actions without a lot of actual custom coding (*see user exit discussion above). Ok, ok....I won't be that harsh. They too have their time and place. Time? Yesterday. Place? If you live your whole life in PA40. Past that, they are of little use....especially to us in the HCM P&F world.
In a nutshell, just as they sound, dynamic actions are like a "mini-program" that runs when a user executes a HR action (like hiring, firing, transfer, etc). Based on that action, they will then inspect other object values (like country code or maybe employee sub group) to make decisions and conditional checks about executing further infotype updates depending on the outcome of those checks (hence "dynamic"). This all happens within the PA40 transaction code. Did you get that? They are triggered all within the PA40 transaction code! So much like user exits, they only get called when that program gets called, and guess what....HCM P&F, or more specifically, SAP_PA, does not call that same code/program.
How do we then handle Dynamic Actions within HCM P&F? This one is a bit tricky. Depending on your dynamic actions and how involved and complex they are, you will basically mimic these in HCM P&F through a clever combination of generic services and rules. In effect, you will be duplicating the Dynamic Action within the "language" of HCM P&F. Again, this effort will depend solely on the complexity of your Dynamic Actions, so your mileage may vary (*no warranty is explicit or implied in this statement. haha)
Change Pointers
This is yet another option at our disposal for quite some time now in order to trigger “stuff” based on changes to a specific infotype tables or even down to specific infotype fields. However, this is getting down to the lower, table level of things (ie. not in program code or some config scripting or whatever). Change Pointers are the “HR Version” of Change Docs (not sure why they are separate, but ok…mark it up as another SAP curiosity). In a nutshell, we can set it so that an infotype will “raise” an event anytime a change or some sort occurs on it at the database level. Not to get too far off, this “event” can trigger a workflow based off of changes to the change pointer tables (old way) or off a business object event (newer way) that we set up in our “event linkage”. Unlike user exits and dynamic actions, my response is not so cut-and-dry (or harsh). Can you use your existing change pointers or will they need to be replaced/duplicated in HCM P&F? In true consulting form, I give you the true consulting answer......."It depends.". I only say this because by the time a database table update occurs (for instance via SAP_PA), then yes, your change pointers should work just as usual. The “depends” part is only because it might also depend on any kind of code (for instance, through a custom function module) that you have “linked” to your Change Pointer configuration. That is the only caveat I can think of right off. However, this rarely comes up (I have only been asked about this once in about 15-20 discussions about HCM P&F).
Well, I hope this blog did not scare you away from HCM P&F. The whole point of this is really two-fold. First off, and tongue-in-cheek, I want to make sure you do not venture into HCM P&F with any assumptions, expectations and/or preconceived notions you might have based on your experience with SAP HR up until this point. It really is quite different. Secondly, I really...REALLY....want you to take these things into consideration when scoping and planning your own HCM P&F project. The effort required to replace/duplicate a lot of this past functionality might be quite an undertaking in your environment. I would hate for this to sneak up on you as something unplanned in your project at the last minute (trust me, I have seen this first hand on my own projects!....with only week's to go till go-live, we suddenly got a last round of "business critical" requirements because someone realized they had not told us about a dynamic action because they thought "oh, HCM P&F doesn't do that just like PA40?" Arggggg!!!!!) As always, I hope you can learn from my own experience (and headaches) in order to have your own successful HCM Processes and Forms implementation. This is just another one of those little "interesting" pieces of HCM P&F. There are plenty more I will be blogging about, trust me! (haha) Till then...
(** a special thanks to Derrick Banks of Banks&Company, a long time friend, workflow guru and fellow HCM P&F veteran, for providing extra info on Change Pointers and the Decoupled Infotype Framework with concurrent employment...hey, he even taught me something! haha Thanks, Derrick!)
- SAP Managed Tags:
8 Comments
