IBM BPM: Tables and Data Column

IBM BPM: Tables and Data Column

Published By : Neil Kolban November 27, 2017

Consider a table within a Coach.  Tables, by definition, are composed of rows of data where each row is composed of distinct and multiple columns.  For example:


Here we see a table with three columns we have called “A”, “B” and “C”.  Within the Human Services environment, we then bind a table to a list of business objects and associate each column with a field in the business object.  When the table is then displayed, a row is presented corresponding to each element in the list.  A cell in the table then displays the value of the bound field within that business object.

Some important points to note.  First, column names don’t have to be related to the field names within the business object.  I can just as easily create a column called “A” and bind it to a field called “X” within a business object.  Next, not all fields in the business object have to be visualized.  Only the columns I explicitly add to the table result in data being presented to the user.  Each column is bound to a field within the business object.

This takes care of simple visualization of data.  However, there other aspects of information beyond their simple appearance.  An example would be whether or not the field is editable.  By default, we can set an attribute on a column describing its ability to be edited.  If true, then all instances of that cell in the column are editable and if false, then none are editable.   But what if we want something more sophisticated.  What if we want to selectively enable or disable a column in the table as a function of some other data element in the row’s data.

In our example, what if we wish the “A” value of the cell in a given row to be editable based on the value of “C” (a visible field) or “D” a (field not shown)?  How might we achieve that?

Create processes with zero technical knowledge. Try the SPARK Quick Process Builder now!

The following video illustrates one example of such a technique.  Give it a view now.


The core take-away from the video is the use of the Data control.  This control can be bound to a field in a business object and, when the field changes, an event associated with the control is fired.  This provides a bridge between changes to data variables and the world of events that can cause work to occur.  By adding a Data control as a column in the table, this causes an instance of the Data control to be created for each row in the table.  Each instance of the Data control is then associated with the instance of the business object used as the backing data for that row.  The result is that we have per-row event handling for the Data contained within that row.

Next we have the apparent puzzle of how being notified that a field in the row has changed (or has some initial value) can be used to modify the characteristics of a distinct column.  The solution to this is found by realizing that the when a Data control event fires, it fires in the context of the row in question.  In the event handler we can leverage the me local context variable which will reference the Data control which is in the same row as the other cells we are interested in manipulating.  By having a reference to me we can then access other controls in the same row by using me.ui.getSibling(controlName).  Once we have a reference to the control we wish to modify, we can invoke its methods (such as setEnabled()) to affect the change we wish.

Finally, we have nothing to visually show associated with the Data control column and we come to our last technique which is to make that column invisible or hidden.  By hiding that column, it simply does not contribute to the visualization of the table but remains present.  This is ideal for non-visual controls such as our Data control.

An important item to watch out for is that you can only reference sibling Coach Views (read our article on IBM BPM enabling coach views from other coach views) if they exist.  While that may sound obvious, realize that columns in a table are constructed left to right.  If we had placed our Data control column before the column containing the cell that we wish to locate and modify, it would have failed.

There are other techniques available that can achieve similar results.  For example, if we wish to make field “A” editable based on field “D” we could use the “on load” event handler of our field “A” to simply examine the row’s data and set the enabled status one time.  This pre-supposes that the value of “D” for a given row is constant for the life of the page.  Using this technique we have no hidden columns nor any overhead for each Data control instances.  However, if the value of “D” changes and doesn’t by itself have a column that can capture a change on it, then we have no event available to us to update the enabled status of “A” in the future.

Automate Processes 7X Faster with NO CODE! Check out SPARK QPB!

Click here to see all that Salient Process has to offer.