nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Workroute: Delegating Activities

suy

Given a workflow process where a user has accepted an activity, can I programmatically pull the activity from that user and give it to another user?

I know that Workroute's API provides WorkflowActivity.unassign() and WorkflowActivity.reassign( User1, User2, WorkflowWorkItem), but those don't seem to work. Either that, or I am using them incorrectly. Would someone mind shedding some light on this, assuming that it is even possible?

Find more posts tagged with

Comments

jpayo

Hello Suy:

I regret not being able to help you. I also am working with workroute (but during a little time), and do not know the workroute api that you say. Could you tell me something on this? How can I obtain it?

Thank you very match. I need help.

Regards.

suy

jpayo:

I have been doing some experimentation with the API over the past few days. The reference I am using is the WOM Developer's Guide. If I remember correctly, it comes with the WOMCOM SDK. The guide covers how to programmatically manipulate activities; the two calls I found earlier were:

WorkflowActivity.unassign()
WorkflowActivity.reassign( User from, User to, WorkflowWorkItem item )

Previously, we were intending to use the two calls within a workflow itself, so that a user could (for instance) reassign a user who has left for vacation but had already accepted a workflow activity. When either of these functions are called from within the context of a Workflow, they throw exceptions indicating that the wfadmin needs for the process to be unlocked. Since the process is in use when in a workflow (either by the assignee or by the workflow engine itself), these functions do not work in this context.

However, using the functions in a third-party program works--they do indeed allow a user to unassign and reassign a workflow activity, with one catch that I've seen so far: voting nodes cannot be reassigned. So, I suppose I've already answered my original question: the API does work, but it only didn't work inside a workflow because I didn't understand how it was supposed to work. I'm still looking into things; if I see anything else worthwhile, I'll post it here.

jpayo

Thank you very much Suy. I am working with Workroute. I will write to you to ask for help. Regards

suy

As it turns out, another thread in this forum provided an answer, and with a good bit of testing, I found it satisfactory for my needs.

First, a little background:
When a user (say, Bob) takes command of an activity (or other assignable) node, a session owned by Bob is opened to Workroute. All scripts run in that node run under the context of that session. However, some Java calls used in JavaScriptHelperClass instances open up other sessions to Workroute. As such, some operations such as reassign(...) and unassign() will not work when called using JSHelperClass.execute().

Note: when scripts are run in unassignable nodes (e.g. OR nodes), the session that is opened is a session "owned" by the Workflow engine itself.

However, JSHelperClass.asynchronousExecute() allows normally unallowable operations like reassign(...) and unassign() to work. This in mind, it's fairly simple to make a form to allow a user to "force" another user to take an action.

Thanks, Nick2112.

It's also worth noting that a WorkflowWorkItem, when unassign()ed or reassign(...)ed to someone else, "disappears." So, it's necessary to re-retrieve an associated WorkflowWorkItem after performing an operation on it, if you want to perform another operation on it.

Cheers!