2007/08/16 Update: 実際にこの精神で作成したサンプルコード (sample code) を以下に掲載しました。
/2007/08/16/wf-web-part-1/

こんにちは。

昨日は、MSDNオフラインセミナー「.NET Framework 3.0 によるサーバアプリケーションの開発」にご参加された皆様、お疲れ様でした。

昨日のセミナーの最後でふれましたが、ワークフローはフレームワーク的にさまざまな箇所で応用できますが、ワークフローを使ってWebの画面をコントロールすることは大変難しいという点をご説明しました。画面遷移などをワークフローで作成できたなら、業務ルールの変更に伴い画面のロジックが変更される場合などにおいても、モデル駆動で対応することができるようになり、大変強力です。今日は、その方法について記載したいと思います。

あらかじめ記載すると、上述した通り、この点に関しては残念なことに一筋縄にはいきません。(今後、何某かの形で下記のような処理をラッピングした便利な仕組みが登場してくることでしょう。) いつものように簡単なサンプルを作成してコードをご紹介しても良いのですが、なかなかそこまで時間もとれないので、申し訳ありませんが、どのような処理概念で、どんなところをポイントに作成するかといったところを以下に手順を追ってご説明します。

前提知識として、Windows Server 2008 の Developer Center の 「ワークフローの作成とランタイムサービス (EDS, 永続化サービス) の利用」でご紹介しているレベルの WF (Windows Workflow Foundation) の知識は必要になりますので、まだこれからという方は、まずはこれらの情報を参考にして WF のイメージをつかんだ上で参考にしてください。

＜構成イメージ＞ (2007/06/08 わかりづらいため図挿入しました)

[ワークフロー側の作成]

• ワークフローを作成する前に、まずカスタムなランタイムサービス(ランタイムサービスのインタフェース)を作成しておきます。このサービスのインタフェースは、遷移する画面ごとに作成しておきます。
  例として、作成画面、承認画面、却下画面、参照画面の４つの間の画面を遷移する場合、対応する４つのカスタムなサービス(サービスのインタフェース)を作成しておきます。
  (2007/06/08追記： 上図では「画面遷移を呼び出すサービス」のような書き方になっていますが、モデリング上は、「ユーザへの承認行為の要求」など、ワークフロー上では「画面」というものを意識しないつくりにしておくと良いでしょう。このようにすることで、同じワークフローのアセンブリをASP.NET以外のアプリにも展開できます。)
• つぎに、上記のサービスを呼び出すカスタムなアクティビティ(上記の例だと4種類のカスタムアクティビティ)を作成しておきます。
• これで準備は完了です。
  ワークフロー作成では、この作成したアクティビティを使って、処理と画面遷移を組み合わせて作成していきます。

[ホストアプリケーション (ASP.NET) 側の作成]

• ホスト側では、上記で作成したサービス(ランタイムサービス)のインタフェースを実装し、AddService でこの実装をランタイムに組み込みます。
  そして、この組み込む実装の中で、実際にページのリダイレクトの処理を記述しておきます。
• 遷移する画面の数 (上記の例だと4つです) だけ、ASP.NET ページ(.aspx)を作成します。
  ここは、必要なロジックなどを通常の ASP.NET の開発同様に作成していきます。
• 各 ASP.NET ページ (.aspx) では、ワークフローに処理を渡すための Submit 用のボタンを作成しておきます。
• ワークフローとの連携をコントロールするためのコントローラ用の .aspxファイル (上記の画面とは異なります) を作成します。
  そして、上記の各 Submit ボタンが押されたときの処理として、このコントローラ用のページに常にリダイレクトするようにします。その際、GET の引数などを使って、ワークフローインスタンスID と必要なパラメータ (これはアプリケーションの内容によって異なるでしょう) を渡すようにします。(もし初回起動時の画面で、まだワークフローインスタンスIDが存在していない場合には、空文字をそのまま渡します。)
• コントローラ用のページ (.aspx) では、ワークフローインスタンスID を受け取って処理するようにします。
  この例では、コントローラ用のページとして、実際の ASP.NET ページ (.aspx ファイル) を作成するのではなく、カスタムハンドラ (カスタムの HttpHandler) を利用することにしましょう。(画面を持っていないコントローラですので。尚、カスタムハンドラの詳細は、こちら でデモとサンプルソースを掲載しています。)
  Web.config を編集して、上記のコントローラ用のページ (.aspx) が呼ばれたら、このカスタムハンドラを使って処理するように定義しておきます。
• カスタムハンドラのコードの中では、ワークフローランタイムの作成をおこないます。そして、ワークフローインスタンスIDが空の場合はワークフローインスタンスを新規作成し、空でない場合は GetWorkflow などを使ってインスタンスを取得します （永続化サービスを使っている場合は、このタイミングでインスタンスのロードがおこなわれます） →(2007/06/08削除： GetWorkflow でロードされますが、今回の例ではEDSを使ってインスタンスを呼び出すのでGetWorkflowは必要ありませんでした、、、すみません、書き終わった後気づきました、、、)。
• さらに、インスタンスの起動が終わったら、データ交換サービス (EDS) を使ってワークフロー側に「ワークフローを実行しても良い」ということを通知するためイベントを渡すようにします。また必要に応じ、データ交換サービスで使う ExternalDataEventArgs を継承してアプリケーション固有の引数なども受け取れるようにしてください。
• 上記で作成したワークフローが実行(または再開)され、上記で作成した画面遷移用のカスタムアクティビティに到達すると、画面遷移用のサービスの実装(ホスト側の実装)がコールされ、リダイレクトします。

  以降は、作成されたインスタンスIDを引き渡しながら、画面遷移と処理が進んでいきます。

無論、永続化サービスも登録しておきましょう (HTTP で毎回処理が途切れるため、セッションなどを使わなければ、基本はステートレスです)。
また余談ですが、ランタイム作成で、必要な設定は、web.config などに外だしすることもできます。この web.config のコードは、ワークフローをWebサービスとして発行すると作成されますので、是非参考にしてみてください。(WebServiceInput アクティビティや WebServiceOutput アクティビティを持つワークフローを作成して、[Publish as Web Service] を選択すると作成できます。) ちなみに、この場合でも、ワークフロー作成時は、いつも通り new WorkflowRuntime ですが、コンストラクタの引数に構成の名前を指定します。(このコードは、System.Workflow.Activities.WorkflowWebService クラスの CurrentWorkflowRumtime プロパティなどを逆コンパイルすると同様のことをおこなっているのがわかります。)
そして、この web.config の仕組みを使って、永続化サービスの追加など、必要なサービスの追加も指定することができます。