ワークフロー システムのアーキテクチャ

  • [アーティクル]

重要

Human Resources を使用している顧客の場合、この記事で説明した機能は、現在、スタンドアロン Dynamics 365 Human Resources とマージした Finance インフラストラクチャの両方で利用できます。 更新中は、記載されたナビゲーションと異なる場合があります。 特定のページを検索する場合は、検索を使用できます。

この記事では、ワークフロー システムのアーキテクチャについて説明します。

ワークフロー インフラストラクチャは、Application Object Server (AOS) でホストされる 2 つのコンポーネント (X++ ワークフロー ランタイムおよび管理ワークフロー ランタイム) で構成されます。

X++ ワークフロー ランタイムは、次のコンポーネントで構成されます。

  • ワークフロー ランタイム アプリケーション プログラミング インターフェイス (API)
  • メッセージング バッチ ジョブ
  • メッセージ キュー

必要に応じて、メッセージング バッチ ジョブまたはワークフロー ランタイム API のいずれかがアプリケーション コードを呼び出すことができます。 X++ ワークフロー ランタイムは、Microsoft .NET フレームワークの CIL (共通中間言語) にコンパイルされます。

管理ワークフロー ランタイムは、Windows Workflow Foundation および財務と運用アプリの拡張機能で構成されます。

論理的には、ワークフロー インフラストラクチャは拡張であり、ユーザーにとって透過的です。 物理的には、X++ ワークフローおよび管理ワークフローのランタイムは両方とも AOS でホストされます。 ワークフロー インフラストラクチャは AOS と .NET Interop でバッチ処理を使用して、その 2 つのサブシステムを統合し、片方のサブシステムからもう一方のサブシステムにメッセージを渡します。 バッチ プロセッサで実行される X++ コードは、.NET CIL にコンパイルされます。 バッチ処理は、.NET 共通言語ランタイム (CLR) で実行されます。

次の図に、ワークフロー インフラストラクチャの高レベル アーキテクチャの概要を示します。

workflow_architecturediagram2016.

ユーザーは、 ワークフロー ページとコントロールを使用して、業務プロセスに参加できます。

開発者は、追加済のオブジェクトのワークフローを作成できます。 次の表は、ユーザーが経費精算書を承認のためにワークフロー システムに提出したときに発生するワークフロー ステップを示します。

ステップ ランタイム 活動
1 X++ ワークフロー ランタイム ユーザーは、ワークフローのいずれかの制御で 送信 をクリックして、経費精算書を送信します。 このアクションにより、X++ コードはワークフロー ランタイム API を呼び出し、ワークフロー インスタンスが有効になります。 ワークフロー ランタイム API は、メッセージをメッセージ キューに書き込みます。 メッセージング バッチ ジョブは、メッセージを読み取り、ワークフローのアクティブ化要求を管理ワークフロー ランタイムに送信します。 注意: メッセージング バッチ ジョブは 1 分間隔でメッセージ キューを処理します。
2 管理されるワークフロー ランタイム X++ からの .NET Interop は、メッセージを受け取り、新しいワークフロー インスタンスを Windows Workflow Foundation 経由で開始します。 このワークフロー インスタンスは、X++ への.NET Interop CIL 経由でX++ ワークフロー ランタイム API のコールバックを実行し、ワークフローが起動されたことを示すメッセージを書き込みます。

メッセージが転記されると、管理ワークフロー ランタイムは、アイドル状態のワークフロー インスタンスをデータベースに保存します。 その後、ランタイムはメモリからワークフロー インスタンスを削除します。 管理ワークフロー ランタイムが、このワークフロー インスタンスに対する別のメッセージを X++ ワークフロー ランタイムから受け取ると、ワークフロー インスタンスはメモリーに復元され、再開されます。

各ワークフロー インスタンスは固有です。 2 人のユーザーが承認のために経費精算書を提出すると、2 つのワークフロー インスタンスが開始されます。
3 X++ ワークフロー ランタイム メッセージング バッチ ジョブが、ワークフローで開始されたメッセージをメッセージ キューから読み取り、ワークフローで開始されたイベントを処理するアプリケーション イベント ハンドラーを開始します。 次に、バッチ ジョブは、イベントが処理されたことを示す確認メッセージを書き込みます。
4 両方 この同じメッセージング パターンが、ワークフロー インスタンスのライフサイクル全体で必要に応じて繰り返されます。

このワークフロー アーキテクチャは、信頼できる堅牢なメッセージ システムを提供し、また、ワークフローの状態とアプリケーションの状態を常に同期させるために役立ちます。 ハードウェアやソフトウェアに予期しない障害が発生すると、ワークフロー インスタンスの状態は最後に保存された既知の点まで戻され、メッセージはキュー内に保持されます。 したがって、アーキテクチャから見ると、復旧モデルは、問題の解決とワークフローの再開です。