Business Rules Integration

A rules engine is designed to allow business users to write rules that effect the processing of search results. For instance, an e-commerce company may wish to alter the search results to boost particular documents based on a sale, or the HR department of a company may wish to make sure the document covering 401K benefits is always at the top of a search for 401K. In essence, a rules engine integrated with a search engine allows businesses to dynamically impact relevance of results based on business needs without having to write extensive, low-level client-server code. Instead, they can express rules in a declarative programming language that are much simpler to understand without the complexity of logic that goes into writing code in a programming language like Java or Ruby.

All business rules depend on information from the system to analyze and take actions. This information is known to the rule processor as facts which will be present in the knowledge session. LucidWorks Search will add facts to the knowledge session on each request and the user’s business rules can use and manipulate those facts.

In a rules engine, users express rules to be matched along with instructions in case a rule is matched, using simple if-then statements. The rules engine then figures out which rules should be fired given the facts present in the system. For example, a set of rules may look like:

if owner.hasDog then recommend dog food
if owner.hasCat then recommend cat food
if owner.gender is female and store is "sporting goods" then discount golf clubs 20%

The important thing to note in this example is we didn't have to do any complex logic to tie these rules together. We simply express the conditions and the things that should happen if a condition is true. The engine is responsible for figuring out which rules should fire based on the information (facts) it has to work with when evaluating the rules. It is also important to note that at any given execution of the engine some, all, or none of the conditions may be met depending on the facts in the system, thus implying that all of the "then" clauses will be executed.

When Should I Use Business Rules?

There is a time and place for the use of business rules. Generally speaking, they are most effectively used in situations where non-developers are expected to apply changes to the search results based on business conditions. They are not a replacement for code that integrates search into an application, but instead should be thought of as a way for companies to fine tune user interactions with a system without the need to go through extensive (and expensive) development cycles. It also is not a substitute for general relevance tuning across a broad set of queries nor is it appropriate for ranking modifications that are best done at a lower level in the search engine.

How to Implement Business Rules in LucidWorks Search

There are two main areas to cover for implementing business rules with LucidWorks Search:

First, determine how the rules will be implemented. There are a variety of methods, each described in the section on LucidWorks Rules Integration.

Second, define the rules themselves. LucidWorks Search has integrated Drools, and you'll want to look at the section on Drools Integration for information on how to construct a rules file.

There are Example Rules and Recipes. If you're not using rules at all, you can disable business rules.

Integrating with your Rules Engine

If you already have a rules engine (such as ILOG's JRules or Fair Isaac's Blaze Advisor) you can hook them into LucidWorks by implementing a RulesEngine class that talks to your rules engine. Naturally, you can also implement your own SearchComponent, DocTransformer, UpdateRequestProcessor, etc., if the ones shipped with LucidWorks do not meet your needs.

Click Scoring Relevance Framework

Query and Search Configuration