Switch from InRule to GoRules.

What you get with GoRules

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

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.

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.

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.

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.

The migration path

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

1. Export rules from your InRule rule application

Rule applications are stored as a single XML file with the .ruleapp extension; .ruleappx files are compressed archives that must be extracted to obtain the .ruleapp XML first. Export from irCatalog via Catalog tab → Maintain or via the Catalog Manager Website, or take the file from the file system. Collect any associated .testscenario files too - they contain the inputs and expected outputs you will rebuild as GoRules simulation cases. The AI copilot accepts the .ruleapp XML and can read pasted Business Language rule text directly.

2. Map InRule constructs to GoRules node types

Business Language If... Then... and If... Then... Else... rules map to decisionTableNode rows - conditions become input columns, actions become output columns, and first hit policy preserves rule ordering. Select... Case... templates map to switchNode with Zen boolean expressions on each branch. Collection aggregate templates (the average/total/minimum/maximum of, the number of, any members exist in, lookup ... where) map to expressionNode chains using Zen built-ins (sum, avg, min, max, filter, map, some, all). Rule sets composed via ExecuteRuleSet map to decisionNode references that load another decision file. Constraints with LimitToValueList, MinimumValue, MaximumValue, PatternMask, etc., become inputNode JSON Schema validations or expressionNode checks placed upstream.

3. Redesign Calculations and working-memory dependencies

Calculations that re-evaluate whenever a field, calculation, or rule they depend on changes have no reactive equivalent in GoRules - re-model each one as an expressionNode placed upstream of every node that consumes its value, with the dependency order made explicit by graph topology. Execute Method calls into bound .NET assembly methods, InvokeEntityMethod, and RefreshFields actions have no equivalent: rewrite as functionNode JavaScript (sandboxed imports: zod, big.js, dayjs, http, zen) for in-process logic, or extract to an HTTP service called via the customHandler integration channel. Patterns built around .NET assembly-bound entity state (runtime object binding), Parent Context, CurrentContext(), and OuterContext() need to be flattened into explicit JSON shapes (parent identifiers joined into child objects) or expressed with Zen array operators.

4. Upload rule application files to the AI copilot

Open a decision document in GoRules, open the AI chat panel, and paste the Business Language rule text or upload the .ruleapp XML. The copilot generates decisionTableNode rows for If/Then rules with conditions converted to Zen unary tests (>= 18, < 650, "US","CA"), switchNode branches for Select/Case, and expressionNode chains for collection aggregates and arithmetic Calculations. Iterate with the copilot - describe what a complex rule should produce and let it restructure the graph. Several constructs still require manual redesign: bound .NET methods, irWord-embedded rules, working-memory re-evaluation patterns, and Vocabulary phrase definitions.

5. Validate against your InRule baseline

Run identical inputs through both engines and compare outputs. GoRules simulation (POST /projects/:projectId/decisions/simulate) returns a per-node trace: each node reports its input, output, and execution time, so divergences are localised to a specific node. For each .testscenario file, extract the input state and expected output and create an equivalent simulation case. Resolve every divergence before cutting over - in particular, double-check date handling (Zen date()/duration() vs Now/Today and #...# literal syntax) and decimal precision (use big.js in functionNode if exact decimal arithmetic is required).

6. Swap the API integration

If you call the Decision API today (POST /api/{ruleAppName}/decision/{decisionName} with inrule-apikey header), GoRules follows the same REST/JSON pattern: POST /projects/:projectId/evaluate/* with {"context": {...}, "trace": false} and x-access-token for auth. The response returns {performance, result, trace}. If you are on the SOAP execution service (RuleEngineServiceClient with ApplyRulesRequest), map those calls to the same GoRules REST endpoint, or move in-process to the GoRules.ZenEngine NuGet package, which replaces the RuleSession → CreateEntity → ApplyRules → Dispose chain with engine.Evaluate(key, context) - no per-request session object to create and dispose, just one long-lived engine. Before the evaluate endpoint can serve a decision, the decision document must be published (released) in GoRules.