Business Rule Engine (BRE) Validation Framework cum Engine - Decisioning system

Rules -> What comes to your mind… is it everyday life rules like following traffic rules. Yes very similar.

Take an example from everyday life, let say

Visitor1 goes to Transportation Authority for Driving License, will he get it hand in hand or will there be some form filling and some validations. Yes correct, basic validation let’s say he/she should be above 18yrs.

Visitor2 goes for account opening in bank, again will he get his account number hand in hand or he has to submit to some documents. Yes correct, PAN card will be required.

Now think about automating the above process instead of paper work. These are nothing but some rules that are governing the process/system.

Take an example of simple form, let say we have a form where customer has to fill in few details like “firstname”, “lastname”, “dob”, “occupationDetails”, “addressDeatils”. Now suppose same form is being used by two or more clients and both have different sets of mandatory fields in the above form. So how will you manage now,
1.)    Will you create two jsp pages, yes why not.
2.)  Or some validation on server side with if else conditions

Ok done, tested and deployed and relaxed.

Now what, I got one more client with different set of mandatory fields, no issues I will create one more jsp page or add more if else statements. I am ok with making my code dirty or maintaining different pages.

But being a intelligent developer, I will think of some generic solution, will create one page only and leave the mandatory field set for client to configure. I will ask the client to create rule for whatever fields he wants to validate, problem solved, no changes on coder side.

The term Rule Engine is quite ambiguous in that it can be any system that uses rules, in any form, that can be applied to data to produce outcomes. This includes simple systems like form validation and dynamic expression engines. There are two methods of execution for a rule system: Forward Chaining and Backward Chaining; systems that implement both are called Hybrid Chaining Systems.

                           

Advantages of a Rule Engine

o    Declarative Programming

Rule engines allow you to say "What to do", not "How to do it".

The key advantage of this point is that using rules can make it easy to express solutions to difficult problems and consequently have those solutions verified. Rules are much easier to read than code.

Rule systems are capable of solving very, very hard problems, providing an explanation of how the solution was arrived at and why each "decision" along the way was made (not so easy with other of AI systems like neural networks or the human brain - I have no idea why I scratched the side of the car).

o    Logic and Data Separation

Your data is in your domain objects, the logic is in the rules. This is fundamentally breaking the OO coupling of data and logic, which can be an advantage or a disadvantage depending on your point of view. The upshot is that the logic can be much easier to maintain as there are changes in the future, as the logic is all laid out in rules. This can be especially true if the logic is cross-domain or multi-domain logic. Instead of the logic being spread across many domain objects or controllers, it can all be organized in one or more very distinct rules files.

o    Speed and Scalability

The Rete algorithm,the Leaps algorithm, provide very efficient ways of matching rule patterns to your domain object data. These are especially efficient when you have datasets that change in small portions as the rule engine can remember past matches. These algorithms are battle proven.

o    Centralization of Knowledge

By using rules, you create a repository of knowledge (a knowledge base) which is executable. This means it's a single point of truth, for business policy, for instance. Ideally rules are so readable that they can also serve as documentation.

o    Tool Integration

Tools such as Eclipse (and in future, Web based user interfaces) provide ways to edit and manage rules and get immediate feedback, validation and content assistance. Auditing and debugging tools are also available.

o    Explanation Facility

Rule systems effectively provide an "explanation facility" by being able to log the decisions made by the rule engine along with why the decisions were made.

o    Understandable Rules

By creating object models and, optionally, Domain Specific Languages that model your problem domain you can set yourself up to write rules that are very close to natural language. They lend themselves to logic that is understandable to, possibly nontechnical, domain experts as they are expressed in their language, with all the program plumbing, the technical know-how being hidden away in the usual code.

When should you use a Rule Engine?

The shortest answer to this is "when there is no satisfactory traditional programming approach to solve the problem.". Given that short answer, some more explanation is required. The reason why there is no "traditional" approach is possibly one of the following:

o    The problem is just too fiddle for traditional code.

The problem may not be complex, but you can't see a non-fragile way of building a solution for it.

o    The problem is beyond any obvious algorithmic solution.

It is a complex problem to solve, there are no obvious traditional solutions, or basically the problem isn't fully understood.

o    The logic changes often

