Windows Workflow Foundation のホスティングの概要

ムスタファ ハリル アーメッド
プログラム マネージャー
Microsoft Corporation

2006 年 8 月

適用対象:
   Windows Workflow Foundation
   Microsoft .NET Framework 2.0
   Microsoft .NET Framework 3.0

概要： Windows Workflow Foundation (WF) をホストするアプリケーションが実行中のワークフローを管理および監視する方法の概要について説明し、ランタイム サービスとそのすぐに使用できる実装の概要を示します。 読者は、Microsoft .NET Framework、C#、WF プログラミング モデルに精通している必要があります。 (16ページ印刷)

内容

はじめに
ワークフロー インスタンスのライフ サイクルの管理
管理容易性と監視
信頼性と高可用性
基本ランタイム サービス
まとめ
詳細情報

はじめに

この記事は、Windows Workflow Foundation (WF) を使用する開発者向けであり、実行中のワークフロー インスタンスをアプリケーションで管理および監視できるようにするためのさまざまなオプションを理解するのに役立ちます。 この記事では、読者が Microsoft .NET Framework、C#、WF について基本的に理解していることを前提としています。

WF は、アクティビティ ライブラリとフレームワーク、ランタイム エンジン、およびホスト アプリケーション プロセス内で実行する必要があるランタイム サービス コンポーネントで構成されます。 ワークフローは、ランタイム エンジンによって実行されるアクティビティのセットとして構築されます。 ランタイム エンジンは、ホスト アプリケーション プロセス内で実行する必要があります。 次の図は、ワークフロー、アクティビティ、およびワークフロー ランタイム エンジンがプロセス内でホスト アプリケーションを使ってホストされるようすを示しています。

図 1. Windows Workflow Foundation ホスト プロセス

WF には、ワークフローの実行と状態管理を担当するランタイム エンジンが用意されています。 WF ランタイムは、ASP.NET、Windows サービス、コンソール アプリケーション、Windows フォーム アプリケーションなど、任意の .NET プロセスでホストできます。 開発者は、ワークフロー対応アプリケーションをビルドするときに、このホスト プロセスを記述する必要があります。 ランタイム サービスはホスト プロセスで動作し、ワークフローの実行を管理するランタイム エンジンに追加の機能を提供します。

WF のホスト アプリケーションを実装する場合は、考慮すべき多くの問題があります。 この記事では、ホスト アプリケーションがワークフローを管理および監視する方法の概要と、基本ランタイム サービスとそのすぐに使用できる実装の概要について説明します。

ワークフロー インスタンスのライフ サイクルの管理

WF では、ワークフローの状態とライフ サイクルを管理するために、 WorkflowInstance クラスにすぐに使用できるアクティビティと制御操作メソッドが用意されています。 「ワークフロー インスタンスのライフサイクルの管理」セクションでは、さまざまなワークフロー インスタンス固有のランタイム イベントと、それらのイベントとそのワークフロー状態との関係の切り替えについて説明します。

永続化ポイント

ワークフローは頻繁に実行時間が長く、実質的にアイドル状態で、ユーザーや他のシステムからの入力が続行されるのを待ちます。 アイドル状態のワークフローをメモリに保持することは実用的ではないので、ワークフローが待機しているイベントを受け取るまで、ワークフロー インスタンスの状態をストレージ メディアに保持することをお勧めします。 さらに、ワークフロー インスタンスの状態を保存すると、プロセスの後半でエラーが発生した場合に、その時点からワークフローを再開するのに役立ちます。

図 2 では、永続化ポイントを使用してワークフロー インスタンスの実行を再開する方法について説明します。

図 2. 永続化ポイントを使用してワークフロー インスタンスの実行を再開する

ワークフロー インスタンスの状態がポイント B で永続化され、ポイント C でエラーが発生した場合、アプリケーションは、ポイント A と B の間で実行された作業を失うことなく、ポイント B からワークフロー インスタンスを再開できます。ただし、永続化サービスが使用できない場合、またはワークフロー インスタンスの状態が永続化されていない場合、ポイント A から B までの作業は失われます。

WorkflowPersistenceService が存在する場合 (つまり、WorkflowRuntime インスタンスに追加されます)、ワークフロー ランタイム エンジンはこのサービスを使用して、ワークフロー インスタンスの状態をストレージ メディアに保持します。 これは、次の点で発生する可能性があります。

• PersistOnCloseAttribute でマークされているアクティビティの完了時 (トランザクション スコープ アクティビティなど)
• ワークフロー インスタンスの完了前
• ワークフロー インスタンスの終了前
• ワークフローがアイドル状態になったとき
• WorkflowInstance.Unload または WorkflowInstance.TryUnload が呼び出されたとき

