clean handoff

[tom.baeyens]

this topic is created to collect comments on the blog entry http://jboss.org/jbossBlog/blog/tbaeyens/2006/07/26/Clean_handoff_Collaboration_and_Pluggable_Process_Constructs.txt

[genman]

I have a general sense of agreement with what you wrote, since I've worked with process editors at m-Qube and we've taken a similar approach. See http://m-qube.com/html/prodServ/studio.html

One interesting thing is the editor tool is a Java applet and the process logic is stored on the server. Having the tool done as an applet means the business users always can access tools. Hosting the code on the server also means the user has the latest version of the tool.

Also, as a business tool, controlled content management of the "flow" is important. There are ways to schedule deployment and test new process flows with the tool. This can only really done by using a centralized server.

As an aside, I see a bit of long-term synergy with rules engines and process management. I wonder if you can explain what is being done to integrate Drools and jBPM at the tool level?

[tom.baeyens]

there are definitely situations where both of them make sense. we are still researching the most common use cases and translating that into practical integration points between jbpm and drools.

there are various ways on how you might want to deploy interlinked processes and rules: separate rule repository and process repository, process in a rule and rule in a process. we'll be searching for allowing all these combinations, but making the most common scenario the default.

experiences on how people use rules and processes together is appreciated.

[wasperen]

Hi Tom,

I have just got my first Drools / jBPM integration working in the area of Authorization - or PooledActors more to speak.

Basically, at each task node I have a set of rules that determine the pooled actors for all active swimlane instances at that moment in time.
For this I have the rulebase stored in a database.

The sequence is straight forward:

* create a new working memory from it and populate it with business data and an abstraction of the swimlane, actor and pooled actor objects.
* fire the rules.
* sync the simlaneinstance and taskinstances with what is in the working memory.

I tried keeping a working memory live for the duration of the process instance, but storing serialized data is a) very slow and b) runs into problems (stack overflows) with large objects. I found it was quicker to assert all business objects and jBPM abstractions each and every time (in memory, no db involved other than retrieving the compiled rulebase).
Works pretty cool.
I can now very easily have rather complex assignments of tasks. for instance: a reviewer is any person that is not the originator, works more than 0.7 FTE and works in the same department as the originator. Cool huh?

[kukeltje]

Yep, realy cool. Are these rules generic or specific for this process? Meaning do you deploy them as a .drl file with the processdefinition or some other way

[wasperen]

The rule base is generated by compiling the .drl file and then stored in a serialized form in a blob in the database.

When a process instance needs to compute task assignments, it pulls the stored rule base from the db, creates a new working memory and requests the authorization seeder for seeding objects.

The seeder is a generic interface that is implemented by a bean in my business domain of which the main method just returns a list of Objects to be asserted into the working memory (as static facts). In my case it returns the list of Individuals. All 3000 of them, actually, therefore my attempt to keep a live working memory during the life time of the process instance... Which fails because of the sheer size of it. (Serialization stack overflow... I tried to use the JBoss serializer but JBoss Rules does not have an interface that works with JBoss serialization...)

Then the BPM engine asserts wrappers (more simplified objects) for all existing swimlane instances and their pooled actors. Fires the rules and re-aligns the process swimlane and task instances with the content of the working memory.

So the rules import the business objects and the interfaces of the simplified swimlanes and pooled actors. The latter are in the api of my BPM engine.
This means that the space the rules live in is entirely abstracted from the specific library that implemented the rule engine. Just thought that would make it more generic. Of course the rule language and rule base compilation is dedicated for JBoss Rules.

[wasperen]

Ah, one more thing. The key to the table that stores the comiled rule bases is just the name of the process. So there is one set of rules for each process.