jeylabs

I came across a query on how to make escalation configurations to be dynamic in K2.

The user wanted escalations to be reset when a process datafield is changed.

He wanted to do this in a client event so that the user interface will have update and submit buttons and as the user make changes to the fields and update the form, the relevant escalations should be reset accordingly. If the user does not do this within the escalation period ofcourse the escalation should fire. If the user makes the update, escalation resets and now we expect the next update to happen and the next update and eventually user will submit and complete the event. then the process moves to the next activity.

Interesting functionality! however doing this in K2 is not straightforward.

K2’s escalations are bound to an activity at the time of the creation of the activity instance. so the escalation timer value cannot be altered afterwards – during runtime.

This means that the way to reset an escalation configuration, is to expire the activity and reinstate that.

Okay but how do we achieve what the user wanted?

If you create an activity with a single client event and configure the escalation in that activity, then you can create another activity with a server event, immediately following the previous escalation activity, we can write code in a server event that can look at what needs to happen based on the updates made in the previous client event, and setup some datafields with appropriate escalation timer values. We then loop back into the escalation activity (when required) and use these datafields to reconfigure the escalation.

the process map will look something like this:

You will also need to create some process data fields – make them hidden and not audited.

In the user interface that corresponds to the client event, we can put in some code that will redirect the page to the user’s next worklistitem from the same process instance and they will see the same page now with the updated values but belonging to another client event.

the code for this will look like this:

con.Open(“k2server”);

WorklistCriteria crit = new WorklistCriteria();

crit.AddFilterField(WCField.ProcessFolio, WCCompare.Equal, “folio_of_my_process_instance”);

crit.AddFilterField(WCField.ProcessFullName, WCCompare.Equal, “project\\processname”);

crit.AddFilterField(WCField.ActivityName, WCCompare.Equal, “activity_name”);

crit.AddFilterField(WCField.EventName, WCCompare.Equal, “event_name”);

Worklist wl = con.OpenWorklist(crit);

if (wl.Count > 0)

{
url = wl[0].Data;
}

Con.close();

Page.Redirect(url);

of course the server event in the activity that follows the escalation activity will have to work out the relevant logic to set the correct escalation timers and line rules. but, we have done it 🙂

Note: This post has been published in the Professional K2 blackpearl book by WROX – checkout pages 848 & 849 🙂