The logic itself may even be simple but the rules change quite often. In many organizations software releases are few and far between and pluggable rules can help provide the "agility" that is needed and expected in a reasonably safe way.

o    Domain experts (or business analysts) are readily available, but are nontechnical.

Domain experts often possess a wealth of knowledge about business rules and processes. They typically are nontechnical, but can be very logical. Rules can allow them to express the logic in their own terms. Of course, they still have to think critically and be capable of logical thinking. Many people in nontechnical positions do not have training in formal logic, so be careful and work with them, as by codifying business knowledge in rules, you will often expose holes in the way the business rules and processes are currently understood.

If rules are a new technology for your project teams, the overhead in getting going must be factored in. It is not a trivial technology, but this document tries to make it easier to understand.

With this we come to our topic “Business Rules Engine”.

A business rules engine (BRE) is a software component that allows non-programmers to add or change business logic in a business process management (BPM) system. A business rule is a statement that describes a business policy or procedure. Business logic describes the sequence of operations that is associated with data in a database to carry out the rule.

A business rules engine works by separating execution code for business rules from the rest of the business process management system. This allows the end user to change business rules without having to ask a programmer for help. When a change is made, the engine will evaluate the change's effect on other rules in the system and flag the user if there is a conflict.

·         Business Rule Repository - A database for storing the business rules as defined by the business users.

·         Business Rule Editor - An intuitive user interface that allows business users to define, design, document and edit business rules.

·         Reporting Component/Auditing - An intuitive user interface that allows business users to query and report existing rules.

·         Rules Engine Execution Core - The actual programming code that enforces the rules.

Rules Usages

• Process rules that automate the routing, assignment, and tracking of work tasks.
• Decisioning rules of varied types including decision trees, decision maps, and decision tables.
• Declarative rules that compute values or enforce constraints as other properties change.
• Transformation rules that map and parse data across heterogeneous IT systems.
• Integration rules that determine the right system connection to make in each circumstance.

Rule Usages

1.) Validation Framework
2.) Driving Workflow and making decision.
3.) Eligibility Policy Engine
4.) Credit Policy Engine
5.) Scoring Policy Engine
6.) Rule chaining.
7.) Matrix based Rule Execution
8.) Allocation of task and assignment

Business rule engines produce logic, as programming languages do.

Graphical Rules for Greater Efficiency in Development and Maintenance 

Greater Agility	Graphical approach to developing and changing rules and their dependencies that is easy to master.carry advantages and a degree of flexibility that may be more beneficial to the business.
More Traceable	Easy-to-change rules for dynamic, process-oriented applications that achieve a high degree of auditability.
Assured Quality	Test-driven approach of graphical creation/debugging/testing and execution statistics
Reusable Rules	Reusable rules/conditions and parameters services are generated, stored in a rule repository

When do i need a business rule engine..??

• Is there an advantage of your rules being able to be created/edited and tested by business analysts rather than programmers.
• Is there a need to understand the rules that apply to a specific interaction. (ie, this loan was denied because of rule x, y or z), reason being displayed and values getting audited.
• Do you need to know what rules are applied to a certain transaction/events/stage movement at a specific point of time.
• Do you want to be able to test rules outside of the context of the application to ensure the logic is right.
• Do your rules change on a consistent basis, or do they need to change rapidly.
  
  

** Step by Step guide of creating Business Rule Engine will be coming soon….

Rounding Decimal places - Maths

public class TestRounding {
    public static void main(String args[]) {

        Object result1 = new BigDecimal(432295.084);
        Object result2 = new BigDecimal(432295.044);
        System.out.println(((BigDecimal) result1).setScale(1, BigDecimal.ROUND_HALF_DOWN));
        System.out.println(((BigDecimal) result2).setScale(1, BigDecimal.ROUND_HALF_DOWN));
    }
}


Output
Result1 Rounded to = 432295.1
Result2 Rounded to = 432295.0

Implementing Inheritance in Hibernate (Single Table Strategy, With Table Per Class Strategy, With Joined Strategy)

This tutorial discusses what are the types of inheritance models in Hibernate and describes how they work like vertical inheritance and horizontal.

There are three types of inheritance mapping in hibernate
1. Table per concrete class with unions 
2. Table per class hierarchy(Single Table Strategy) 
3. Table per subclass 
Example:
Let us take the simple example of 3 java classes.
Class TwoWheelerVehicle and FourWheelerVehicle are inherited from Vehicle Abstract class.

