Skip to Content

     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 /wp-content/uploads/2013/06/feeder_233730.jpgblood 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.     

/wp-content/uploads/2013/06/fsc_create_233731.jpg

    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:

/wp-content/uploads/2013/06/form_type_233802.jpg    

     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)

     /wp-content/uploads/2013/06/feederclass_233801.jpg

     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…

/wp-content/uploads/2013/06/feeder_config_241224.jpg

     Click the “feeder class” button/link, and you will see what “feeder class” is being used for your component (which you can also change).

/wp-content/uploads/2013/06/feeder_config2_241225.jpg

     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).

/wp-content/uploads/2013/06/feeder_config3_241235.jpg

     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….

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Nic Van Diermen

    Good work Mr Solomon. I must say i have been waiting for your next series of blogs since SAP did away with ISR framework requirement for forms. Your previous blogs on Adobe interactive forms were a valuable source of info (and amusement). LifeCycle designer is dead – long live FLUID!

    (0) 
    1. Christopher Solomon Post author

      haha Thanks…it’s nice to feel appreciated….or at least close to that. 😛 Now, I will warn you to pump the breaks a bit on your enthusiasm….I don’t think Adobe/ISR is dead (has ITS taught us nothing!!!! *shakes fist in air*)…it just has a time and place AND there are other options now available. That being said (and I had this discussion with someone else today)….SAP is “gifting” us with FPM (developed with FLUID)….however, if you read between the lines, the door is now open for MUCH more….and I plan to blog on that….next? haha Stay tuned!…and THANKS AGAIN!

      *side note: one nice thing about ISR is that it is a pretty simple “broker” layer…on a very early HCM P&F project, we developed a Blackberry app for a process approval step that was just pure Java interacting with ISR and some exposed RFCs….to SAP for all purposes, it “looked” like an Adobe form was talking to the framework just as usual….so yeh, it has its place at times but those places are shrinking fast. 😉

      (0) 
      1. Raghavendra Prabhu Mithal

        Hi Chris, Another good one from you. Are there concept of generic services in FPM base forms also, incase we need to implement our custom logic then is there a way.

        And does this feeder actually replace CL*HRASR*PROCESS* classes by any chance.

        (0) 
        1. Christopher Solomon Post author

          You will still use generic services. MUCH is all the same…just the “form” part is switched out.  I will be blogging more on other aspects and concerns to keep in mind with FPM.

          (0) 
  2. Ghadeer Zahaiqa

    hi Chris

    Many thanks for your great blog , but please we need more blogs how to get advantage of

    feeder class in developing HCM P&F

    and one more question , is it possible to bind external WDA with form scenario fields ? if yes , how we can do that

    Regards

    (0) 

Leave a Reply