SEAM/jBPM Synchronization

[jayzaw]

Hi,

we intend to separate page-flow from process-flow in our application.

This means:
a) to every activity/task in a business process, there is a set of pages assigned, within which there is pageflow. One such set of pages is assigned to one and exactly one activity/task in a business process. (there are exceptions, like the login page, and the page in which you can chose to trigger one of several business processes at your disposal as a user)

b) the "web rendering" tier (where pageflow takes place, and we will use SEAM here) does basically NOT know about the business process (loose coupling). All it knows is :
- which activity/task is performed right now, while the current pageset is active
- at the end of the dialogue for the activity, it tells jBPM to resume the business process instance. jBPM would then either acknowledge the resume of the business process, or signal a fault in case the submit of the activity to jBPM has somehow failed. In case jBPM would signal a success, it would tell to the "web rendering" tier what the next activity is. That way, the web tier would know what the next set of pages is to load.

This is the loosest coupling I can imagine between page- and process-flow. The question is: is it feasible that way, and where do I find material/infos on it ? How would the synchronization take place ?

How would the user interface controller be notified of the next activity in the business process, without having knowledge of the whole business process ?

How would the jBPM tell the user interface controller that the successful completion of an activity has failed and that it must be restarted ? (meaning, e.g. that a user would have to correct some values submitted and resume the business process again)

Kind regards,

Jay

[kukeltje]

Sure it is possible this way (currently developing an app like this myself). But what is 'synchronization' in your case?

I do not intend to send any info to the webtier, the webtier 'queries' the processengine.

[jayzaw]

Hi Ronald,

this is kind of great - we should keep in touch for that, if you agree of course.

Well, I m quoting you here:

"But what is 'synchronization' in your case? I do not intend to send any info to the webtier, the webtier 'queries' the processengine."

About what information exactly are you talking about here ? There are different kinds of infos exchanged:

Let's denote web-tier with WT, and use BPE for the process engine, PgF for pageflow, PrF for process flow

a) WT triggers BP in BPE --> response from BPE: next activity taking place.
b) WT submits the result of the dialogue with the user to BPE: BPE eventually performs call to service-tier, gets response/fault back, propagates response to WT. Now there are two cases. The WT (we are talking about the simple synchronous case here) is waiting for the following answer:

1st case: A response, along with a spec of what activity is next, or if the process already terminated.

2nd case: A "normal" fault, and here I mean by "normal": something for which a re-submission of the request with some corrections (maybe some semantic validation on the server-side failed) will do. In this case the WT session controller just restarts the activity. The "normal" fault might also include technical exceptions, etc. - in any case the fault's scope is just the current activity, and not the whole process. This means that no next acitivity in the BP can be taken on for now.

3rd case: A "complex" fault - and I leave this out for now: complex faults might trigger compensational business processes, in which case there is another branch to be taken in a correctional/compensational BP perhaps. This would be specified at process engine level.

You see that the WT here queries in fact too. How do you solve this ?

Kind regards,

Jay Zawar