[rules-dev] Declarative Agenda

[Mauricio Salatino]

Hi man, I didn't have the time to review the code of this feature but I'm
really interested to understand how you are achieving this:
"
-All matched rule's Activations are inserted into WorkingMemory as
facts.
"
How are you getting the newly created activation and inserting it inside the
working memory? Are you wrapping the real Activation Object or creating a
new representation of it?  I want to understand how you are managing the
information and if you create a hook to do that to be able to copy the same
mechanism and apply it for processes.

Cheers.



On Sun, Aug 7, 2011 at 6:29 AM, Mark Proctor <mproctor at codehaus.org> wrote:

> I just got a first cut working for "declarative agenda". The idea here
> is rules can control which rule can or cannot fire. Because this is
> highly experimental it is off by default and users must explicitely
> enable it, it will stay this way until we are happy with the solution.
> My hope is that it will provide a more declarative approach to execution
> control; which will enable more readable and maintainable rules compared
> to using magic salience values and in some circumstances control objects..
>
>         KnowledgeBaseConfiguration kconf =
> KnowledgeBaseFactory.newKnowledgeBaseConfiguration();
>         kconf.setOption( DeclarativeAgendaOption.ENABLED );
>         KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase(
> kconf );
>
> The basic idea is:
> -All matched rule's Activations are inserted into WorkingMemory as
> facts. So you can now match against an Activation the rules metadata and
> declarations are available as -fields on the Activation object.
> -You can use the kcontext.block( $a ) for the current rule to block the
> selected activation. Only when that rule becomes false will the
> activation be elegible for firing. If it is already elebible for firing
> and is later blocked, it will be removed from the agenda until it is
> unblocked.
> -An activation may have multiple blockers, all blockers must became
> false, so they are removed to enable the activation to fire
> -kcontext.unblockAll( $a ) is an over-ride rule that will remove all
> blockers regardless
> - at activationListener('direct') allows a rule to fire as soon as it's
> matched, this is to be used for rules that block/unblock activations, it
> is not desirable for these rules to have side effects that impact else
> where. The name may change later, this is actually part of the pluggable
> terminal node handlers I made, which is an "internal" feature for the
> moment.
>
> I should be committing this later today, and will send a follow up email
> once it hits HEAD, but here is a unit test. It uses a control role to
> stop all rules with metadata declaring the rules to be in the "sales"
> department. Only when that control rule becomes false can they fire.
>
> package org.domain.test
> import org.drools.runtime.rule.Activation
> global java.util.List list
> dialect 'mvel'
>
> rule rule1 @department('sales')
> when
>      $s : String( this == 'go1' )
> then
>     list.add( kcontext.rule.name + ':' + $s );
> end
> rule rule2 @department('sales')
> when
>      $s : String( this == 'go1' )
> then
>     list.add( kcontext.rule.name + ':' + $s );
> end
> rule rule3 @department('sales')
> when
>      $s : String( this == 'go1' )
> then
>     list.add( kcontext.rule.name + ':' + $s );
> end
> rule blockerAllSalesRules @activationListener('direct')
> when
>      $s : String( this == 'go2' )
>      $i : Activation( department == 'sales' )
> then
>     list.add( $i.rule.name + ':' + $s  );
>     kcontext.block( $i );
> end
>
> KnowledgeBaseConfiguration kconf =
> KnowledgeBaseFactory.newKnowledgeBaseConfiguration();
> kconf.setOption( DeclarativeAgendaOption.ENABLED );
> KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase( kconf );
> kbase.addKnowledgePackages( kbuilder.getKnowledgePackages() );
> StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();
> List list = new ArrayList();
> ksession.setGlobal( "list", list);
> ksession.insert(  "go1" );
> FactHandle go2 = ksession.insert(  "go2" );
> ksession.fireAllRules();
> assertEquals( 3, list.size() ); // none of the rules 1-3 fire, as they
> are blocked.
> assertTrue( list.contains( "rule1:go2" ));
> assertTrue( list.contains( "rule2:go2" ));
> assertTrue( list.contains( "rule3:go2" ));
>
> list.clear();
>
> ksession.retract( go2 ); // the blocker rule is nolonger true, so rules
> 1-3 can now fire.
> ksession.fireAllRules();
>
> assertEquals( 3, list.size() );
> assertTrue( list.contains( "rule1:go1" ));
> assertTrue( list.contains( "rule2:go1" ));
> assertTrue( list.contains( "rule3:go1" ));
>
> ksession.dispose();
>
>
>
>
>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>



-- 
 - CTO @ http://www.plugtree.com
 - MyJourney @ http://salaboy.wordpress.com
 - Co-Founder @ http://www.jbug.com.ar

 - Salatino "Salaboy" Mauricio -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110807/bfc514be/attachment.html