ASP.NET プログラム開発に WWF を使用する

はじめに

WWF を使用すると、プロセッサ フロー ベースのワークフローを作成し、任意の種類の .NET アプリケーションにデプロイできます。さらに、この記事では、ASP.NET 開発者が直面するいくつかの固有の問題、つまり状態やページ ナビゲーションの維持など、ワークフローを使用することで解決できる問題についても説明します。

2005 年 9 月、Microsoft は年 2 回の専門開発者カンファレンスで Windows Workflow Foundation (WWF、Windows Workflow Foundation) を発表しました。 WinFX API の柱の 1 つとして、WWF はプロセス主導型およびワークフロー中心のアプリケーションを開発するための共通フレームワークを開発者に提供します。

現在、一部の組織はビジネス プロセス全体を自動化しようとしていますが、その標準的な答えは、対応するコードを開発する開発者チームを編成することです。このアプローチはこれらの組織にはうまく機能しますが、固有の問題がいくつかあります。この問題を深く理解するには、ワークフローの基本的な特性を理解する必要があります。

ワークフローは本質的に、作業単位の完了に関連するアクティビティをアーカイブするための方法です。通常、処理中、作業は 1 つ以上のアクティビティを通じて「フロー」します。これらのアクティビティは機械または人間によって実行でき、インターネット アプリケーションでページの順序を定義するなど単純な場合もあれば、多数の人が閲覧、変更、承認する必要があるドキュメントや製品の管理など複雑な場合もあります。複雑な。

非常に多くのワークフローでは人間の関与を考慮する必要があるため、完了までに数時間から数か月以上の長い時間がかかる場合があります。たとえば、プロセスに関与する人が不在であるか、現地にいない、または他のタスクで忙しい場合があるため、ワークフローは非アクティブな期間中も継続できる必要があります。さらに、コーディングによって独自に実装されたプロセスは、技術者以外の人にとっては理解しにくく、開発者にとっては変更が難しい場合があります。これやその他の要素は、まさに Windows WF などの汎用ワークフロー フレームワークの目標です。このフレームワークは、ワークフローに視覚的なインターフェイスを提供するか、実現される共通の API セットを定義することによって、ワークフローの作成、変更、管理を容易にすることを目的としています。

WWF ワークフローは、Windows フォーム、コンソール アプリケーション、Windows サービス、ASP.NET Web アプリケーションなど、あらゆる種類の .NET アプリケーションに配置できます。それぞれのタイプには特別な考慮事項が必要です。いくつかの既存の例は、ワークフローを Windows フォームやコンソール アプリケーションにホストする方法を説明するのに十分ですが、この記事では、ワークフローを独自のアプリケーションに統合したい ASP.NET 開発者が直面する問題に焦点を当てます。

著者注: この記事で提供されているコードは、Windows WF Beta 1 および Visual Studio 2005 Beta 2 を使用して作成されました。 Windows WF のインストールに関する情報は、 www.windowsworkflow.netで参照できます。この記事では Windows WF の基本の一部について説明しますが、この分野では他のリソースも利用できます。読者は Windows WF について少なくとも少しは知っていると思います。この記事の目的は、Windows WF について高レベルから説明するのではなく、Windows WF と ASP.NET を詳しく分析することです。

1. Windows WF および MVC パターン

ASP.NET アプリケーションを開発する場合、WWF を使用する一般的な方法は、モデル ビュー コントローラー (MVC) アプローチを実装することです。本質的に、MVC の目標は、プレゼンテーション層、アプリケーション ロジック、およびアプリケーション フロー ロジックを分離することです。

