I just added a new business rules action which lets Helpstream push real-time updates to external systems.  One example of this is to push real-time updates from Helpstream to Twitter - for example, whenever a new post is made in the Community, or a new Case is open or resolved.  Of course, Helpstream has its own "subscribe" features, but if you want people to be able to "follow" your Helpstream workspace on Twitter, with whatever events please you, this is now possible!

It's simple really - for the new 'Http or Https request' action, enter expressions for the URL, method, content-type, body, and optionally user name and password (for HTTP Basic Auth).  To integrate with Twitter, for example, posting an update with a case summary, you would enter

url - 'https://twitter.com/statuses/update.xml?status=New+case:++' + urlEncode($summary)

method - 'POST'

user - 'myusername@company.com'

password - 'twitterpassword'

This  will post a "New case:  [case summary]' message to Twitter, as real-time as possible.  If real-time is not possible due to current load, the update should happen within a minute or so.

Twitter has a simple REST api, with HTTP basic authentication, so it can all happen in one request.  For other systems, at worst you'd have to host a web page (PHP, Java servlet, etc.), and have that act as a proxy that converted the request into whatever was needed.

 

 

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

 

We try hard to make Helpstream as easy to use as possible, so you can get up and running in minutes, without any training at all.

Under the hood, however, there are rich capabilities that are probably not obvious when you first sign up.  In this entry, I'll give a brief introduction to our Business Rules engine - one of of our most powerful, and most technical, components.  In future entries, I'll drill down into more technical details.

The Business Rules engine is designed to configure your Helpstream support desk according to your own workflow and rules.  Do you want tickets automatically assigned (based on problem type, priority, requester's account support level, geography, day of week, etc.)?  Business rules does that.  Do you want to be notified if a particular type of case is open for more than X hours?  Business rules does that too. 

Business rules are also completely integrated with the Custom Field engine, so your rules can be based on your custom attributes on Account, Case, or Person.

Each Business Rule boils down to three things:

1) Condition.  What causes this rule to run?  The condition is evaluated on every create/update transaction for a business object type.

2) Date.  Do the actions run immediately and transactionally, or are they scheduled for a future date?

3) Actions.  What should happen?  This can consist of updates to fields (such as assignment, automatic prioritization), email notifications (using customizable email templates), and data validation (presenting error messages and preventing a transaction).

I'll get into more technical details in the next entry, but for now here's an example.  This action assigns all networking tickets to Norm Network if they are created without an assignee.

Condition: $old.id = null and $assignee = null and $problemType = 'Networking'

Date: empty (now)

Action: Assignment.  Field: 'assignee'.  Value: query('Person', "record.emailAddress = 'norm.network@mycompany.com'")

Here's another example.  Let's automatically set the priority to High if the summary or description contains the word "urgent", "emergency", or "important", or something similar such as "urgently".

Condition: $old.id = null and fullTextSearch($summary + ' ' + $description, "urgent~ important~ emergency~")

Date: empty (now)

Action: Assignment.  Field: 'priority'.  Value : 'High'

More on what each field and expression means next time.

Dan