Friday, May 25, 2007
My blog is moved... to ... http://srikantha.wordpress.com
FEED is here: http://srikantha.wordpress.com/feed
FEED is here: http://srikantha.wordpress.com/feed
Tuesday, May 22, 2007
Task Delegation
K2 provides delegation features out of the box. Every manager in the directory has access to their subordinates' tasks. As a user you can redirect your worklist items to anyone in the directory as well.
there is also a nice out of office component that allows users to setup out of office scenarios as well.
When you want a group of users to have exclusive access to business process tasks so that they can manage them, you either make this group of users as a destination in those tasks of interest and leverage the K2's out of the box task management features OR will need to use K2 APIs to implement this functionality.
K2MNG is the management API that can be used by anyone who has K2 Admin permissions. this API allows you to implement custom interfaces that can provide functionality (or a sub set) that is found in the K2 service manager tool.
let's look at the code required to set this up.
1. you connect to K2 via the management API as a k2 admin (only K2 admins can use this API) -> K2Manager.login(...)
2. you get the worklist items for process instances you are interested in. This will bring in any currently running processes'
worklistitems from the criteria you have passed in. look at the help for detailed info on this method and other parameters. there is also a sample in the K2 help file. -> K2Manager.Getworklistitems(...)
3. you then redirect any interested worklistitems to anyone required.
5. you disconnect -> K2Manager.logout()
Try
Dim kmgr As New SourceCode.K2Mng.K2Manager
'I must be a K2 Admin
kmgr.Login("localhost", 5252)
Dim wl As SourceCode.K2Mng.WorkListItems = kmgr.GetWorkListItems( Nothing,
"project\processname")
'redirect this wlitem to admin
'you need to find and select which one/ones you want to redirect
kmgr.RedirectWorklistItem(wl.Item(0).ID, "Administrator")
kmgr.Logout() 'remember to logout
Catch excep As Exception 'catch any exception
' Exception Occurred :)
End Try
there is also a nice out of office component that allows users to setup out of office scenarios as well.
When you want a group of users to have exclusive access to business process tasks so that they can manage them, you either make this group of users as a destination in those tasks of interest and leverage the K2's out of the box task management features OR will need to use K2 APIs to implement this functionality.
K2MNG is the management API that can be used by anyone who has K2 Admin permissions. this API allows you to implement custom interfaces that can provide functionality (or a sub set) that is found in the K2 service manager tool.
let's look at the code required to set this up.
1. you connect to K2 via the management API as a k2 admin (only K2 admins can use this API) -> K2Manager.login(...)
2. you get the worklist items for process instances you are interested in. This will bring in any currently running processes'
worklistitems from the criteria you have passed in. look at the help for detailed info on this method and other parameters. there is also a sample in the K2 help file. -> K2Manager.Getworklistitems(...)
3. you then redirect any interested worklistitems to anyone required.
5. you disconnect -> K2Manager.logout()
Try
Dim kmgr As New SourceCode.K2Mng.K2Manager
'I must be a K2 Admin
kmgr.Login("localhost", 5252)
Dim wl As SourceCode.K2Mng.WorkListItems = kmgr.GetWorkListItems( Nothing,
"project\processname")
'redirect this wlitem to admin
'you need to find and select which one/ones you want to redirect
kmgr.RedirectWorklistItem(wl.Item(0).ID, "Administrator")
kmgr.Logout() 'remember to logout
Catch excep As Exception 'catch any exception
' Exception Occurred :)
End Try
Friday, May 18, 2007
Dynamic Escalations
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:
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 :)
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.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();
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 :)
