For those working with HCM P&F during the "Dark Ages" (ie. prior to EhP6/HR Renewal haha), you are most likely very familiar with using and getting way too friendly with the ISR (Internal Service Request) interface layer. Previously, if you wanted to see exactly what fields and field values were being passed back and forth and all around in an HCM P&F process, you could debug and inspect the ISR data. The ISR layer was a magical land where data was passed back and forth from our "process object" to an Adobe Interactive Form who knew nothing about the backend configuration and was only bound to ISR fields. Ok ok......so the ISR wasn't that "magical"...it was just a "middleman" or broker for our communication from the Adobe form (web) to the backend. However, you will not find the ISR layer in the "new" WebDynpro FPM based form processes. So how does the data get from what fields we configured to fields on our form now?!?! Is this some new magic right out of SAP-land? Nope. It is actually quite simple.
In a nutshell, it can be summed up best by Audrey II from the 1986 movie "Little Shop of Horrors" as the 
blood thirsty, talking plant beseeched it's keeper "Feed me, Seymour! ...Feeeed me!!!" (how's that for a reference! haha) The Floor Plan Manager framework makes use of "feeder" classes to pass data between the UI and elsewhere. From SAP documentation:
http://help.sap.com/saphelp_nw70ehp3/helpdata/en/6c/5632d4e79b4003b97c93946ad3aa29/content.htm
A feeder class provides a link between the application and the generic user interface building block (GUIBB).
Feeder class implementations are based on a predefined interface definition, providing all necessary methods and corresponding signatures to standardize the communication between the application and the GUIBB.
A feeder class is a class that implements one of the following ABAP interfaces:
- IF_FPM_GUIBB_FORM (for form components)
- IF_FPM_GUIBB_FORM_REPEATER (for form repeater components)
- IF_FPM_GUIBB_LIST (for list components)
- IF_FPM_GUIBB_SEARCH (for search components)
- IF_FPM_GUIBB_TREE (for hierarchical list components)
- IF_FPM_GUIBB_LAUNCHPAD (for launchpad components)
Using the GET_DEFINITION method, the class defines the field catalog (the fields that are available for use in the configuration) of the component and supplies the component at runtime with data from the application using the GET_DATA method.
So when we first create a new form scenario, we define what our choice will be for not only our form/UI (Adobe, FPM or mass data), but it actually defines how we are going to be passing our data back and forth as well.
Once we have selected our form type as "FPM form" and created our form scenario if we go to the form configuration section, we see:
If you notice the list of options for the drop down for "Type", you see that these are all related to the interfaces a "feeder" class for FPM implements. So for us, what is this "feeder" class that's doing all our old ISR heavy lifting? Well, I happened upon it during a debug trace, but there are numerous other ways to see what "feeder class" is defined for a FPM configuration. Enough beating around the bush though (sorry, that's a common American saying). So......drumroll please (oops! another American saying)............it .....is......called......
CL_HRASR00_FPM_FEEDER
...and let me just tell you...it does a LOT! It's "catch all" sort of class for us that implements all of the interfaces mentioned above (so when we select our "form type", it knows which implementation of which interface to use...wow! magic! haha)
If you look at the methods of the "form" and "list" interfaces, you can see the implementation of the GET_DEFINITION and GET_DATA methods as mentioned above in SAP's documentation. I will leave it to you to look at, learn and have fun with all the other methods of the feeder class itself. There are a lot of "cool" ones in there (hint: you might start with the INITIALIZE_DATA method). For example, if you set a debug spot in INITIALIZE_DATA, you can see all your form fields, their values and attributes (mandatory, read only, visible) as the form first loads up. Anyways....like I said....a LOT going on in that class. Have fun with it!
So if you are like me (and sorry for that haha), this begs the question....what is stopping me from developing my own, custom version of this feeder class? Well....NOTHING! It's not even marked as "final", so you could use it as a superclass instead of just copying it. Now, "should" you do this? I would not unless you had immediate needs not met by the standard class itself (or as sometimes happens, you found and can fix a bug that SAP has not yet addressed....I know...*gasp*...yeh, I just said that. haha).
Now that we see this "feeder" class, the question is obviously "how does it know what fields to make available when I am building my layout in FLUID?". Well this is pretty easy too. If you notice while in FLUID for the configuration of your form/list/composite, the top of the "general settings" area show...
Click the "feeder class" button/link, and you will see what "feeder class" is being used for your component (which you can also change).
Now click on the "feeder class parameters" button/link, and you will find out the answer to "how does it know my fields?". You see that the parameters tell the feeder class WHICH form scenario and form scenario version to use (since you can think of the form scenario as its own little container and all fields in it are shared among all form scenario steps in it).
So, much like our ISR interface would "synch" to our configuration and then that would in turn expose our fields in the Adobe LC Designer for our layouts, this is how it is being done for us in the FPM forms world. Pretty easy eh? However, this brings up a point of contention for me that I will most likely blog a rant about later (haha). It would be nice if these components could be shared around more easily if they had fields that NAMES matched with instead of having them so tightly bound to ONE form scenario....more on that another time.
Well, this was a short and to-the-point blog this time around, but I hope it helped cover a confusing but quite simple aspect of the "new" HCM P&F with HR Renewal. As always....more blogs to come! Till next time....
- SAP Managed Tags:
5 Comments
