Switch from DecisionRules to GoRules.

What you get with GoRules

Where your rules land: the parts of GoRules most relevant to this migration.

One expression language everywhere

Decision table cells, expression nodes, and switch conditions all use Zen - a single expression language with 60+ built-in functions (sum, avg, filter, map, date, duration, matches). For logic beyond expressions, functionNode runs sandboxed JavaScript with zod, big.js, dayjs, and http imports.

Versioning, environments, and rollback built in

Semantic versioned releases, environment-scoped deployments with rollback, and branching for parallel rule development. Publish, release, and deploy are explicit human actions, each with an audit trail.

AI copilot for authoring and conversion

The copilot converts uploaded rule files into decision graphs, edits tables from plain-language instructions, generates test cases, and explains what a decision did on a given input. Deploys and releases stay explicit human actions.

Stateless Rust engine with per-node tracing

The Zen Engine evaluates a decision per request: JSON in, DAG traversal in topological order, JSON out. Each node runs exactly once, and the response can include a per-node trace with input, output, and sub-millisecond timing.

The migration path

A step-by-step route from your current setup to running your rules on Zen Engine.

1. Map DecisionRules rule types to GoRules node types

Decision Table rows map to decisionTableNode rows - condition columns become input columns with Zen unary tests (> 1000, in ["US","CA"]), result columns become output columns. The FIRST_MATCH strategy maps to first hit policy and STANDARD maps to collect. EVALUATE_ALL (which returns a result for every row, matched or not) and the ARRAY strategy have no direct hit-policy equivalent - restructure those tables around collect plus downstream expression logic. Calculation columns have no direct equivalent - use expressionNode upstream of the table to compute intermediate values. Decision Trees (IF-THEN-ELSE blocks) map to switchNode with ordered Zen conditions and downstream nodes for each branch. Scripting Rules map to functionNode (sandboxed JavaScript) or expressionNode chains for simpler logic. Decision Flows map to the graph itself - Business Rule nodes become decisionNode references, Switch nodes become switchNode, Assign nodes become expressionNode.

2. Convert operator syntax to Zen expressions

DecisionRules per-cell operators translate to Zen unary tests: = "US" → "US", >= 1000 → >= 1000, BTW [10 AND 50] → [10..50], IN "A"|"B"|"C" → "A","B","C", NULL → == null, C TXT "abc" → contains($, "abc"). Functions translate to Zen equivalents: SUM(a,b) → a + b or sum(list), CONCAT("a","b") → "a" + "b" or string(a) + string(b), IF(cond,a,b) → cond ? a : b (chain ternaries for multi-branch logic). Variables change from {variableName} to direct path references (customer.age). Inside an expressionNode, $.key references keys computed earlier in the same node; in decision-table cells, $ refers to the tested column value.

3. Restructure flow orchestration patterns

If your Decision Flows use Foreach, Global Variables, Declare, REST API Client, or Database Query nodes, restructure them onto the graph DAG: switchNode for conditional branching, expressionNode chains for data transforms, decisionNode for sub-rule calls, and functionNode for HTTP calls or complex logic. For array iteration, use loop execution mode on decisionTableNode or expressionNode - set executionMode: "loop" with inputField pointing to the array (e.g., order.items) and outputPath to wrap the results. There is no built-in database query node - use functionNode with the http import to call a data API.

4. Handle Integration Flow workloads

If you use Integration Flows for batch processing or long-running jobs, note that GoRules does not have a built-in async job system - it is designed for synchronous request/response evaluation. For batch workloads, call the GoRules evaluate endpoint from your application's own job infrastructure (worker queues, cron jobs, or serverless triggers). The evaluate API returns sub-millisecond for typical rules, so high-throughput batch processing is achievable via parallelized HTTP calls from your orchestration layer.

5. Swap the API integration

Replace POST /rule/solve/:ruleId/:version with body {"data": {...}} and Authorization: Bearer <SOLVER_API_KEY> (plus any X-Strategy header) with POST /projects/:projectId/evaluate/* with body {"context": {...}} and the x-access-token header. The response changes from an array of result objects to { performance, result, trace } - result is a single object, with built-in execution timing. If you send bulk inputs as an array under data, send individual requests per input instead (the engine creates and disposes per request). Three evaluation variants: /evaluate/* (published), /environments/:environmentId/evaluate/* (pinned release), /releases/:releaseId/evaluate/* (specific release).

6. Replace environment and CI/CD patterns

If your environments are modeled as separate spaces with distinct API keys and your CI/CD pipeline exports from one space and imports into another via the Management API (decisionrules-cicd-tools), replace that with first-class environments and release pinning: deploy a semantic versioned release to a named environment, and all evaluations against that environment use the pinned release. No export/import cycle needed. Branching supports parallel rule development with change request approvals. Roll back by repointing the environment to a previous release.

7. Validate in parallel, then cut over

Run identical inputs through both engines and compare outputs. GoRules simulation returns a per-node trace - each node reports its input, output, and execution time - so divergences localize quickly. Once outputs match, publish the decision documents and release them to the target environment, then switch your Solver API calls over to the GoRules endpoint.