WF ランタイム エンジンは、WorkflowPersistenceService で SaveWorkflowInstanceState() メソッドを呼び出して、ワークフロー インスタンスの状態を保存します。 LoadWorkflowInstanceState() メソッドを呼び出して、必要に応じワークフロー インスタンスの永続化状態を取得します。 ワークフロー ランタイムは永続化を実行するタイミングに関するすべてのセマンティクスを処理し、永続化サービスはワークフロー インスタンスの実際の保存と読み込みを担当します。 アクティビティの状態とワークフロー インスタンス ID はシリアル化され、永続化ストアに保存されます。 さらに、ワークフロー インスタンスの実行を再開するために必要なその他のすべての情報 (キューなど) は、シリアル化された保存された状態に含まれます。

ワークフロー インスタンス イベント

ワークフロー インスタンスは、 Created、 Running、 Suspended、 Completed、 および Terminated の 5 つの状態のいずれかになります。 ワークフローには、ワークフロー インスタンスの有効期間中に発生する 13 個のイベントがあります。 これらのイベントは、別の状態への遷移を示すことができます。 たとえば、 WorkflowCompleted イベントは、インスタンスが Running から Completed に移行したことを示します。 一部のイベントは、インスタンスが別の状態に移行したことを示していません。 たとえば、 WorkflowPersisted イベントは、インスタンスが永続化されていても実行中の状態であることを示します。 これらの 13 個のイベントのうち、11 個はランタイム イベントと追跡ワークフロー イベントを介してホスト アプリケーションに伝達されます。 Change イベントと Exception イベントの 2 つのイベントは、追跡ワークフロー イベントを介してのみホスト アプリケーションに伝達されます。

WF は WorkflowInstance クラスに制御操作メソッドを提供し、ホスト アプリケーションがワークフロー ライフ サイクルを管理できるようにします。 さらに、アプリケーションでは、ワークフローのライフ サイクルを管理するポリシーを設定できます。 たとえば、アプリケーションは、ワークフロー インスタンスをアンロードするように WF エンジンに指示するアンロード ポリシーを持つことができます。 WF には、ワークフロー インスタンスの統計に影響を与える可能性があるすぐに使用できるアクティビティが用意されています。たとえば、 SuspendActivity アクティビティと TerminateActivity アクティビティを使用して、それぞれワークフロー インスタンスを中断および終了できます。 次のセクションでは、ワークフロー インスタンスのイベントとワークフロー インスタンスの状態遷移を伝えるためにワークフロー ランタイムによって発生するさまざまなワークフロー インスタンス固有のイベントについて説明します。

WorkflowAborted

ワークフロー インスタンスは、ワークフロー ランタイム エンジンがメモリ内インスタンスを破棄すると中止されると見なされます。 ホスト アプリケーションは、 WorkflowInstance.Abort() を呼び出してワークフロー インスタンスを中止できます。 中止されたワークフロー インスタンスは、 WorkflowInstance.Resume() を呼び出すことによって、最後の永続化ポイントから再開できます。 ワークフロー インスタンスの中止は、 WorkflowInstance.Abort() が呼び出されるまで、アプリケーションが最後の永続化ポイントから実行されたすべての作業を破棄することを決定する極端な状況で使用されます。

WorkflowCompleted

ワークフロー インスタンスは、インスタンスの実行が完了すると完了します。 その時点で、ホスト アプリケーションは、ワークフロー インスタンスによって使用されなかったメッセージやその他のイベントのキューを調べることができます。

WorkflowCreated

ワークフローは、インスタンスが完全に構築された後、アクティビティの実行が開始される前に作成されます。 ワークフロー インスタンスは、複数の WorkflowRuntime.CreateWorkflow() オーバーロードされたメソッドのいずれかを呼び出すことによって作成されます。

WorkflowIdled

ワークフロー インスタンスは、外部イベント (タイマー、メッセージ、またはその他のカスタム イベント) が実行を続行するのを待機しているときにアイドル状態になります。 システム リソースを保存するために、アプリケーションはアンロード ポリシーを設定して、アイドル状態のときにワークフロー インスタンスをメモリからアンロードできます。 ホスト アプリケーションですぐに使用できる SqlWorkflowPersistenceService を使用している場合は、アプリケーション構成ファイルで UnloadOnIdle フラグを設定して、インスタンスがアイドル状態のときにワークフロー状態を保持するように WF ランタイム エンジンに指示できます。

WorkflowLoaded

WorkflowLoaded イベントは、インスタンスの状態が永続化ストアからメモリに読み込まれるときに発生します。

WorkflowPersisted

すぐに使用できる SqlWorkflowPersistenceService またはカスタム永続化サービスが WorkflowRuntime インスタンスに追加されている場合、ワークフロー インスタンスの状態が永続化ストアに保存されると、ワークフロー インスタンスが永続化されます。

WorkflowResumed

ワークフロー インスタンスは、中断または中止されたワークフロー インスタンスで WorkflowInstance.Resume() が呼び出されたときに再開されます。

WorkflowStarted

WorkflowInstance.Start() が呼び出されると、WorkflowStarted イベントが発生します。 ワークフロー開始イベントは、ワークフロー ランタイム エンジンがワークフロー アクティビティの実行を開始する前に発生します。

WorkflowSuspended

