ワークフローするかしないか？

私は、軽量保険金請求システムの開発を開始しようとしている開発者チームの責任者です。システムには多くの手動タスクとビジネスワークフローが含まれており、Windowsワークフロー（.NET 4.0）の使用を検討しています。

ビジネスドメインの例は次のとおりです。保険契約者は、コンタクトセンターに電話して、申し立てを提出します。この「イベント」は、手動で並行して実行される2つのサブタスクを起動し、完了するまでに長い時間がかかる場合があります。

1. 顧客の不正をチェック–オペレーターが手動でさまざまなクレジット会社に電話をかけ、不正な顧客の可能性をチェックして評価します。ここから、サブタスクはいくつかのサブステータス（進行中のチェック、参照チェックの失敗、参照チェックの合格など）を入力できます。
2. 修理センターへのアイテムの送信–保険契約者が申し立てを提出したアイテムが修理センターに送られ、修理される手動プロセス。ここから、サブタスクはいくつかのサブステータス（修復待ち、進行中、修復済み、投稿済みなど）を入力できます。クレームは、各サブタスクのステータスが事前定義されたステータス（ビジネスルールに基づく）に達した場合にのみ続行できます。

表面的には、ワークフローは確かに最良のテクノロジーの選択のようです。しかし、私はWF 4.0の使用に関していくつかの懸念を持っています。

1. スキルセット–平均的な開発者スキルセットを見ると、ワークフローを理解または知っている開発者はあまり見かけません。
2. 保守性– WF 4.0プロジェクトに対するコミュニティ内のサポートはほとんどないようで、スキルセットの欠如と相まって、保守性に関する懸念が生じています。
3. 参入障壁–私は、Windowsワークフローの学習曲線が急であり、必ずしも簡単に習得できるとは限らないと感じています。
4. 新製品–ワークフローが.NET 4.0用に完全に書き直されたので、私はこの製品を第1世代の製品と見なしており、必要な安定性がない可能性があります。
5. 評判–以前のバージョンのワークフローは十分に評価されておらず、開発が困難であると考えられ、ビジネスへの関心が低かった。

私の質問は、この状況ではWindowsワークフロー（WF）4.0を使用する必要があるか、それとも代替テクノロジー（Simple State Machineなど）を使用するか、それともより優れたワークフローエンジンを使用するかということです。

いくつかのWF4プロジェクトを実行したので、他の回答に役立つ情報を追加できるかどうかを確認してみましょう。

あなたのビジネス問題の説明から、WF4は良い一致であるように聞こえるので、問題はありません。

あなたの懸念に関してはあなたは正しいです。基本的にWF4は新製品であり、いくつかの重要な機能が欠けており、いくつかの荒削りな部分があります。学習曲線があり、いくつかのことを異なる方法で行う必要があります。主なポイントは、実行時間とシリアル化です。これは、平均的な開発者が慣れていないことであり、エンティティフレームワークのデータコンテキストのシリアル化に問題があるとよく耳にするので、正しく理解する必要があります。

ほとんどの場合、IIS / WASでホストされているワークフローサービスを使用することは、これらの長時間実行されるワークフローを実行する場合に最適なルートです。これにより、バージョン管理の問題を解決するのも難しくありません。最初のメッセージでワークフローバージョンを返し、それを後続の各メッセージの一部にします。次に、バージョンに基づいて正しいエンドポイントにメッセージをルーティングするWCFルーターを間に置きます。基本は、既存のワークフローを変更することではなく、常に新しいワークフローを作成することです。

だからあなたへの私のアドバイスは何ですか？未知の、そして証明されていないテクノロジーについて、大きな賭けをしないでください。WF4を使用して、アプリケーションの小さな、重要ではない部分を実行します。そうすれば、それが機能すれば拡張できますが、失敗すると、それを取り除いて、より伝統的な.NETコードに置き換えることができます。そうすれば、中古情報に基づいて決定する必要がなく、WF4の実際の経験を得ることができ、その過程で新しく強力なテクノロジーを学ぶことができます。できれば、WF4のコースを受講してください。スピードに慣れるために多くの時間を節約できます（ここで恥知らずなセルフプラグイン）。

Simple State Machineについて。私はそれを使用していませんが、短期間の、メモリ内の、ステートマシン用であるという印象を受けました。WF4の主な利点の1つは、長期実行の側面です。

私はこのジレンマに数回遭遇し、Work Flow Foundationを使用しないことを選択しました。考慮事項のいくつか（あなたと同様）は

