Decision engines · Export
PYD ENTERPRISES and Camunda
Import PYD ENTERPRISES' DMN decision tables into Camunda so extracted legacy rules can be modeled, tested and executed in the target architecture.
Camunda
Decision engines
1<decision id="maintenanceFee" name="Maintenance fee">2 <decisionTable hitPolicy="FIRST">3 <input label="Account tier"><inputExpression typeRef="string"><text>tier</text></inputExpression></input>4 <input label="Average balance"><inputExpression typeRef="number"><text>avgBalance</text></inputExpression></input>5 <output name="fee" typeRef="number"/>6 <rule>7 <description>DDAFEE01.cbl:22-25 (CS-R2)</description>8 <inputEntry><text>"B"</text></inputEntry>9 <inputEntry><text>< 1500</text></inputEntry>10 <outputEntry><text>12.00</text></outputEntry>11 </rule>12 </decisionTable>13</decision>
From COBOL paragraphs to executable decisions
When the target architecture uses Camunda for process orchestration and decisioning, the business rules PYD ENTERPRISES extracts do not need to be re-keyed. PYD ENTERPRISES writes each decision as a DMN file containing a decision table with typed inputs, outputs, a hit policy and FEEL unary tests, plus a decision requirements graph when one decision feeds another (for example a risk tier decision feeding a fee decision).
Those files open in Camunda Modeler and deploy like any DMN you design by hand. Analysts see the same table they signed off in PYD ENTERPRISES' review view, and each rule carries an annotation with the PYD ENTERPRISES rule ID and source location so traceability survives the move into the engine.
What maps cleanly, and what does not
Most legacy decision logic is condition-heavy and maps well: nested IF and EVALUATE blocks over 88-level condition names become rows with unary tests such as "B","P" or [1500..5000), and the order in which COBOL evaluates branches is preserved with the FIRST hit policy where order matters, or proved irrelevant and expressed as UNIQUE where it does not.
Some logic does not belong in a decision table, and PYD ENTERPRISES says so instead of forcing it:
- Iterative calculations (amortization schedules, day-by-day accrual loops) are exported as formulas with worked examples, to be implemented in service code.
- Decisions that depend on data the legacy program read mid-calculation from VSAM or DB2 are flagged, because the target service must supply that data as an input.
- Rules whose source depends on unresolved calls are exported with a review flag.
DMN version compatibility
PYD ENTERPRISES writes DMN 1.5 by default and can target an earlier DMN namespace when your engine release expects one. The decision table constructs PYD ENTERPRISES emits (UNIQUE, FIRST, PRIORITY and COLLECT hit policies, simple FEEL unary tests and literal outputs) are common to recent DMN versions. Check the DMN version and FEEL support of the Camunda release you run and set the export target to match; the export report lists any construct the chosen target cannot express.
FAQ
Camunda questions.
Does PYD ENTERPRISES deploy decisions to Camunda for us?
No. PYD ENTERPRISES produces DMN files; your team deploys them through its normal pipeline. That keeps the decision of what runs in production with you.
Is the FIRST hit policy a sign of bad rule design?
Not necessarily. It faithfully reproduces COBOL's top-to-bottom branch order. PYD ENTERPRISES reports which FIRST tables have overlapping rows, so analysts can decide whether to rewrite them as UNIQUE.
Can we round-trip edits from Camunda Modeler back into PYD ENTERPRISES?
PYD ENTERPRISES can import an edited DMN file and compare it to the extracted baseline, showing which rows now differ from the legacy behavior. That comparison is useful when rules are intentionally changed during modernization.
RELATED INTEGRATIONS
DroolsRun extracted legacy rules on the Drools DMN engine in Java services, with DMN files packaged alongside the code and verified against legacy fixtures.
GitHubMirror GitHub or GitHub Enterprise Server repositories inside your VPC, scan a pinned commit, and return specifications to a review repository as pull requests.
GitLabClone self-managed GitLab projects inside your network, run PYD ENTERPRISES as a CI job on your own runners, and publish specs back as merge requests.
BitbucketIngest legacy repositories from Bitbucket Data Center or Bitbucket Cloud with read-only credentials, and return specification bundles as pull requests for review.See the Camunda flow on your own code.
Run PYD ENTERPRISES on 100,000 lines of COBOL or Java in your private VPC and review OpenAPI specs and DMN tables tomorrow.