ワークフロー インスタンスの中断は、 WorkflowInstance.Suspend() 呼び出しまたは SuspendActivity アクティビティの実行時に実行されます。 その結果、ワークフロー インスタンスは中断状態になります。

WorkflowTerminated

ワークフロー インスタンスの終了は、 WorkflowInstance.Terminate() 呼び出し、 TerminateActivity アクティビティの実行時、または実行中のワークフロー インスタンスでハンドルされない例外が発生したときに実行されます。 このイベントが発生すると、ワークフロー インスタンスは終了状態になります。

WorkflowUnloaded

WorkflowUnloaded イベントは、ワークフロー インスタンスがメモリから永続化ストアにアンロードされるときに発生します。 これは、永続化ポリシーに応じて、または WorkflowInstance.Unload() または WorkflowInstance.TryUnload()の呼び出しによって行われます。

ワークフロー インスタンス イベントの遷移

ワークフロー インスタンス イベントは、ワークフロー ランタイム イベントと追跡ワークフロー イベントを介してホストに伝達されます。 ホスト アプリケーションは、ランタイム イベントをサブスクライブするか、追跡サービスを使用して通知を受け取ることができます。 例外イベントと変更イベントは、追跡サービスを介してのみホスト アプリケーションに伝達されます。 Exception イベントは、ワークフロー インスタンスの実行中に例外が発生したことを示します。 Changed イベントは、実行中にワークフロー インスタンスが動的に更新されたことを示します。

図 3 は、さまざまなワークフロー イベントとワークフローの状態の間の遷移を示しています。

大

図 3: ワークフロー イベントと状態の間の遷移 (画像をクリックして拡大)

永続化サービスが有効になっている場合は、図 3 に示すように永続化ポイントが発生します。 これらのホスト アプリケーションでは、必要に応じて WorkflowPersisted、 WorkflowUnloaded、 WorkflowLoaded の各イベントが表示されます。 ワークフロー インスタンスがメモリ内に存在せず、永続化サービスが有効になっている場合、インスタンスに対する有効な操作 (Resume、 Abort、 Terminate など) により、ワークフロー インスタンスが最初に読み込まれるので、要求の処理を続行します。 たとえば、中断されているがアンロードされたワークフロー インスタンスがある場合、 Resume を呼び出すと、最初に読み込まれた後、図に示すように Resumed イベントが引き続き発生します。

ワークフロー インスタンスの操作

前に説明したように、 WorkflowInstance クラスには、ワークフロー インスタンスのライフ サイクルを制御するためのメソッドがあります。 このセクションでは、これらのメソッドについて説明します。

WorkflowInstance.Start()

作成されたワークフロー インスタンスの実行を開始します。 WorkflowInstance.Start() により、ワークフロー ランタイムは WorkflowStarted イベントを発生させ、ワークフロー インスタンスは実行中の状態になります。 既に開始されているワークフロー インスタンスで Start() が呼び出されると、InvalidOperationException がスローされます。

WorkflowInstance.Abort()

ワークフロー インスタンスを中止します。 中止が成功すると、ワークフロー ランタイムは WorkflowAborted イベントを発生させます。

WorkflowInstance.Load()

永続化ストアからメモリにアンロードされたワークフロー インスタンスを読み込みます。 その後、インスタンスはアンロード前の状態から実行されるようにスケジュールされます。 読み込みが成功すると、ワークフロー ランタイムによって WorkflowLoaded イベントが 発生します。

WorkflowInstance.Resume()

中断または中止されたワークフロー インスタンスを再開 (引き続き実行) します。 ワークフロー ランタイムは、ワークフロー インスタンスの実行が再開 される直前に WorkflowResumed イベントを発生させます。

WorkflowInstance.Suspend()

ワークフロー インスタンスの実行を中断します。 WorkflowInstance.Suspend() の呼び出しが成功すると、ワークフロー ランタイムは WorkflowSuspended イベントを発生させます。

WorkflowInstance.Terminate()

ワークフロー インスタンスを終了し、メモリ内ワークフロー インスタンスをクリアします。 ワークフロー ランタイムは、登録された永続化サービスに、ワークフロー インスタンスがメモリからクリアされたことを通知します。 SqlWorkflowPersistenceService の場合、これは、そのワークフロー インスタンスのすべての状態情報が、終了時にデータベースから削除されることを意味します。 以前に保存した永続化ポイントからワークフロー インスタンスを再読み込みすることはできません。 WorkflowInstance.Terminate() が成功すると、ワークフロー ランタイムは WorkflowTerminated イベントを発生させます。

WorkflowInstance.Unload()

メモリ内のワークフロー インスタンスを永続ストアにアンロードします。 WorkflowInstance.Unload() は同期です。 アンロードを正常に実行するために、現在スケジュールされている作業が完了するか、トランザクション スコープの終了に達するまでブロックされます。 WorkflowInstance.Unload() が成功すると、ワークフロー ランタイムによって WorkflowUnloaded イベントが発生します。 登録された永続化サービスがないときに Unload() が呼び出されると、InvalidOperationException がスローされます。

