When and where to use jBPM in Seam app ?

[dkane]

If I understand correctly, jBPM was developed for :

1) Defining navigation and pageflows

2) Providing support for business process context, which is wider than session context. This way componens can be persisted across multiple users/sessions. Also, tasks can be logically assigned to users.

For first task, in my case, JSF navigation rules is pretty enough and I don't need jBPM.

Second, cross-user context and assignments - yes, could be convenient for order management. In my application, order passes through multiple states and is being processed by multiple executives. I guess this is the classic case of jBPM practice.
But I afraid I don't understand the whole power of jBPM here comparing to oldschool approach. Order and it's status is being persisted in database, anyway. Executives can see only orders with states corresponding to their responsibilities, it is easy to program. Can jBPM simplify this job and/or encapsulate any functionality which requires lots of manual coding ? Or do I miss yet another important aspects of jBPM usage ?

Thank you.

[ellenzhao]

I'm afraid even for the first task, jBPM has something that jsf navigation does not offer. For example, nested pageflow with all kinds of converstaion states propagation....

[gavin.king]

Sometimes its a fine line. For example, if your objects have just 2, or maybe even 3 different statuses, it might not be worth using jBPM. OTOH, if they have 5 status values, I'm pretty sure that jBPM makes sense.

[pmuir]

jBPM also allows you to split out the processes into a pretty diagram, which you can use to impress people ;)

But seriously, it does make your code cleaner and more descriptive, as the separates the process from the support code (e.g. sending an email to the customer) very neatly.

[dkane]

Ok.

Let's consider the order example again. Order processing in my system may take several days or even weeks. During that process order is handled by 5 different executives and passes through 7 statuses. From business point of view, it is single long running business-process.

If I understand correctly, I can associate "order" component with @Scope(PROCESS) so that Seam takes care of it's persistence across sessions and users. Order can be tied to jBPM task, and task is always assigned to some person (actor).
Under such approach, Order may even not be entity bean. Stateful session bean with scope=process will be persisted too, right ?

On the other hand, if I make Order entity bean, I can explicitly save it's state and assignments in key points. In such case, I don't understand benefits of jBPM usage, except of better visualization as Pete says.

Using both approaches together seems some kind of persistence duplication to me : Order will be (1) persisted as entity bean , and (2) persisted as scope=process Seam component. Or does Seam "know" that it is already an entity bean that needs no additional state management efforts ?
Is it a good practice to rely on Scope=process context for stateful session beans , without EJB persistence ?

[gavin.king]

OK, fine. Now imagine what happens if you upgrade your system, completely changing the order process (potentially multiple times), with orders in the middle of their lifecycle.

Some statuses disappear. Some new ones appear. The dependency between statuses changes. The possible transitions change.

How can you cope with all that?

In practice, its a total disaster unless you are using something like jBPM, in which case you don't need to even think about it.

[dkane]

In practice, its a total disaster unless you are using something like jBPM, in which case you don't need to even think about it.

Sounds reasonable. I probably need more experience in complex business processes to realize that with my skin.

Let's assume we are using jBPM. One question is unanswered, I will ask it again. When we expose stateful bean as Seam component with scope = business process, it's persistence may be longer than session and continue across sessions/users , right ? If we don't need this object when process ends, then we don't need it to be entity bean and stay in database afterwards. We don't care how Seam/jBPM saves state in context (maybe using the same database), maps table names, fields, etc. Is it good practice to use process-wide stateful bean in such manner, or Entity bean is still recommended ?

[pmuir]

"dkane" wrote:
Let's assume we are using jBPM. One question is unanswered, I will ask it again. When we expose stateful bean as Seam component with scope = business process, it's persistence may be longer than session and continue across sessions/users , right ?

An object can stay in the BUSINESS PROCESS scope for longer than a session, yes. I would avoid the word persistence, as it has a specific meaning in Seam/JPA.

If we don't need this object when process ends, then we don't need it to be entity bean and stay in database afterwards. We don't care how Seam/jBPM saves state in context (maybe using the same database), maps table names, fields, etc. Is it good practice to use process-wide stateful bean in such manner, or Entity bean is still recommended ?

If you don't need to persist your object using JPA, then it doesn't need to be a JPA entity (you may still need to map it to a database for JPBM to persist between server restarts, but thats another matter...)

[gavin.king]

When we expose stateful bean as Seam component with scope = business process, it's persistence may be longer than session and continue across sessions/users , right ? If we don't need this object when process ends, then we don't need it to be entity bean and stay in database afterwards. We don't care how Seam/jBPM saves state in context (maybe using the same database), maps table names, fields, etc. Is it good practice to use process-wide stateful bean in such manner, or Entity bean is still recommended ?

I would really strongly recommend against the use of serialized blobs in databases. For the same reason I cited above: how will this work across a system updgrade?

However, with a jBPM Converter, you can sometimes persist some kind of state into jBPMs tables without the need for a binary representation, or a separate entity.

Still, IMO, things that need to persist beyond a user session should usually be entities mapped to welldefined database schemas. You app will be legacy one day.

[vladimir.kovalyuk]

Dkane, probably Lifecycle would meet your requirements.

From my perspective Lifecycle can be defined by jPDL. But I still in research how Seam contexts could help.

I'm going to create a new topic.