Switch from Drools to GoRules.

What you get with GoRules

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

Rule changes are live in seconds

Rules are JSON decision graphs (application/vnd.gorules.decision). Edit in the editor, publish, and the change reaches production via an atomic releaseId swap - the decision cache expires within 5 seconds (DECISION_CACHE_TTL, configurable). No build step, no restart.

Visual editor for developers and business users

Rules are modeled as decision graphs in a web editor: decision tables, expressions, switches, and functions on one canvas. Business users and developers edit the same graph, with changes tracked per release.

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.

Native SDKs across languages

The same Rust core ships as @gorules/zen-engine for Node.js, zen-engine for Python and Rust, zen-go for Go, io.gorules:zen-engine for JVM (Java and Kotlin), GoRules.ZenEngine for .NET, plus Swift, Android, and browser or Lambda via WASM.

The migration path

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

1. Export rules from your Drools project

For KJAR deployments, extract rule sources with jar -xf your-rules.kjar - .drl files live under src/main/resources/. Export .dmn files from the KIE DMN Editor or your project resources. For spreadsheet decision tables, locate .xls/.xlsx spreadsheet decision tables (conventionally named .drl.xls/.drl.xlsx). Collect everything - the AI copilot works with all of these formats.

2. Map Drools constructs to GoRules node types

DRL when/then condition-action rules map to decisionTableNode rows - conditions become input columns, actions become output columns. salience-ordered rules become first hit policy tables where row order is the priority. accumulate/collect logic maps to expressionNode chains using Zen built-ins (sum, avg, filter, map). Conditional routing via agenda groups maps to switchNode with Zen boolean expressions. FEEL and Zen share range and comparison syntax (>= 18, [1..10]), but built-in function names differ - review the Zen function reference when migrating DMN expressions.

3. Upload DRL files to the AI copilot

Create a decision document in GoRules, open the AI chat panel, and attach your .drl file. The copilot converts DRL conditions to Zen unary tests (>= 18, < 650), maps actions to output columns, and adds a catch-all default row automatically. DMN files and spreadsheet decision tables can also be uploaded - their row structure maps directly to decisionTableNode rows.

4. Rebuild constructs that depend on working memory

insertLogical() with truth maintenance, modify() triggering re-evaluation, and salience-driven cross-rule ordering have no structural equivalent in a stateless DAG - redesign as explicit switchNode branches and expressionNode chains. eval() blocks with arbitrary Java code require rewriting as functionNode JavaScript (sandboxed, with zod, big.js, dayjs, http imports available) or Zen expressions. Iterate with the copilot - describe the intended behavior and let it restructure the graph. Drools CEP (temporal operators like after, before, during, sliding windows, stream event processing mode) has no equivalent in GoRules - GoRules is designed for request/response decisioning, not continuous event processing.

5. Validate against your Drools baseline

Run identical inputs through both engines and compare outputs. GoRules simulation returns per-node trace - each node reports its input, output, and execution time. The AI copilot can generate boundary-condition test cases from your original DRL if you prompt it. Resolve any divergences before cutting over.

6. Swap the API integration

If you use Kogito REST (POST /{model-name} with raw JSON, with whatever auth your service adds), GoRules follows the same POST/JSON workflow: POST /projects/:projectId/evaluate/* with input wrapped in context and auth via x-access-token header. The response returns { performance, result, trace } - trace is included when the request body sets "trace": true. The decision document must be published in GoRules (and released to the target environment) before the evaluate endpoint will serve it. For embedded JVM use (Java or Kotlin), replace the KieServices → KieSession → fireAllRules() → dispose() chain with io.gorules:zen-engine (Maven Central). Node.js: @gorules/zen-engine, Python: zen-engine, Go: zen-go.