REST API for Integration
Crux runs as a separate service, and integrates with business applications through a REST interface. This makes it possible for all applications in all programming languages to integrate with a single Crux container, provided they can perform REST calls.
Postgres
Crux uses a private PostgreSQL database. The database transaction is low, because the database is hit once with Crux starts working on each ruleset, and when rulesets are updated. These are infrequent operations.
Detailed Logging
Crux was built from Day 1 with maintainability in mind. It's not enough to just maintain the source code of the engine, it's equally important to allow the ruleset managers to manage rulesets which may have 1,000+ rules. To allow such rulesets to be debugged and tested, Crux supports class-leading tracing of ruleset traversal.
Multi-version Access
Rulesets in Crux are kept with version tags. If a few rulesets already exist in the Crux data store, and some of them need to be modified, Crux supports the creation of a replica of the rulesets, effectively creating a snapshot with a new version number. The ruleset managers may continue to refine, test and debug the rules in this new snapshot while the business application continues to operate reliably with the old version. This facilitates smooth and controlled change management.
Stateless Design
When Crux works as a business rules engine, each query to Crux results in a lookup of its rulebase, and a response. Each query is stateless (other than log entries being written). This allows Crux to scale-out almost infinitely. The rulesets are loaded into RAM by the engine at startup, and are not reloaded till one of them is updated, thus ensuring that the DB is not a bottleneck for high volume lookups.
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.
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 starting point for reading more about Crux is the wiki of the main repository.
The main repository holds the source code for the Crux service and client libraries.
The UI repository holds the Angular code for the user interface. This is used by administrators or ruleset managers to manage the rulesets in Crux.
The roadmap for the product includes building client libraries for Java. We are waiting for the right Java project to come along.