Skip to Content

HCM Processes & Forms: Images/Logos and Reusable Components for FPM forms

     If you are familiar with HCM P&F using Adobe Interactive Forms, you know all too well that one of the major pains was keeping all of your forms consistent looking. Most all of your forms shared some similar sections of layout. For instance, you usually had a “boilerplate” area that contained your company logo, the process name, process reference number and other “common” information. Along with this, you most always had a “comments” section at the bottom of the form with the “Previous” and “Your” comment sections. For Adobe forms, keeping these consistent was largely a manual task….hand manipulating layouts on every form or “cut-n-paste” from form to form….to keep everything “in synch”. Sure, you could create your own library object to share across workstations, but even then, any changes done late to that “library component” would not auto-magically update all previously create, existing forms. In a nutshell, it was a nightmare with no real reusability in place.


     Big news!….with FPM based form (part of the HR Renewal updates to HCM P&F), reusable components are not only VERY possible, but they are also quite easy. In this blog, I will give away a few of my secrets to not only make life easier but also in hopes of spurning other great ideas from the community.

     Now, I will also add that when I say “reusable” it is not quite that straightforward. In my opinion, SAP missed the mark on how the implement configurations and assigning feeder classes. More on that later….

     So like I said, most forms have some “common” parts they all share. For example,


This form has a “header” and “footer” section that we most likely want to use on all other forms. So how do we do this in HCM P&F?

     Comments and Footers

     We will take the easy one first….the “comments” section. When we go to the “form” configuration section for our form scenario in the Design Time (HRASR_DT), we see a table of “configurations”. (note: I spoke about this in length in my blog HCM Processes & Forms: the Anatomy of a FPM Form and the Secrets of How HR Renewal HCM P&F Delivers Yours ). We create a new “form” type configuration and give it a description. For example, I created configuration “ZWD_HRASR_COMMENTS_CES” as ….


Once you enter the information, then click the “Create” icon on the tables toolbar. This will launch you into the FPM Designer (FLUID). In FLUID, simply layout your comment fields (drag the fields from the repository on the left panel onto your “Preview” pane and then adjust the attributes of each as needed to suit your design). For example,


Save your work and Viola….just that easy. Now you can add this to any FPM form you need simply by entering it into the FPM Configuration Table in the Design Time. Now keep in mind….you do not have to make just ONE reusable configuration (“like duh, Chris!” haha). You might want to make one like this but also make another one that only has “Your Comments” section for a form for the “initiator” only that never loops back to them (since there will not be any “previous” comments if they are the ones starting it). I am sure you can come up with others.

Boilerplates and Headers

     Now let us go back to the beginning….er….I mean back to the top….of the form….the header! Now usually for every process it makes sense to let the user know WHAT they are doing right from the start. Therefore, we usually include the process’ name, and it is also nice to include the process reference number (makes it very easy for your support desk people to have this number to use when hunting down issues). So let us build a “common” header in a similar way as our “comments” footer section….but with a slight twist.    

     First off, we know that we want the “process name” at the top of each form. However, we can not use a static process name on our FPM layout because we want to use this all around for our forms. So how do we do this? Easy!    

     We define a new form field in our form scenario fields. I called mine “PROCESS_DESCRIPTION” ,and you assign it the data element type of ASR_PROCESS_DESCRIPTION. Now, we simply assign this a manual default value of our process name (in my example, “Request Relocation Benefit”).form_config_header2.JPG    

     Back in our form configuration in the Design Time much like we did for our “comments” section, we create a new configuration for our “header” section.form_config_header.JPG   

     Again, we use the “form” type layout, but I called my configuration “ZWD_HRASR_HEADER” and gave the description. As before, click the “Create” icon in the FPM Configuration Table toolbar to launch us into the FPM design tool (FLUID). form_config_header3.JPG    

     Here, I dragged my “PROCESS_DESCRIPTION” field onto the Preview pane and adjusted a few things. I removed the label (set as “not visible), changed it to a “textview” field, changed its “Text View Design” to “header 1”, and positioned as I wanted. I saved my work and then if I launch my process now, you can see my new “reusable” header as well as our footer/comments too.


