• Internet
• 27.11.2017
• EN

Integration between OpenText RedDot LiveServer and Drools

written by oshyn Team, 12. November 2010
 

Oshyn often works on OpenText/RedDot LiveServer integrations, and found that understanding how to integrate LiveServer and Drools can be very helpful for applying business rules and separating the logic from the application implementation. Now, I'd like to share some details on integrating LiveServer’s events and Drools 4.0.7

Drools is a rule engine implementation that describes “What to do” not “How to do it”. Drools allow developers to write natural language semantics for rule authors in order for business users to create rules to determine the behavior of applications under certain circumstances. For more details please check http://www.jboss.org/drools/.

On the other hand, Live Server supports events that can be triggered when content is updated, created or deleted. Live Server events can call actions defined by users like Java Methods. Java Methods are methods that can do any action related to the triggered event, and they need to be defined in Live Server.

The proposed architecture is to create a generic Java Method that is in charge of calling other Java Methods depending on the business rules defined with Drools. Following, is the proposed architecture for this integration.

When a page is published from the CMS or is updated from Live Server, the Generic JAVA Methods Caller is invoked by the events, “On Content Attribute Create”, “On Content Attribute Update” or “On Content Attribute Delete.” Then, this component is in charge of looking at the defined business rules to call the configured Java Method.

The component “Generic Java Methods Caller” is a registered jar in Live Server, configured to be called when one of the mentioned events is triggered. It uses a file called “JavaMethodsCaller.drl” that contains the business rules, for example:

rule "Rule Name" 
when 
p1 : Attributes() 
p2 : Caller() 
eval (p1.getStringAttibuteValue("category").equals("article")) 
then 
p2.callJavaMethod("com.oshyn.sample","toAction"); end 

This rule means that when the published page has the category content attribute equal to “article”, the method “toAction” of the class “com.oshyn.sample” will be called. One important requirement is that the Java Method “toAction”, needs to have the sign public void foo (java.utilMap). Another requirement is that each Java Method that is going to be handled by this architecture does not need to be registered in Live Server because the “Generic Java Methods Caller” is the unique Java Method that needs to be registered. So, to include a new Java Method, the jar that contains it needs to exist in the folder Live Server Root/WEB-INF/lib, and then Tomcat must be restarted.

If you want to implement this architecture, you need the file JavaMethodsCaller.jar, and you also need to download Drools jars from here. Then you need to put the files JavaMethodsCaller.jar, core-3.2.3.v_686_R32x.jar, drools-core-4.0.7.jar, drools-compiler-4.0.7.jar, drools-analytics-4.0.7.jar, core-3.2.3.v_686_R32x.jar, mvel-1.3.1-java1.4.jar and antlr-runtime-3.0.jar in the folder Live Server Root/WEB-INF/lib and restart tomcat. The file JavaMethodsCaller.drl is located inside the file JavaMethodsCaller.jar.

As a conclusion, this architecture is applied very dynamically to manage Java Methods. By adding rules to the file .drl, we can determine which Java Method should be executed and under what conditions or circumstances.

Source: Integration between OpenText RedDot LiveServer and Drools

© copyright 2010 by oshyn