WorkflowInstance.TryUnload()

WorkflowInstance.Unload()とは異なり、WorkflowInstance.TryUnload() はワークフローをアンロードできるまでブロックしません。 WorkflowInstance.TryUnload() は 、ワークフロー インスタンスをメモリから永続化ストアにアンロードし、インスタンスが中断またはアイドル状態のときに true を 返します。 それ以外の場合、呼び出しは false を返 します。 登録された永続化サービスがないときに TryUnload() が呼び出されると、InvalidOperationException がスローされます。

WorkflowInstance のさまざまな制御メソッドの詳細については、Windows Foundation SDK を参照してください。

管理容易性と監視

ワークフローをホストするアプリケーションは、ホストおよび実行するワークフローの管理と監視を担当します。 WF は、さまざまな管理容易性と監視ツールのサポートを提供します。 たとえば、WF には、ワークフロー データの抽出と監視のための低レベルのデバッグと追跡インフラストラクチャに使用できるエンドツーエンドのトレースが用意されています。

このセクションでは、管理容易性と監視インフラストラクチャの配置方法と、それをホスト アプリケーションで使用する方法について説明します。

追跡

WF には、ワークフロー インスタンスの実行中にワークフロー、アクティビティ、およびユーザー のイベントとデータをキャプチャするための追跡インフラストラクチャが用意されています。 ワークフロー ランタイム インスタンスには、複数の登録済み追跡サービスを含めることができます。または、いずれも使用できません。 追跡情報は、登録済みの追跡サービスに送信されます。 追跡サービスは、ホスト アプリケーションのニーズに従ってこの情報を格納および処理する役割を担います。 WF には、ホスト アプリケーションで使用できるすぐに使用できる SQL ベースの追跡サービス (SqlTrackingService) が用意されています。 さらに、ホスト アプリケーション開発者は、独自のカスタム追跡サービスを記述し、ホスト アプリケーションに使用できます。

追跡を使用して、ワークフロー インスタンスの実行履歴を調べ、システムで実行されているワークフロー インスタンスの現在の状態を確認できます。 さらに、追跡では、ワークフロー定義と共に使用して、システム上で実行されているワークフロー インスタンスの将来の予想される実行パスを予測できる情報を提供できます。 WF には、すぐに使用できる SqlTrackingService コントロールとワークフロー デザイナー コントロールを使用して、完了したワークフローと現在実行中のワークフローに関するワークフローとアクティビティの状態情報を表示する、ワークフロー モニター サンプルというアプリケーション サンプルが用意されています。

追跡を使用したワークフローの監視の詳細については、「アプリケーション サンプル/ワークフロー モニター サンプル」の ワークフロー モニター SDK ツール を参照してください。 カスタム追跡サービスを構築する方法を示す例については、「 ConsoleTrackingService Sample and File Tracking Service」および「Query Sample in Technology Samples/Tracking」を参照してください。 すぐに使用できる SqlTrackingService の使用方法を示す例については、「テクノロジ サンプル/Trackingout-of-box」の「SQLTrackingService サンプルを使用した単純な追跡サンプルとクエリ」を参照してください。

トレースとエンドツーエンドのトレース

トレースを使用してアプリケーションの正常性を監視し、実行中のシステムを妨げることなく問題を分離して修正できます。 WF では 、System.Diagnostics API を使用して、ルール セットの評価情報など、ワークフロー ランタイムとワークフロー インスタンスの実行に関する情報をトレースします。 既定では、トレースはオフになっていますが、必要に応じてオンにすることができます。

さらに、WF はエンドツーエンドのトレースに参加します。 エンドツーエンドのトレース機能を使用すると、トレース ビューアーは、さまざまなコンポーネント間の継続トレース情報と、それらのコンポーネント間の遷移を表示できます。 これにより、エンドツーエンドのデバッグが容易になります。

アプリケーション構成ファイルを使用している場合は、いくつかの WF 名前空間のログ トレースを有効にするには、次を追加する必要があります。

<system.diagnostics>
    <switches>
        <add name="System.Workflow LogToTraceListeners" value="1" />
        <add name="System.Workflow.Runtime" value="All" />
        <add name="System.Workflow.Runtime.Hosting" value="All" />
        <add name="System.Workflow.Runtime.Tracking" value="All" />
        <add name="System.Workflow.Activities" value="All" />
        <add name="System.Workflow.Activities.Rules" value="All" />
    </switches>
</system.diagnostics> 

LogToTraceListeners を使用すると、WF はホスト アプリケーション内で作成された各 TraceListener を列挙し、すべてのログ情報をそれらに送信します。 この例の残りの行では、ログ情報をキャプチャする名前空間と、トレースされる情報の量を指定できます。 value 属性に指定できる値には、All、Off、Critical、Error、Warning、Information、Verbose があります。 値属性の使用の詳細については、WF SDK を参照してください。

ワークフロー ランタイム イベント

