多くの皆さんが、 Microsoft Workflowというそのような技術について聞いたことがあると思います。 それはかなりよく宣伝されており、ハブに投稿があり、英語とロシア語の本があります。 はい、 マイクロソフトは美しい写真を公開しています。
このテクノロジーの本質は、プログラマーがAPIを作成し、ビジネスアナリストが自分でビジネスプロセスを作成することです。 仲介なし。
たとえば、クライアントがこのビジネスプロセスを要求しました。
そして、ビジネスアナリストはそれを引き出します。 プログラマは、Accept、Reject、およびその他の同様のキューブのみを実装する必要があります。 かっこいい？
私は本やマーケティング出版物からこの技術についてしか聞いていなかったという点で特に幸運ではなかった。 そしてもちろん、「6か月前にMS WFを調べましたが、もう1か月間使用していました-フライトは正常です！」などのプレゼンテーションから。 私は、Workflowが6年間実装された製品で作業しています（2、3年しか使用していません）。かなり負荷が高いため、このライブラリの主な設定と待ち伏せを示したいと思います。 この投稿が、私たちが踏んでいたのと同じレーキを避けるのに役立つことを願っています。
どのように機能しますか？
アイデアは非常に単純です。プログラマはキューブを作成します-アクティビティ。 各アクティビティにはパラメータを設定できます。 たとえば、Userプロパティを使用してRejectActivityを作成できます。 ほとんどの場合、これはこのユーザーに対して拒否が発生することを意味します。 実際、各アクティビティには、外部表現（つまり、ビジネスアナリストがそれを見る方法）と実装があります。 ところで、ここですぐに待ち伏せ＃1を取得します：これは同じクラスです。 まあ、つまり、美しいデザイナーは実装にリンクする必要があります。 しかし、これはIoCの助けを借りて非常に簡単に解決されるため、単にウォームアップと呼びます。
ビジネスアナリストがデザインを作成した（つまり、一連のアクティビティを描画し、それらを矢印で接続した）場合、Xamlビューとして保存できます。 Microsoft Workflow Runtimeをダウンロードして実行を開始できるようになります。
一部のアクティビティでは、一時停止できます（アクティビティの遅延など）。 この場合、動作状態はデータベースにシリアル化されます。 さて、一定の時間が経過すると（私たち自身が示したように）、ワークフローが再び起動して続行します。 保存するには、ベースまたは独自の書面による保存が必要です。 すべてがクールだよね？
シリアル化ポッド
上記のテキストから理解したように、ビジネスプロセスを一時停止する必要がある場合があります。 典型的な例：ユーザーからの応答を待っています（つまり、イベントアクティビティを使用しています）。 この場合、通常のシリアル化が行われます（Workflow 4.0+ではxmlシリアル化、古いバージョンではバイナリ）。 読者はすぐに、ここに多くを保存するか、リリースAで保存し、リリースBでロードするときに少し間違いを犯すことが非常に簡単であることに気づいたと思います。 知っている場合は、そうすることで、新しいクラスフィールドを作成し、データベースに保存します。 そして、デシリアライゼーションが低下するにつれて、負荷も低下します。 したがって、重要なヒント： すべての作業コードは、アクティビティの範囲から厳密に除外する必要があります。 すべてのフィールドは、ワークフローから離れた場所に保管する必要があります。 アクティビティでは、最小限の最も単純なタイプを保存します。 安定性よりも内部設計の方が良いとしましょう 。
実際、ここでのセットアップは終了しませんでした。 最もクールなことは、フィールドのセットを変更する必要があるときに始まります。 たとえば、例のRejectActivityでは、Reasonを追加する必要があります。 そして、古いRejectActivityにこのフィールドが含まれていないという事実に備えて、コードを準備する必要があります。 ワークフロー4.0+では、データベース内のシリアル化されたビューを変更できますが、ワークフロー3.0では、この方法は常に機能するとは限りません（圧縮されたバイナリビューが保存されるため）。このすべてをすばやく更新することはできません。
待ち伏せのパフォーマンス
実際、Microsoft Workflowには一連の欠陥があります。 さらに、問題は単一の実行（つまり、多くの操作が効率的に実行されない）と負荷分散の両方に関連しています。 ただし、最初にまず最初に。
いつ保存しますか？
ゼロの期待があるビジネスプロセスがあると想像してください。 どのように出てきたとしても。 重要なことは、彼らがいるということです。 ワークフローは、期待を保存する優れた理由として扱います。つまり、シリアル化を行い、作業を再度アップロードします（ただし、すぐにではありませんが、重要ではありません）。 当然、これは最も好ましくない方法で反応時間に影響します。 したがって、アドバイス： Delay Activityをできる限り少なく、さらに良い方法で-If Activityと組み合わせて、実際に待つ必要がないことを確認します 。 もう1つの不快な瞬間は、「5日間待つ」と言った場合、単純な方法では、インスタンスが既にデータベースにある場合、ワークフローが何も待たないようにすることです。 さらに、Workflow Runtimeが作業内容をメモリにロードし、待機する時間がまだまだあることがわかった場合、奇妙なことに、メモリに残しておくだけです。 そして彼は多くの時間を待つでしょう。 したがって、別のヒント： このような問題のため、長い待ち時間を使用しないでください。 多くの短いイベントを使用するか、外部イベントのために起動するのが最善です。外部サービスは必要に応じてプロセスを起動します 。
分散実行
Microsoftの同じ記事を信じている場合、Workflowは作業を分散する方法を知っています。 つまり、複数の独立したサーバーを使用できます。各サーバーは、いくつかのタスクを実行し、それらを完了し、次のタスクを実行します。 欠点が1つだけあります。これはフィクションです。 問題は、Workflowの分散実装が非常に奇妙な製品であることです。 次のアルゴリズムに従って動作します。
- データベースから、現在実行可能なすべての非ブロックワークフローを取得し、5分間ロックします
- 2分後：手順1を繰り返します
はい、数字2と5は変更できます。 もう1つ重要なことは、最初の幸運な人がすべての作業をデータベースから取得することです。 ちなみに、2分後、彼は何かしなければならない場合でも、再びベースをクリーニングします。 ワークフローに5分間収まらない場合、奇妙なことが起こります：ワークフローを実行し（すべてのWCF接続などを呼び出します）、データベースに保存しようとしますが、何も動作しません（ブロッキングはありません！）。 その結果、この壊れたオブジェクトはこのワークフローランタイムのメモリに永久に残ります。 そして、あなたがプロセスを物理的に停止するまで、彼は自発的にそれを離れません。 Workflow Runtimeはそれ自体を停止せず、何も実行できません。 素晴らしい実装。 5分ではなく、より長い時間ロックを構成すると、より美しいシナリオが発生します。 この場合、プロセスが停止した後、これらのレコードはブロックされます。 つまり、プロセスを停止することはできなくなり、生産プラットフォームに非常に悪影響を及ぼす可能性があります。 この問題は非常に簡単に解決できます。 適切な分散作業を行うには、データベースを操作する手順を自分で作成する必要があります（つまり、並列作業と分散作業のすべての手順を実装し、 WorkflowPersistenceServiceを独自に実装します）。 ところで、ここには1つの機能があります。MSSqlデータベースを操作する必要はなく、他の方法を試すことができます。 実際、問題は単純なファイルボールの助けを借りて解決され、迅速かつ正確に機能しますが、これは流行ではありません。
負荷の下で成功した作業
実際、彼女はそうではありません。 もちろん、 Microsoftはすべてがうまくいっていると主張していますが 、1つの小さなグラフを忘れていました。メモリ内のアクティビティの量の合計時間への依存性です（以前はそのようでした ）。 実際、変更されていません。
これは二次グラフです。 ここで重要なのは、絶対的な時間の値ではなく、依存関係です。ビジネスプロセスの複雑さが増した場合に、すべてがどのくらい機能するかです。 さらに、実際には、実行時間はメモリ内のアクティビティの総量に依存するため、1つまたは複数のワークフローであるかどうかは関係ありません。 たとえば、10の並列ワークフローがある場合、各小さなアクティビティの処理は、1つのワークフローがある場合よりも多くのリソースを消費します。 または別の方法で：10個の並列タスクは、10個の連続したタスクよりも長く処理されます。 さらに、非線形依存性を持ちます。
前のパートで、Persistence Serviceの仕組みを書きました。データベースからすべてを取得します。 実際、5000並列の複雑なワークフローというこのようなトリックは、システムにとって悲惨なものです。1分あたり1〜10アクティビティ（!!!）という非常に低い速度で動作し始めます。 そして、これは、プロセッサがほぼ100％ロードされることを前提としています。 問題は明らかですが、それを解決する方法は？ 解決策： アクティビティハンドラを作成し、アクティビティを再利用して、ワークプロセスをエミュレートします。 実際、アクティビティの開始と停止に関与するワークフローの基本コンポーネントを迅速に実装する必要があります。 これは、第一に、ワークフローで多数の起動されたアクティビティを防ぐため（すべてが遅くなるため）、第二に、シリアライゼーション/デシリアライゼーションの時間を短縮するために必要です（メモリから不要なものをすばやく追い出します） 。 Microsoft Workflowは、使用済みのアクティビティを削除することはありません。 完了したアクティビティがメモリ内にないように、すべてを実装する必要があります。
まとめ
Microsoft Workflowで作業するときに待ち受ける問題のいくつかを説明しようとしました。 実際、ニュアンスは多数ありますが、多かれ少なかれ解決可能であり、あなたはそれを処理できると確信しています。 実際、独自のカスタムビジネスプロセスを作成するタスクがある場合は、Microsoft Workflowの使用を開始することをお勧めします。 プロトタイプの場合はそれで十分です。 さらに、軽負荷の場合、システム全体が機能します。 主な基盤は知られています-それらはより高く、完全に解決可能です。 さらに、マーケティング情報のみを持つシステムを使用するよりも、何を期待すべきかがわかっているシステムを使用する方がはるかに優れています。 負荷が増大し始めたら、モジュールごとに効果的な実装に移行できます。