jbpm and drools integration

[tom.baeyens]

on behalf of Wojtek:

I've managed to learn enough about drools and businness rules to state that integrating it into JBPM is a challenging task.

One of jBPM contributors is Marcin Mieszek, whose mail you have recently posted on our newsgroup. This guy I know quite well, because I work with him ;-) We've had few words about the drools integration and we think it's a subject complex and effort-demanding enough for both of us.

By the end of the next 2-3 weeks Marcin will have closed all the issues he wishes to work on; by that time I will dig into the subject and prepare a brief design. After verification we would like to start implementation.

What do you think about that? Is that all right?

Greets

Wojtek

[tom.baeyens]

the simplest task that should be done is the following: create an jbpm action that does the following: take all the process variables and use those variables as facts in a drools calculation.

the most difficult bit (apart from learning jbpm and drools) should be to find a right set of libraries that match both jbpm and drools.

note that this is a critical piece of the JEMS stack integration. we expect that soon one of us (me or mark proctor) is going to get involved with this full time as well. any work that can be done in preparation is good. in case you want a task that you can accomplish completely by yourself, you can also have a look at http://jira.jboss.com/jira/browse/JBPM-564

regards, tom.

[julian_k]

I have begun learning drools and can see some overlap b/w jBPM and Drools, but I am curious if Drools will better facilitate the bridge between a GUI and jBPM versus writing to the jBPM engine directly. Of course this will create a dependency b/w the two projects or perhaps spawn a new one, but I believe this to be a critical area for further jBPM adoption. Also, I am curious if such plans will be JSR 94 compliant. Thank you for your thoughts.

[kukeltje]

hmm..... drools for the ui? That's not my opinion. Drools is complementary, no real overlap, unless in the decision nodes.

Drools is JSR 94 compliant, so that is not an issue. If a default jBPM action uses a factory, the rules engine could indeed be plugable (much better then with expensive engines).

In the future, I think jBPM will connect to the jboss-esb as will the rules engine. Then the rules engine could be called via the bus.

The company I work for is 'connecting' the Tibco iPE and rules engine to Mule (an opensource esb) and behind the scenes I'm doing the same with jBPM and Drools. We (a collegue and I) will have to give a demo with the Tibco products but we haven't decided yet if we are going to cheat and do the demo with jBPM/Drools and not telling anyone. At least not in advance ;-)

Ronald

[julian_k]

Well Drools does have the ability to integrate with Swing per their examples on their website. Now I would imagine if this the case, one could manage the same thing by integrating a web framework like Spring/Struts with Drools. This presents a problem though b/c there would have to be some passthrough mechanism to access or allow execution of such logic from the Drools decision nodes through a jBPM action. This seems to be a different approach then that of the current jBPM webapp. Please correct me if I am wrong, but this is my current understanding. Finally, integration with an ESB is certainly the next step in my learning process and I appreciate the comments.

[kukeltje]

"julian_k" wrote:
Well Drools does have the ability to integrate with Swing per their examples on their website.

You mean this:

GUI and Swing

While drools itself does not provide a GUI API it does provide the ability to link a GUI with a rules engine via Application Data and make a reference available to the JFrame to the Working Memory.
GUI is demonstrated in the following examples....

This is some kind of integration. Just like you can integrate SAP in Drools, or JMS or whatever. Nothing special.

"julian_k" wrote:
Now I would imagine if this the case, one could manage the same thing by integrating a web framework like Spring/Struts with Drools.

Sure one can.... just like you can integrate Spring/Struts with SAP or JMS or whatever... Sorry I do not want to sound rude, but this is 'integration' on a completely different level.

"julian_k" wrote:
This presents a problem though b/c there would have to be some passthrough mechanism to access or allow execution of such logic from the Drools decision nodes through a jBPM action.

The other way around. Drools should not call an action of jBPM, jBPM should via an action call a rulesengine.

"julian_k" wrote:
This seems to be a different approach then that of the current jBPM webapp. Please correct me if I am wrong, but this is my current understanding.

This I do not understand.... You mean a Struts webapp with Drools behind it which calls jBPM????

"julian_k" wrote:
Finally, integration with an ESB is certainly the next step in my learning process and I appreciate the comments.

