[!WARNING] Breaking change for Rust crate consumers: arbitrary_precision is no longer enabled by default in zen-engine, zen-expression, zen-types, and zen-tmpl. If you rely on arbitrary precision number handling, add features = ["arbitrary_precision"] to your dependency. Bindings (Node.js, Python, C, UniFFI) are unaffected — they opt in automatically.

Business Rules Engine

ZEN Engine is a cross-platform, Open-Source Business Rules Engine (BRE). It is written in Rust and provides native bindings for NodeJS, Python and Go. ZEN Engine allows to load and execute JSON Decision Model (JDM) from JSON files.

An open-source React editor is available on our JDM Editor repo.

Usage

ZEN Engine is built as embeddable BRE for your Rust, NodeJS, Python or Go applications. It parses JDM from JSON content. It is up to you to obtain the JSON content, e.g. from file system, database or service call.

Supported Platforms

List of platforms where Zen Engine is natively available:

NodeJS - GitHub | Documentation | npmjs
Python - GitHub | Documentation | pypi
Go - GitHub | Documentation
Rust (Core) - GitHub | Documentation | crates.io

For a complete Business Rules Management Systems (BRMS) solution:

Rust

[dependencies]
zen-engine = "0"

use serde_json::json;
use zen_engine::DecisionEngine;
use zen_engine::model::DecisionContent;

async fn evaluate() {
    let decision_content: DecisionContent = serde_json::from_str(include_str!("jdm_graph.json")).unwrap();
    let engine = DecisionEngine::default();
    let decision = engine.create_decision(decision_content.into());

    let result = decision.evaluate(&json!({ "input": 12 })).await;
}

For more advanced use cases visit Rust Docs.

JSON Decision Model (JDM)

GoRules JDM (JSON Decision Model) is a modeling framework designed to streamline the representation and implementation of decision models.

Understanding GoRules JDM

At its core, GoRules JDM revolves around the concept of decision models as interconnected graphs stored in JSON format. These graphs capture the intricate relationships between various decision points, conditions, and outcomes in a GoRules Zen-Engine.

Graphs are made by linking nodes with edges, which act like pathways for moving information from one node to another, usually from the left to the right.

The Input node serves as an entry for all data relevant to the context, while the Output nodes produce the result of decision-making process. The progression of data follows a path from the Input Node to the Output Node, traversing all interconnected nodes in between. As the data flows through this network, it undergoes evaluation at each node, and connections determine where the data is passed along the graph.

To see JDM Graph in action you can use Free Online Editor with built in Simulator.

There are 5 main node types in addition to a graph Input Node (Request) and Output Node (Response):

Decision Table Node
Switch Node
Function Node
Expression Node
Decision Node

Decision Table Node

Overview

Tables provide a structured representation of decision-making processes, allowing developers and business users to express complex rules in a clear and concise manner.

Structure

At the core of the Decision Table is its schema, defining the structure with inputs and outputs. Inputs encompass business-friendly expressions using the ZEN Expression Language, accommodating a range of conditions such as equality, numeric comparisons, boolean values, date time functions, array functions and more. The schema's outputs dictate the form of results generated by the Decision Table. Inputs and outputs are expressed through a user-friendly interface, often resembling a spreadsheet. This facilitates easy modification and addition of rules, enabling business users to contribute to decision logic without delving into intricate code.

Evaluation Process

Decision Tables are evaluated row by row, from top to bottom, adhering to a specified hit policy. Single row is evaluated via Inputs columns, from left to right. Each input column represents AND operator. If cell is empty that column is evaluated truthfully, independently of the value.

If a single cell within a row fails (due to error, or otherwise), the row is skipped.

HitPolicy

The hit policy determines the outcome calculation based on matching rules.

The result of the evaluation is:

an object if the hit policy of the decision table is first and a rule matched. The structure is defined by the output fields. Qualified field names with a dot (.) inside lead to nested objects.
null/undefined if no rule matched in first hit policy
an array of objects if the hit policy of the decision table is collect (one array item for each matching rule) or empty array if no rules match

Inputs

In the assessment of rules or rows, input columns embody the AND operator. The values typically consist of (qualified) names, such as customer.country or customer.age.

There are two types of evaluation of inputs, Unary and Expression.

Unary Evaluation

Unary evaluation is usually used when we would like to compare single fields from incoming context separately, for example customer.country and cart.total . It is activated when a column has field defined in its schema.

Example

For the input:

{
  "customer": {
    "country": "US"
  },
  "cart": {
    "total": 1500
  }
}

This evaluation translates to

IF customer.country == 'US' AND cart.total > 1000 THEN {"fees": {"percent": 2}}
ELSE IF customer.country == 'US' THEN {"fees": {"flat": 30}}
ELSE IF customer.country == 'CA' OR customer.country == 'MX' THEN {"fees": {"flat": 50}}
ELSE {"fees": {"flat": 150}}

List shows basic example of the unary tests in the Input Fields:

| Input entry | Input Expression | |-------------|------------------------------------------------| | "A" | the field equals "A" | | "A", "B" | the field is either "A" or "B" | | 36 | the numeric value equals 36 | | < 36 | a value less than 36 | | > 36 | a value greater than 36 | | [20..39] | a value between 20 and 39 (inclusive) | | 20,39 | a value either 20 or 39 | | <20, >39 | a value either less than 20 or greater than 39 | | true | the boolean value true | | false | the boolean value false | | | any value, even null/undefined | | null | the value null or undefined |

Note: For the full list please visit ZEN Expression Language.

Expression Evaluation

Expression evaluation is used when we would like to create more complex evaluation logic inside single cell. It allows us to compare multiple fields from the incoming context inside same cell.

It can be used by providing an empty Selector (field) inside column configuration.

Example

For the input:

{
  "transaction": {
    "country": "US",
    "createdAt": "2023-11-20T19:00:25Z",
    "amount": 10000
  }
}

IF time(transaction.createdAt) > time("17:00:00") AND transaction.amount > 1000 THEN {"status": "reject"}
ELSE {"status": "approve"}

Note: For the full list please visit ZEN Expression Language.

Outputs

Output columns serve as the blueprint for the data that the decision table will generate when the conditions are met during evaluation.

When a row in the decision table satisfies its specified conditions, the output columns determine the nature and structure of the information that will be returned. Each output column represents a distinct field, and the collective set of these fields forms the output or result associated with the validated row. This mechanism allows decision tables to precisely define and control the data output.

Example

And the result would be:

{
  "flatProperty": "A",
  "output": {
    "nested": {
      "property": "B"
    },
    "property": 36
  }
}

Switch Node (NEW)

The Switch node in GoRules JDM introduces a dynamic branching mechanism to decision model

Zen

Install / Use

README

Business Rules Engine

Usage

Supported Platforms

Rust

JSON Decision Model (JDM)

Understanding GoRules JDM

Decision Table Node

Overview

Structure

Evaluation Process

Inputs

Switch Node (NEW)