"kukeltje" wrote : | 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? | The jbpm deployment can detect that there are rule sources in the process archive. Then at deployment, it can compile all the rule files into a rulebase and deploy that to the rule repository with a link to the process definition. "kukeltje" wrote : | 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. | The process local rule base would only be to create a simple environment where process and its rules appear as one logical entity. Apart from that, we also must support global rule bases. But in that case, the process developer must always specify the name of the rule base in the process and manage the rule deployment separately. The process local rules are a simplified scenario in case the developer considers the process and rules as one logical entity. "kukeltje" wrote : | 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 | They need to be re-installed in the rule base because they might have changed indeed. But they should not be re asserted, as that might fire rules and causes consequences (right hand sides) to be executed and that might cause side effects since these already have been executed. The idea is that the working memory should behave as if it is restored transparantly after the previous use. One way would be to serialize it in a process variable, but that would create duplicates of the process variable facts. Only the agenda-part of the working memory should be serialized and the facts should be re-installed without being asserted as that might mess up the agenda. "kukeltje" wrote : | 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 | probably it doesn't make sense to fire the rules after each update, but only when a process is saved. every process variable update should then be marked with a flag that triggers the rule firing... i am still in doubt and didn't think this through yet. i'll respond to the rest later as my 30' internet connection is almost consumed :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964129#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...