Windows Workflow 101

米国 MSDN – VisualBasic Developer CenterCommunity から Community Content (ってか、階層深すぎ…)に、Window Workflow 101 という記事が公開されています。
シリーズの第一回ということだそうですが、取っ掛かりとしては非常に判り易い内容で、今後が楽しみな所です。
問題は、コレが英語で、かつ、Community Contents ということ。
確かに、スクリーンショットとソースコード、キーワードだけ追っていっても、概要はわかります。ですが、コレが日本語化される日は来るのでしょうか?
このあたりは、当局にオウカガイをたててみるべきなんでしょうね。
#翻訳するにしても片手間でやるにはキッツイ分量だなぁ…

InvokeWorkflow で呼び出された Workflow の InstanceID

InvokeWorkflow を使って別のワークフローを呼び出すと、呼び出された先のフローではInstanceIDが別のものになってしまいます。
したがって、同じInstanceIDで呼び出しても、EventDeliveryFailedException が帰ってきてしまいます。
呼び出すためには必ずInstanceIDが必要なので、どこかで取得しなければいけません。
単純なフローでしたら、WorkflowInstance.InstanceID を取得すればよい話ですが、呼び出された先のフローのInstanceIDはココには居ません。
ではどうするのか?
昨日の”WorkflowStarted”イベントで捕まえた先で、”WorkflowEventArgs”を見れば、中に入っています。WorkflowEventArgs.WorkflowInstance.InstanceId で、呼び出された先のフローのInstanceIDが取得できますので、これを使用して、呼び出された先のフローにイベントを投げてあげれば良いわけです。

InvokeWorkflow の結果を得るには

InvokeWorkflow Activity の結果が必要なことがあります。
・ちゃんと終わったの??
・次のイベント投げてもいい??
特に後者は、いつもの”EventDeliveryFailedException”が起きる可能性があるので、きちんと確かめておきたいところではあります。
そこで見つかったのが、
Microsoft サポートオンライン – InvokeWorkflow を実装する方法が Windows ワークフロー基礎 のイベントを完了しました。
タイトルからして「これはヒドイ機械翻訳ですね」丸出しです。
あまりにヒドイので、英語をあたってみました。
How to implement an InvokeWorkflow completed event in Windows Workflow Foundation

「Windows Workflow Foundation で InvokeWorkflow の完了イベントを実装するには」ということのようです。
(ちなみに文書番号は 926499 です。)
サンプルがC#だとかいう個人的なアレはさておき、要するに「WorkflowRuntimeから”WorkflowCompleted”イベントが投げられるから、それを受け止めてね。」ってコトのようです。
で、上記KBのは「完了」の例ですが、呼んだ先のルールがちゃんと開始されたのか?は、こんな感じになります。

‘—開始イベントを引っ掛けるハンドラを用意する
AddHandler objWFRuntime.WorkflowStarted, AddressOf [具体的にやらせたいメソッド]

で、その[具体的にやらせたいメソッド]の中では、こんな感じになります。

Sub SomeMethod(ByVal sender As Object, ByVal e As WorkflowEventArgs)
  Dim strWFName As String = e.WorkflowInstance.GetWorkflowDefinition.Name
  If strWFName = [目的のワークフロー名] Then
   ’—Do Something
  End If
End Sub

ここでは「ワークフロー名」を使いましたが、もちろん、他の手もあるはずです。
ご参考まで。

XAML Schema とその小さな罠

Workflow 定義は XAML で出来るわけですが、その定義はコチラからダウンロードできます。
イマドキ珍しい、自己解凍EXEとなっています。
そのため、Vista上で実行して、さらにデフォルト状態で展開させようとすると(”Program Files”内の ¥Visual Studio 8¥XML¥Schema に出力しようとします)、Vista の UAC のおかげで、警告無く終了して、何も出力されていないという罠に嵌れます(少なくとも、エクスプローラー上には表示されません)。

WFの使い方についての記事

WFの使い方記事で、良い記事を見つけたのでオシラセまで。
・MSDN blog:松崎さんの「WF (ワークフロー) を使った Web ページ (ASP.NET) の画面遷移
・上記で紹介されている「Windows Developer Center:ワークフローの作成とランタイムサービス (EDS, 永続化サービス) の利用」の スクリーンキャスト
このスクリーンキャスト、内容の濃さもさることながら、その長さです。WFアプリを作って動かすまでの「道の長さ」もよく判る内容となっております。
飲み物とスナックを用意して、若干くつろいだ感じでご覧になることをオススメします。

VS2005 Extensions for .NET 3.0 (WF) は Express Edition にはインストールできない

