2026-11 / 07
Camunda 研究 — 自分で閉じるロール
成果Camunda 8 の小さな実験を設計・運用しました。メッセージで開くロール、仕事が実際の子プロセスインスタンスとして届く 3 本の並列レーン、期限後に子が残っていなければ自分で終わるロールです。
概要
Camunda 8 のプロセス設計と実行時の挙動を扱う小さな実験集の最初の一つです。ロールはメッセージで開き、一定期間動いてから捌けて終わります。期間中に届いた仕事は、親とルートがそのロールである子インスタンスになり、ルートインスタンスの数は小さく保たれます。小さな運用ページから、ロールの開始・投入・取消と、月次または間隔のスケジュール編集ができます。
設計要件
月次のウィンドウは、任意の仕事を受け付けたうえで、ポーリングなし・仕事ごとにルートインスタンスを増やすことなく、自分で終わる必要がありました。
システム
課題
「今月」のようなウィンドウは、任意の仕事を受け付けたうえで自分で終わる必要がありますが、ポーリングは使いたくなく、仕事のたびにルートインスタンスが増えてエンジンを散らかすのも避けたい、という条件でした。
初期前提
最初の仮説
仕事を 1 件ずつメッセージで起動するか、ロール内のインラインのタスクとして走らせれば足りると考えました。
メッセージ role.open 1 通でロールが始まります。並列フォークが 3 本のレーンを開き、各レーンはイベントゲートウェイで絶対期限タイマーと終了メッセージを競わせ、非割り込みのイベントサブプロセス内のコールアクティビティで実際の子インスタンスを起動します。レーンは稼働中の子が終わるまで残るので、ロールは期限に加えて排出が終わった時点で閉じます。開始タイマーもポーリング変数もありません。
見つかった制約
role.open # message, correlation key roleKey
work.a|b|c # non-interrupting event sub-process -> call lab-child-a|b|c
role.close # races the absolute deadline timerメッセージ起動では仕事 1 件ごとにルートインスタンスができ、インラインのタスクでは親子関係をまったく示せませんでした。ロールを親・ルートとする実際の子インスタンスになるのは、非割り込みのイベントサブプロセス内のコールアクティビティだけでした。
退けた修正
最初の設計は仕事をインラインのサービスタスクとして走らせました。その 13 項目の検証結果は記録したうえで破棄しました。子インスタンスではなくスコープを測っていたためです。2 つ目はメッセージで子を起動し、N 個のルートができました。
設計判断
ロールを、3 本のレーンスコープとコールアクティビティの子を持つメッセージ起動のプロセスとしてモデル化し、レーンは稼働中の子が終わるまで残すことにしました。
結果
設計は動いています。ロールはスケジュールまたは手動で開き、レーン内で子が走り、ページには各ロールと実行中・完了済みの子が表示されます。先行する 2 つの設計は誤りで、記録にもそう明記しています。インラインのタスクでは親子関係を示せず、メッセージ起動の仕事は 1 件ごとにルートインスタンスになりました。期限競合・3 通の終了メッセージ・排出・取消の連鎖を含む完全な検証はまだ終わっておらず、主張は「設計し動かした」にとどめています。
現在の境界
境界: 期限競合・3 通の終了メッセージの相関・排出・取消の連鎖を含む完全な検証は終わっていません。スケジューラは実験プロセスの中にあり、分散スケジューラではありません。
次の一手: エンジンに対して検証を最後まで実行し、数字を記録してから主張を格上げします。