jBPM 4 - sugessted execution mode

[citylights]

I was hoping to get some advice about which of the execution modes we should be using for our process engine requirements. If i understand these modes correctly they are used to demarcate data ownership and processing responsibilities between the process engine and the containing system into which the engine has been embedded.

Persistent modes require the process engine to keep a record of current and historical states as well as the process definitions themselves. This means therefore that jBPM uses its own relational database structures to store and maintain both the execution details and process definitions.

Am I correct in assuming that if we use our own data structures we can distinguish between embedded included or embedded referenced. For example we either refer to the execution instance id maintained by jBPM or we hold a copy of the current state in our data model [included]. When the state of the process instance is updated we update our records accordingly. Thus with the included mode we are responsible for maintaining the value of the current state.

If some can point me to some documentation about this for jBPM 4 it would be appreciated.

[bestage]

I see that you never get an answer to your post.

I also was interested in understanding what exactly Tom Bayens meant in his execution modes docs I read in the wiki. I guess you understand it correctly.

We have a similar situation in our recent project.

The workflow as states and the business object related to the workflow has states. These have to be synchronized manually. In some event handlers or similar. In concept (4) the state of the workflow would be persisted directly to an attribute of the related business object. I wonder what exactly Tom Bayens meant here.

[bestage]

I have found this, which means a "yes"-answer to my previous post.
This would be a cool feature.

3) New will be an execution mode where the process state will be stored as one column in the users domain object. Imagine an Order class. With the PVM, you can deploy the process as a Java resource on the classpath and manage the state of the execution in a memberfield of the Order class. A special hibernate type can store this memberfield as a string column directly into the Order class.

http://www.infoq.com/news/2008/08/oswf


But I wouldn't persist the process state as string to a member field of an entity, but rather make it configurable, in case one wanted to use an Integer or whatever.