I would also like to know how this might be handled.
I'm assuming that "stages" could also mean "states".
We potentially talked about having this functionality where we are using jBPM, and came up with the same idea of drawing transitions back to everywhere.
However, the tasks that have already been performed would still be completed, unless you programmatically did some magic to undo whatever that task might have been.
and roll back all (remote/webservice) actions that have been carried out, etc....
In business terms, you can not unsend a letter that you send though the post, instead, you send a new letter, telling to ignore the first one, or with an invoice, you send a 'credit invoice' (do not know if this is the correct term). Besides that, you want to keep it for audit purposes (it DID happen initially, right...)
If it is on the businesslevel, try modelling it in...
Assuming there are no interactions/handoffs (or) updates to external services,
does the engine have a generic capability to rollback(UNDO) previous workflow states. This would imply removing all data corresponding to variables stored/taskinstances/token information etc..
nope, there was something like this in 2.0, but Tom removed it for reasons unknown to me. It might be that the issues were to complex, not frequently used (if at all) and things should be modeled in
I know the user guide mentions using logging for undo capability (IN THE FUTURE). I wouldn't doubt it was removed for complexity, because man we talked about this again and again, and it's just crazy.
The point of Graph Oriented Programming... is to follow the graph! If you want undo paths, graph them up.
Do you want to share some information on your BPM evaluation? I am going throug the same process right now. JBPM is very strong candidate so far. My only disapointment is with JPDL editor.
Would you in turn, in a new thread, inform us about your disappointment with the jdpl editor? We are always looking for ways to learn and improve things.
I have been researching the topic of Undoing or Rolling Back also. This seems to be an area of concern for many. I am still investigating this and would like to know how others are handling this.
I believe one reason that we are having difficulty finding information about this subject is our terminology. You might try searching for BPEL and the following terms:
Long Running Transactions
Here is one article that I found that talked about Compensation.
Here is some additional food for thought:
A Process is made up of States, Transitions, and Transition Events. A Transition is used to move from one State to another State. During the course of that Transition, you may invoke many Transition Events that may need to be carried out (sequentially or parallel).
Two scenarios may require the need to 'compensate':
1) During the execution of your Transition Event(s), you encounter a problem (business rule or exception) that prevents the Transition from completing to the new State.
2) A situation occurs that requires the need to move a Task backwards in the Process. This could be as simple as user moving a Task forward by mistake. Additionally, it could involve multiple Transitions and States.
In both of these scenarios, you need the ability to 'compensate' for the Transition Events that have already occurred. It is not ideal to create additional Transitions for every possible scenario. Additionally, this functionality should not be treated as a fault, but it may be the response to a fault.
Suppose a Transition had knowledge of all the Transition Events that are in progress, completed, or failed. The Transition could have a reverse() method that could cycle through the Transition Events and determine which ones needed to be handled. It would then call a rollback() method on each Transition Event, as necessary. The rollback() method would perform the most appropriate action to compensate for changes that already occurred.
When I refer to the 'most appropriate action', I mean that whoever codes the Transition Event execution, would also define what should occur on a rollback(). You can't use a standard mechanism to handle this. It is just too process-specific and requires knowledge of your logic.
In scenario 1 (above), the Transition would never complete or get to the new State. It would just call the rollback() method on each of the Transition Events (that had occurred). When all appropriate rollback() methods were called, the Transition's reverse() method could return a boolean indicating whether all the rollback() methods completed successfully or not.
In scenario 2 (above), the reverse() method of the Transition would be called and all Transition Event rollback() methods would be called. Again, the reverse() method would return a boolean indicating if all the rollback() methods were successful. If the reverse() method returned true, then the State of the Task would be changed to the previous State.
I haven't thought through the implications of guard conditions that may be dependent on variables that have changed. Furthermore, the order of Transition Events, that did not occur sequentially, could be problematic. These issues may just have to be the responsibility of the logic within each rollback() method.
Please let me know if this idea has merit or is riddled with holes.
Thanks in advance,
first, jBPM (the jpdl part) is not bpel. So the analysis is not a (complete) match
1: is covered afaik by jbpm since you get an exception then. You can configure an exceptionhandler and do whatever you want.... Additionally if you want you can even set the token in another node/state. Normally you only get an exception on events like leave-node and 'transition-taken' so jbpm already has some (enough?) support for this.
RollBack methods could be implemented but imo the current support should be sufficient
2: Roling back multiple states etc... hmm... in that if you want the user to be protected, give hime a warning.... 'Are you sure..?" Besides that, jBPM has the option to put the token in any node so a 'goto state' is easy to program, IF the node is in a state (see a Jira issue JBPM-728) Rolling back everything is a different thing. What if letters are already printed and sent out. Those have to be nulled or packages transported or..... These are additional tasks and should therefore be modeled in (my not so humble opinion) Additionally, things can be cascading, rolling back one database update could be possible, but what if that new data is already used in other systems.... hmm..... The implications of these things are major in the systems we work with. I therefore see these things as such exceptions that manual intervention is needed. It would take to much effort to design a system that can handle these very rare happenings
just my ?0,01
Interesting reading: Business Rules and Business Process Exceptions