I have probably heard the word "compensation" in the last two months more than I have ever heard it before, which outlines how critical this feature is becoming. Through this post, David French touched on a very important issue in BPMN/BPEL and compensation support that I am sure our community will find very interesting.

Starting from 5.2, Intalio introduced major improvements in Compensation support whereupon we are able to support any kind of scenarios involving compensation.

The only problem left is, you need to know how to do it! There is a few extra restrictions on the modeling side that when respected, everything becomes clearer and much easier to do.

These restrictions are not a result of non compliance with specifications , it is actually a consequence of incompatibilities between the BPMN and BPEL: Despite all the efforts made by OMG to ensure a smooth translation between those specifications, they still disagree on a certain number of points, among which compensation and error handling.

By the release of 5.3, we are hoping that Intalio will be able to align those specifications more and ease the use of those features on the user end. Meanwhile, users will just have to respect the extra restrictions. Again, this does not go against neither BPMN nor BPEL, it just ensures a better mapping between them. Hence, diagrams and generated BPEL code will still be 100% BPMN and BPEL compliant as you will notice in this thread.


The business case presented by David was both simple and realistic and I would like to make use of the scenario and the diagrams as support material for this discussion. I will go through the diagrams and explain for each why they behaved as such. This will cover the most important parts of compensation and error handling.




First diagram:

Problem : Starting a compensation from a normal execution mode . By the BPEL specification, you only compensate when you have an error (kind of makes sense from an execution stand point doesn't it?)

So first rule is: To compensate a scope from a normal mode, throw an error, catch it and then compensate it.

In his specific case, he did the "throw" part in the second diagram, and the "catch" part in the last one, but never the "compensate" part. I will go back to that later on.



Second diagram:


Problem: compensating a scope that is not immediately enclosed in the scope the compensation is thrown from.

This is also a BPEL rule: you can only compensate a scope from its immediate parent.

So the only scope allowed to compensate the "book hotel" scope is the fault handler of the parent scope.


Third diagram:

Problem: did not specify a fault handler that describes how he would like to handle the fault in this particular case.

When you don't specify a "Fault Handler" on a scope, BPEL automatically installs what it calls "Default fault handlers". A default fault handler compensates all sub-processes in your scope and rethrows the fault to the parent one.

So when you throw an error, it is a best practice that you catch it and define how you want to handle it.

So in your case, you throw an error in the "book air" sub-process without defining a fault handler. The default fault handler will compensate all the enclosed scopes in the "book air" scope (none in your case") and rethrow the fault to the parent scope.

The parent scope has no fault handler either, so its default fault handler will take care of it. It will compensate all the completed scopes, in your case "book flight" scope only as the "book Air" has not successfully completed, and then it will rethrow the fault to the process scope. Hence the process faults and exists.



Fourth diagram:


Problem: The fault handler is empty .

You are defining a fault handler for the scope, so the default fault handler will be uninstalled. Your fault handler is empty so nothing will happen when this fault is thrown.


The solution:

Now I think you all see how the design should be done :
In the fault handler, we should compensate the scope "book air".

Please note that I gave an extensive explanation for what happened
including some technical details that you don't have to be aware of to solve the problem. Just make sure you apply the rule "throw, catch ,compensate" and you will be fine.

I hope this gives a good first insight into compensation and error handling...
Feedback, comments and further questions or additions are more than welcome!


Ihab EL Alami

Thanks for taking the time to respond so thoroughly.
There is a significant issue (for me anyway). Generally, Intalio is presented as a "zero code" solution to business problems. Understanding the limitations of BPEL (an execution language) should be your problem not the business user, process analyst or whatever. I think that where you are limited by BPEL in the implementation of valid BPMN, you should say so.
While I understand that you have made the first rule
To compensate a scope from a normal mode, throw an error, catch it and then compensate it.
the BPMN spec does not ... what is an Compensation End Event if not a specific statement of a failure condition?
I agree that BPMN is short of concrete examples and reference implementations which is why I tried, and will continue to try, to use examples from the spec and respected experts like Bruce Silver.
Elsewhere in the forums I have muttered about documentation of where you get to understand the basis of what happens in Intalio (BPEL engine = Apache ODE; BPMN from Eclipse; Workflow from TEMPO ...). I am interested enough to track through the dense stuff in unit tests but others may appreciate a single set of pointers to what is is not implemented. For example ODE does not implement the full BPEL spec which may be a problem for those who understand BPEL .
Thanks for the pointer on grouping shapes into a sub-process ... I will certainly exercise that ... I wonder where that button was hidden:)
Would you please get someone to review the Intalio paper on compensation that I referenced and provide a working example. Feel free to make my original example work!
David

Sure!! Just attach your project and I will correct it for you as soon as I have a chance.
Cheers

attached to forum post here http://bpms.intalio.com/forums/bpmn-and-designer/compensation-how-to-s...

( there was en error in the link provided by David. The correct link is this one )

David,
I think we do perfectly agree with each other, ,we have just expressed it differently.

Understanding the limitations of BPEL (an execution language) should be your problem not the business user, process analyst or whatever.

I can not agree more, this is why I emphasized at the end of my explanation that all the BPEL details I have provided are meant to explain to the technical crowd what lies behind the shapes of the diagram. However, users are not required to know that.
They might find this information useful as it gives an idea on how challenging transforming BPMN to BPEL is. Some would think this is very easy and should be straightforward , and my post explains why it is not the case at all.

the BPMN spec does not... what is an Compensation End Event if not a specific statement of a failure condition?

You are perfectly right. I have just said that we add a simple and a clear temporary restriction that will align the divergent specs as a first step. The second step is to be able to map any BPMN diagram to BPEL, but that requires a bit more time because of all the incompatibilities I mentioned before. We are hoping to be able to achieve that by 5.3 .

Again, with 5.2 , by respecting this temporary restriction you will be able to model any scenario that involves compensation and execute it.
I have attached your project corrected, I hope this makes thing even more clear.
Let me know how that works for you .

Regards,

Thank you for helping me understand this complex issue.
The corrected example demonstrates the requirement well. A couple of points...
1. I note that you included a compensate target for the compensate end event ... this shows the flexibility of the BPMN spec in allowing an individual sub process to be compensated or all eligible compensation to be performed. Omitting the compensate target property has the same effect in this example. I suspect that the better practice would be to omit the compensate target property, then if the process is later expanded to include other elements with compensation, you do not have to think about the logic for firing the compensate action for each.
2. The compensation end event can be placed inside a sub-process if the error handling has to be more complex. This executes as expected but, in this case, the compensation target property cannot be set (there are no targets available for selection) and there is an error flagged only in the properties box "the target of the compensate activity does not represent the name of a completed scope". This 'error' does not propagate to the bpm diagram (which is good,because it is not really an error!)
3. If compensation target property is set, it cannot be unset (you have to delete the end event and re-renter.

The error link in my post was provided by the flaky forum software but I am not going to try to debug that. This error occurs several times in posts throughout the forum.

Yes, we do agree. My irritation was due to spending some time trying to work out where I had gone wrong in my understanding of BPMN only to discover it was a restriction (temporary, I hope) introduced in the implementation. If the error messages made that kind of thing obvious, it would be helpful. I do not expect early releases of anything to be perfect ... but when the imperfection is deliberate I think the user deserves a bit more.
Thank you again for taking the time for such a complete explanation.
David