1. 関与するワークフローははるかに単純であり（ステートマシンと順次アクションの組み合わせ）、WFでそれを実行することは、関与する労力に対して過剰に見えるようです。
2. 開発者がWFを理解して効果的に使用するための学習曲線は高いと見なされました。有効な遷移と実行されるアクションを説明するステータス遷移表は、柔軟性を高めるために使用され、開発者はそれに慣れ、概念と目的を簡単に理解しました。
3. ビジネスプロセスの変更の可能性はわずかであり、初歩的な変更は移行表の助けを借りて簡単に可能でした。移行の変更はデータベーススクリプトを意味し、アクションの変更は新しいリリース/パッチをもたらします。しかしながら、そのような発生の確率は低いと考えられた。

13〜14か月後を振り返ると、WFを使用しないという決定は正しかったと私はまだ思います。IMO、WFは、ワークフローが変更されたり、ビジネスルールが変更されたりする可能性が高い場合に有効です。WFでは、ワークフローを個別のファイルに分離できるため、ユーザーがワークフローを構成できるようにするのが簡単になります。

過去数か月間、WF 4.0を使用しています。ワークフローの方法を考えるのは難しいと言わざるを得ません。しかし、私はそれが価値があるとあなたに言うことができます。始めたときはほとんど知りませんでした。私たちは、WF 4.0の初心者向けおよび専門書を購入しました。私自身、オンラインで多くのビデオを視聴し、PDC 2009をフォローして、WF 4.0に関する速報と、以前のやや厄介なバージョンとの違いについて説明しました。私たちが解決策を提案しなければならなかった1つの主要なことは、カスタムアクティビティを特定のデータ型に制限せずにワークフロー内の引数を処理する方法と、アクティビティ間でパラメーターを渡す方法です。私はそのための良い解決策を考え出しました、そして今までのところ私たちが持っているワークフローの経験は全く悪くありません。実は ますます大きくなるワークフロー集約型のアプリケーションがあり、実際に別の環境で解決することは想像できません。私はそれが持っている視覚効果が大好きです：if / elseなどの構造の詳細から遠ざけられ、何が起こっているのかを知るためにコード行に飛び込むことを強制されない方法でビジネスルールを明らかにしますいくつかのバグを修正する方法。ちなみに、私たちが取り組んだプロジェクトは、あなたが説明したものと非常によく似ており、中規模のプロジェクトです。私の言葉から、私はそれが好きで、私はそれをお勧めしますが、それは新しいテクノロジーであり、いくつかの革新的なアイデアを考え出す必要があるため、いくつかのリスクが組み込まれています。if / elseなどの構成要素の詳細から離れて、何が起こっているのか、またはいくつかのバグを修正する方法を知るためにコード行に飛び込むことを強制されない方法で、ビジネスルールを明らかにします。ちなみに、私たちが取り組んだプロジェクトは、あなたが説明したものと非常によく似ており、中規模のプロジェクトです。私の言葉から、私はそれが好きで、私はそれをお勧めしますが、それは新しいテクノロジーであり、いくつかの革新的なアイデアを考え出す必要があるため、いくつかのリスクが組み込まれています。if / elseなどの構造の詳細から離れて、何が起こっているのか、またはいくつかのバグを修正する方法を知るためにコード行に飛び込むことを強制されない方法でビジネスルールを明らかにします。ちなみに、私たちが取り組んだプロジェクトは、あなたが説明したものと非常によく似ており、中規模のプロジェクトです。私の言葉から、私はそれが好きで、私はそれをお勧めしますが、それは新しいテクノロジーであり、いくつかの革新的なアイデアを考え出す必要があるため、いくつかのリスクを組み込んでいます。

私の2セント...

私はWF 3.5で3つのプロジェクトを行いましたが、それは簡単なことではありません。特に永続化が使用されている場合、まったく新しい方法で考えることを強いられます。何百もの不完全な永続化ワークフローを含むアプリケーションを更新することは困難です。シリアライゼーションの1つの重大な変更により、すべてがクラッシュします。実行中の新旧のワークフローをサポートするために、同じライブラリの複数のバージョンを導入することは一般的です。挑戦的でした。

私はまだWF 4.0を試していませんが、BizTalkとWF 3.5の経験に基づいて、同様になると思います。

とにかく、あなたが取ることができる最善のアプローチは、概念実証を行うことです。要件から単一のWFを取得し、それをWF 4.0に実装してみてください。ある程度の時間を費やしますが、WF 4.0でそれが可能かどうか、目に見える利点があるかどうかを証明します。

WF 4.0を使用する場合は、Windows AppFabricでホストされているWCFサービスとしてWFを実行できるかどうかを確認するように要求します。AppFabricは、WFをホストするためのすぐに使える機能をいくつか提供します。