Keep in mind, you will have to make sure you add your “process name” field to every form scenario in order to make this work.

Advanced Components (Composites!)

     Now that we covered our reusable header and footer, let’s step itup a notch. Now I am REALLY going to share the good stuff….FREE of charge! haha    


     It is very common….especially coming from the Adobe form era of HCM P&F to have a company logo or some other image included in the header area of our forms. Usually, we display an image one corner and then have our other information to the side. But how do we do this with the FPM tools from our HCM P&F Design Time? Well, I will try to make this as simple to follow as possible, and then leave it to you to come up with more complex usages. In a manner of speaking, we first need to build our blocks before we can put them together.

     First off, I created a VERY simple WebDynpro ABAP component.


The ONLY thing this WDA component does is to display an image (there are PLENTY of example around the web of how to do this), however, there are some important points to follow.

  • Make sure you have added IF_FPM_UI_BUILDING_BLOCK as one of your “Implemented Interfaces” of your WDA component. Once added, make sure you have clicked the “Reimplement” button in the Action column. This sets up our WDA component to be a FPM UIBB.


  • From our WDA top node, right click and navigate through the context menu to import a new MIME object. This will allow you to select the image you wish to use as your company logo.


  • In your view for your WDA component, simply add a “image” element and assign it the MIME object you imported as its source.


     Now comes the FUN part! Back in the HCM P&F Design Time in our form configuration, we are going to add a new configuration in our FPM Configuration Table (just like we did in the example above for a header and footer/comment). First off, make sure that we remove our “header” configuration entry that we created previously. Do not worry, it is still there (ie. created), but just not used in our form now (remember reusability!). This time we are going to add a “Composite” type configuration which I have named ZWD_HRASR_BOILERPLATE. 


NOTE: When you add your composite to the configuration, be sure to REMOVE the configuration from this table that you will be using in your composite. Otherwise, you will get an error telling you that it is being used twice. Make note of the name of the configuration you will be using inside your composite because you will need it in the steps to come.

     Again, we click “Create” in the table toolbar. This will again launch the FPM design tool (FLUID) for us. The first thing we want to do is change our layout in the “General” pane at the top.


We select a split screen, and we also drag one of our UIBB elements in the “Preview” pane into our new empty side.


Now this is where the MAGIC happens! We now are going to assign our TWO UIBB elements.

In the “Composite UIBB Schema” table, we enter…


For UIBB (1), the component name is the name of our custom WDA component we made (i.e. YCES_HRASR_FPM_LOGO) and the window name is our window that holds the view for our image (i.e. W_MAIN).

UIBB(2) is the really interesting one. The component name is FPM_FORM_UIBB_GL2. How do we know that? Well if you read my other blog ( HCM Processes & Forms: the Anatomy of a FPM Form and the Secrets of How HR Renewal HCM P&F Delivers Yours) ,then you know that this is the component used for “form” type configurations in HCM P&F for FPM forms and furthermore, that the window name is FORM_WINDOW. But what configuration do we assign this? Well, guess what….we REUSE the “header” we configured earlier! I put in the configuration name “ZWD_HRASR_HEADER”. Yep! IT IS BACK! 

NOTE: Again, make sure that you removed the configuration “basic” configuration in your form configuration table since it is now included inside your composite here. Otherwise, you will get an error telling you it has been used twice.