これを理解することは、ASP.NET アプリケーションを開発するときに非常に有益です。ヘルプ デスク チケット ワークフローの場を検討してください。ビジネス ユーザーが ASP.NET Web フォームに記入し、送信ボタンをクリックしてこのワークフローを開始すると仮定します。次に、サーバーは Windows フォーム アプリケーションを使用して従業員とヘルプ デスクに「新しいチケットが利用可能です」と通知します。その後、ヘルプ デスクの従業員が問題に取り組み、最終的にチケットをクローズします。 Windows WF を使用してこのワークフロー シナリオを開発する場合、すべての処理ロジックとフローをワークフロー自体に含めることができ、ASP.NET アプリケーションはこのロジックをまったく理解する必要がありません。

この種の場では、確かな証拠が提供されます。説明と論理を分離するのは良いことです。ヘルプ デスクのリクエストを処理するこのプロセスは非常に日常的なものであるため、C# または VB.NET コードを使用してこのロジックを複数の異なる .NET アプリケーションに実装すると、コーディングが重複したり、まったく異なるコード リードを使用したりする危険が生じます。同じビジネスプロセスの異なる実装に。しかし、WWF を使用してこのプロセスを実装すると、このプロセスを必要とするアプリケーション開発者は、アプリケーション ロジックの変更を心配することなく、1 か所のステップ (ワークフロー自体) を変更するだけで済みます。 Windows WF を使用すると、コードの重複とこのプロセスの実装場所を軽減できます。

Windows WF を使用して ASP.NET に MVC アーキテクチャを実装する場合、開発者は、ワークフローがアプリケーション内でホストされている間に、アプリケーションから独立したワークフローを構築するように努める必要があります。これにより、ロジックを記述から独立させ、一連の作業ステップと Web アプリケーションのページ フローとの間の高度な独立性を維持することができます。

新しい WWF 開発者は、特定の順序で固定数のアクティビティを含むワークフローを開発し、同じ順序で 1 つのフォームから別のフォームに流れる一連の ASP.NET Web フォームを開発しようとするかもしれません。残念ながら、これは論理的であるように見えますが、ワークフロー ロジックを再度実装することになるため、実際には非常に非生産的です。 Web ページ X は、このワークフロー ステップを正しく実装するためにページ Y またはページ Z に移動する必要があるかどうかを知る必要はありません。代わりに、ワークフロー (モデル) が ASP.NET (コントローラー) に次に何をするかを指示し、ASP.NET がどのページを表示するかを決定する必要があります。このように、各ページはプロセス全体をほとんど理解する必要がなく、別のアクティビティを完了する方法を知り、ページがある場所から別の場所にどのように流れるかをワークフローに任せるだけで済みます。この分離により、開発者はページ フローを扱う際に大きな柔軟性が得られます。たとえば、ページの表示順序を変更する場合、ASP.NET アプリケーションのコードを 1 行も変更することなく、ワークフロー内から簡単に変更できます。

2. 単純なワークフロー MVC の例

このアイデアを説明するために、単純な ASP.NET アプリケーションとワークフローを示します。この非常に単純化されたワークフローは、外部アプリケーションからいくつかの個人情報を収集し、それを表示するプロセスを説明しています。手順は次のとおりです。

1. メソッドを呼び出します。これは、人の名前を要求することを意味します。このワークフローでは、InvokeMethod アクティビティを使用します (図 1 を参照)。

2. イベントが発生するまで待ちます。これは、名前を受け取ることを意味します。このステップでは、ワークフローは EventSink アクティビティを使用します。

3. 同様の呼び出しを使用してホストから電子メール アドレスを取得します。

4. イベントを待つということは、アドレスを受信することを意味します。

5. 名前と電子メールを受信した後、ワークフローは InvokeMethod アクティビティを開始して、呼び出し側アプリケーションに個人情報を送信します。実際の状況では、この最後のステップはそれほど重要ではありません。おそらく、Web サービスを呼び出してデータを別のシステムに送信したり、データベースに保存したりすることになるでしょう。

図 1. サンプル ワークフロー: このワークフローは、サンプル ASP.NET アプリケーションに暗黙的に含まれるプロセスを説明します。