Tweak the BPMN merge

One question that has been asked by two customers is how do we make sure that IT changes are always preserved, especially if business has made simple changes like update the descriptionof the BPMN activity in the BPMN model.
First and foremost, its important to understand that any change by business user is considered a change to the BPMN activity and therefore IT changes in that scope are rendered deprecated. This may not be most desirable in some usecases as the one described above.
The solution is right infront of you in your BPEL file. The scope annotation will surmise what was the last update date of the activity corresponding to this scope. If you change it to an arbitrary date in future, the merge algorithm will think that the version in JDev is the latest greatest and will therefore not overwrite your implementation. However, pl note that this is not advisable as it violates the basic premise that business user controls the flow of the process definition and the definition of the activity itself. This workaroud is just to ensure that if IT guy thinks that the implementation is "final". Use it with the same care as you would use final in java classes.

More about BPMN 2.0

In response to my previous blog post, Sebastian Stein identifies the areas of improvement for BPMN 2.0. One very important area he has identified is execution semantics besides the well known lack of exchange format. And I would like to reassure the wider BPM community that the same is a very important target for the BPMN 2.0 RFP and consequently for the submissions. The approach 1 as outlined and characterized by Sebastian and Bruce attempts to address both of these concerns using the inherent metamodel of BPMN 1.0 and 1.1. There are some great facets of the second submission as well, and there are merger talks in progress.

Going back to what is (or should be) good about BPMN 2.0:

Users get the flexibility to "underspecify" a business activity, e.g. as a business user I know that "Create Order" step is to be followed by an "Audit Step". I may not know exactly how these steps will be executed. If I know it or if there is an IT specialist refining the model, he can specify the execution details of each of these steps.


The execution semantics is an area of focus and ironing out the ambiguous IOR gateways and resulting patterns is high on the agenda. This is also an area for learning from user experience. e.g. in this diagram - how many times does a business user expect the activity "Step X" to be executed?
You will get a different answer from different people. How about the case when the activity Step X is after another similar construct - how many times will the activity X be executed in that scenario.


Stay tuned for the next blog post where I will discuss token flow semantics.