Stumbling Through

Join me as I stumble, bumble and fumble my way through some new developer technologies. We'll laugh, we'll cry, there may be a mouse tossed through a monitor, but in the end we will all hopefully learn something.
in

Stumbling Through: K2 Blackpearl (Escalations Part I)

A key feature of workflows that needs to be implemented in any technical workflow solution is escalations, that is, redirecting a task to a different user or sending notifications to various system users if the task goes un-addressed for too long.  Today, I'd like to take a look at how the K2 blackpearl product handles escalations in the following scenario:

We will create a simple task, called 'Escalating task', and put it on a specific users task list.  If the task goes un-addressed after one minute, that owner of the task will be sent an e-mail reminder to address the task.  If the task goes un-addressed for five minutes, then it will be moved from the current work list to a different user's work list.

Let's get started by adding a new Process to a workflow project (see previous posts on blackpearl if you need more direction on how to do this).  Within this process, drag out a 'Default Client Event' wizard to the canvas.  We won't make this event actually do anything important, but the wizard requires an action of some sort so simply make it navigate to my company's home page at www.claritycon.com:

image

Click 'Next' and specify that we would NOT like notification of the event (don't want to get our escalation e-mails mixed up with notification e-mails).  Click 'Next' again and blow through the Action wizards and accept their default 'Task Completed' action recommendation, but do not create the line for this outcome (we aren't going to care what happens when the user closes this task, that isn't what we are testing here).

For the Destination User, specify someone that you can log in as to view their task list, just so we can be sure it is appearing as expected when we run this process.  Finish the wizard, and our client event will appear within a new activity on the canvas.  Within this activity, select the 'Activity Escalations' icon from the activity strip (it looks like a clock).  This brings us to the Activity Escalations dialog, where we can specify as many different escalations as this activity requires.  In our case, that will be two - the e-mail escalation and the redirect escalation.  Lets define the e-mail escalation first by clicking the 'Add' button:

image

Click 'Next' and specify that we want an 'e-mail' action template:

image

Now the process is asking us for specifics on when this escalation should take place.  We want it to happen one minute after the task has been assigned to the user, so select 'Escalate After' - 1 Minute:

image

Click 'Next' again and we are required to fill in some information about the e-mail we are sending out.  It doesn't really matter who it is from or what it says, as long as it is directed to the owner of this task.  That is accomplished by clicking the 'Destination User' as the recipient, which becomes available when you uncheck 'Specify'... or so I thought!  Why the heck can't we select 'Destination user'?  Bug!  Bug!  Bug!  I screamed in my head, but no, this is by design and I will explain why... by default, only one instance of an activity is created that is owned by the server, and various destination users simply get links to it from their respective work lists.  So telling it to send an e-mail to its 'destination user' is invalid at this point, because the task is technically global, and has no idea what destination users may be linking to it.  To change this behavior so that the activity is created for the actual destination user, we need to re-visit the 'Destination Rule' on the activity strip (looks like a cluster of three people).  After clicking the destination rule icon, immediately click 'Back' to get the welcome screen which allows us to run in advanced mode:

image

Click 'Next' after checking the advanced mode option and we are presented with a 'Destination Rule Options' screen... the default option here is 'Plan just once', which is not what we want.  We need to specify one of the options under the 'Plan per destination' section to create the activity for each destination.  I'm not yet sure what the difference is between the two options here, for our simple test I'm sure 'All at once' will be fine:

image

Click 'Next' and we get a custom dialog based on the selection we just made... in our case, it is asking for parameters on how to handle 'slots' (instances) of this activity.  Since we are assigning the activity to one (and only one) user at a time, these options don't really apply to us so we can accept the defaults:

image

Now we get to the 'Destination Sets' dialog, which provides further customization on specifying who will be receiving the activity.  Again, this is all overkill for our simple test, so just create one destination set named 'Default' and put our destination user into it:

image

Click 'Finish' and our activity is now setup to create specific instances for the destination users.  Now, let's get back into our e-mail escalation and we see that this time, Destination User is enabled:

image

Finish the wizard and our e-mail escalation is complete.  Now, lets create our redirect escalation by clicking 'Add' again on the Activity Escalations dialog:

image

Click 'Next' and this time, specify the 'Redirect' template:

image

Click 'Next' and specify that we want this to escalate after five minutes:

image

Click 'Next' and we need to now specify who to redirect the task to:

image

Click 'Finish' and then 'Finish' again to complete our escalation definitions.  Deploy this process, and start it up via workspace.  Visit the destination user's task list and notice the 'Escalating task':

image

After one minute, check the destination user's e-mail for the reminder.  After five minutes, refresh the task list and note that the task no longer appears:

image

Log in as the escalation destination user and see that their work list now has the task:

image

Posted: Dec 04 2007, 12:51 PM by tbyrne | with no comments
Filed under:

Comments

No Comments

Leave a Comment

(required) 

(required) 

(optional)

(required)