1. Table per concrete class with unions
In this case there will be 2 tables
Tables: TwoWheelerVehicle, FourWheelerVehicle[all common attributes will be duplicated]

2. Table per class hierarchy
Single Table can be mapped to a class hierarchy
There will be only one table in database called 'Vehicle' that will represent all the attributes required for all 3 classes.
But it needs some discriminating column to differentiate between TwoWheelerVehicle and  FourWheelerVehicle;

3. Table per subclass
In this case there will be 3 tables represent TwoWheelerVehicle , FourWheelerVehicle and Vehicle

Inheritance is one of the most visible facets of Object-relational mismatch. Object oriented systems can model both “is a” and “has a” relationship. Relational model supports only “has a” relationship between two entities. Hibernate can help you map such Objects with relational tables. But you need to choose certain mapping strategy based on your needs. There are three possible strategies to use.

1. Single Table Strategy,

2. With Table Per Class Strategy,

3. With Joined Strategy 

Single Table Strategy

In Single table per subclass, the union of all the properties from the inheritance hierarchy is mapped to one table. As all the data goes in one table, a discriminator is used to differentiate between different type of data.
Advantages of Single Table per class hierarchy

• Simplest to implement.
• Only one table to deal with.
• Performance wise better than all strategies because no joins or sub-selects need to be performed.

Disadvantages:

• Most of the column of table are nullable so the NOT NULL constraint cannot be applied.
• Tables are not normalized.

Lets see the following example code.
Vehicle.java

package com.sdnext.hibernate.tutorial.dto;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Inheritance;
import javax.persistence.InheritanceType;
import javax.persistence.Table;

@Entity
@Table(name="VEHICLE")
@Inheritance(strategy=InheritanceType.SINGLE_TABLE) //Least normalisation strategy
public class Vehicle 
{
 @Id
 @GeneratedValue(strategy=GenerationType.AUTO)
 @Column(name="VEHICLE_ID")
 private int vehicleId;
 
 @Column(name="VEHICLE_NAME")
 private String vehicleName;
 
 public int getVehicleId() {
  return vehicleId;
 }
 public void setVehicleId(int vehicleId) {
  this.vehicleId = vehicleId;
 }
 public String getVehicleName() {
  return vehicleName;
 }
 public void setVehicleName(String vehicleName) {
  this.vehicleName = vehicleName;
 }
}

TwoWheeler.java

package com.sdnext.hibernate.tutorial.dto;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.Table;

@Entity
@Table(name="TWO_WHEELER")
//@DiscriminatorValue("Bike")
public class TwoWheeler extends Vehicle 
{
        @Column(name="STEERING_TYPE")
        private String steeringTwoWheeler;

 public String getSteeringTwoWheeler()
 {
  return steeringTwoWheeler;
 }

 public void setSteeringTwoWheeler(String steeringTwoWheeler) 
 {
  this.steeringTwoWheeler = steeringTwoWheeler;
 }
}

FourWheeler.java

package com.sdnext.hibernate.tutorial.dto;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.Table;

@Entity
@Table(name="FOUR_WHEELER")
//@DiscriminatorValue("Car")
public class FourWheeler extends Vehicle
{
 @Column(name="STEERING_TYPE")
 private String steeringFourWheeler;

 public String getSteeringFourWheeler() 
 {
  return steeringFourWheeler;
 }

 public void setSteeringFourWheeler(String steeringFourWheeler) 
 {
  this.steeringFourWheeler = steeringFourWheeler;
 }
}

hibernate.cfg.xml

 
  
  
   com.mysql.jdbc.Driver 
   jdbc:mysql://localhost:3306/vehicleDB2 
   root 
   root 

  
   1 

  
   org.hibernate.dialect.MySQLDialect 

  
    thread 
  
  
   org.hibernate.cache.NoCacheProvider 

  
   true 
  
  
   create 
   
   
   
   
   
   
   
   

Now run the following test class
HibernateTestDemo.java

package com.sdnext.hibernate.tutorial;

import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.cfg.AnnotationConfiguration;

import com.sdnext.hibernate.tutorial.dto.FourWheeler;
import com.sdnext.hibernate.tutorial.dto.TwoWheeler;
import com.sdnext.hibernate.tutorial.dto.Vehicle;

