I've read various posts on the forum and stuff from the knowledge base. But I would like to get a definitive "no that's not possible" or "yes that's the best way, go ahead" from here before starting.
I have two client events in my workflow. One is for the destination user, the other is for the originator. The originator can open his client-side form and redirect the other client event to a different destination user.
Can I use K2Mng to do this? The originator will not have administrative rights on the K2 Server.
Does anyone have a code sample of how to achieve this?
Also, will the redirection be seamless - i.e. the item will disappear from user A's worklist, and reappear in user B's worklist, with no strange goings on or side-effects?
Many thanks,
Richard
+11
I will go for the golden mid-way...
It is possible, but I don't like it. First because you will have to hardcode K2Server administrative credentials to be able to redirect the worklist item and secondly because you are manipulating a client event contained within a different activity.
I would change the process' logical flow to give the Originator the choice of who should action the other item. If this item is not actioned within a predefined time, I would expire that item and redirect the processflow back to the originator to decide on another user to action the item. If this second user acts within the specified time, the process flow can continue to the next step.
Hope this makes sense,
Ockert
PS!! I'm sure you would like a response from someone else for a change - let's hope someone will come to the rescue.
It is possible, but I don't like it. First because you will have to hardcode K2Server administrative credentials to be able to redirect the worklist item and secondly because you are manipulating a client event contained within a different activity.
I would change the process' logical flow to give the Originator the choice of who should action the other item. If this item is not actioned within a predefined time, I would expire that item and redirect the processflow back to the originator to decide on another user to action the item. If this second user acts within the specified time, the process flow can continue to the next step.
Hope this makes sense,
Ockert
PS!! I'm sure you would like a response from someone else for a change - let's hope someone will come to the rescue.
+7
Hi Ockert!
First of all - whatever K2 are paying you, it's not enough :D
I can see why you don't like doing this. However, if we assume the following:
1. Let's say I don't want the originator to do the redirection, but one specific user who is trusted and assigned K2 administrative rights - therefore bypassing the hardcoding of security credentials.
2. At all times I know the exact serial number of the activity I'm trying to redirect (which is ServerName, ProcessID, ActivityID right?)
Are there any further potential negatives that I'm not seeing?
It seems that this should be a very straighforward piece of code.... However if anyone has an example of this in action I'd love to see it. I'm only just scratching the surface on K2ROM, let alone getting into K2MNG.
However I do see your point and your suggestion is a very helpful one. But it does involve adjusting the process design very significently so I'd like to go back to the client with all the options :D
Thanks again,
Richard
First of all - whatever K2 are paying you, it's not enough :D
I can see why you don't like doing this. However, if we assume the following:
1. Let's say I don't want the originator to do the redirection, but one specific user who is trusted and assigned K2 administrative rights - therefore bypassing the hardcoding of security credentials.
2. At all times I know the exact serial number of the activity I'm trying to redirect (which is ServerName, ProcessID, ActivityID right?)
Are there any further potential negatives that I'm not seeing?
It seems that this should be a very straighforward piece of code.... However if anyone has an example of this in action I'd love to see it. I'm only just scratching the surface on K2ROM, let alone getting into K2MNG.
However I do see your point and your suggestion is a very helpful one. But it does involve adjusting the process design very significently so I'd like to go back to the client with all the options :D
Thanks again,
Richard
+11
I still don't like it because you may run into record locks - highly unlikely but possible.
Let's say I don't want the originator to do the redirection, but one specific user who is trusted and assigned K2 administrative rights - therefore bypassing the hardcoding of security credentials
K-I-S-S. If at all possible, leave the workflow administration to be done through K2.net Service Manager and the workflow process to focus on the specific business problem solution i.e. let the user redirect worklist items through K2.net Service manager and let K2.net Server manage the logical flow.
Regards,
Ockert
+7
Yes.... I can see that is the best way. Unfortunately our environment prevents it - the application is running within a sharepoint portal which is accessed over the web by clients external to our domain.
Allowing clients access to Service manager, and therefore our servers, is not an option for obvious reasons :lol:
I feel I will have to discuss this with the client. I think at the moment the best solution would be for the destination user to have an option to release the activity for redirection, which then sends it back to the originator.
If the destination user is on holiday or something I can put an escalation that does this automatically after X days.
Thanks for your help and patience once again Ockert
Richard
Allowing clients access to Service manager, and therefore our servers, is not an option for obvious reasons :lol:
I feel I will have to discuss this with the client. I think at the moment the best solution would be for the destination user to have an option to release the activity for redirection, which then sends it back to the originator.
If the destination user is on holiday or something I can put an escalation that does this automatically after X days.
Thanks for your help and patience once again Ockert
Richard
Reply
View our Community Site Map
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.