Compensation Page - mrietveld/jbpm GitHub Wiki

Home ▸ 1-Pager: Compensation
2015-12-01

"Compensation" refers to the behavior that can be triggered when something goes wrong in a BPMN2 process. The textbook example is the "Travel Booking example" by Falko Menge, which can be found here (pdf).

I have extensive notes on my interpretation of the (BPMN2) spec on Compensation which can be found here.

Fully implement Compensation in jBPM features.

The overview jira issue for Compensation is JBPM-4349.

• Stackless/action queue implementation
• Compensation persistence
• Ordered compensation
• Cancel event compensation

• Business transactions
• Asynchronous compensation

I created the basic framework for Compensation for the 6.0 release. However, I wasn't able to fully implement Compensation becaues of the challenge posed by implementing safe point-related tasks within the Compensation Scope in the engine.

2015-10: At Barcelona, Kris created these code modifications to the NodeInstanceImpl class that do the trick:

protected void triggerCompleted(String type, boolean remove) {
    ((StatefulKnowledgeSessionImpl) getProcessInstance().getKnowledgeRuntime())
        .addPropagation(new TriggerCompleted(this, type, remove));

}

private void internalTriggerCompleted(String type, boolean remove) {

and

public class TriggerCompleted extends AbstractPropagationEntry {
    private String type;
    private boolean remove;
    private NodeInstanceImpl nodeInstance;

    public TriggerCompleted(NodeInstanceImpl nodeInstance, String type, boolean remove) {
        this.type = type;
        this.remove = remove;
        this.nodeInstance = nodeInstance;
    }
    public void execute(InternalWorkingMemory wm) {
        nodeInstance.internalTriggerCompleted(type, remove);
    }
}

2013-05-13: talked with Kris, and decided on a more feasible solution and set of priorities:

1. Compensation persistence, by making the CompensationScopeInstance persistent (protobuf, etc).
2. Queue-based implemenation ("stackless"), which will enable business transactions and asynchronous compensation
3. Advanced compensation, including compensation of for-each, ad-hoc, dynamic and other advanced process structures. This is mostly a question of extending existing compensation logic to deal with these instances, including certain accounting of node instance states.

• Persistent compensation
  • Code
  • Quickstarts/examples
  • Documentation
• Stackless/Queue refactoring
  • Tests
  • Code
  • Documentation (configuration, behavior)
• Business Transactions
  • Code
  • Quickstarts/examples
  • Documentation

In short, this refers to the ability to use a user task, or other "pausing" task in the compensation handler.

As of 6.0.2.Final, only script tasks and service tasks which completed could be used with compensation.

Part of the challenge is that the jBPM engine is a "stack-based" engine: a process instance proceeds by calling the method(s) of the subsequent nodes. When a process instance reaches a point where the process instance must (temporarily or permanently) stop, the last call terminates, and the (java method) stack is cleared.

Compensation, however, has a number of semantics which make it unique with regards to other behaviors in BPMN2:

• trigger order
• "saved-state" logic (order of compensation handlers)
• other "meta" logic (transaction integrity, compensation handlers can be asynchronously executed)

In order to implement these, the first step is to refactor the core engine from a "stack-based" execution model to a "queue/loop" based model, where the following node is executed by retrieving it from a queue and executing the node. Execution of a node can lead to more nodes being added to the "node queue".

Kris's description:

The use of the Java stack for state is not ideal, I agree (as it imposes several limits), and could quite easily be changed I believe. Instead of immediately triggering the next node, we could use more something like micro-commands and add commands to a queue. The number of micro-command would be very limited I believe (trigger a node basically). I think it's also something we might have to do, to support something like asynchronous continuatiuons and transaction subprocesses.

"transaction subprocesses" refer to Business Transactions, which are a part of Compensation. "asynchronous continuations" are necessary in order to implement asynchronous Compensation Handlers.

2013-05-13

One of the problems with the migration from (java) invocation stack based to stackless, is that the behavior of a process instance will change. In particular, After Node Left (ANL) and After Node Triggered (ANT) events will be triggered at different times.

However, we'll mitigate this by letting users configure the engine in 2 ways:

• Old invocation based
• New command-queue based

The old way will keep the same behavior as the current implementation, while the new way will of course run node instances by looping through a queue of "node instance commands". The existing (drools) Action framework will be used for this.

7.0

• Persistent compensation
  • Code: protobuf and marshaller work to persist CompensationScopeInstance (and related)
  • Code: taking Snapshots of variable information and persisting it?
  • Quickstarts: The tests are decent, just need to formalize them into quickstarts. Maybe Eric can help?
  • Documentation: Some of this has already been written but commented out.
• Stackless
  • The "Stackless" refactoring is a big task, because we're intrinsically changing the structure of the engine.
  • This branch is a decent start, but it's written for a stack impl, not a queue impl (ANT/ANL behavior). It does identify a lot of the points where changes will need to be made, though.
• Business Transactions
  • Code: This is just as big as the other two parts and there's no time for it in 6.1. We'll have to further take advantage of the stackless refactoring to do this. I'll have to make sure to get lots of feedback from Maciej and Kris.
• Asynchronous Compensation
  • Code:

• Tiho:
  • Designer will have to add the capability for Compensation Handlers, related events and Business transactions
• Bob:
  • The Eclipse BPMN2 designer will have to add the same things as Designer
• QE/QA:
  • keep QE/QA as up-to-date as possible to give them a jump on testing this
• Documentation: