My client has just completed upgrading their K2 blackpearl and K2 SmartForms software from version 4.6.11 to 4.7. Here’s something I learned about how SmartForms behavior has changed in version 4’s final minor release.
Cache the Picker’s Data to Avoid Problems with Events and Actions
Given a SmartForm with the same item view attached to it three times, like rows: View A at top, View B in the center, and View C at bottom. Each view contains a series of controls, including a picker. Events on the view are wired such that the selections of the controls are recorded in a data label as each was made, So a dropdownlist control set to “I”, a radio button list with “am” selected, and a picker control set to “asleep” would give us a value of “I am asleep” in the data label.
I was seeing a peculiar behavior wherein the entire value of the data label in View A was being wiped out after the picker resolved, but the same combination of controls and values were working just fine in subsequent views. The same was also true if I skipped View A and used View B.
“‘X’ Gon Give It To Ya”: Monitor the Close Event of a Subview Closed by a Window Border Control (the “X” button)
Here’s the scenario: A user closes a subview by clicking on the “X” button its window, messing up your order of rule execution AND the demo of your work to the client.
Not that that really happened (oh yes it did).
Well, I’m not angry about it or anything (oh yes I am).
I spent several hours running through the entire chain of events and possible actions. And all of them worked correctly in EVERY instance — before I thought to test what would happen if the user closed the subview using that blasted “X” button in its window.
And what I found were three things: (1) clicking on that “X” control will abort normal rule execution, which (2) reproduced the behavior we saw during the demo, and (3) the window controls’ events are not captured by K2 SmartForms.
Well. Not without a little help.
Find the Action Result of a Client Event in a Process Instance
I had a question today about how to determine which action was taken in a specific Process Instance.
Make Escalations Smarter
K2 blackpearl has a nice way to automatically escalate activities. Say you have an activity which contains a SmartForms Client Event. Because events are fired sequentially within an activity, client events bring a process instance to a standstill until the client event is completed. (The example below contains four events, which are called sequentially. The green backgrounds indicate events which have completed; the blue background indicates the Get Approval Client Event is in progress, and the white indicates the Call Review event has yet to be called.)
K2 was clever to bake in some simple escalations, which can be based on an arbitrary value for elapsed time. If your approver hasn’t taken action in a timely manner, you can have K2 do things like send the process instance to a separate activity, or to nag the approver with reminder messages.
Recently, I was asked if we could shut off the escalation for a specific activity. Several hundred people were about to receive reminders about their applications when the delay was actually on our side, not theirs. Sadly, because the process instances were tied to a specific version of the workflow, deploying a new version with the escalation action deleted or modified would only affect processes instantiated after the new version was deployed. It wasn’t going to do anything to help with the current situation.
The conundrum led me to think about how we could handle a situation like this in the future, and at will. Here’s what I came up with.
Monitor Worklists from the K2 Workspace
I was recently asked if one can determine whether a specific person has a specific process instance in his/her worklist. The answer is yes — an administrator can do this from the K2 Workspace if some attributes about the process instance are known.
Start Rule 
You must be logged in to post a comment.