Visual Studio 205 Extensions for .NET Framework 3.0 (Windows Workflow Foundation) はWFを使用するのには必須です。
しかしながら、Visual Studio 2005 Express Edition にはインストールできません。インストールできたとしてもサポート外です。
と、ダウンロードページの下のほう、「必要システム」の項に、英語でひっそりと書いてあります。
…和訳してくださいよぉ。

WF ハンズオンラボ資料(和訳)

[ネタ元]:KKONDO’s Blogより
「Windows Workflow Foundation ハンズオン ラボの日本語ドキュメントを公開しました」
WF関連の最善の資料の一つ、ハンズオンラボのドキュメントがようやく和訳されたそうです。
ダウンロードはコチラから。(6.4MBあります。ご注意を。)
…kkondo先生及び関係各方面には申し訳ないのですが、敢えて一言。
「遅いよ…」
しかし、和訳していただけるだけでもありがたいです。イロイロなところで使わせていただきます。
‘——-と、書いている間にダウンロード完了——-
そして、読んでみた感想。
・さすがに日本語だから理解しやすい
・でもC#なんだよなぁ…(VB使いとしては…)
・11ファイルあるのがなんとも「盛られた」感。
演習-1だけでも44ページあるので、通勤電車の中で読むのは若干のチャレンジという感があります。

State Machine は同時に2つ以上の"State"になれない

State Machine において、一つのインスタンス上で同時に二つ以上の状態(State)にはなれないようです。
ちょっと実験をしてみました。
まずは、下のようなState Machineを作ってみます。
分岐したState
で、これが分岐しているところは…
if-else Activity ではなく、parallel Activity である点に注意してください。
分岐させるところ-if-elseではない点に注意
これが期待するところは、同時にAとB、二つの状態を共存させたいということです。
さて、Host側コードはこんな感じです。
実験コードなので、ひたすらシンプルです。
分岐したStateを呼んでいるHost側コード
さて、実行結果は…
その結果
…さようなら。
StateAのイベントを呼ぼうとした所であえなく砕け散りました。
「またお前かよ」と言いたくなる”EventDeliveryFailedException”です。
Host側から呼ぶ順番をかえても、ダメでした。
そもそも”State Machineとは?”という原点に立ち戻って考えてみると非常に当たり前な結果ではあるのですが…期待が大きすぎた模様です。

State Machine の EventDriven での EventDeliveryFailedException – 続編

第一回はコチラ:http://blog.tk-engineering.com/?eid=586994
で、もうひとつ、この EventDeliveryFailedException の発生要因について追記しておきます。
標準のHandleExternalEvent Activityで手を抜いて、複数のActivityで複数のEventを使いまわそうとしたとします。
そうすると、どこに配信していいのかわからないらしく、思いっきりThrowされてしまいました。
と、いうことは、EventDriven , HandleExternalEvent の数だけアホのようにイベントを実装しなければいけない?
ちょっとぞっとする結論ですね。
※しっかし、WFに関する日本語リソースの少ないこと…

ワークフローをDBに保存するには – 準備編:テーブルの用意

Workflow Foundation では、その内容はDBに保存されません。
単にメモリ上に展開されているだけです。
従って、ウッカリすると、何の記録も途中経過も残りません。
それでは困る場合には、そのワークフローインスタンスの内容をDBに保存させることが出来ます。
SqlWorkflowPersistenceService を使用して、ステートマシンのワークフローインスタンスを保存することが出来ます。
そのほかにも、SqlTrackingService もありますが、それらの詳しい内容には未だ触れません。
マエフリがヤタラと長くなりましたが、今回はその下準備についてのオハナシです。
前提として、SQL Server 2005の準備は済んでいるものとします。
SqlWorkflowPersistenceService や 、SqlTrackingService を使用するには、当然ソレナリなデータベース・テーブルが必要なわけですが、ソレが何処にあるのか?
実は、非常に奥深いところに潜んでいます。
システムフォルダの中に ¥Microsoft.NET¥Framework¥v3.0¥Windows Workflow Foundation¥SQL というフォルダが居ます。
この中に(日本語環境でしたら)”JA”と”EN”という二つのフォルダがあります。これらはどちらでも構わないようです。
で、”*_Logic.sql”がストアドプロシージャー定義、”_Schema.sql”がスキーマ定義。Persistence , Tracking 用、それぞれが用意されているので、SQL Server Management Studio なり、osql コマンドなりで流し込んであげればよいと言うことになります。
で、コード側でPersistance, Tracking のインスタンスを作成する際に、引数で接続情報を渡してあげる形になるわけですが、そこはまた別の話で。