entity's lifecycle and jBPM

[vladimir.kovalyuk]

The question is "Can Seam+jBPM help with implementing entity's lifecycle?"
Let's consider Document as an example of entity that has lifecycle. The states are as follows: Draft, Pending Verification, Pending Approval, Archived.

From my perspective lifecycle is a graph with states and actions (transitions).
Instance of entity is always in some state, beginning from start-state and ending with end-state. Any action promotes the instance to the next state.
It seems that jBPM provides us with all means we need to implement lifecycle.
(I saw definition where lifecycle was a reduced graph where states were on the line. jBPM can handle this case as well)

My current understanding is as follows:
1. Entity has field lifecycleId, it is essentially the id of process instance.
2. Entity should keep current lifecycle state (for instance as a name of node).
3. Action should signal the process and eventually entity's lifecycle state should be changed.

From the UI perspective we're on the page where entity details are shown.
There are lifecycle state and possible actions (as outgoing transitions from the state). When user clicks the link with an action the process instance is loaded and signal is sent.

How could Seam handle such a scenario?

[norman.richards]

The Jbpm process can handle the manage the persistent state changes. Normally with a process your indvidual tasks would be a bit larger, but there is really no reason that you couldn't simply show your tasks as links which signal the process. Look at the task list components for how to show the tasks and create proper links. You can start/end tasks with annotations or in pages.xml.

It's really a very straightforward and simple use of jbpm. I don't see anything too complicated there.

[vladimir.kovalyuk]

My understanding is different.
For instance once the author of a document completed with draft it might ask somebody to review the document. And the process of reviewing would be a normal business process. As the result of reviewing the document could be promoted to the next state. But, when it is being promoted the action assigned to the transition could perform whatever we want, for instance inform the people interested in the traking the document about the the fact that the document has been promoted. That's why I believe jBPM suites.

Lifecyle is similar to state-diagram or timeline (It's matter of taste). I'd prefer not to see tasks in the Lifecycle graph.
And what is important user can be happy looking at the picture. Tasks make the picture overcomplicated.

[norman.richards]

Yes, jbpm fits it. Several of the example apps use Seam's jbpm integration to do very similar tasks. It works quite well. I think you'd want to do something similar to the DVDStore, except you want the UI to be more elegant than the very generic view there.