ランタイム イベントはワークフロー ランタイムによって発生し、ワークフロー ランタイムとワークフロー インスタンスのライフ サイクルを管理する手段をホスト アプリケーションに提供します。 イベント ハンドラーは WorkflowRuntime クラスで定義されており、ホスト アプリケーションはこれらのイベントを使用するためにサブスクライブする必要があります。

ランタイム イベントは、ホスト アプリケーションがクエリを実行するためにそれらのイベントとそれに関連するデータを格納するのではなく、特定のイベントに対して動作する必要がある場合に、軽量通知システムとして機能します。 後者の場合は、追跡インフラストラクチャを使用することをお勧めします。

WorkflowRuntime のインスタンスは、複数のワークフロー インスタンスを実行している可能性があります。各ワークフロー インスタンスには、独自のライフ サイクルがあります。 したがって、ワークフロー インスタンス イベントのイベント引数には、ワークフロー インスタンス ID とその他の情報が含まれます。 この情報を使用して、イベントをワークフロー ランタイムがこのイベントを発生させる原因となっているワークフロー インスタンスと関連付けることができます。

次のセクションでは、使用可能なワークフロー ランタイム イベントについて説明します。

WorkflowRuntime.ServiceExceptionNotHandled

このイベントは、サービス所有のスレッドが例外をスローしたときに発生します。 WorkflowRuntimeService クラスから派生したサービスは RaiseServicesExceptionNotHandledEvent() メソッドを呼び出して、実行中に例外が発生し、この例外を処理できなかったことを ServicesExceptionNotHandled イベントにサブスクライバーに通知できます。 このような状況では、アウトオブボックス サービスによってこのイベントが発生します。 ホスト アプリケーションは、このイベントをサブスクライブして回復メカニズムを実装できます。 このイベントに関連付けられているイベント引数は ServicesExceptionNotHandledEventArgs です。

WorkflowRuntime.Started

このイベントは、 WorkflowRuntime の指定されたインスタンスが開始されると発生します。 このイベントに関連付けられているイベント引数は WorkflowRuntimeEventArgs です。

WorkflowRuntime.Stopped

このイベントは、 WorkflowRuntime の指定されたインスタンスが停止したときに発生します。 このイベントに関連付けられているイベント引数は WorkflowRuntimeEventArgs です。

表 1 WorkflowInstanceEvents

さまざまなイベントとワークフローがさまざまな状態に入る方法の詳細については、この記事の前の「ワークフロー ライフ サイクルの管理」セクションを参照してください。

さまざまなワークフロー ランタイム イベントの使用方法については、「Windows Workflow Foundation SDK サンプル」を参照してください。

パフォーマンス カウンター

Windows パフォーマンス ツールを使用して、ワークフローのパフォーマンスを監視できます。 システム モニターとパフォーマンス ログとアラートの 2 つの部分で構成されます。 パフォーマンス ログとアラートを使用すると、パフォーマンス カウンターを構成してパフォーマンス データを記録し、指定したカウンターの値が定義されたしきい値を超えるか下回ったときに通知するようにシステム アラートを設定できます。

WF には、ワークフローのパフォーマンスを追跡するために使用できる WF パフォーマンス オブジェクトを含む一連のパフォーマンス カウンターが用意されています。 パフォーマンス カウンターの完全な一覧については、WF SDK の ワークフロー パフォーマンス カウンターに関するセクションを参照してください。

パフォーマンス ツールにパフォーマンス カウンターを追加する方法の詳細については、Microsoft TechNet Web サイトを参照してください。

ポリシーのアンロード

システムでは、特定の時点で何千ものワークフローが同時に実行される可能性があります。 すべてのユーザーがメモリ内に留まるのを許可することは実用的でない場合があります。 システムのリソースをより適切に管理するために、アンロード ポリシーを設定してワークフローの状態を保持し、メモリからアンロードすることができます。

すぐに使用できる永続化サービスを使用する場合、WF はアイドル 状態のポリシーに対してアンロードを提供します。 SqlWorkflowPersistenceService クラスで UnloadOnIdle プロパティを設定し、アイドル状態のときにワークフローをアンロードするようにランタイム エンジンに指示すると、ポリシーはアクティブになります。 ホスト アプリケーションが構成ファイルを介して SqlWorkflowPersistenceService を有効にする場合は、 UnloadOnIdle フラグを true に設定することでこれを行うことができます。 SqlWorkflowPersistenceService がコードを使用して構築され、有効になっている場合、ホスト アプリケーションは SqlWorkflowPersistenceService (String、Boolean、TimeSpan、TimeSpan) コンストラクターを使用して構築する必要があります。 ホスト アプリケーションでは、他の複雑なアンロード ポリシーを実装できます。

さらに、 WorkflowInstance.Unload() メソッドを呼び出して、この特定のワークフロー インスタンスをメモリからアンロードし、その状態を保持するように要求できます。 ホスト アプリケーションは、後でインスタンスで Load() メソッドを呼び出して、最後の永続化ポイントから実行を続けることができます。 ワークフロー インスタンスがアンロードされると、ランタイム イベント WorkflowUnloaded イベントが発生します。

