Skip to Content

     Eventually, anyone working with HCM Processes & Forms will encounter the need to create a “table” in their form interface. It might be needed to display all the wage types that make up Basic Pay or maybe all recurring payments made to an employee. Just like that lingering student loan, you can try to avoid it as you may….but oh yes….”data in table format” will find you!!! It will be at this time that you also realize how pretty complicated SAP has managed to make this seemingly straightforward, simple idea play out in our HCM Processes & Forms (HCM P&F) world. I explained this “long ago” in the “old” Adobe Interactive Forms world we lived in (HCM Processes & Forms: The Trouble with Tribbles…er, Tables ), but thankfully, we have managed to evolve a bit in the “new” FPM form option now available.

Backend

     The first thing to understand and “wrap your head around” is how a “table” is actually represented in the HCM P&F framework. If you are familiar with defining our “form fields” in configuration of our form scenario, you have noticed that there is no where in there to define a “structure” for table rows or anything like that. You have to think of it in a slightly different way.

     You define your “form fields” as we all know and love as:

/wp-content/uploads/2015/04/form_fields_715537.jpg

      But then, you need to visualize them a bit differently. Imagine you form fields as actually “columns” in your table.

/wp-content/uploads/2015/04/form_fields_as_table_715538.jpg

     As you see, the one thing that allows us to know which “row” of our table we are referring too is the index number. For example, if we want row 2 in our table, we would have to look at each form field that has an index value of 2. Otherwise, there really is nothing that enforces our columns staying “in synch” with one another (as you might find if you manually add a “row” and forget one of the columns).

     In our FPM forms, a “table” is considered a “list” component, so you will actually create a “configuration” of the standard FPM “list” component FPM_LIST_UIBB_ATS. When you create your configuration, in the FLUID design tool, you will actually “bind” your form fields to the table columns. I will not cover that here as it is basic FPM form development.  However, for CRUD (Create, Read, Update and Delete) operations, let us look at how we add this functionality to our table.

     To add the buttons for our operations (add and delete), we switch to the menu view of our list configuration and click “add toolbar element”:

/wp-content/uploads/2015/04/fluid_add_btn_715540.jpg

Then we select from the standard “user events”:

/wp-content/uploads/2015/04/fluid_add_event_715544.jpg

Once we add the “Add Row” button, we can make settings to it’s attributes (and we can see the standard USER_EVENT_ADD_INDEX_ROW event as it’s “action”):

/wp-content/uploads/2015/04/fluid_add_event2_715545.jpg

Similarly, we add a button for “delete”:

/wp-content/uploads/2015/04/fluid_del_event_715546.jpg

We can see and change it’s attributes as well.

/wp-content/uploads/2015/04/fluid_del_event2_715553.jpg

We can see it is tied to the USER_EVENT_DELETE_ROW “action”. In runtime, this now appears as:

/wp-content/uploads/2015/04/fluid_runtime1_715554.jpg

But what if we want to add an icon to our “Add Row” button? Let’s go back and add a little icon on the “Add Row” button. We simply click the “Image Source” dropdown and select from the pop-up window:

/wp-content/uploads/2015/04/fluid_addicon1_715555.jpg

There are lots of standard options. We select one and save.

/wp-content/uploads/2015/04/fluid_addicon2_715556.jpg

In runtime, we now see a “fancier” view as:

/wp-content/uploads/2015/04/fluid_runtime2_715557.jpg

Since we are using “standard” events, these are caught and handled in the standard “feeder” class.

/wp-content/uploads/2015/04/feeder_1_715558.jpg

…and more to the point, it all is handled in this method:

/wp-content/uploads/2015/04/feeder_2_715559.jpg

But now…..on to the operations!!!!

Create (add row)

     If we look within the feeder class, we will see this particular handler for our “add row” event.

/wp-content/uploads/2015/04/add_row_1_715564.jpg

…where c_user_event_add_index_row is a constant class attribute defined as:

/wp-content/uploads/2015/04/add_row_2_715565.jpg

So we see it calls method ADD_ROW_AT_INDEX. From the comments in this method:

     This method is called to add a row after selected index for Simple LIST provided the row selected and row after the selected row is not blank. If both this condition meets then only we add a blank row after the selected row. For doing so we directly add the records for the new index in A_FORM_DATA and rearrange the indices appropriately. This method is only provided for Line type structures in PA or table type infotypes in PD as in that case only we are allowing to add a row at any index and also we can select multiple rows and add rows after that provided the above given two conditions does not fail.


So when the user clicks the “Add Row” button which fires the standard “user_event_add_row_index” event, this is handled in the feeder class.

This calls class CL_HRASR00_FPM_FEEDER method ADD_ROW_AT_INDEX via method IF_FPM_GUIBB_LIST~GET_DATA. This will add a row under the selected row (and resort indexes) or add to bottom if no row is selected.

Let us look at the “simple” case. We start with an initial row, so we enter some data in it to make it unique (ie. has value):

/wp-content/uploads/2015/04/add_row_ex1_715566.jpg

We then select the “Add Row” button.

/wp-content/uploads/2015/04/add_row_ex2_715568.jpg

After clicking it, we get a new row added underneath the previous row:

/wp-content/uploads/2015/04/add_row_ex3_715569.jpg

This is all handled for us “auto-magically”!

But let’s show a bit more complex example to show you what it will really do. Here, I have defaulted some values into my table:

/wp-content/uploads/2015/04/add_row_ex_complex1_715577.jpg

If I click “Add Row” now, it simply adds a new row to the bottom for me. The nice part is that it has also handled adding this new “row” into our dataset as well (unlike the old days where the ISR interface could not handle that for us!)

/wp-content/uploads/2015/04/add_row_ex_complex2_715578.jpg

But the additional “nice’ thing this event will automatically do for us is to add a new row at a specific point in the table also! (ie. “Add row at index”). For this, we must first select a row:

/wp-content/uploads/2015/04/add_row_ex_complex3_715579.jpg

Then, we click the “Add Row” button and we will see:

/wp-content/uploads/2015/04/add_row_ex_complex4_715580.jpg

Again, the feeder class handles adding the “row” at the specific index and then reordering all other rows for us. MAGIC!

Read (read row)

     There is not a whole lot to cover on “read” as it is handled either by using “standard” configuration to the standard services (SAP_PA, SAP_PD, and SAP_PT) or your own generic service. This is how you “default” your values into the table. Now, if you would like to “read” the row the user currently has selected (for example, if you wanted to display a “details” section under your table to show more information about a selected row.), well, sorry to say, there really is not anything “standard” as far as I know (though I do cover how to detect the “selected row” later in part 2 of this series!).

Update (modify row)

     There is nothing directly “standard” for updating a particular row other than how you layout your column definitions. For example, if you want to allow the user to update a field, you would just define the control used for the column (“display type”) as an input field or drop-down list or whatever. Because your field is bound to the list/table, it knows automatically which index you are updating. There is really nothing you have to handle from there.

Delete (remove row)

     The delete operation is an interesting one in that you might be looking at the wrong one if you are not careful! This is due to how SAP has named it in the feeder class code. Remember that our event is USER_EVENT_DELETE_ROW ,so be careful that you are looking at the right one. Looking at the class attribute, we find:

/wp-content/uploads/2015/04/del_row_1_715581.jpg

…and the constant name might look wrong at first. Do NOT get it confused with (which gets called on line 297):


/wp-content/uploads/2015/04/del_row_2_715527.jpg

Our code for “delete row” is actually handled here:

/wp-content/uploads/2015/04/del_row_3_715528.jpg

     So when the user clicks the “delete row” button, this calls class CL_HRASR00_FPM_FEEDER method DELETE_ROW_SIMPLE via method IF_FPM_GUIBB_LIST~GET_DATA. This will delete the selected row from the table and re-order the indexes on remaining rows.

Let’s start with a bunch of initial rows.

/wp-content/uploads/2015/04/del_ex_1_715593.jpg

Now we select a row and click the “Delete Row” button.

/wp-content/uploads/2015/04/del_ex_2_715594.jpg

Here is the result….as expected, our row is removed.

/wp-content/uploads/2015/04/del_ex_3_715596.jpg

The nice thing to notice it that it does reorder our indexes for us as well:

This is our “index” column before the change.

/wp-content/uploads/2015/04/del_ex_4_715597.jpg

It then deletes the selected row (index 4)

/wp-content/uploads/2015/04/del_ex_5_715598.jpg

And finally, reorders the remaining ones (you can tell because our “Values” are now off from the true index itself).

/wp-content/uploads/2015/04/del_ex_6_715599.jpg

Limitations and last thoughts…

     As you have hopefully seen, SAP provides some very nice “standard” events for most all of our CRUD needs and feeder class code to handle those. We can add rows and delete rows quite easily without having to put any additional code into our own process configuration via “do operations” in our generic service or what have you. However, there are some drawbacks to this “automatic” handling for us. This is not an exhaustive list and is just off the top of my head….

Add Row

  • No way to validate before row is added. For example, what if we do not allow more than some maximum number of rows?
  • No way to handle default values intelligently. What if we want our new row to have particular default values based off of some business logic?
  • No pre/post logic allowed. We cannot really do anything before or after we add the row. For example, what if we wanted to display a message about the new row?

Delete Row

  • No way to catch/trap/validate a row marked for deletion. What if we do not want our user to delete “existing” and only allow them to delete rows they added as “new” entries?
  • No “follow up” on delete. What if we wanted other things to occur after a delete? Maybe we want a recalculation of some total.

     If you want better handling of these events, well….it is time to take matters into your own hands….which is what we will discuss in…

HCM Processes & Forms: CRUD with FPM tables/lists – part 2 : Advanced Operations.


To report this post you need to login first.

3 Comments

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

  1. Philip Johnston

    Ok Chris, you’ve outdone yourself once more.  I appreciate the easy to follow teaching documents.  Keep up the good work and save some of the contractor dollars for TechEd in Vegas.  See you there..

    (0) 
  2. Jim Reyes

    Hello Christopher,

    Thanks for sharing this knowledgeable documentation.

    I need you expertise on my requirement.

    I have the same requirement to implement to add new Row but i my feeder class does not have the event to add new Row and i need to create a custom button for it.

    Feeder class is /PLMU/IF_FRW_G_AFTER_GET_DATA

    I have added the button already using a code below in the method and the button appeared.

     

     

    On the left of the button delete is the button to Add new row where i added.

    Now, seems i’m having difficulties in coding this to a new method since as per checking on your example the add method you have is already exist.

     

    Please advise, looking for your help on this.

    please provide any code logic needed.

     

    Thanks

     

    (0) 

Leave a Reply