So now, if I execute the process, we can now see our new “composite” boilerplate header with our fancy image displayed.



     Now, if you caught all that….and your brain gears are really churning now….you just exclaimed “EUREKA!” in your head because you realized what I actually just gave away. haha

     We just went WAYYYYY past talking about simple reusable “chunks” on a form. What we are talking now is that you can easily add ANY custom WDA component you create right into your form. Again….ANY WDA COMPONENT!!!! That means whatever HCM P&F can not do for you in configuration or additional functionality you might need, you can add it in using a composite component (and just look at the interesting ways the FPM framework allows us to communicate between UIBBs….the possibilities are endless) ! 

     Uh oh! Maybe I have said too much….I was going to talk about….uhm……well, I will save that one for later. haha

     Aside from the fancy, advanced stuff, you might also think of other “content” this might be applicable too. For instance, if you always have the same bits of employee information (name, ID number, position, org, etc) at the top of every PA form, why not make it a reusable component too?!?! Again, get that brain working, and I am sure you can come up with many use cases.

Reusable in a manner of speaking…but not quite perfect

     Now everything above where I mentioned “reusable” and how easy it is, is not exactly the whole truth (and I hope SAP is listening/reading and will fix this). When we create a configuration, you will notice if you go into FLUID to layout your design that our “feeder class” is assigned “feeder class parameters” at that point.

     So this is HOW we are able to see what fields are available to do our layout (much like our ISR interface would let Adobe LC Designer know what fields we could bind with). But there is the problem….the configuration is TIGHTLY bound to one form scenario. If you want to use it elsewhere, it might not work (I say “might” because I have seen a bug firsthand where I used one config from a different FSCN in another one and it somehow worked….I am thinking the feeder class looks at the first config in order and sets that parameter as what to use on all….more debugging on that later), but more than likely you need to do a few steps to “reuse” it.

     Step 1: Run WDA application CONFIGURE_COMPONENT.(go to SE80 and select WDA component WDR_CFGE_EDITOR)

     Step 2: This will launch the FLUID interface in a browser window. The “component name” will depend on your “configuration type” (form, list, composite)                     and I discussed this in my other blog HCM Processes & Forms: the Anatomy of a FPM Form and the Secrets of How HR Renewal HCM P&F Delivers Yours. The configuration name will be the one you want to copy. 

     Step 3: Click the “copy” icon and follow the steps to give your new, copy configuration and name.


Step 4: In our copied configuration, go in and now change the feeder class parameter. 


     After saving, you should now have all the correct fields from your own form scenario available in the repository.

     Now curiously enough, SAP does this with everything BUT our notes fields (I guess they assume those will ALWAYS be part of every form scenario). You can see this in method CONVERT_BACKEND_TO_FPM_DATA of class CL_HRASR00_FPM_UTILITIES.

     So I am not one of those to grumble and groan over a problem without offering up a solution. How do I think this should work to make our configurations TRULY reusable? I think the parameter for the feeder class should come dynamically from whatever our current form scenario is. For example, when we go into edit from our “form” section in our form scenario, it should know WHICH form scenario we are in. Now, of course you think “But Chris, when it is used in multiple form scenarios, there will be fields that do not exist!” Correct. So this has a couple of things I think it should handle…It could look at ALL the form scenarios for which we have currently assigned the SAME configuration. From those, it could consolidate the list of ALL fields from all of them down to ONLY the fields that exist in ALL of them for our repository. Secondly, in some way, it should also report to us if we are using a field in our layout that does not exist in one or more of the form scenarios using that configuration and which ones those are. This would be something like our nice process and form scenario “check” tools. If this was done, THEN I think we would really be able to QUICKLY build some nice forms! TRULY reusable components! Ok…rant over. haha

     As always, I hope you have enjoyed this and that it helps on your project(s) as well. As for me, I need to get back to work, so….like I always say…Till next time….

