State Machine の EventDriven での EventDeliveryFailedException

State Machine ワークフローでは、EventDriven アクティビティをよく使用します。
これは、外部からのイベントを元に何か-多くの場合、最終的にSetStateに至る何か-をするためのトリガです。
で、呼び出し元からは、そのイベントをRaiseしてあげることにより、何かを発生させるわけです。
で、これを使っていると、よく発生するのが、
EventDeliveryFailedException” です。
System.Workflow.Activities に存在するこの例外は、「このイベントは配信できませんでしたよ。」と言っているのです。
…そんなこたぁ字面みりゃわかります。
で、英語のMSDNのリファレンスを読んでもロクな事はわかりません。
で、なぜ、この例外が発生するのか。
良くありがちな原因を二つ挙げます。
1)実装側の単純ミス
2)タイミングの問題(←妙に根深い)
これらの共通点は、
イベントを配信しようとしたが、現在のStateでの”EventDriven”アクティビティ内の”Handle External Event”アクティビティで定義されていない為、誰にも配信されなかった。
ということです。
もっと簡単に言えば、「当該受取人はこの住所には存在しません」と書かれて年賀状が返ってきてしまったと思ってください。
したがって、上記1)の場合、現在のStateと呼ぶべきイベントのミスマッチが発生していると言うことになります。つまり、単純に呼ぶべきイベントを間違ったと言うことです。
これは話が簡単で、サクッと直せばよいだけの話です。
上記2)の場合には、呼び出し元はとっくにそのStateに来ていると思っていたのに、実はまだ到着していないということです。これが発生した場合、ちょっとややこしいことになります。
Workflow Foundation は、Eventを発行した後、そこから繋がるアクティビティの終了を待つことなく、呼び出し元に制御を返却します。そのため、”HandleExternalEvent”から”SetState”までがヤタラと時間のかかる処理である場合(或いは、全体の処理負荷が非常に高い場合等)において、この状況が生じる可能性があります。
だったらどうしたらよいのか…
解ったらまた書きます(←弱っ!!)

CreateWorkflow メソッドでエラーになったら

Workflow Foundation 上で Workflow を扱う際に、必ずWorkflowRuntime.CreateWorkflow を呼ばなければいけません。
ま、メソッドの説明はコチラ:MSDN:WorkflowRuntime.CreateWorkflow Method [英語]
で、「このRuntimeが何か、Instanceが何か」を始めると「Workflow Foundation 概論」を始める羽目になるので、飛ばします。
ようやく本題。
非Vista環境に.NET Framework 3.0 を入れて、WFを動かそうとすると、この”CreateWorkflow”メソッドでエラーになることがあります。ありがちなのは引数のTypeを間違えたとか、そういう話なのです。
しかしながら、こんなとんでもないエラーが出現することがあります。

‘System.InvalidOperationException’ のハンドルされていない例外が System.dll で発生しました。
追加情報: 要求されたパフォーマンス カウンタはカスタム カウンタではありません。ReadOnly として初期化する必要があります。

CreateWorkflow でのエラー
は、はぁ!?パフォーマンスカウンタがどうしたこうしたと言われましてもねぇ…
で、探っていくと、USのMSDN Forumにやり取りがありました。
コチラ: MSDN Forums » Software Development for Windows Vista » Windows Workflow Foundation » CreateWorkflow Exception
で、回答を意訳すると、
「パフォーマンスカウンタに『Windows Workflow Foundation』があるか確認しろ。ないなら、管理者権限で .NET 3.0 の再インストールよ。」
と言うことのようです。
で、その現象が出たマシン(2003)のパフォーマンスモニタを見ると、しっかりと…
2003上のパフォーマンスカウンタ
で、Vista上では…
Vista上のパフォーマンスカウンタ
特にWF関連をやられる方、非Vista環境への.NET 3.0 インストール後には、パフォーマンスカウンタの確認をされたほうが吉な様子です。
※何とかなりませんか、MSさん…
——————- 07/01/08 追記 ——————-
別のXP-ProにAdministratorで.NET 3.0 を入れたら、きちんとパフォーマンスモニタに”Windows Workflow Foundation”が追加されていました。で、WFがきちんと動きました。

第九回codeseek勉強会資料公開 – WF

出席者の皆様にはお待たせいたしました。
去る10月に行われました、codeseek勉強会-WF概論 に関する資料を公開いたしました。
過去の資料も含め、コチラからどうぞ。
なお、含まれるものは、
・プレゼンで使用したppt
・デモで使用した一式(State Machine / Sequential 一緒入り)
・時間切れで使用できなかった一式(State Machine – XOML版)
です。
例によって二次使用はご自由にされて構いませんが、モノがモノだけに自己責任でお願いします。

Workflow Foundation #4 – 実際に動かす環境を作るには

概論を並べてみたところで、結局のところ、手を動かすのが一番早いわけです。
その環境のレシピは、こんな感じです。
・XP , 2003 , Vista の動作環境
・Visual Studio 2005 (Express Edition でも良いらしいですが、未確認)
この環境の上に、WFの環境を構築します。
必要なものは以下の通りです。
.NET Framework 3.0 RC1 (Vistaの場合には不要)
Microsoft Visual Studio 2005 Extensions for Windows Workflow Foundation RC5
最低限、上記のものが必要になります。
これらの環境を、仮想マシン上に構築することをオススメします。
で、めでたくインストールに成功した後、Visual Studio を起動し、「新しいプロジェクトの作成」を選択すると、以下のようなメニューが表示されます。
VS上に表示されるメニュー
これだけでもアレですので、以下のリソースにあるサンプルをダウンロードしてきて開いてみるとよいでしょう。
Microsoft Windows Workflow Foundation 入門:開発者向けの手引き
NetFX3 .NET Framework 3.0 Communtiyから、WFSamples