信頼性と高可用性

WF では、次のサポートを提供することで、信頼性と高可用性を選択するホストがサポートされています。

SQL クラスタリング

すぐに使用する SQL ベースのサービスでは、クラスタリングのインストールがサポートされます。 WF のすぐに使用できる SQL ベースのサービスは、バッチをSQL Serverにコミットするときに再試行を提供します。 そのため、フェールオーバー シナリオまたは一時的にアクセスできない SQL サーバーをサポートします。 再試行ロジックは、次のいずれかのサービスの組み合わせで設定できます。

• DefaultWorkflowCommitWorkBatchService
• SharedConnectionWorkflowCommitWorkBatchService
• SqlTrackingService
• SqlWorkflowPersistenceService

既定では、再試行ロジックは OFF です。 この機能を使用するには、ホスト アプリケーションで再試行ロジックを明示的に ON にする必要があります。 アプリケーションは、サービスごと、または前述したすべてのサービスで再試行を有効にすることを選択できます。 これを行うには、サービス クラスの EnableRetries プロパティを設定するか、構成ファイルを使用します。 構成ファイルを使用すると、ホスト アプリケーションは共有フラグ EnableRetries を使用して、影響を受けるすべてのサービスで有効な再試行を ON または OFF に設定できます。 サービスで EnableRetries プロパティが設定されている場合、その値によって EnableRetries 共有フラグ値が上書きされます。 WF の既定の SQL ベースのサービスは、一定の回数再試行します。 再試行回数は構成できません。 ただし、アプリケーションはサービスの接続文字列の接続タイムアウトを調整して、再試行の間隔を部分的に調整できます。

再試行の設定

次の例では、共通パラメーター EnableRetries を追加し、その値を True に設定して、すべての既定のサービスに対して EnableRetries を設定する方法を示します。 このサービスの EnableRetries フラグを追加し、False に設定することで、SqlWorkflowPersistenceService の EnableRetries を無効にする方法を示 します。

<WorkflowRuntime Name="SampleApplication" UnloadOnIdle="false">
    <CommonParameters>
        <add name="ConnectionString" value="Initial Catalog=WorkflowStore;Data Source=localhost;Integrated Security=SSPI;" />
        <add name="EnableRetries" value="True" />
    </CommonParameters>
    <Services>
        <add type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService, 
System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, 
PublicKeyToken=31bf3856ad364e35" EnableRetries="False"  />
    </Services>
</WorkflowRuntime>

一般に、すべてのサービスの再試行を ON または OFF に設定することをお勧めします。

WorkflowCommitWorkBatchService クラスは、TransactionScopeActivity 以外のすべてのアクティビティに関連するすべてのバッチ コミット (永続化ポイント) を再試行することに注意してください。 WorkflowCommitBatchService クラスは、TransactionScopeActivity アクティビティの作業バッチ コミットの再試行を実行できません。 これは、この場合、トランザクションを開始していないため、トランザクションを所有していないためです。 TransactionScopeActivity アクティビティの作業バッチ コミットの再試行は、ワークフローにモデル化する必要があります。 これは通常、 While ループと TransactionScopeActivity の外部の例外ハンドラーの形式で行われます。

非トランザクション モードで実行されている場合は、既定の SqlTrackingService で再試行し、既定の SqlWorkflowPersistenceService は、作業バッチ コミットとは関係のない SQL 関連の作業を制御します。 これには、期限切れのタイマーのチェックとワークフロー インスタンスの読み込みが含まれます。

負荷分散とFront-Endスケーリング

WF をホストしているアプリケーションは、負荷分散シナリオとフロントエンド スケーリング シナリオを管理します。 WF では、エンジンとすぐに使用できる SQL ベースのサービスがサポートされ、異なるホスト アプリケーション インスタンスが同じ永続化または追跡 SQL データベースを指すようにすることができます。

複数のホスト アプリケーションが同じ永続化ストアに接続されている場合は、いずれかのホスト アプリケーションがデータベースからワークフロー インスタンスの種類を読み込むことができます。 WF の既定の SqlWorkflowPersistenceService では、同じ永続化ストアを共有するときに、特定のホストに読み込まれるワークフローの種類またはインスタンスの割り当てはサポートされていません。 この動作がホスト アプリケーションのニーズを満たしていない場合は、カスタム永続化サービスを実装する必要があります。

WF ランタイム エンジンは、複数のホスト アプリケーションが同じ永続化ストアを使用する場合のフロントエンド スケーリング シナリオをサポートするロック セマンティクスを提供します。 ロック セマンティクスを使用すると、別のアプリケーションによって既に読み込まれているワークフロー インスタンスをアプリケーションが読み込めなくなります。 WorkflowPersistenceService クラスを使用すると、ワークフロー インスタンスの状態情報をデータ ストアでロック解除するかどうかを指定する SaveWorkflowInstanceState() メソッドにパラメーターを指定し、UnlockWorkflowInstanceState() メソッドを指定して、以前にロックされたワークフロー状態情報をロック解除することで、このワークフロー ランタイム エンジン機能をサポートできます。 ロックを実装する永続化サービスでは、 LoadWorkflowInstanceState() メソッドの呼び出しでワークフロー インスタンスの状態情報をロックする必要があります。

