「オーケストレーション」とは、有限状態マシンを意味すると仮定しています。現在の状態によって、どの遷移をたどれば他の状態に移行できるかが決まります。エッジと頂点としての状態と遷移の表現は、多くの場合有向非巡回グラフを生成しますが、グラフが循環する場合があります (たとえば、ドラフト -- 承認のために提出 --> 承認待ち --> 却下 --> ドラフト)。
実際には、定義を実行から分離すると、カスタマイズに容易に対応できる永続化形式が求められます。システムが進化するにつれて、永続化スキーマを変更する必要はなく、コードのみを変更する必要がある解決策である、予期しないエッジ ケースが多数見つかります。これは、XML または NoSQL ソリューション (スキーマが簡単に変更されるか存在しないもの) を意味します。
さて、この目的のために独自の XML 定義を作成したので (興味深い理由で除外します)、JPDL (または BPMN) を使用することをお勧めします。その理由は、それらの定義には、現在検討していること、将来考えていることをすべて組み込み、カスタマイズを可能にする可能性が高いからです。たとえば、任意のデータをぶら下げたり、特定の時点で動作をオフにしたりできます。また、UI だけでなく、既に構築されているツールの利点も得られます。たとえば、サイクル検出を処理したり、完了へのパスがあることを確認したりできます。
私が知っている JPDL の興味深い機能のいくつかは、フォークされたプロセス、時間指定されたタスク (定期的に繰り返されるタスクを含む)、および通知を送信するための機能をマージする機能です。この最後の項目 - 通知 - には、さらに詳しい説明があります。私が自分のシステムで発見したことの 1 つは、流れるデータに基づいた内容の構成可能な電子メールを送信する必要があることです。これらの既存のエンジンは、たとえば変数をテキストにプラグインする方法を提供することで、これを比較的簡単にします。テキストは、実行時に送信前に動的に評価されます。また、ユーザー グループに通知を送信し、タスクを実行し、セキュリティ ポリシーを実施する目的で、エンジンと任意のユーザー ストア間のブリッジを提供します。
最後に、システムの範囲によっては、データベースも使用している可能性があります。私が提案するのは、シリアル化された形式でデータベースに編成されている XML とデータを保存することです。次に、データが実行中に変更されている場合は、データのシリアライゼーション (変更されている場合はおそらくワークフロー) も履歴/監査ログ テーブルに書き込みます。