For those familiar and experienced with developing forms for HCM P&F using Adobe Interactive Forms, you will have to think of "forms" in a whole new way if using FPM (Floor Plan Manager) based forms. I am still having a hard time referring to the FPM based ones as "forms"....but "configurations" or "layouts" just sounds way weirder still. I will leave it to folks far more clever than me to come up with something better suited. In the meantime, let's talk about what the FPM forms are and maybe I can give you a better way to look at and understand them.
From the Adobe Interactive Forms world, we think of a form as just that....a SINGLE form...much like a print/hardcopy form. As an Adobe form developer, we are used to laying out and arranging our form as creative as we like but all within one form instance. We might have used subforms to arrange areas on our form...maybe even subforms within subforms within subforms. In the end, we had everything all nicely living together in one easy to find spot.
Forms based on the Floor Plan Manager framework, however, are just a little....ok....VERY....different. It is easier to think of our FPM based "form" as actually a collection of "building blocks" (configurations of blocks we cobble together actually). You will notice when you are configuring your FPM based form for a form scenario in HCM P&F, you are given a table with the option for several "configurations" of various types.
Their order is important because this is the order in which you are actually "building" your form. As an example, we might have a FPM form that appears as:
As you can see, our "form" is actually made up of three separate "configurations" or "blocks". Each of these, we lay out separate and independent of each other, but in the end, they all come together to appear as a single "form" to our end user. These types are referred to by SAP in documentation as HCM PF FPM Configuration Types. The "type" you select will depend on your need. From SAP documentation, they suggest these guidelines:
In the Design Time Tool, you can create forms using the following user-interface building blocks (UIBBs):
- Form – You use this when you want to display data using a form. For details, see Creating a Form Layout.
- List – You use this when you want to display or perform operations on repeat fields of a single infotype record. For details, see Creating a List Layout.
- List Complex – You use this when you want to display or perform operations on multiple records of a single infotype. For details, see Creating a List Complex Layout.
- Composite – You use this to group multiple UIBBs within a single UIBB. For details, see Creating a Composite Layout.
from https://help.sap.com/erp_hcm_ias_2013_01/helpdata/en/3d/8bf4fe6365452197bf4dbb179aa11b/content.htm
WARNING: Now, this brings up a pain point with me (and I am sure some others might feel this). One of the "type" options is called "form" which I think could be very confusing for people who are configuring their FPM form. If I think about this in the shoes of someone coming into HCM P&F with no experience and thinking "ok, this is where I configure my FPM form", I can see where they would think "oh, I am configuring my FPM form, so of course, I need to select the 'form' type here and layout my whole form". WRONG! And the SAP documentation does not help with the equally confusing description "You use this when you want to display data using a form." True, you will be configuring your FPM form for your HCM P&F form scenario, but do not get the "form " configuration type confused for this. The "form" configuration type simply describes the layout you will be building....basically that you are laying out a simple "web form" (like a bunch of label/field sets all arranged together).
So now that we know that a FPM based form is just a bunch of building blocks of configurations of layouts pieced together, how does HCM P&F know how to build our form for us? ....and furthermore, since the new HCM P&F is actually running in a FPM layout itself, how does it know how to build our form dynamically?!?!? MAGIC!!!!!!.....ok....not so much....prepare for a long winded, detail of something quite simple actually.....
If you run transaction SE80 and select package PAOC_ASR_WD_PROCESS_EXECUTE, you can locate all the FPM configurations used for the various "Process Execute" applications.
These are the "new" FPM based options for all the previous applications you might be familiar with. Now, I will show you an easy way to find the actual WebDynpro ABAP application component being used and which window/view in that application as well.
We will take a look at one that many of us are most familiar with....the PA "start application" which is listed a "ASR_EXECUTE_5_STEP_PA". What it is referring to there is our usual 5 steps in a PA process initiation:
- Select Employee
- Select Process
- Edit Form
- Check
- Send
If we select ASR_EXECUTE_5_STEP_PA, we will see:
Select the Start Configurator button at the top below the main menu area. This will launch us into the FLUID (flexible user interface designer) application. (note: FLUID is a whole other discussion to itself, and I highly suggest you play around with some of the many tutorials for it that can be found on the internet.) On the initial FLUID page, select "Continue in Display mode" from the menu bar at the top. This will bring us to the page showing our other configurations within this configuration (yes, it gets layered ....remember that FPM is a collection of configurations that describe layouts for areas all over your screen/page).
From this table, select the "ASR_EXECUTE_5_STEP_PA_GAF" configuration at the right end of the table (click the link!). Now, this is where things get interesting! (note: there are "flavors" of FPM configurations....GAF refers to the "guided activity floorplan"....which I always think of as "ahhh the one with the little road map thing at the top!" haha.....you can look into the others like OIF/"tabs" and QIF on your own)
The Preview section of our FLUID designer shows how our page will layout our "building blocks".
As you see in the image, if you click on "Step 3" in the road map and then click the "UIBB area", you can see at the bottom (the Attributes area) exactly what WebDynpro ABAP component/app is being called and exactly what window of that app (which has it's "default view") is used for that "road map" step. Just for grins, I put together this table so you can reference what WDA is used at which step (in case you might want to make an enhancement):
| Road Map Step | WDA Component | Window | View |
Select Employee | HRASR00_PROCESS_EXECUTE_1 | W_SELECT_EMPLOYEE | V_SELECT_EMPLOYEE |
| Select Process | HRASR00_PROCESS_EXECUTE_1 | W_SELECT_PROCESS | V_SELECT_PROCESS |
| Fill Out Form | HRASR00_PROCESS_EXECUTE_1 | W_EDIT_FORM | V_EDIT_FORM |
| Review and Send | HRASR00_PROCESS_EXECUTE_1 | W_EDIT_FORM | V_EDIT_FORM |
Send | (no component/button event) |
Ok, so now we found where our "Edit Form" step lives, but how does it know how to "build" and layout our form once it is here? I mean, from our configuration in HRASR_DT for our FPM "form" in our form scenario, how does it know how to put our form together (since we are no longer simply displaying an Adobe Interactive Form)?
You can think of our FPM "form" as a composite of "building blocks" as I said. In the FPM world, these are called UIBBs (User Interface Building Blocks). So naturally, we want to find where our "composite of UIBBs" is being formed, and wouldn't you know it...it is just that obvious....
If you step through some debugging, you will see that the method GET_COMPOSITE_UIBBS of class CL_FPM_FLOORPLAN_ASSIST is called. Here you will look for <LS_UIBBS> to be assigned in the code....
* Get composite child UIBBs and add them to the table of UIBBs which are relevant for the event
CLEAR lt_uibb_key[].
<ls_uibb>-interface->get_uibbs( EXPORTING co_event = io_event
IMPORTING et_uibb = lt_uibb_key ).
If we follow this, we find that <LS_UIBB> gets assigned the "interface" of
CLASS-POOL=/1BCWDY/0O2TINOC26HHIKWDANML\CLASS=CLF_COMPONENTCONTROLLER_CTR
There is a LOT going on in there in the method OVERRIDE_CONFIG_COMPOSITE! In that method, you will find TWO very important calls to other methods. The first is to the method GET_FPM_CONFIGS_FSCN of class CL_HRASR00_FPM_UTILITIES.This method actually loops through our HCM P&F configuration for our form scenario and will "collect" all of our configuration types and configurations information.
Shortly after this it calls method GET_FPM_CONFIG_TYPE in class CL_HRASR00_FPM_UTILITIES as well as it loops through our configuration types to figure out how to dynamically "build" our form.
LOOP AT lt_fpm_configs INTO ls_fpm_config.
" Add the new UIBB
CLEAR ls_uibb.
cl_hrasr00_fpm_utilities=>get_fpm_config_type(
EXPORTING
iv_config_type = ls_fpm_config-config_type
IMPORTING
ev_fpm_component_name = lv_component_name
ev_fpm_interface_view = lv_interface_view ).
Each type tells us which actual WDA component to use as our UIBB which in essence is really just defining our "canvas" for how our configuration says to lay out our HCM P&F form scenario fields.
So back to our original FPM example form image,
....this tells us we are using window FORM_WINDOW of the FPM_FORM_UIBB_GL2 component (form) , then the window LIST_WINDOW of the FPM_LIST_UIBB_ATS component (list) and then again using window FORM_WINDOW of the FPM_FORM_UIBB_GL2 component (form) for our "comments" section. In effect, we used 3 UIBBs to build our form.
So that's about it. Unlike an Adobe form which can be thought of as a single form/document that can become a tangle of subforms within "subforms within subforms" in order to layout your form correctly not to mention a performance nightmare, our new FPM based forms are really a collection of building blocks. Knowing this, the possibilities are much more open now for your to layout your forms. Careful though....as they say...."With great power comes great responsibility." haha
As always, I hope this helps. I hope it helps clear up any questions and/or confusion about how the new FPM based forms actually get created. With HR Renewal, there is plenty more to cover, so I will keep cranking out blogs if you keep reading them. haha Till next time....
- SAP Managed Tags:
13 Comments