You must be Logged on to comment or reply to a post.
  • Nice blog Chris. You are opening up the framework very nicely.

    Your blogs are going very useful for folks working on P&F based forms be it Adobe or WDA FPM.



    PS: You seem to have missed mentioning one point – that the feeder class needs to be changed where relevant?

  • Chris Please Help.

    I followed these steps and I get this error.

    ERROR: View Is Already Displayed in Window COMPOSITE_WINDOW of Component FPM_COMPOSITE_UIBB (termination: RABAX_STATE)

    The error sounds logical as the View for header is already there in the config and also embeded in the composite view, How did you overcome this problem?



    • Oh yeh….guess I should update this ….you have to remove the “form” one before you can use/configure the “composite” one (which will include your form one in it). Found some more “gotchas” on this approach so I will update the blog.

      edit: UPDATED THE BLOG.

  • Great blog Chris.  I had been trying to get reusable components to work and came very close (my footer worked but header did not). I gave up ultimately because of the feeder class limitation (my header had a standard Employee Data section). I do hope this is something SAP can fix in the future.

    I may go back and re-implement a smaller version of the Header/Footer design, keeping any customer fields out of them, simply as preparation for future enhancements.

    • I feel your pain, Justin. Like I said, it is BUGGY. I have had it work for a reused “header” but then not for other components when just ONE field is different. I really hope, like I said, that SAP folks take a look at this (and maybe do something like I suggest)…or I might just have to come up with some enhancement myself. hahaha

  • Hi Chris,

    When we use a resuable component and plug it in to the HCM P&F I find that the alignment takes a beating no matter what we do,and it depends on screen resolution, so even if I align the fields correctly as per my screen it takes a different alignment in other computer and it defeats the purpose of reuse. Do you have any suggestions how we can overcome this?



  • Hi Chris,

         Excellent blog, really appreciate it.  I’m in the position of waiting for an EHP6 system to be built so I can start building FPM forms, so I can’t yet try this out for myself.  As I understand it, you can reuse a configuration (which is bound to one particular form scenario by the feeder class parameters) in another form scenario as long as the fields contained within the configuration are common to both form scenarios?  Or do you always need to copy the configuration and set the feeder class parameters in each one?  I require just the Process Description, Reference Number and company logo in a reusable header across about 8 forms initially – if I have to create 8 configurations will this mean editing each configuration individually in the future if we decide to add something else?



    • Peter, Just as a headsup, you might experience difficulty with alignments if you go for reusable component if the reusable component is a standalone Webdynpro, otherwise it should be OK


      Raghavendra Prabhu

      • Ok thanks for that.  I’m still not clear on whether you really can have a reusable component – so does this alignment problem happen when you have a standalone Webdynpro within a composite configuration, regardless of how many forms it is used in?



  • Hi Chris,

    Excellent info that I’m trying to implement on my project.

    But I’m facing some problems and let see if you could help me.

    I want to add a comments section, reusable on several forms, but when I add configuration to my form there is a problem with help values of the main form configurarion. Let’s say, I have the main one, with a several fields as dropdown listboxes wich they are feeded in a generic custom backend service, followed by my new form configuration with only Comments field.

    I have checked when I have the two configuration on FPM Configuration Table dropdown values are lost, if I remove second configuration (comments section) everything is fine.

    Did you notice something like that?


  • Hi Chris… This is really a great blog. It helps to understand how external WDA components can be integrated in the forms.

    May I ask, I’m struck with communication between external WDA component and the form fields. Can you please throw some pointers as to how I can achieve the same.

    Thanks in Advance…


  • Hi Chris,

    Thanks for all the info. I was wondering… would it be possible to create all WD configurations and assign them to a form scenario (so basically set the class parameter always the same) and then reuse them in different form scenarios?

    I noticed if you assign always the same form scenario for all WD configs you can use them in different form scenarios (since they will have the same form scenario assigned).

    I am considering this since we will have a composite configuration common to all form scenarios and it is absolutely outrageous to replicate this configuration 30+ times!!

    What do you think about this approach?

    Thanks in advance.


    • Sadly Andre….you hit upon one of my biggest gripes with how they use FPM configurations in our HCM P&F framework. Because the feeder class depends on a particular Form Scenario  in order to know what fields are available in it’s context (and their type), you can not reuse the configurations among form scenarios (unless you get lucky and have a configuration with the exact same fields ….which I have gotten to work but it is buggy and results are not consistent). I end up having to copy configurations and then change the feeder class parameter for form scenario. It is a royal pain in the….well….you know. haha I have looked at modifying the feeder class to handle it but I did not spend a whole lot of time on it.

      • I am really disappointed…

        Let me share our requirements… we will have a dynamic workflow and for each scenario the system will determined fixed approvers and “optional” approver that can be added after the fixed approvers (to support multiple processes in all companies & countries).

        So we build up a list form as you can see


        Then we came across this major issue of replicating configs and we thought this would be possible if we include in a form scenario that will not be used at all but will have all fields and all WD configs (IT0001, IT0002, etc , comments, approvers list etc)

        So in this form list we will have all of them and then reuse these configs on the “real” form scenarios.


        Do you think it might work?

        Thanks again.


        • Short answer….nope. Because your workflow step is bound (bindings) to a specific form scenario…which in turn has it’s own specific “form” defined with it’s own configurations.

          Like I said, it *might* work because fields match, but results are not consistent. Let me think on another way and get back to you (yes, I have done these kind of fixed/dynamic approvers on forms too before)

          • Thanks again Chris.

            Regarding WF we decided to simplify a little and we decided to have a single form scenario per process and using this approach I can do the binding dynamically to object porcess.leadingform which is instantiated when the WF is triggered and use the same workflow for all processes (I cannot afford spending time with copy and paste bullshit on workflows too 🙂 )


            Thanks a lot for helping us on this.


          • haha great minds think alike! I did the same in the past… workflow was pretty much the same for about 6 different OM processes. I just made one workflow and used for all of them using similar way. 😛

          • Thanks Christopher.

            Just came across with another issue as Standard Task TS33700022: Approve Form (Web Dynpro) – does not allow the approver to change the content of the form. So even on the custom config with multiple approvers table the data cannot be changed. Do you have any hints how to solve this topic? Set an approval task where we are allowed to change the form data?


          • Yes Andre,, that task is for display only approve. even if you make it editable using ui attributes, the form will still fail in capturing the entered values. May be you can try creating enhancements in feeder and push the entered data.

  • This is not the right place for this and you have posted it across at least 4-5 places that I have seen. Make a separate thread for it and ask your question there. Spamming like that will not get you help faster.

  • Hi Christopher,

    We have the same requirement which you have covered in the above blog and that is RE-USABILITY.

    We are creating FPM Form having many common parts which we will be using in other forms as well. For each part, we have created separate Generic Service and Form.

    Now while using this in Generic Service/Form in other Process, it is giving me Null Pointer issue. Any specific setting  which I might be missing.

    500 SAP Internal Server Error

    ERROR: Access using a ‘ZERO’ object reference is not possible. (termination: RABAX_STATE).



  • Thanks Federica for your response.

    Havn’t checked but this make sense to me as I can see Form Scenario of the Old Process.

    But in that case don’t you feel we are losing the re-usability feature.

    This maybe a basic question as I am new to this Framework.



    • I know what you mean.

      I have copied all of them of every form scenario and so on.

      Try if you get the same error again.

      Let me know, anf if you find anither way to do it don’t esitate to share it 😉

      Have a nice day

    • Re-read the blog CAREFULLY. Basically, as I point out…it would be nice if SAP allowed us to have form configurations reusable among form scenarios, but due to the feeder parameter pointing to ONE form scenario, this is just not possible (without doing some feeder class enhancement….which I have done before to make it work…but it is an enhancement). It is possible for it to work in some cases (when the fields you use are the same in both form scenarios….like current/previous notes), but even then, it is not reliable and can cause additional problems in synchronization.

      What I end up doing is creating my “boilerplate” configurations in one “template” process and then just copy them into my own form scenario where needed and make sure to change the feeder class parameter to point to my new form scenario. And yes…if any changes are made to the “boilerplate”, you have to make sure you make the same changes all around. Ugggg. Thanks SAP! (*keep in mind how long ago I wrote this original blog and still they did nothing to work on this).