Rules on Java Classes vs. Rules based on XSD

[Former Member]

Hi

I was just going through the BRM tutorial center on SDN and I studied the documents on rule creation using Java classes and xsd. From my point of view the mechanism using xsd seems very straight forward and easy to understand as decision tables are used. This fulfills the promise of externalising business rules and giving business users the possibility to maintain them.

I'm not quite sure whether I completely understand the Java based method though. Below a very brief summary of the buyer discount example and my understanding:

1) First a Java class is created This class is comprised of attributes and methods which are able to set and retrieve the attribute values.

2) A business rule is created. By adding our previously created Java class as a class alias we have the possibility to access the classes attributes and methods in the actual rules.

3) Rules are modeled utilising the methods of the java class

4) At runtime the rules engine is invoked from a JSP which instantiates an object of the class we created in step 1. Using the setter methods the objects attributes are set and the object is passed to the rule engine which is subseqhently invoked.

5) The rule engine executes the actual rules and sets an attribute of our object which was passed in step 4

6) the value set in step 4 is retrieved by the calling application.

Is my understanding in general correct ? When would I use the java class method and when the decision table ? From what I can understand the example in the tutorial (buyer discount) could have also been modeled using a decision table. Is increased flexibility compared to decision tables the reason ?. How does the java class method relate to the promise of giving business users the possibility to maintain rules ? I can' t see business users changing the java classes

thanks for ayn helpful input

[Former Member]

HI Andreas,

Glad to see you trying out the stuff we put out in SDN. Your understanding is perfect.

Here is some more explanation.

1. To write rules, you need a description of the business terms. Also called vocabulary, business terms etc.. Examples of such terms are discount, customer name etc.

2. These terms normally come from the application data model, or you define as definitions in the rules composer.

3. An application data model can be available in the form of an XSD or a Java Object Model. (Even a DB Schema could be a source of Data Models. We do not support it now though.)

To illustrate, here is an example of a rule.

IF BUYERu2019S ORDER VALUE > $ 300 & BUYERu2019S CREDIT SCORE > 700 , THEN BUYER TYPE = u201CPREMIUMu201D

An Analysis of the terms used in this rule.

BUYERu2019S ORDER VALUE

Buyer.getOrderValue (Java Operation)

Read Buyer/OrderValue(XSD Operation)

BUYERu2019S CREDIT SCORE

Buyer.getCreditScore (Java Operation)

Read Buyer/CreditScore (XSD Operation)

BUYER TYPE

Buyer.setType (Java Operation)

Write Buyer/SetType (XSD Operation)

The read and write operations are done by the engine at runtime, but these will have to be used at design time for the engine to use them at runtime.

The engine uses java reflection at runtime to execute these operations on the java objects you pass at runtime. For XML, it just reads or updates the DOM.

The same approach works for decision tables also at runtime & design time.

About Business Users

We use a method called aliasing, where we give friendly display names to all the terms imported from a java class or from a XML Schema.

Aliasing enables us to display the rules in a friendly representation, and avoid showing java types or XML XPaths.

CE 7.2 will introduce a web interface for rule management by business users. The NWDS (Rules Composer) is an IT tool.

About Rules & Decision Tables

1. You use decision tables when your rules are structurally similar.

2. Each row in a decision table can be thought of as a If Then Rule, though the engine just executes the table top to bottom & left to right.

3. Whether to use a table or if then rules is a design choice.

4. However, tables are very powerful, and can be used to model very complex scenarios. So, the guidance is that if you can use a table, use a table over a set of If Then Rules. Easier for business users.

[Former Member]

Hi Andreas

You are right on track. Your understanding of how rules on Java classes are meant to be used is correct.

Editing decision tables is far easier for business users. But the use of decision tables is not to avoid Java methods. You use decision tables if your rules indeed are tabular in nature, or better visualized as tables.

Since rules cannot always be expressed using decision tables alone and if your business classes are Java based, you use Java methods in rule conditions and actions.

regards

Rahul.