first of all, what you describe is not realy ad-hoc task, since it is part of the flow. For me, ad-hoc is out-of flow but part of the process, but that is just me.
See planetjbpm.wordpress.com (milestone example) on how to create runtime tasks that are defined in the process but not part of the flow.
Ronald.... thanks for the reply & I gotcha on the terminology.
I had seen the milestone pattern before but I'm not sure if that meets my need? I don't really know when & where in the process definition the user will need to essentially pause the current execution.... perform some arbitrarily complex one-off process... and then return execution to their originally definition afterward. I think the disconnect for me is that my one-off process will not be defined in the original process or the flow.
For this process definition:
start --> task 1 --> task 2 --> node 3 --> task 4 --> end
We normally expect for the process instance to be just that. But on some occasions users need to be able to define any process that needs to be executed during only one particular instance of the process definition above. For example... while our token in on task 1.... they might say i need the following to execute after node 3 completes but before task 4 starts:
task x --> node y --> task z
making the execution:
start --> task 1 --> task 2 --> node 3 --> (execute sub process above then return) -- > task 4 --> end
or maybe for another instance they need the following to execute after task 1 completes but before task 2 starts:
task m --> task n --> node o --> node p
making the execution
start --> task 1 --> (execute sub process above then return) -- > task 2 --> node 3 --> task 4 --> end
Ultimately my problem is that not only is in not part of the flow... but really it's not a part of the definition either. It's a one-off process definition that needs to be executed at some point in a process instance (essentially pausing it... and then letting it continue after completion).
then use the api to suspend the fisrt process, start the new one and when it finishes, resume the first process
That was what I was thinking.... thanks for the feedback. (And for what it's worth I don't like having to implement this... seems to run in the face of having a process to follow and then throwing in some extra steps... but you gotta do what you gotta do if the users can't live without being able to have something like that)
So... on the concept of intercepting signaling on a node when the user specifies "I need this one-off process to occur after x node completes"... my only thought was to override the leave functions on a set of nodes that extend from the core jBPM ones and have those suspend the workflow and start the one-off when they are flagged to do so. Any thoughts on other ways to interrupt? I remember reading that you are not supposed to alter the context during event handlers like a node-leave (i.e. it should just be for reference and trigger other external activities)... but that was the only other place I could think of trying to suspend the flow.
Thanks again for helping thinking this through.
I remember reading that you are not supposed to alter the context during event handlers like a node-leave (i.e. it should just be for reference and trigger other external activities)... but that was the only other place I could think of trying to suspend the flow
exactley, so do not do it IN the process, do it with the api since you've got to build an application anyway