Last time I introduced one of our more advanced features - the Business Rules Engine - and gave some examples of its uses.   Here I'll discuss the design and implementation of the engine itself.

The core technical bit of the business rules engine is the expression evaluator.  When defining business rules, you need to be able to describe what condition triggers the rule, when it should execute, and what it should do.  Each of these is defined by providing an expression.

The expression syntax is really a programming language of sorts.  In fact, when designing this part of the product, that's exactly how I approached it.  I needed to invent a grammar, or language, that supported many of the standard constructs in any other language, but also had special syntax for working with Helpstreams' data (business objects and their properties, useful functions, etc.).

I started by coming up with some use cases I knew we would need to support, and then writing what I thought each expression should look like.  This let me take a "top down" approach, and choose whatever syntax I thought was most capable and usable.  For example, to test whether a status has changed to "Resolved" in an update, I though you would write something like this:

$old.status != $status and $status = "Resolved"

The first part tests whether the status property is different from what is in the database (the "old" value).  The second part tests whether the new value of the status property is Resolved.  This seemed pretty straightforward.  I tried to make the syntax pretty easy for developers familar with almost any language, and was targeting "someone who can write an Excel spreadsheet formula" as about the expected skillset of the audience.

Of course, you don't want to reinvent the wheel, so things like operator precedence (and/or, grouping with parentheses, +- vs */) should work like other languages such as Java.

To define the grammar and write the evaluator, I turned to the ANTLR open source package. 

ANTLR is an excellent example of how the best-of-breed open source packages provide a huge benefit to software developers today.  Take a look at the number of grammars that have been defined using it!

The entire Helpstream grammar is defined in a relatively short file (~300 lines), and ANTLR generates the lexer and parser classes.  These classes are over 18,000 lines of Java code!  I sure wouldn't want to write that by hand.  During evaluation, the parser calls into several evaluator classes I wrote to handle things like object property references, functions, etc.

In the end, you can write extremely sophisticated expressions, and it isn't any harder than a spreadsheet formula.  For example, to trigger a rule if it is between 9 and 5, California time, AND the priority is High OR the summary contains the word "Emergency", AND the Account associated with the requester has a valid support contract (a custom field we'll assume is defined on Account):

(hour(date()+tzOffset(date(), "PST")) >= 9 AND  hour(date()+tzOffset(date(), "PST")) < 17) AND

($priority = 'High' OR fullTextSearch($summary, "Emergency~")) AND

$requester.accountCustom.supportValid = 'Yes'

This uses a few functions - hour, date, tzOffset, and fullTextSearch (which uses the excellent Lucene open source package) - and demonstrates referencing object properties, including related objects and custom fields.

To take an action such as assigning this ticket automatically, you might add AND $assignee = null to the condition, and set field 'assignee' to the expression:

query("Person", "record.emailAddress = 'bob.backline@mycompany.com'")

The "query" function in this case will find the appropriate Person to assign to the 'assignee' field based on their email address.

By combining all of the customization features available in Helpstream (custom fields, custom notifications, business rules, reporting, branding), you can really tailor the solution to fit your specific needs - easily, without complex programming, and without installing any software.

~Dan