public class HibernateTestDemo {

 /**
  * @param args
  */
 public static void main(String[] args) 
 {
  SessionFactory sessionFactory = new AnnotationConfiguration().configure().buildSessionFactory();
  Session session = sessionFactory.openSession();
  session.beginTransaction();
  
  Vehicle vehicle = new Vehicle();
  vehicle.setVehicleName("Car");
  
  TwoWheeler twoWheeler = new TwoWheeler();
  twoWheeler.setVehicleName("Bike");
  twoWheeler.setSteeringTwoWheeler("Bike Steering Handle");
  
  FourWheeler fourWheeler = new FourWheeler();
  fourWheeler.setVehicleName("Alto");
  fourWheeler.setSteeringFourWheeler("Alto Steering Wheel");
  
  session.save(vehicle);
  session.save(twoWheeler);
  session.save(fourWheeler);
  
  session.getTransaction().commit();
  session.close();
 }
}

In the above table Vehicle there are four columns (DTYPE, VEHICLE_ID, VEHICLE_NAME, STEERING_TYPE).
The first column has the value of discriminator type(DTYPE) is Vehicle, TwoWheeler, FourWheeler as its entity name by default.

For user convenience we can override the default value of column as well as column name by using the following annotation.
@DiscriminatorColumn
Target:
  Classes

Specifies the discriminator column for the SINGLE_TABLE and JOINED Inheritance mapping strategies.
The strategy and the discriminator column are only specified in the root of an entity class hierarchy or subhierarchy in which a different inheritance strategy is applied
If the DiscriminatorColumn annotation is missing, and a discriminator column is required, the name of the discriminator column defaults to "DTYPE" and the discriminator type to DiscriminatorType.STRING.

@DiscriminatorValue
Target:
  Classes

Specifies the value of the discriminator column for entities of the given type.

The DiscriminatorValue annotation can only be specified on a concrete entity class.

If the DiscriminatorValue annotation is not specified and a discriminator column is used, a provider-specific function will be used to generate a value representing the entity type. If the DiscriminatorType is STRING, the discriminator value default is the entity name.

The inheritance strategy and the discriminator column are only specified in the root of an entity class hierarchy or subhierarchy in which a different inheritance strategy is applied. The discriminator value, if not defaulted, should be specified for each entity class in the hierarchy.

@Inheritance

Target:
  Classes

Defines the inheritance strategy to be used for an entity class hierarchy. It is specified on the entity class that is the root of the entity class hierarchy. If the Inheritance annotation is not specified or if no inheritance type is specified for an entity class hierarchy, the SINGLE_TABLE mapping strategy is used.

Now adding the following annotation to the Vehicle class is

@Entity
@Table(name="VEHICLE")
@Inheritance(strategy=InheritanceType.SINGLE_TABLE) //Least normalisation strategy
@DiscriminatorColumn(
  name="VEHICLE_TYPE", 
  discriminatorType=DiscriminatorType.STRING
  )
public class Vehicle 
{

Now adding following annotation to the TwoWheeler class

@DiscriminatorValue("Bike")
public class TwoWheeler extends Vehicle 
{

Now adding following annotation to the FourWheeler class

@DiscriminatorValue("Car")
public class FourWheeler extends Vehicle 
{

After these above modification we run the code then we will get the following output.

With Table Per Class Strategy

In this case every entity class has its own table i.e. table per class. The data for Vehicle is duplicated in both the tables.
This strategy is not popular and also have been made optional in Java Persistence API.
Advantage:

• Possible to define NOT NULL constraints on the table.

Disadvantage:

• Tables are not normalized.
• To support polymorphism either container has to do multiple trips to database or use SQL UNION kind of feature.

In this case there no need for the discriminator column because all entity has own table.
The Vehicle entity in this case is
Vehicle.java

package com.sdnext.hibernate.tutorial.dto;

import javax.persistence.Column;
import javax.persistence.DiscriminatorColumn;
import javax.persistence.DiscriminatorType;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Inheritance;
import javax.persistence.InheritanceType;
import javax.persistence.Table;

@Entity
@Table(name="VEHICLE")
@Inheritance(strategy=InheritanceType.TABLE_PER_CLASS) //slightly more normalized
public class Vehicle 
{
 @Id
 @GeneratedValue(strategy=GenerationType.AUTO)
 @Column(name="VEHICLE_ID")
 private int vehicleId;
 
