camunda-dmn

Camunda DMN

Camunda 8.8 以降向けの実行可能な DMN 1.3 決定を作成します。.dmn ファイルには、1 つ以上の決定を含む 1 つの Decision Requirements Diagram が格納されます。各決定は、決定テーブルまたはリテラル式のいずれかです。BPMN のビジネスルールタスクは、ID で決定を参照し、結果をプロセス変数として受け取ります。

相互参照

• camunda-bpmn：ビジネスルールタスクの接続（<zeebe:calledDecision decisionId="..." resultVariable="..."/>）
• camunda-feel：入力式、出力エントリー、リテラル式内の FEEL 構文
• camunda-process-test：推奨される動作検証 — CPT は呼び出し元の BPMN を通じて決定を実行します
• camunda-process-mgmt：代替の動作検証 — クラスターにデプロイして実行します（ローカルの c8run を推奨）

作成

DMN ファイルでは、DMN 1.3 の名前空間を宣言し、1 つ以上の <decision> 要素を囲みます。

<definitions xmlns="https://www.omg.org/spec/DMN/20191111/MODEL/"
             id="DinnerDecisions" name="Dinner Decisions"
             namespace="http://camunda.org/schema/1.0/dmn">
  <decision id="dish" name="Dish">
    <decisionTable id="decisionTable_dish" hitPolicy="UNIQUE">
      
    </decisionTable>
  </decision>
</definitions>

デフォルトの名前空間と namespace="http://camunda.org/schema/1.0/dmn" 属性は必須です。

決定には、<decisionTable>（入力／出力／ルールとヒットポリシー）または <literalExpression>（単一の FEEL 式 — 上流の決定を組み合わせるのに便利）のいずれかが含まれます。複数の決定を含むファイルでは、<informationRequirement><requiredDecision href="#upstream"/></informationRequirement> によって決定同士をリンクします。Camunda は BPMN から参照されたルート決定のみを評価し、必要な決定を透過的に取得します。

入力／出力句の XML 全体、単項テスト文法、ヒットポリシーごとの例、COLLECT 集計関数、型の一覧、DRG のリンクについては、references/decision-tables.md を参照してください。

ID と命名規則

• 決定の id、出力の name、決定テーブルの列名には、英数字と _ のみを使用します。空白、-（FEEL の演算子）、その他の特殊文字は使用できません。違反すると BPMN からの参照がサイレントに失敗し、実行時に解決値が null になります。
• name 属性（Decision、InputData、BusinessKnowledgeModel、KnowledgeSource、DecisionService）：任意の文字列です。dmnlint は name の欠落を警告します。id ですでに意図が伝わる場合でも、必ず設定してください。
• 文字列の出力エントリーは引用符で囲む必要があります。 "HIGH" は文字列リテラルです。引用符のない HIGH は変数参照として解析され、解析エラーや lint 警告なしに null と評価されます。

ヒットポリシー（Camunda がサポートするもの）

decisionTable 要素に設定します（デフォルトは UNIQUE）。Camunda 8 がサポートするのは 5 種類です。DMN 仕様にはさらに多くの種類が定義されていますが、PRIORITY と OUTPUT ORDER はサポートされていません。

ヒットポリシー	結果	動作
UNIQUE	単一	ルールがちょうど 1 つ一致する必要があります。複数一致すると実行時エラーになります。
ANY	単一	複数のルールが一致してもかまいませんが、すべて同じ出力を返す必要があります。そうでない場合は実行時エラーになります。
FIRST	単一	上から下へ評価し、最初に一致したルールを適用します。
RULE ORDER	リスト	一致したすべてのルールの出力を、ルール順に返します。
COLLECT	リスト／スカラー	任意の順序で一致したすべてのルールを返します。aggregation="SUM" | "MIN" | "MAX" | "COUNT" を指定すると、単一の値に集約します。

デフォルトでは UNIQUE を使用します。ハードルールを優先してからソフトルールを適用する場合（例：「最初にブロックリストを適用し、その後に許可ルールを適用」）は FIRST を使用します。リスト出力自体が目的の場合は COLLECT を使用します。各ポリシーの例については、references/decision-tables.md を参照してください。

BPMN 側の接続

