ワークフローにするかしないか
私は、軽量保険金請求システムの開発を開始しようとしている開発者のチームを担当しています。このシステムには多くの手動タスクとビジネスワークフローが含まれており、Windowsワークフロー（.NET 4.0）の使用を検討しています。
ビジネスドメインの例は次のとおりです。保険契約者は、コンタクトセンターに電話をかけて申し立てを行います。この「イベント」は、手動で並行して実行される2つのサブタスクを起動し、完了するまでに長い時間がかかる場合があります。
- 顧客の不正行為の確認-オペレーターがさまざまなクレジット会社に電話して、不正な顧客の可能性を確認および評価する手動プロセス。ここから、サブタスクはいくつかのサブステータスを入力できます（進行中のチェック、参照チェックの失敗、参照チェックの合格など）
- アイテムを修理センターに送信-保険契約者が請求を提出したアイテムが修理センターに送信され、修正される手動プロセス。ここから、サブタスクはいくつかのサブステータス（修復待ち、進行中、修復済み、投稿済みなど）を入力できます。クレームは、各サブタスクのステータスが事前定義されたステータス（ビジネスルールに基づいて）に達した後にのみ続行できます。
表面的には、ワークフローが実際に最良の技術選択であるように思われます。ただし、WF 4.0。
- スキルセット–平均的な開発者のスキルセットを見ると、ワークフローを理解または知っている開発者はあまりいません。
- 保守性–コミュニティ内ではWF 4.0プロジェクトに対するサポートがほとんどないようです。これはスキルセットの欠如と相まって、保守性に関する懸念を引き起こします。
- 参入障壁– Windows Workflowの学習曲線は急勾配であり、必ずしもそれほど簡単に習得できるとは思わない。
- 新製品– .NET 4.0向けにワークフローが完全に書き直されたため、この製品は第一世代の製品であり、必要な安定性がない可能性があります。
- 評判–以前のバージョンのワークフローは好評でなく、開発が困難であると考えられ、ビジネスへの取り込みが不十分でした。
したがって、私の質問は、この状況にWindows Workflow（WF）4.0を使用する必要がありますか、または代替技術（たとえば、 Simple State Machine など）または使用するより良いワークフローエンジンさえありますか？
いくつかのWF4プロジェクトを作成したので、他の回答に役立つ情報を追加できるかどうかを確認しましょう。
あなたのビジネス上の問題の説明から、WF4が良い一致であるように聞こえるので、そこで問題はありません。
あなたの懸念については正しいです。基本的に、WF4は新しい製品であり、いくつかの重要な機能が欠けており、いくつかの荒い部分があります。学習曲線があり、いくつかのことを異なる方法で行う必要があります。主なポイントは、長期実行とシリアル化です。これは平均的な開発者には慣れておらず、エンティティフレームワークデータコンテキストのシリアル化に問題があるとよく耳にするため、正しく理解するためにいくつかの考えが必要です。
IIS/WASでホストされるワークフローサービスを使用するほとんどの時間は、これらの長期実行タイプのワークフローを実行する場合の最適なルートです。これにより、バージョン管理の問題を解決することも難しくなく、最初のメッセージにワークフローバージョンを返させて、それを後続の各メッセージの一部にするだけです。次に、バージョンに基づいてメッセージを正しいエンドポイントにルーティングするWCFルーターを間に配置します。基本は、既存のワークフローを変更することではなく、常に新しいワークフローを作成することです。
だからあなたに私のアドバイスは何ですか？未知の、そして証明されていない技術に大きな賭けをしないでください。 WF4を使用して、重要ではない小さなアプリケーションを実行します。そのように機能する場合は拡張できますが、失敗した場合はリッピングして、従来の.NETコードに置き換えることができます。こうすることで、中古情報に基づいて決定を下す代わりにWF4で実際の経験を得ることができ、その過程で新しく強力なテクノロジーを学ぶことができます。可能であれば、WF4のコースを受講すると、スピードアップにかかる時間を大幅に節約できます（恥知らずなセルフプラグ ここ ）。
シンプルステートマシンについて。私はそれを使用していませんが、メモリ内のショートランニングステートマシン用であるという印象を受けました。 WF4の主な利点の1つは、長期にわたる側面です。
私はこのジレンマに何度か来て、Work Flow Foundationを使用しないことを選択しました。いくつかの考慮事項（あなたと同様）は
- 関与するワークフローははるかに単純で（ステートマシンとシーケンシャルアクションの組み合わせ）、WFで作業を行うとやり過ぎになるようです。
- 開発者が理解して使用するための学習曲線WFは実質的に高いと考えられました。有効な遷移と実行されるアクションを説明するステータス遷移表は柔軟性を高めるために使用されます。コンセプトと目的。
- ビジネスプロセスの変更の可能性はわずかであり、移行テーブルを使用して初歩的な変更を簡単に行うことができました。移行の変更はデータベーススクリプトを意味し、アクションの変更は新しいリリース/パッチをもたらします。しかし、そのような発生の可能性は低いとみなされました。
13〜14か月後を振り返ってみると、WFを使用しないという決定は正しかったと考えています。IMO、WF WFワークフローを個別のファイルに分離できるため、ユーザーが構成できるようにするのが簡単になります。
ここ数か月、WF 4.0を使用しています。ワークフローの方法を考えるのは難しいと言わざるを得ません。しかし、それだけの価値があると言えるでしょう。 WF 4.0の初心者向けおよび専門家向けの本を購入しました。私自身、多くのビデオをオンラインで見て、ニュース速報のために2009年PDC= about WF 4.0と、以前のやや不愉快なバージョンとの違い。解決策を提案しなければならなかった主なことの1つは、制限なくワークフローでIn/Our引数を処理できる方法です。特定のデータ型へのカスタムアクティビティと、アクティビティ間でパラメータを渡す方法。そのための優れたソリューションを考え出しましたが、これまでのワークフローエクスペリエンスはまったく悪くありません。それはどんどん大きくなり、異なる環境でそれを解決することは本当に想像できません。私はそれが持っている視覚効果が大好きです。 if/elseなどの詳細から構築し、何が起こっているのか、またはバグを修正する方法を知るためにコード行に飛び込むことを強制しない方法でビジネスルールを明確にします。ところで、私たちが取り組んだプロジェクトは、あなたが説明したものと非常に似ており、中規模のプロジェクトです。私の言葉から私はそれが好きだと言うことができます。それは新しい技術であり、いくつかの革新的なアイデアを考え出さなければならないのでいくつかのリスクが組み込まれていますがお勧めします。
私の2セント...
WF 3.5で3つのプロジェクトを行いました。簡単ではありません。特に永続性を使用する場合は、まったく新しい方法で考える必要があります。不完全な数百を含むアプリケーションの更新永続化されたワークフローは困難です。シリアル化の単一の破壊的な変更はそれらすべてをクラッシュさせます。
私はまだWF 4.0を試していませんが、BizTalkの経験とWF 3.5に似ています。
とにかく、あなたが取ることができる最善のアプローチは、概念実証を行うことです。単一のWFを要求から取得し、それをWF 4.0で実装しようとします。それでしばらく時間を費やしますが、実行できるかどうかを証明しますWF 4.0で、目に見える利点があるかどうか。
WF 4.0を使用することに決めた場合、Windows AppFabricでホストされるWCFサービスとして、WFを実行する可能性を確認することを強くお勧めします。 WFをホストします。
今日、WF4のワークフローをこの種の問題に対するテクノロジーの選択肢として話すことは、あまり意味がないと思います。上記のLadislav Mrnkaが述べたように、本当に適切なのは、WCF WF AppFabricでホストされるサービスです。
私の経験では、これは多大な利益をもたらし、非常に楽しいものですが、多くのプログラマーにとって、これは技術のシフトよりも方法論のシフトであると正しく認識されていないため、最初に問題が発生します。一方、ジェネラリストと問題解決の考え方を持つ人々は、WCF WF AppFabricを一連の刺激的な機会として見ました。プロジェクトの人々のミックスがかなり保守的なC＃開発者である場合彼らの毎日のOOとパターン、紹介するのは難しいでしょう。チームがより革新的であるなら、潜在的で新しい戸口が発見ごとに増加するため、採用ははるかに容易になります。
プログラマーがこのテクノロジーに移行する際に抱えていた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はすぐに使用できる製品ではなく、ワークフローシステムを構築するためにアプリケーションに埋め込むことができる一連のピースです。 IMHOワークフローロジックは最も重要な技術ではありません。ビジネスオーナーにはGUI以外は表示されないため、まずGUIに集中する必要があります。しかし、システムが成功した場合は、変更要求と新しい要件に対処する必要があります。そのため、ビジネスロジックを実装して、変更しやすく、異なるユーザーニーズに合わせて別々のプロセスに簡単に分割できるようにします（矛盾する場合があります） 。 BPMを使用すると、さまざまなビジネスニーズに合った個別の複数バージョンのビジネスプロセスを使用できるため、このタスクに役立ちます。本格的なBPMエンジンは必要ありませんが、ビジネスロジックをコーディングしてバージョン管理し、個々のビジネスプロセスに分割できると便利です-最悪の事態は、「すべて」を処理する手に負えない絡み合ったコードの塊ですそして誰も理解できないこと。そのための多くのアイデアがあります-ステートマシン、DSL（ドメイン固有の言語）、スクリプトなど-あなたは実装がどうあるべきかを決定します。ただし、常にビジネスプロセスの観点から考え、それに応じてロジックを整理して、これらのプロセスを反映させる必要があります。そして、ビジネスロジックとデータ構造の多くのバリアントの共存に備えてください-これは最も難しい設計作業です。
あなたのチームはc＃中心であるように見えるので、私の考えは当てはまらないかもしれません。私はかなりの数の従業員でハイテク企業を経営しており、私たちはまったく同じニーズに直面しました。他の多くのビジネスとは異なり、自由に使える開発者がたくさんいたので、コードベースのワークフローソリューションが理想的でした。
問題は、それが私たちのビジネスの中核でない限り、システムのセットアップ/保守およびライセンスコストのための多くのリソースがないことです。 Azure/Window Workflowは問題外です。また、世の中にあるかなりの数の大きなBPMスイートを試してみましたが、さらに多くの問題に遭遇しました。それらはかなりナーフなビジュアルプログラミングエクスペリエンスを提供します。プログラミングは、視覚的な環境では完全には行えません。 非BPMソフトウェアのリスト が実際に私たちに興味を持っていることがわかります。 Decisions.com やIFTTTなどのツールは便利です。実際、意思決定は、私が理解しているようにマイクロソフト製品と統合されるため、あなたにぴったりかもしれません。
ストーリーの最後は、起業家としての冒険として、そして社内で使用するために、独自のソフトウェアを展開したということです。ワークフローは、APIだけでなく、人間のプロセスをフォームで直接作成して統合できます。たとえば、他の多くのソフトウェアをプル/アップデートする新しい開発者をオンボーディングするためのワークフローを統合しています。かなりグリーンですが、ワークフローシナリオでは非常に強力です。 Nebri をチェックアウトできます。ルールベースのアプローチはイベントで発生するため、アーキテクチャはまったく異なります。記述する必要があるコードの量が減り、速度のトレードオフがあります。しかし、Pythonが自由に使えるので、 complex-event-processing のようなものを簡単に処理できます。
.NET 4.5はprod環境での使用がまだ認定されていないため、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にバインドします。