[jboss-dev-forums] [Design of JBoss jBPM] - Re: jbpm drools integration meeting

kukeltje do-not-reply at jboss.com
Tue Aug 8 19:03:09 EDT 2006


I know some things about drools and use it (and probably will use it in a major financial system in the Netherlands, but I still have to convince people). 


Some things I read above:
1:

anonymous wrote : This scenario allows for rule bases to be deployed and managed separately from processes but in the same repository. andanonymous wrote : A special simplified use case is when a process archive contains a set of rules in source format.sounds contradictory, do I miss something?

anonymous wrote : In a process you can then say 'fireAllRules' without specifying a specific rule base. All rules specific to that process right? or also global rules? Making processes dependend on global rules in not neccesarilly a problem, but keeping referential integrity is.

2:
I cannot grasp the first part of this paragraph which might be the reason for the next questions

anonymous wrote : In a subsequent process operation, you might want to fire all rules again. Currently, that would require that all the process variables will have to be fed in again.I do not think this is unwanted behaviour since the chances are big they have changed

anonymous wrote : By default, jBPM will fire all rules when a process variable is updated.I hope you mean after all process variables in a transaction are updated. I do not (never?) want rules to go of after one update if I update several variables in e.g. a task

And why automatically? What is the usecase for this. Isn't doing it explicitly in an actionhandler/decisionnode/custom node enhough?

3:

Initially this sounds ok, but this introduces the chance people start signalling tasks/nodes from within JBoss Rules (not drools anymore right ;-)). you get a mix then of the pd and the rules which might lead to a more complex definition. We internally made the choice to let the rules have a minimal impact on the process, just return an outcome and have the pd use that info to e.g. make a decision. Since we WANT to store the outcome anyway, we have a mapping of the outcome of the rules to a process variable and NOT have the rules definition set the process variable. 

The only situation where we want to have the rules engine start a number of tasks is in a custom node (not implemented yet) is in a kind of evaluation system where depending on the outcome each of 100 rules, either a task should be started, a message send or some dossier has to be updated e.g.

  | if (var1 > 10) {
  |    start task2;
  |    risk = risk + 10;
  | }
  | 
  | if (var2 = "yes") {
  |    start task5;
  |    send message3;
  | }
  | 
  | etc...
  |  

This is one rulebase (customer risk assertion) which will fire. We'd like the tasks to be separately defined in the pd (due date etc...) but created if needed (create task=false or even skip the node) Maybe we can take this as an example usecase and see how JBoss rules fits in this)


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3963929#3963929

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3963929



More information about the jboss-dev-forums mailing list