Drools: Problems with the Traditional Approach

Drools is extensively used in the BFSI Industry(Banking, Financial services and Insurance). The primary reason being the continuously changing requirements and the addition of new rules which keeps on adding given the Volatility in the BFSI Industry.

Let us take an example of a system where trades are coming from external system in the form of XML and JAXB is used and casted into customized Java Object. Now there are business rules which needs to be applied on certain parameters in the xml.

So the code would be something like:

if (trade.getProductInformation() == Product.IRS) {
	// do something for IRS (Interest Rate Swap Trade)
} 
else if (trade.getProductInformation() == Product.CDS) {
  	if (trade.getPartyIds() == null) {
    	// do something else for CDS trades with no Party Id
  	} 
  	else {
    	if(trade.getTradeId() ! =null) {
			//do something
      }
  }
}

Now currrent java code handles two product type (IRS and CDS) and the application wants to onboard a third product(Bonds), the above Java code will be very difficult to maintain and change every time a new condition has to be introduced.

The solution to the rescue is using a Rule Engine. With Rule Engine your business logic is segregated in Rules and if there is a new product to be on boarded, only new rules would have to be added.

For example:

if Trade( productInformation == Product.IRS)
	then do something else for IRS Trade

if Trade( productInformation == Product.CDS)
	then do something for CDS trade

Now a new system is added so a new rule would be:

if Trade( productInformation == Product.BONDS)
	then do something for BONDS trade

The above example is a simple one (just for reference). When there are a lot of nested if and else statements in the code then using rules really help in easily adding new requirements/changes to the application and also the modification of the existing rules.