Business rules engine and workflow engine

Tiny business people reading list of rules. Man and woman making checklist for control of companys management on huge clipboard flat vector illustration. Guidance concept

Modern businesses work in a constantly changing rules, compliance, and regulatory scenario, where rules keep changing either due to internal business tactics or due to external regulatory changes. If business applications have to be re-built and released as a new version release every time a rule changes, then this reduces business agility. If rules are codified and stored as data, then the rules may be changed in two minutes, followed by ten more minutes of testing, instead of code change, extensive testing and a fresh version release which may take weeks. Crux follows the strategy of rules-as-data, whereas a lot of business rules engines today follow the strategy of rules-as-code. With the latter approach, a new version of the application needs to be built every time a rule changes.

Crux works as a workflow engine too. In this mode, workflows are defined using the same structure and syntax as business rules, but an “entity” or “object”, e.g. a loan application or an expense voucher, traverses a workflow step by step, guided by the sequencing indicated by Crux. A workflow engine introduces the idea of a sequence of process steps, which is not applicable for business rules.

The BRE landscape

A description of business rules engines defines rules engines as either forward-chaining or backward-chaining engines. Forward-chaining rules engines are further classified as either production or reaction engines. Crux implements a production forward-chaining rules engine, which makes it stateless.

Drools describes itself as an open source Business Rules Management System. It is oriented more towards Java applications. Kissflow, which describes itself as an enterprise low-code development platform, includes a business rules engine and workflow engine. Nected is described as the universal decisioning tool for every industry. This system integrates AI into the decision-making process. Netflix designed and implemented its own business rules engine, Hendrix, to handle subscription rules for their very large subscriber base. Orkes Conductor is another well-known workflow engine.

Crux finds place in this landscape as a simple, lightweight, open source business rules and workflow engine with a very powerful rules engine, horizontal scalability, and programming language independent architecture. It may be deployed equally easily in an on-premise data centre as on a public cloud.

Technical details

Fully open source: front-end code repository, server-side code repository on Github

Written in Go for server-side code, and Typescript/Angular for the admin interface. May be integrated with business applications in any programming language since Crux is accessed through a REST API.

Requires a private database on Postgres. The database is not subjected to heavy load.

Is capable of logging all activity and debug trace into LogHarbour.

Has an admin interface for editing rulesets, testing rulesets in a sandbox environment, and generating a trace log of a run through a ruleset.

Can run within a container and scales horizontally easily if multiple pods are instantiated, sharing a single database.

Allows the creation of an editable replica of an existing set of rulesets or workflows (called “realm-slice”), which can then be edited for changes to rules, tested, and frozen, without impacting production flows which continue to access the original realm-slice. When the new rulesets are finalised, the applications can be redirected to the new realm-slice, without any downtime or software source code change.

The business rules engine is stateless, and query results are cached because the lookup operation is a pure function. This allows very high throughput of business rules lookup if the same entity is fed to the same ruleset multiple times.