この種の問題に対するテクノロジーの選択としてWF4のワークフローについて話すことは、今日ではあまり意味がないと思います。上記のLadislav Mrnkaが述べたように本当に適切なのは、AppFabricでホストされているWCF WFサービスです。

これに関する私の経験は、それが大きな利益をもたらし、非常に楽しいということですが、多くのプログラマにとってこれは技術のシフト以上の方法論のシフトであることを正しく認識されていないため、最初に問題が発生します。一方、ジェネラリストや問題解決の考え方を持つ人々は、WCF WF AppFabricを一連の刺激的な機会と見なしていました。したがって、プロジェクトの人々の組み合わせが、日常的なOOおよびパターンのセットに接続されたかなり保守的なC＃開発者である場合、紹介するのは困難です。チームがより革新的である場合、潜在的な新しい出入り口が発見ごとに増加するため、採用ははるかに容易になります。

プログラマーがこのテクノロジーに移行する際の2つの主要な概念的な問題は、a）メッセージの相関とメッセージ交換パターンb）ワークフローと単体テストたとえばC＃の標準システムでは、ワークフローがめったに明示的ではないため、めったに単体テストされません。全体的なワークフローは、受け入れシナリオまたは統合によるテストに委ねられます。明示的なWFをソフトウェアアーティファクトとして導入すると、標準の開発者が突然それを試してユニットテストを行いたくなりますが、通常は行う価値はありません。

そのメッセージ相関の側面は、メッセージ交換パターンに慣れていない人にとっては、ちょっとした考え方の転換です。ほとんどの開発者はインプロセスコールとリモートコール、Webサービス、SOAPを扱っており、通常はそのうちの1つまたは2つに焦点を当てています。上記のすべてを抽象化し、一般的なメッセージベースのシステムで作業することは、最初は混乱する可能性があります。

しかし、良い面としては、最終結果は多くの時間を節約し、多くの機会を生み出すものです。主なことの1つは、視覚的に明確である場合、worfklowはエンドユーザー、開発者、およびアナリストが一緒に取り組むことができるものであり、開発ライフサイクルの不要なステップを排除し、1つのアーティファクトに関係者を集中させます。さらに、ビジネスドメインごとにWFで一連のビジネスプロセスを促進することにより、専用の接着層を備えた専用アプリの機能の孤立を防ぎます。さらに、AppFabricを使用すると、永続化、ロギング、およびスケジュールされたアクティビティのウェイクアップのすべてが自動的に行われます。WF4のパフォーマンスも抜群です。

私の推奨は、最も革新的または探索的なチームメンバーが最初の偵察を行ってトリッキーな部分を発見し、コア機能を動作させ、残りの作業を最初の担当者が担当することです。

役割と「サブタスク」を伴う複雑な保険金請求システムを実行するには、ワークフローだけでなく、BPMソリューションが本当に必要です。Workflow Foundation 4.0は洗練されていますが、BPM製品の機能に実際には近づきません。

Metastorm BPM、Global360、K2.NETなどのBPMソリューションは、保険請求システムなどのビジネスプロセスをモデル化および合理化できる人間中心のワークフロー、タスク、役割、およびシステム統合を提供します。ASP.NETを使用して、BPMワークフローエンジンと統合するインターフェイスを構築します。組み込みデザイナーは通常制限されており、ASP.NET Webコントロールほどフル機能ではないカスタム構築Webコントロールを使用するように強制します。