Learning..... me to, all day... :-) Keep going....

Ronald

[kukeltje]

shoot... forgot to preview.. sorry

[julian_k]

np, I did mean that jBPM would call Drools through an action...now how then would "pass through" from the UI to jBPM to the Drools decision node function? I do not see any way currently for a "view-state" in jBPM whereby one could tie a given state to a given UI component (e.g. a web controller)...or maybe a way for a given state to take over "application control". Personally, I have created a custom task instance which has a few extra fields that if present can be parsed from the jPDL and indicate whether or not the task is a form that is pulled from the jBPM database (via the jbpm_bytes table and generated) or a link to another website/page in the application. Regardless, the current jBPM RM doesn't point to a clear solution here...maybe it's best this way, but IMHO creating dynamic task forms based on task-controllers and corresponding variables is not a flexible/robust solution for managing application flow, esp for legacy apps. Of course, my solution does not provide this functionality yet therefore my interest in this.

[kukeltje]

"julian_k" wrote:
now how then would "pass through" from the UI to jBPM to the Drools decision node function?

This is where the actionhandler comes in. Maybe someone will write a generic actionhandler sometimes that can map process variables to the data format Drools expects. Since the latter is also flexible, it could go anywhere.

I do not see any way currently for a "view-state" in jBPM whereby one could tie a given state to a given UI component (e.g. a web controller)...or maybe a way for a given state to take over "application control".

I'm working (again... sorry for the third time) on adapting the jBPM ui part so a custom page can be shown for a certain task and even specific pages if a certain transition is taken.

jBPM RM doesn't point to a clear solution here...

RM?

maybe it's best this way, but IMHO creating dynamic task forms based on task-controllers and corresponding variables is not a flexible/robust solution for managing application flow, esp for legacy apps.

It wasn't meant to be. It's just for a realy rapid application development, where an addition for variable type in the process definition would give an dynamic rendererd ui which is more usble then the current one. afaik, Tom is thinking of adding a variable type to the PD

I understand your interest, it's the same as mine, but it is completly separated from drools (which in itself has a realy interesting field where it should be applied.

Ronald

[julian_k]

Thanks for the thorough response.

RM?

RM = Reference Model, iow the Domain Model.

It wasn't meant to be. It's just for a realy rapid application development, where an addition for variable type in the process definition would give an dynamic rendererd ui which is more usble then the current one. afaik, Tom is thinking of adding a variable type to the PD

I think task types or something similar would be great and may faciliate such "view states".


I look forward to Wojtek's input on the integration of these two components. As far as a "view state" seeming to be a separate topic, it still is central IMO to adoption and providing practical examples for newbies. As I study these subjects more, I will try to post back on my findings in the appropriate forums. Thanks again.

[michaelneale]

This is on Mark and my radar as #1.1 priority. (we talked to TomB last night)

Similar points apply to Seam integration. Basically it sounds like you want to pass in a variable resolving context of some kind (possibly a lazy loaded map?).

To make this efficient for a rules engine, we need to implement backwards chaining so it can pull facts out of the appropriate context when a partial match is found. Once we have backwards chaining, it should be striaght forward.

In the meantime, we have the following possibilities:

a) jBPM asserts into the rule engine only the facts that it knows the rule needs (this has limitations, obviously, and gives less control to the rule engine). In this case it would be silly to assert ALL objects in the context, as that would defeat the purpose of lazy loading etc.
b) jBPM just asserts the Context (or Seam does, whatever) and the rules operate on this one context object. Its kind of like a scripting engine.

A slight improvement on b) above would be too have a "bootstrap" rule where a user has configured what named facts it wasn't to pull out of the context. It then asserts these discrete facts to the engine. The *real* rules operate on these named facts that were previously extracted (it sounds clunky, but it can be made pretty neat possibly).

rule "extract variables"
 salience 100 //this makes this rule fire first
 when
 There is a variable called "sacha"
 then
 >assert(sacha); //this makes sacha available to other rules
 //we may need to wrap this with a NamedFact object
 //if there are multiple objects of this type floating around

end

rule "my rule"
 when
 Sacha has a blood alchohol over [0.05]
 then
 Send message "Partay"
end

The above assumes that the Sacha_party_animal.dsl language config is used.