ワークフロー インスタンスのロック セマンティクスの詳細については、「WF プログラミング ガイド」の 「Windows ワークフロー 永続化サービス」および「 カスタム永続化サービスの作成 」セクションを参照してください。

基本ランタイム サービス

WF ランタイム エンジンは、ランタイム サービスを使用してワークフローを実行します。 ランタイム サービス モデルにより、ホスト アプリケーションは WF ランタイム エンジンにさまざまなサービスを柔軟に提供できます。 このセクションでは、WF によって提供されるランタイム サービスと、それらのサービスの既定の実装について説明します。

ランタイム サービス の実装の詳細については、「WF プログラミング ガイド」の 「Windows Workflow Foundation Services」および「Windows Workflow Foundation Services の開発 」セクションを参照してください。

WF ランタイムは、4 つのサービスを提供します。 これらのサービスには、すぐに使用できる実装があります。または、ホスト アプリケーションは独自のサービスを実装し、ワークフロー ランタイムに提供できます。

ワークフロー トランザクション サービス

Windows ワークフロー トランザクション サービス (WorkflowCommitWorkBatchService) の目的は、作業バッチ ( 永続化ポイントとも呼ばれます) のコミットメントに関するカスタム ロジックを有効にすることです。 作業バッチがコミットされると、ランタイムは現在のトランザクション サービスを呼び出し、デリゲートを渡してを呼び出して、作業バッチの実際のコミットを実行します。 コミットの実行は通常どおりランタイムが担当しますが、サービスを処理に参加させることによって、コミット処理をある程度カスタマイズできます。

WF フレームワークでは、外部から独自のトランザクションをワークフロー インスタンスに取り込む機能はサポートされていません。 WorkflowCommitWorkBatchService でサポートされるアンビエント トランザクションの種類は、ワークフロー インスタンスによって生成されるトランザクションのみです。 ワークフロー ランタイムを実行しているホスト アプリケーションによって生成されたアンビエント トランザクションは、副作用を減らすために、現在のスレッドから一時的に削除されます。 ワークフローがアイドル状態の後、に含まれるホスト アプリケーションの元のアンビエント トランザクションがスレッドに戻されます。

WF には、トランザクション サービス用の既定の実装として 、DefaultWorkflowCommitWorkBatchService と SharedConnectionWorkflowCommitWorkBatchService という 2 つの既定の実装が用意されています。

WF ランタイム エンジンにはワークフロー トランザクション サービスが必要です。 既定では、 DefaultWorkflowCommitWorkBatchService が使用されます。 ホスト アプリケーションは、 DefaultWorkflowSchedulerService を SharedConnectionDefaultWorkflowCommitWorkBatchService またはカスタム サービスに置き換えることを選択できます。

DefaultWorkflowCommitWorkBatchService

ワークフロー ランタイム エンジンが起動すると、 DefaultWorkflowCommitWorkBatchService のインスタンスが作成され、他のトランザクション サービスが追加されていない場合は WorkflowRuntime に追加されます。 このサービスは、データベース接続ごとに.NET Frameworkトランザクションを作成します。 たとえば、SQL Tracking Services と SQL Persistence Services の間の接続は共有されません。 ワークフローでこのサービスを使用して、データの整合性に必要なトランザクションをサポートできます。

SharedConnectionWorkflowCommitWorkBatchService

このサービスは、さまざまなオブジェクト間の共有接続を使用するデータベース トランザクション用に使用されます。 ホスト アプリケーションでこのサービスを使用する場合は、AddService メソッドを使用するか、構成ファイルを使用して WorkflowRuntime に追加する必要があります。

ワークフロー スケジューラ サービス

ワークフロー スケジューラ サービスは、ワークフロー ランタイム エンジンがワークフロー インスタンスを非同期または手動の同期モードで処理するかどうかに関係なく、ワークフロー インスタンスをスケジュールする方法を管理します。 WF には、 WorkflowSchedulerService に既定の 2 つの実装 ( DefaultWorkflowSchedulerService と ManualWorkflowSchedulerService) が用意されています。

WF ランタイム エンジンでは、ワークフローを実行するためにワークフロー スケジューラ サービスが必要です。 既定では、 DefaultWorkflowSchedulerService が使用されます。 ホスト アプリケーションは、 DefaultWorkflowSchedulerService を ManualWorkflowSchedulerService またはカスタム サービス に 置き換えることを選択できます。

DefaultWorkflowSchedulerService