あなたのチームが知っていて、快適に感じているテクノロジーを使ってください。Workflow Foundationは、すぐに使用できる製品ではありません。ワークフローシステムを構築するためにアプリケーションに組み込むことができる一連のピースです。ワークフローロジックは私にとって最も重要なテクノロジではありません。ビジネスオーナーにはGUIしか表示されないため、まずGUIに集中する必要があります。しかし、システムが成功した場合、終わりのない変更要求と新しい要件に備える必要があるため、ビジネスロジックを実装して、簡単に変更し、異なるユーザーのニーズに合わせて（場合によっては矛盾する）個別のプロセスに分割する必要があります。 。BPMを使用すると、さまざまなビジネスニーズに合った複数のバージョンのビジネスプロセスを個別に作成できるため、このタスクに役立ちます。あなたは そのために本格的なBPMエンジンが必要ですが、ビジネスロジックをコード化して、バージョン化して個々のビジネスプロセスに分割できるようにすると便利です。理解できる。ステートマシン、DSL（ドメイン固有の言語）、スクリプトなど、そのための多くのアイデアがあります。実装を決定します。ただし、常にビジネスプロセスの観点から考え、それに応じてロジックを編成し、これらのプロセスを反映する必要があります。そして、ビジネスロジックとデータ構造の多くのバリアントの共存に備えてください。これは、最も難しい設計作業です。ビジネスロジックをコード化して、バージョン管理して個々のビジネスプロセスに分割できるようにするのに便利です。最悪の事態は、「すべてのもの」を処理し、誰も理解できない、管理不能で複雑なコードの塊です。ステートマシン、DSL（ドメイン固有の言語）、スクリプトなど、そのための多くのアイデアがあります。実装を決定します。ただし、常にビジネスプロセスの観点から考え、それに応じてロジックを編成し、これらのプロセスを反映する必要があります。そして、ビジネスロジックとデータ構造の多くのバリアントの共存に備えてください。これは、最も難しい設計作業です。ビジネスロジックをコード化して、バージョン管理して個々のビジネスプロセスに分割できるようにするのに便利です。最悪の事態は、「すべてのもの」を処理し、誰も理解できない、管理不能で複雑なコードの塊です。ステートマシン、DSL（ドメイン固有の言語）、スクリプトなど、そのための多くのアイデアがあります。実装を決定します。ただし、常にビジネスプロセスの観点から考え、それに応じてロジックを編成し、これらのプロセスを反映する必要があります。そして、ビジネスロジックとデータ構造の多くのバリアントの共存に備えてください。これは、最も難しい設計作業です。DSL（ドメイン固有言語）、スクリプトなど-実装を決定します。ただし、常にビジネスプロセスの観点から考え、それに応じてロジックを編成し、これらのプロセスを反映する必要があります。そして、ビジネスロジックとデータ構造の多くのバリアントの共存に備えてください。これは、最も難しい設計作業です。DSL（ドメイン固有の言語）、スクリプトなど-実装を決定します。ただし、常にビジネスプロセスの観点から考え、それに応じてロジックを編成し、これらのプロセスを反映する必要があります。そして、ビジネスロジックとデータ構造の多くのバリアントの共存に備えてください。これは、最も難しい設計作業です。

.NET 4.5はまだ製品環境での使用が認められていないため、4.0を使用する必要がある状況にあります。長時間実行するワークフローをビジネスニーズに合わせる方法を大まかに理解していましたが、最終的にはエレガントなソリューションを見つけました。これは、後でサポートする人だけが簡単に理解できるものではありません。考えなければならないことがたくさんあるので、ワークフローの状態を管理するツールとしてWFを信じています。

私がWF 4.0で問題とする大きなことの1つは、モーリスのコメントです。

基本は、既存のワークフローを変更することではなく、常に新しいワークフローを作成することです

新しいバージョンが必要なだけならそれはすばらしいことですが、50,000のワークフローを永続化していて、ワークフローにバグがあることに気付いた場合はどうでしょうか。xamlxを更新しながら、既存のインスタンスに結合できる必要があります。SQL Serverのインスタンステーブルにあるさまざまなメタデータ列を解凍して、インスタンスをワークフロー定義に結びつけるものが見つからないようにしてみました。

古いシステムから新しいWF 4.0駆動のシステムにデータをインポートするための同期アプリケーションを作成しました。基本的にデータをシステムにロードしてから、ワークフローステップを自動的に呼び出し、検証メソッドを呼び出すプロセスを実行します。ワークフローサービスホストにアクセスするために実装したアーキテクチャにより、これは本当にうまくいくだけでした。実行後、データ移行プロセスの一貫性を確認するために確認およびチェックを行うことができますが、システムが稼働すると、このアプローチを数十万のケースに使用しなければならないというのは、実際にはアプローチではありません。これは自信を植え付け、統合のプロセスに単純なバグ修正の負担をかけます。

私の推奨は、WF 4.0を完全に回避し、環境でサポートされている場合はそのまま4.5に直接進むことです。動的更新とサイドバイサイドバージョン管理は、バグ修正とWFバージョン管理にすべて対応します。まだ4.5がクライアントによる使用について認定されていないので、正確に調査する必要がありますが、この機会を心待ちにしています。

私が切望しているのは、クライアントがポリシーの変更（したがってワークフローの調整）を要求しないことと、現在のワークフローがバグなしで維持できることです。バグは常に発生するため、後者は無駄で空の希望です。

私は、WF開発チームの責任者がシステムをリリースして、箱から出しただけではバグを簡単に修正できない状況を本当に理解できません。彼らは、インスタンスを新しいxamlxに再バインドするための手法を開発していたはずです。