<bpmn:businessRuleTask id="ApplyDiscount" name="Apply discount">
  <bpmn:extensionElements>
    <zeebe:calledDecision decisionId="discount" resultVariable="discountPercent"/>
  </bpmn:extensionElements>
</bpmn:businessRuleTask>

decisionId は DMN の decision id と一致します。結果は resultVariable に格納されます。UNIQUE／ANY／FIRST の場合は単一の結果、RULE ORDER／COLLECT の場合はリスト（集計関数を指定した場合はスカラー）です。

resultVariable は値を上書きします。 既存の入力変数と同じ名前を指定すると、入力値が上書きされます。後続のアクティビティでも入力を読み取れるように、異なる名前（例：customer ではなく discountPercent）を選んでください。

<zeebe:calledDecision> では bindingType も指定できます。値は latest（デフォルト）、deployment、versionTag です。バインディングタイプの一覧については camunda-bpmn を参照してください。BPMN と DMN を同時にデプロイする場合は、deployment が適切です。

DMN 内の FEEL

DMN では、inputExpression、inputEntry（単項テスト）、outputEntry、literalExpression で FEEL を使用します。BPMN とは異なり、= のプレフィックスは不要です。すべての text 要素が FEEL として解析されます。

入力エントリでは、単項テストのサブセットを使用します。入力値は暗黙的で、< 5 は ? < 5 を意味します。カンマ区切りのリテラルは OR、カンマ区切りの比較は AND です。範囲は [1..10] / (1..10)、not(...) は否定、- はすべてに一致します。

単項テストの文法、単項テストでできないこと、リンクされた意思決定間の変数スコープ、DMN 固有の FEEL 機能については、references/feel-in-dmn.md を参照してください。

検証

2 つの段階があります。ファイルの作業完了を宣言する前に、両方を実行してください。

1. 構造のリント。 npx dmnlint で問題が 0 件と報告されるまで、DMN の編集は構造的に完了したとはいえません。

[ -f .dmnlintrc ] || echo '{ "extends": "dmnlint:recommended" }' > .dmnlintrc
npx --yes dmnlint path/to/decision.dmn

ディレクトリ全体を対象に作業する場合は、まず .dmn ファイルを再帰的に見つけ（.git、node_modules、target、build、.gradle、.mvn、.idea、.settings、.snapshots は除外）、見つかった各ファイルに対してリントを実行します。修正ループを続けてください。リント → 対象を絞った XML 編集 → リントを再実行し、問題がなくなるまで繰り返します。

よくあるルール：label-required（name を追加）、no-duplicate-requirements（重複した informationRequirement エッジを削除）。ルールと修正の対応一覧については、references/dmnlint.md を参照してください。

2. 実行による動作検証。 dmnlint は FEEL、ヒットポリシーの正しさ、型の一致を理解しません。意思決定を実行してください。

• 推奨 — 各 UNIQUE パーティション／FIRST のカスケード／COLLECT の経路を検証する CPT シナリオを作成または拡張します。camunda-process-test を参照してください。
• 代替 — c8ctl deploy decision.dmn process.bpmn --profile=local でデプロイし、c8ctl await pi --id MyProcess --variables '{...}' --profile=local でインスタンスを開始します。インシデントは、EXTRACT_VALUE_ERROR（FEEL の問題）または DECISION_EVALUATION_FAILED（ヒットポリシー違反）として表面化します。camunda-process-mgmt を参照してください。

BPMN の完了を確認するテストが成功しても、意思決定が失敗しなかったことしか証明できません。正しいルールが適用されたことは証明できません。動作の正しさに関するアサーション（assertThatDecision、ヒットポリシーごとのルール序数の照合、DRG カバレッジ）については、references/testing-decisions.md を参照してください。

参考資料

• decision-tables.md — 入力／出力句の形式、単項テストの形式、ヒットポリシーごとの実例、意思決定レベルの <variable> ルール、型の表、注意点
• feel-in-dmn.md — DMN の FEEL コンテキスト、単項テストと完全な FEEL の違い、リンクされた意思決定間のスコープ
• dmnlint.md — dmnlint:recommended のルール、ルールと修正の対応、リンターで検出できない一般的な注意点
• testing-decisions.md — assertThatDecision、ルール序数の照合、ヒットポリシーごとの戦略、DRG カバレッジ、モックとテストの違い