DefaultWorkflowSchedulerService は、ワークフロー ランタイム エンジンで非同期的にワークフロー インスタンスを実行するスレッドを作成および管理し、ランタイム スレッド プールに複数のワークフロー インスタンスをキューに入れる既定のサポートを含みます。 WorkflowRuntime に他のワークフロー スケジューラ サービス インスタンスが追加されていない場合、既定では DefaultWorkflowSchedulerService が使用されます。

ManualWorkflowSchedulerService

ManualWorkflowSchedulerService は、ワークフロー インスタンスの同期実行に使用されます。 このサービスを使用している場合、ワークフロー インスタンスはホスト アプリケーションから呼び出し元のスレッドで実行されるため、ワークフロー インスタンスがアイドル状態になるまでホスト アプリケーションの実行がブロックされます。

ワークフロー永続化サービス

永続化サービスは、ワークフロー インスタンスの状態の格納と取得 (読み込みとアンロード) を行います。 WF では、永続性サービス SqlWorkflowPersistenceService のすぐに使用可能な SQL ベースの実装が提供されます。

SqlWorkflowPersistenceService

この標準の実装では、状態とタイマーの情報が SQL Server/MSDE に格納されます。 SqlWorkflowPersistenceService はワークフロー トランザクションに参加し、ロック アクセスを実装します。 さらに、 SqlWorkflowPersistenceService には、SQL サーバーが使用できないときに再試行を有効にする機能が用意されています。 これは、サービスで EnableRetries プロパティを設定することで制御できます。 SqlWorkflowPersistenceService の詳細については、「WF プログラミング ガイド」を参照してください。

ワークフロー追跡サービス

追跡サービスは、追跡プロファイルと追跡情報の保存を管理します。 WF には、 SqlTrackingService クラスに実装された追跡サービスの、すぐに使用する SQL ベースの実装が用意されています。

SqlTrackingService

この実装では、追跡プロファイルとデータを SQL Server/MSDE に格納します。 このサービスでは、次の機能がサポートされています。

• 既定ではワークフロー トランザクションに参加します。動作は 、SqlTrackingService.IsTransactional プロパティによって制御されます。

• すべての種類の既定の追跡プロファイルを使用したり、ワークフローの種類またはワークフロー インスタンスごとに追跡プロファイルを関連付けたりするためのメカニズムを提供します。

• ライブおよびオンデマンドのパーティション分割機能を提供することで、データメンテナンスをサポートします。

  データ メンテナンスの詳細については、「WF プログラミング ガイド」の 「SqlTrackingService を使用したデータメンテナンス 」セクションを参照してください。

さらに、WF には 、SqlTrackingService に格納されている追跡データのクエリに使用できる SqlTrackingQuery API が用意されています。 SqlTrackingService の詳細については、「WF プログラミング ガイド」を参照してください。

まとめ

WF には、ワークフローを実行し、その状態を管理するためのランタイム エンジンとサービスが用意されています。 ホスト アプリケーションまたはプロセスは、ホスト WF ワークフローに書き込む必要があります。 このホスト アプリケーションは、ワークフロー ランタイム エンジンにさまざまなランタイム サービスを提供します。 WF アウトオブボックス ランタイム サービスは、一般的なシナリオに対処するためのものです。 ただし、すぐに使用できるサービスがホスト アプリケーションのニーズを満たしていない場合は、ホスト アプリケーションでカスタム サービスを実装し、ワークフロー ランタイムに提供する必要があります。

さらに、WF には、実行中のワークフロー インスタンスを管理および監視し、信頼性と高可用性を選択するホスト アプリケーションをサポートするためのインフラストラクチャが用意されています。 ホスト アプリケーションは、ホスティング固有のシナリオに基づいてさまざまなオプションを使用する方法を決定する必要があります。

詳細情報

この記事は、次のリソースと共に、ワークフロー テクノロジを初めて使用する開発者がテクノロジについて学習し、それを使用して迅速に生産性を高めるのに役立つ必要があります。

• MSDN ワークフロー デベロッパー センター
  • Web キャストとラボへのドキュメントとリンクが含まれています。
• コミュニティ サイトのサンプル
• Windows SDK のドキュメント
  • Windows Foundation SDK をお持ちでない場合は、 Windows SDK サイトからダウンロードしてください。 Windows Workflow SDK は、Windows SDK の一部です。 WF プログラミング ガイドのリファレンス、API リファレンス、さまざまな テクノロジとアプリケーションのサンプルが含まれています。
• MSDN ワークフロー フォーラム
  • WF ランタイム ホスティングまたは WF 全般に関連する質問に対する回答を提供できるディスカッション フォーラム。

筆者について

Moustafa Khalil Ahmed は、MICROSOFT Corp.、Redmond、WA の WF チームを持つプログラム マネージャーです。 2000 年に Microsoft に入社して以来、さまざまなサーバー コンポーネントの開発に取り組み、Microsoft BizTalk Server を含む 4 つのサーバー製品の出荷を支援してきました。 Microsoft で働く前は、エジプトのカイロにある ITWorx でソフトウェア エンジニア、ビジネス アナリスト、アカウント マネージャーを務め、業務を担当していました。