 @Column(name="VEHICLE_NAME")
 private String vehicleName;
 
 public int getVehicleId() {
  return vehicleId;
 }
 public void setVehicleId(int vehicleId) {
  this.vehicleId = vehicleId;
 }
 public String getVehicleName() {
  return vehicleName;
 }
 public void setVehicleName(String vehicleName) {
  this.vehicleName = vehicleName;
 }
}

And there no need to the discriminator value for the TwoWheeler and FourWheeler Entity so in this case the
TwoWheeler.java

package com.sdnext.hibernate.tutorial.dto;

import javax.persistence.Column;
import javax.persistence.DiscriminatorValue;
import javax.persistence.Entity;
import javax.persistence.Table;

@Entity
@Table(name="TWO_WHEELER")
public class TwoWheeler extends Vehicle 
{
 @Column(name="STEERING_TYPE")
 private String steeringTwoWheeler;

 public String getSteeringTwoWheeler()
 {
  return steeringTwoWheeler;
 }

 public void setSteeringTwoWheeler(String steeringTwoWheeler) 
 {
  this.steeringTwoWheeler = steeringTwoWheeler;
 }
}

FourWheeler.java

package com.sdnext.hibernate.tutorial.dto;

import javax.persistence.Column;
import javax.persistence.DiscriminatorValue;
import javax.persistence.Entity;
import javax.persistence.Table;

@Entity
@Table(name="FOUR_WHEELER")
public class FourWheeler extends Vehicle
{
 @Column(name="STEERING_TYPE")
 private String steeringFourWheeler;

 public String getSteeringFourWheeler() 
 {
  return steeringFourWheeler;
 }

 public void setSteeringFourWheeler(String steeringFourWheeler) 
 {
  this.steeringFourWheeler = steeringFourWheeler;
 }
}

With Joined Strategy

It's highly normalized but performance is not good.
Advantage:

• Tables are normalized.
• Able to define NOT NULL constraint.

Disadvantage:

• Does not perform as well as SINGLE_TABLE strategy

Using Join Strategy with the vehicle entity
Vehicle.java

package com.sdnext.hibernate.tutorial.dto;

import javax.persistence.Column;
import javax.persistence.DiscriminatorColumn;
import javax.persistence.DiscriminatorType;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Inheritance;
import javax.persistence.InheritanceType;
import javax.persistence.Table;

@Entity
@Table(name="VEHICLE")
@Inheritance(strategy=InheritanceType.JOINED)//Highly normalized
public class Vehicle 
{
 @Id
 @GeneratedValue
 @Column(name="VEHICLE_ID")
 private int vehicleId;
 
 @Column(name="VEHICLE_NAME")
 private String vehicleName;
 
 public int getVehicleId() {
  return vehicleId;
 }
 public void setVehicleId(int vehicleId) {
  this.vehicleId = vehicleId;
 }
 public String getVehicleName() {
  return vehicleName;
 }
 public void setVehicleName(String vehicleName) {
  this.vehicleName = vehicleName;
 }
}

Now run the code we will get the following output.

We have seen the three strategies about inheritance in the hibernate.
A comparison of three strategies is as follows:

Criteria	Single Table	Table per subclass(Join Strategy)	Table per Class
Table Support	Data not normalized. Constraint for mandatory columns to be not nullable cannot applied. Change in any subclass leads to change in structure of Table	Normalized. Mandatory column constraint can be applied	One table for each concrete class. Not maintainable. Change in base class leads to changes in all tables of derived class
Discriminator Column	Present	Absent	Absent
Retrieving data	simple SELECT. All data is in one table. Using discriminator type, individual types can be selected	Joins among table. For example fetching FourWheeler will require a join on FourWheeler and Vehicle table. If all user needs to be fetched than it will put a join for all three tables	Separate Select or Union Select
Updating and Inserting	Single INSERT or UPDATE	Multiple. For Vehicle type one insert on Vehicle table. For FourWheeler type one insert on Vehicle table and another on FourWheeler table.	One insert or update for each subclass
JPA Support	Mandatory	Optional