Hello,
what are use cases that you plan to cover by camel component?
I can think of 2:
- stateless camel producer, which would create knowledge session, insert
body of camel message
(or if it's a collection - all elements) and then use some kind of helper to
set the output:
from("direct:foo").to("drools:testRules.drl?someparameters")
- this is pretty straightforward, I already imlemented simple version of
that
- more advanced stateful engine. I am currently implementing following
scenario:
camel receives notifications of changes of order state for different
customers, drools(fusion) implement rules which decide when to send some
sms/mail notifications to customers (e.g. if no action happened for 3 days)
. For each customer I want separate stateful knowledge session (so that I
can have more control over each customer) . So my camel component have to be
able to persist state for many sessions (so that they survive e.g. server
restart) and be able to route messages to appropriate sessions (or create
new if needed). Don't know if it's typical use - but so far I more or less
got it working.
br, maciek
Mark Proctor wrote:
http://blog.athico.com/2009/10/spring-integration-for-drools-has.html
Spring integration for Drools has landed.
<
http://blog.athico.com/2009/10/spring-integration-for-drools-has.html>
Posted by Mark Proctor
I've just committed the first end to end working Spring integration for
Drools. There is still lots more to do, but it at least now allows for
end to end working examples. The latest build that includes this work
can be found from hudson here:
https://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/t...
So how does it work. Lets look at the unit test for more details. The
beans.xml
<
http://fisheye.jboss.org/browse/JBossRules/trunk/drools-container/drools-...
provides a configuration for KnowledgeBases, StatefulKnowledgeSession,
StatelessKnowledgeSession and the ServiceManager. KnowledgeBases can be
confired from a list of resources, that work in the same way that
changeset xml does. This allows resources to be pulled from any URL
resolveble location, be it classpath, localdisk or from artifacts
published from Guvnor:
<drools:kbase id="kbase1">
<drools:resource
source="classpath:org/drools/container/spring/testSpring.drl"
type="DRL"/>
<drools:resource
source="classpath:org/drools/container/spring/IntegrationExampleTest.xls"
type="DTABLE">
<drools:decisiontable-conf input-type="XLS"
worksheet-name="Tables_2"/>
</drools:resource>
</drools:kbase>
The above xml shows a KnowledgeBase configured from a DRL and a XLS,
remember we could have added DRFs if we wanted workflow in there too.
That KnowledgeBase is now a bean that can be referenced via the id
"kbase1". From that bean we can now create sessions. The "type"
attribute specifies whether the session is stateful or stateless:
<drools:ksession id="ksession1" type="stateless"
kbase="kbase1"/>
<drools:ksession id="ksession2" type="stateful"
kbase="kbase1"/>
Those sessions are now beans and can be injected into your own classes
using Spring annotations, or used to configure up a Drools ServiceManager.
<drools:serviceManager id="sm1">
<drools:register name="stateless1" ref="ksession1"/>
<drools:register ref="ksession2"/>
</drools:serviceManager>
The ServiceManager is a new class that I haven't mentioned before that
will be in the upcoming Drools 5.1. The ServiceManager can be worked
with both locally and remotely. It allows sessions to be created and
registered all seamlessly, whether it's local or remote and those
sessions are also exposed both locally and remotely. This ties in with
the Camel <
http://camel.apache.org/>work we are doing to make it easy to
work with Drools out of the box in a service and remoting environment
and should hopefully provide the ultimate in event driven architectures.
I'll blog more on those pieces as they fall into place.
The XSD can be found here: spring-drools.xsd
<
http://fisheye.jboss.org/browse/JBossRules/trunk/drools-container/drools-...
Once the xml is in place, using it with Spring is a doddle and you can
look at the two unit tests
<
http://fisheye.jboss.org/browse/JBossRules/trunk/drools-container/drools-...
to see this in action:
public void test1() throws Exception {
ClassPathXmlApplicationContext context = new
ClassPathXmlApplicationContext( "org/drools/container/spring/beans.xml" );
List list = new ArrayList();
StatelessKnowledgeSession kstateless = (StatelessKnowledgeSession)
context.getBean( "ksession1" );
kstateless.setGlobal( "list", list );
kstateless.execute( new Person( "Darth", "Cheddar", 50 ) );
assertEquals( 2, list.size() );
list = new ArrayList();
StatefulKnowledgeSession kstateful = (StatefulKnowledgeSession)
((StatefulKnowledgeSession) context.getBean( "ksession2" ));
kstateful.setGlobal( "list", list );
kstateful.insert( new Person( "Darth", "Cheddar", 50 ) );
kstateful.fireAllRules();
assertEquals( 2, list.size() );
}
public void test2() {
ClassPathXmlApplicationContext context = new
ClassPathXmlApplicationContext( "org/drools/container/spring/beans.xml" );
ServiceManager sm = (ServiceManager) context.getBean( "sm1" );
List list = new ArrayList();
StatelessKnowledgeSession kstateless = (StatelessKnowledgeSession)
sm.lookup( "stateless1" );
kstateless.setGlobal( "list", list );
kstateless.execute( new Person( "Darth", "Cheddar", 50 ) );
assertEquals( 2, list.size() );
list = new ArrayList();
StatefulKnowledgeSession kstateful = (StatefulKnowledgeSession)
sm.lookup( "ksession2" );
kstateful.setGlobal( "list" list );
kstateful.insert( new Person( "Darth", "Cheddar", 50 ) );
kstateful.fireAllRules();
assertEquals( 2, list.size() );
}
There is still lots more to do, especially around exposing actual
configuration information (JPA etc) and initial setup data (globals,
inserted facts) along with extending this to work with Camel. So if you
want to help, you know where to find us :)
IRC <
http://labs.jboss.org/drools/irc.html>
Mailing Lists <
http://labs.jboss.org/drools/lists.html>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev