Here's what I did - it's a bit of a hack, but it seems to be working okay with
many concurrent instances running.
Each node has node-leave event code that checks for certain conditions that may
indicate assignment to an arbitrary node in the process instance is desired. If
these conditions are found, a transient variable is set in the context instance
with a reference to the current (proper) toNode of the transition that's about
to execute (nothing happens in Node.leave(...) between the line where the
node-leave event code is triggered and transition.take() is called except
logging and the setting of the transitionSource). After the transient variable
is set, I get a reference to the transition about to execute from
executionContext.getTransition(), and set the 'to' of the transition to the
node indicated by the triggering conditions. I now allow the transition code to
run, sending the token to the desired node.
Each node also has node-enter event code that sets the 'to' of the transition
back to what it's supposed to be (otherwise the temporary 'to' will be
persisted when the transaction is committed and tokens following the normal
workflow will be routed incorrectly). This code simply checks for a transient
variable in the current ContextInstance with the appropriate name, and if it's
there, it sets the 'to' of the ExecutionContext's transition to the original
(proper) node.
Here's the code for the node-leave:
Node n = executionContext.getProcessDefinition().getNode(nodeToGoTo);
| Transition transition = executionContext.getTransition();
|
executionContext.getContextInstance().setTransientVariable(ORIGINAL_TO_NODE,
transition.getTo());
| transition.setTo(n);
And here's the code for the node-enter:
Node n =
(Node)executionContext.getContextInstance().getTransientVariable(ORIGINAL_TO_NODE);
| if (n != null){
| executionContext.getTransition().setTo(n);
|
executionContext.getContextInstance().deleteTransientVariable(ORIGINAL_TO_NODE);
| }
Of course I have a lot more validation and other stuff in my production code,
but this is the part that does the work.
Putting this code at the node-enter and node-leave events of every one of my
nodes allows me more flexibility for routing an individual token at runtime,
without specifying all possible paths in a workflow graph. So, for example, I
can allow an end user to specify that after task "X" has been completed,
whether that's two days or two months from now, and no matter where it has gone
in that time, the token should come back to them and assign them a "Y" task,
even though "Y" is never done after "X" normally.
I don't know if this is a reasonable way to accomplish my aim, or if this will
ever make sense to or help anyone, but I thought I'd post my solution anyway!
If there is a 'proper' way to do this (outside of adding many decisions and/or
transitions to graphs), and someone wants to post how, that would be cool.
-Brian
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3916250#3916250
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3916250
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
JBoss-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jboss-user
