[rules-users] Activate/Deactivate parts of the rule sets

[Wolfgang Laun]

Look at the agenda-group attribute. Setting the focus makes just the group's
rules
eligible for firing. Falling back to the "MAIN" (default) group is
automatic, after
all group rules have been "exhausted". I think this is what you mean with
your #2

Solution 1 could be used, too; efficiency's not a problem.

-W

-W

On 28 October 2010 02:08, Tina Vießmann <tviessmann at stud.hs-bremen.de>wrote:

> Hi,
>
> I'm thinking about how to activate/deactivate parts of the rule set
> during runtime. I'm doing some brainstorming about that and would be
> happy, if I could get more experienced input. ;-)
>
> What I want to do:
> I have several rules where I process 4 different objects separate and
> some rules processing combinations of the 4 objects. Now I want to be
> able to activate/decativate the processing of e.g. one of the objects at
> runtime when my application receives a specific command.
> How can I do that?
>
> My thoughts:
> 1.) I thought about maybe inserting a fact that states if the processing
> of a object is disabled. If I'm including the fact in the rules
> conditions, the rules including the specific object are prevent from
> firing. But I could imagine that is results in performance costs because
> its always checked in every rule condition if the specific processing is
> (de)activated.
> 2.) Is it possible to (de)activate the execution of rules for a specific
> object using some grouping...
> 3.) Is it possible to rebuild the knowledge base during runtime using
> templates and incremental change-set processing. Or something alike...
> (Because the separate processing of the 4 objects is kind of identical.)
>
> Thanks for any input! :)
>
> Tina
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20101028/96f1e331/attachment.html