Workflow Foundation #3 – 2類型の相違と共通点 – アクティビティ

#2で、ワークフローの2類型を説明しました。
本当は、ワークフローには
・もっと沢山の類型がある
・単一の「シーケンシャルフロー」の拡張でしかない
と、学術的なモロモロはあるのですが、そんなこととは関係なく、あえて2類型です。
なぜか?単に、Windows Workflow Foundation (以下、”WF”)がサポートするのが、この2つだからです。
そして、この2つで、使い方が大きく変わってくるからです。
ただ、ココから先は同じ話です。
#2のフロー図・状態遷移図の、一つ一つの箱の中、あるいは箱自体。これらは、基本的に同じものです。
これを WF 的には「アクティビティ (Activity)」と称します。
いろいろなアクティビティを並べて、組み合わせて、一つのフローを作り上げることになります。
もちろん、ステートマシーンで使用できるがシーケンシャルでは使用できないアクティビティ、或いはその逆というのも存在します。
また、これはWFの特徴の一つと言ってもよいと思いますが、このアクティビティは開発者が独自に作成することも出来ます。
WFは、基本的には「アクティビティの組み合わせ」と理解しても良いと思います。

Workflow Foundation #2 – ワークフローの2類型

ワークフローは、基本的に「決められた流れに沿って何かを流す」と#1で定義してみました。
で、その流れを表現するのは何か?どうやって表現するのか?
最も基本的なのは、いわゆる「流れ図」ですね。プログラムの「やること」をまとめたりするのに良く使ったアレです。
流れ図
しかし、これでは若干やりにくい時もあります。例えば業務フローを「流れ図」で表現するのはややムリがあります。例えば「ここから来たデータはどう流れて、どのように遷移し…」という場合です。ま、プログラム的ではなく、業務的なフローとでも言いましょうか。そういうのを表現するのは、「データフローダイヤグラム(DFD)」です。DFD
まぁ、フロー表記法としては、まだまだイロイロとあるわけですが、Workflow Foundation 的なワークフローの2類型としては、先ずはこの二つを理解しておけば良いでしょう。
で、何故そういう話になるのかと言うと、Workflow Foundation では、「シーケンシャルワークフロー」と「ステートマシン」という、二つのタイプが存在し、それぞれに作り方が微妙に違うのです。作り方の違いはさておき、それぞれの考え方の違いが、先程の「流れ図」と「DFD」になります。
つまり、この二つの違いを理解しておかないと、かなり悲惨な目に遭えるというわけです。

Workflow Foundation と BizTalk の違い

そんな質問をいろんなところで受けます。
「WFでBizTalkは無くなるのか?」「違いはなんだ?」と。
で、ざっくりとまとめてみました。
・WFのやりたいこと=基本的な考え方
 アプリケーションの内部で動作する(”Foundation”ですから)。
 ヒューマン・ワークフロー、システム・ワークフローを実現する。
 フローの動的な変更を許可する(実装する必要はある)。
 トランザクション、永続化は実装する必要がある。
・BizTalkのやりたいこと=基本的な考え方
 BizTalk Server のランタイム内で動作する(製品ですから)。
 外部システム連携(EAIとか…)を実現する。
 外部システム連携用のアダプタが豊富に用意されている。
 追跡・記録機能は標準で備える(WFでは実装する必要がある)。
#強引にまとめると
WFとは…
 「部品」であり、これを元に「何か」をするためのもの。
BizTalkとは…
 「製品」であり、これだけでも「何か」ができるもの。
 従って、これら二つは全く別のものであります。
 理論上は、WFを使ってBizTalkを置き換えることも出来るでしょう。しかし、それは「エンジンがあるから車が作れる」というのと同義であると考えられます。
詳しい解説はコチラをお勧めします(英語)
Brian Loesgen’s Blog – BizTalk Server 2004/2006 and Windows Workflow Foundation

Workflow Foundation #1 – Workflow ってそもそも何?

個人的に .NET 3.0 で最も気になる機能である、Workflow Foundation について述べてみます。
先ず、そもそも論として、Workflow って何でしょう?
直訳すると「仕事の流れ」ですが、「(ビジネス)プロセスの流れ」と考えるとわかりやすいと思います。
例えば、昔も今も、事毎に「ステータス管理」というのがあります。
「月次受付中」→「月次締切」→「支払確定済」…という具合にステータスが進み、それごとに画面の一部、あるいは全部が変化すると言う奴です。
或いは、携帯電話でも、「待ち受け状態」→「架電」→「発呼」…と、ステータスが進むわけです。
厳密な定義はともかく、このような流れを「ワークフロー」と呼ぶと考えればわかりやすいと思います。
ココで重要なのは、「決まった流れに沿って何かを流す」事であって、流れるモノが何かという点ではなく、とにかく、コンベアに乗せて流す。誤解を恐れず言えば、これが「ワークフロー」です。
で、従来はこれらをゴリゴリと実装して実現していたわけですが、それをミドルウェアに任せてしまおうというのが、最近の潮流であるようです。
そんな星の数ほどあるワークフロー製品ですが(Googleで「ワークフロー製品」で検索すると935件でした)、そんな中に .NET Framework 3.0 標準装備品として Workflow Foundation が出てきてしまいました。
と、言うように、ワークフローを定義したところで、次回以降、Workflow Foundation を掘り下げていくつもりです。
※予告編かよ!これは!!