Once you "get your feet wet" with SAP HCM Processes and Forms and Adobe Interactive Forms development, if you are the typical developer/gearhead type, you will want to jump from laying out and binding regular old single input/output fields (which the LiveCycle Designer practically does for you itself) to doing full blown dynamic tables. That's where the real fun is, right?! (haha)
First of all, you need to understand how a "table" is realized and visualized in the world of HCM P&F. We do not really have a table that is composed of a number of rows of fields. We have a individual fields that are "arrays". To define our fields as "multi-line" (ie. arrays) we have to reference them to special data structures. You will know these because they have "_LIN_" in their name. (if we define them ourselves....for example, not mapped to SAP_PA using multi-line structures....then we have to handle making them multi-line ourselves via generic services but that is beyond this discussion). For example, we can tell the "multi-line" fields from our normal (single) fields in this definition.
But with each INDIVIDUAL field defined as "multi-line", how does this become our concept of a "table"? What if we wanted a table like this on of form? To visualize this, let us consider a common example of "wage types".
Our table is just really "columns" of these fields. These "array fields" that share a common "index" number can be thought of as a "row".
As you can see if we wanted our first "row", we would loop through all of our fields with index 0.
Now, back on our Adobe form side of things, it is actually quite easy to add a table to a form and then bind our table columns to our data fields (again, think of our table as actually "a collection of columns of data field arrays"...oof, now my head hurts....ok, maybe do not think about it much at all....haha). This is pretty basic Adobe form development work, so I will not go into it here.
But now we want to get "fancy" with our form and dynamically add and remove rows! You might want to build something like this....
You will most likely search around and discover tutorials like THIS ( http://help.adobe.com/en_US/livecycle/9.0/designerHelp/index.htm?content=000178.html ) one which discusses using the "Instance Manager" via script to add and remove rows dynamically. It works great! There is even a nice online example HERE (http://forms.stefcameron.com/samples/tables/ExpandableTable.pdf). Very VERY easy!.....but it does not work for us. BOOOO!!!!!) This will frustrate you (well, it did me).
Deleting rows is not so much the issue. It is adding rows that will cause you grief.....maybe some head scratching....hair pulling....and in extreme cases, much gnashing of teeth can occur. (haha) The problem lies in "how" the ISR Framework handles our communication from the HCM P&F framework to the Adobe form and back again. You would think that if we want to "add" a row on the form side, we simply increment our indexes across our "collection of field arrays" and viola, we have our new row. Not so. This is what will happen....
- the framework sends out the fields (in this case, let's call our field "WT") that it has determined the number via generic services or standard SAP_PA. In this example, let's say we found 3 wage types and are sending them over to our form.
- Our fields "pass" through the ISR interface which communicates with our form. Our form displays them as a table.
- On our form, we have some script (FormCalc or JavaScript) that our user has executed to dynamically add two rows to our WT table. These new fields are WT(3) and WT(4). Our user submits the form which communicates back through the ISR interface.
- The ISR interface receives our fields....but strips off/ignores the two added ones. WHY!?!?!?!
What happens is simply that our "field length" is defined from back-to-front (one way)...not circular....and not truly dynamic. Our backend says for example "I am sending you space for 3 WT fields....and I expect 3 WT fields back" (an "empty" field would simply denote one that was deleted...so now you see why a "delete" is easier). If we add more on the front end (ie. the form) and then send them back, the interface is simply blind to any more than the 3 fields we sent over. It will ignore anything more than what it sent over to begin with.
Soooooo how do we handle this?!?! What you will find fromsearching for tutorials, examples, forum posts, etc, is that there is basically a standard, common way this is done....by using a "user event" defined in your HCM P&F configuration. This is how it pretty much works:
- Same as before....the HCM P&F framework determines it's field length for our multi-line field (by generic services or SAP standard services) and sends this to the ISR layer.
- Our fields "pass" through the ISR interface which communicates with our form. Our form displays them as a table.
- The user clicks a button on the form (or triggers in some way) the "add row" event.
- The "add row" user event is sent to the framework.
- The HCM P&F framework adds a new field entry(index) in our multi-line field (usually via a generic service operation).....basically, the generic service "makes new space" for the field to be used. Like step #1, this field information is passed to the ISR layer again.
- Our fields "pass" through the ISR interface which communicates with our form. Our form displays them as a table.
- The user enters data in the new fields/row and submits it back to the ISR interface.
- The ISR interface picks up the 4 entries for field WT....the same number it sent over and expected back.
I personally despise this method. This seems VERY kludgey to me not to mention causing a round trip back to do something so simple and more than likely requiring you to build an additional generic service just to handle this for you.
Now I cannot give away all of my little personal tricks and secrets, but I can give you some hints. If you look back at the images of the process of sending and receiving fields over, you might get an idea of how to handle the constraint of defining field length back-to-front while also giving the user the flexibility and user friendliness on the front end to make adding rows "seem" to them to be instant and dynamic. At least this is how my "secret" solution came to me. (haha)
Think of it this way.....there is nothing stopping us of defining SEVERAL "empty" fields to send over on the backend even if we are not going to use them....we are just defining "space". So for our wage type example, we might find that an employee might have at the most maybe 8 wage type entries at one time. Ok...so we define our "space" to have let's say more than enough room....we set up 25 entries to send over. Now of those 25, let's say our selected employee only has 5 actual entries. Therefore, our first 5 field entries have data and the remaining 20 do not. We send this ALL from the back, through the ISR layer to the form. On our form, we set up our table and define it as such that we hide any fields/rows that do not have a value in them (empty). So our user sees the table showing only 5 rows (the ones the employee has data for). Now if the user would like to add a row by clicking our nice little "add row" button, they click the button and instantly we add a new row....simply by marking our next "row" from hidden (since it was empty and we hide all empty rows) to "visible". Just that easy! To the user, it appears nice and instant, and for the backend, it gets back the same 25 field entries it sent over. Everyone is happy....especially me at that point. (haha) The scripting can be a little tricky for all of this, but I think you can work through it....simple "presence" settings on fields(visible/invisible) and looping through field indexes to do things...you figure it out...and no, I am not going to provide it for you (haha).
So that's it....hope you learned a bit about "tables" in the HCM P&F world, what to watch out for, how to work with them.....and most of all, how to make "magic" happen for your users! Till next time.....
- SAP Managed Tags:
5 Comments
