ワークフローエンジンの使用例
SOリーダー-ワークフローエンジンを使用して解決した特定の問題と、独自のロールを使用しなかった場合に使用したライブラリ/フレームワークについて知りたいのですが。ステートマシンを使用するTaskList/WorkList/Task-Managementタイプのアプリケーションなど、ワークフローエンジンが最良の選択ではなかった時期と、より簡単なものを選択したかどうか/どのように選択したかを知るため。
質問：
- ワークフローエンジンを使用して解決した問題は何ですか？
- どのライブラリ/フレームワークを使用しましたか？
- システムのような単純なステートマシン/タスク管理で十分なのはいつですか？
- ボーナス： タスク管理 と ワークフローエンジン をどうやって区別しましたか？
私は直接の経験を探しています。
私がチェックアウトしたリソースの一部：
StonePath の主な著者であるため、私も偏見があります。
私は、米国国務省、人道的地雷除去のためのジュネーブセンター、いくつかのフォーチュン500のクライアント、そして最近ではワシントンDC Public School System。）のワークフローアプリケーションを開発しました。エンジンをビジネスプロセスの1つのマスターリファレンスにしようとしたが、ツールを回避するために闘っている組織を見てきました。これは、これらのソリューションが常にベンダー/製品主導であり、最終的にはアプリを絶えず提供する「コンサルタント」の戦術的なチーム...しかし、このため、「ワークフロー定義を一箇所に集中させて再現可能にする」ことを約束するプロセスベースのツールの利点を聞くと、否定的に反応する傾向があります。
そうは言っても、私はRuoteに非常に似ています-私はしばらくそのプロジェクトをフォローしてきましたが、そのようなソリューションが必要になった場合、それは私が試してみたい次のツールになります。 StonePathの目的はruoteとは非常に異なります。Ruoteは、Rubyに役立ちます。StonePathは、Rubyで書かれたWebフレームワークであるRailsを対象としています。Ruoteは、長期にわたるビジネスプロセスと関連付けられた定義であるStonePathは、状態ベースのワークフローとタスクの管理に関するものです。率直に言って、外部からの区別は微妙だと思います-多くの場合、同じ種類のビジネスプロセスをどちらの方法でも表すことができます-状態とタスクベースのモデルは私のメンタルモデルにマップする傾向があります。
状態ベースのワークフローのハイライトについて説明しましょう。つまり、住宅ローンやパスポートの更新などの処理を中心にしたワークフローを想像してください。文書が「オフィス内を移動」すると、状態から状態へと移動します。あなたがドキュメントの責任者であり、上司が数時間ごとにステータスの更新を要求し、簡単な答えが欲しいと想像してください...あなたは「データ入力中です」などと言います...」申請者の資格情報」...「品質レビューを待っています」...「完了しました...」など。これらは、状態ベースのワークフローの状態です。 「承認」、「適用」、「キックバック」、「拒否」などの遷移を介して状態から状態に移動します。これらはアクション動詞である傾向があります。このようなものは常にソフトウェアで状態マシンとしてモデル化されます。
状態/タスクベースのワークフローの次の部分は、タスクの作成です。タスクとは、通常、期日と処理指示を伴う作業単位であり、作業項目（たとえば、ローン申請やパスポートの更新）を「ボックス内」のユーザーに接続します。タスクは互いに並行して、または連続して発生する可能性があり、状態に入ると自動的にタスクを作成し、人々が作業を完了する必要があることに気づいたときに手動でタスクを作成し、新しい状態に移行する前にタスクを完了する必要があります。この種の動作はすべてオプションであり、ワークフロー定義の一部です。
うさぎの穴はこれよりもはるかに深くなる可能性があり、私はPragPub（Pragmatic Programmer's Magazine）の第4号にそれについて記事を書きました。その記事の更新されたPDFについては、上記のリンクをチェックしてください。
過去数ヶ月間、StonePathを使用して、状態ベースのモデルは安らかなWebアーキテクチャに非常によくマッピングされることを発見しました。特に、タスクと状態遷移はネストされたリソースとしてうまくマッピングされます。このテーマに関する今後の執筆を期待してください。
私は偏見があり、私は ruote の著者の一人です。
バリアント1）リソース（ドキュメント、注文、請求書、書籍、家具）に接続されたステートマシン。
バリアント2）タスクという名前の仮想リソースに接続された状態マシン
バリエーション3）ワークフロー定義を解釈するワークフローエンジン
これで、質問に「BPM」というタグが付けられ、「ビジネスプロセス管理」に拡張できます。そのような管理は、各バリアントでどのように行われますか？
バリアント1では、ビジネスプロセス（またはワークフロー）がアプリケーションに散在しています。リソースに接続されたステートマシンは、ワークフローのいくつかの側面を強制しますが、リソースに関連する側面のみを強制します。同じビジネスプロセスに従って、独自のステートマシンを持つ他のリソースが存在する場合があります。
バリアント2では、ワークフローをタスクリソースに集中させ、そのリソースの周りのステートマシンで表すことができます。
バリアント3では、ワークフロー定義（またはビジネスプロセス定義）と呼ばれるリソースを解釈することにより、ワークフローが制定されます。
ビジネスプロセスが変化するとどうなりますか？ビジネスプロセスが管理可能なリソースであるワークフローエンジンを使用する価値はありますか？
ほとんどのステートマシンライブラリには、1セットの状態+遷移があります。ほとんどの場合、ワークフローエンジンはワークフロー定義インタープリターであり、複数の異なるワークフローを一緒に実行できます。
ワークフローを変更するコストはいくらですか？
バリアントは相互に排他的ではありません。ワークフローエンジンが複数のリソースの状態を変更する多くの例を見てきましたが、その一部はステートマシンによって保護されています。
また、ヒューマンタスクにはバリアント3 + 2を多く使用します。ワークフローエンジンは、プロセスインスタンスを実行するときのある時点で、タスク（ワークアイテム）を人間の参加者に渡します（リソースタスクが作成され、状態が「準備完了」になります） 。
バリアント2のみ（タスクマネージャバリアント）を使用すると、長い道のりを進むことができます。
また、バリアント0）に言及することもできます。この場合、ステートマシンもワークフローエンジンも存在せず、ビジネスプロセスがアプリケーションに散在し、ハードコーディングされます。
多くの質問をすることができますが、答えを読むのに時間をかけず、試してみて実験するのに時間をかけなければ、あなたはあまり遠くに行かず、いつ使用するかの才能を決して得ませんこれまたはそのツール。
以前のプロジェクトで、ヘルスケア業界の一連の政府フォームにワークフロータイプのルールを追加していました。
フォームはエンドユーザーが記入する必要があり、いくつかの回答に応じて、他のフォームが後日記入される予定でした。スケジュールされたフォームをキャンセルしたり、新しいフォームをスケジュールしたりする外部イベントもありました。
サンプルフロー：
入院患者->初期評価フォームのスケジュール->四半期レビューフォームのスケジュール->患者死亡->レビューのキャンセル->退院評価フォームのスケジュール
他の多くのルールは、患者の年齢、入院する場所などに基づいていました。
これはASP.NETアプリであり、ルールは基本的にデータベース内のテーブルでした。スクリプトを追加したので、フォームの完了時にスクリプトを実行して、次に何をすべきかを判断します。これは恐ろしい設計であり、適切なワークフローエンジンに最適でした。
チェック Railsワークフロー gem-これはあなたが探しているものに近いと思います。
ネットワークノードのインフラストラクチャで高性能かつ高スループットのデータ転送プロセスを処理するために Activiti BPMN 2.0エンジンを使用した経験があります。基本的なタスクは、このような転送プロセスの構成と監視を可能にし、各ネットワークノードを制御することです（つまり、特定のトランスポートレイヤーを介してnode1にnode2にデータファイルを送信するように要求します）。
一度に数千のプロセスが実行され、全体で1日に数十または数十のプロセスが存在する可能性があります。
さまざまなプロセス定義がありましたが、システムのオペレーターがカスタムワークフローを作成できることは必ずしも必要ではありませんでした。そのため、BPMエンジン自体の主な使用例は、堅牢でスケーラブルで、各プロセスフローを監視できるようにすることでした。
結局、それは基本的には機能しましたが、このプロジェクトから学んだことは、BPMNプラットフォーム、具体的にはActivitiエンジンは、このようなハイスループットシステムには最適ではないということです。
主な課題は、タスク実行の優先順位付け、DBロック、BPM自体に関する少数の名前を指定するための実行の再試行でした。そのため、たとえば、これらのカスタム処理を開発する必要がありました。
- ノードに特定のタスクの空きワーカーがなかった場合、またはノードがまったく実行されていなかった場合のBPMでの再試行の処理。
- 単一プロセスでの並列転送タスクの実行と結果の同期（成功/失敗）。
他のBPMNエンジンがこのようなシナリオに適しているかどうかはわかりません。BPMNは、パフォーマンスがおそらく私たちの場合と同じ問題ではないユーザーインタラクションを含む長期実行ビジネスタスクを主に対象としているためです。
私は、Uberで開発した Cadence Workflow Engine の著者の1人です。 Cadenceと既存のワークフローエンジンの大部分の違いは、開発者向けであり、非常に柔軟でスケーラブルであることです（1秒あたり数万の更新と最大数十億のオープンワークフロー）。ワークフローはオブジェクト指向プログラムとして記述され、エンジンは、ホスト障害が発生した場合にスレッドスタックやローカル変数を含むワークフローオブジェクトの状態が完全に保持されるようにします。
ワークフローエンジンを使用して解決した問題は何ですか？ケイデンスは、単一の要求応答を超えて存続する実質的にすべてのバックエンドアプリケーションに使用されます。使用例は次のとおりです。
- 分散CRONジョブ
- ML /データパイプラインの管理
- ビジネスイベントへの対応。たとえば、Uberでの旅行イベントです。ワークフローは、受信したイベントに基づいて状態を蓄積し、必要に応じてアクティビティを実行できます。
- Mesos/Kubernetesへのサービス展開
- CIパイプラインの実装
- 要求を受信したときに複数のサービス呼び出しが完了することを保証します。 [〜＃〜] saga [〜＃〜] パターン実装を含む
- ヒューマンワーカーのタスクの管理（Amazon MTurk と同様）
- メディア処理
- カスタマーサポートチケットルーティング
- 注文処理
- ChaosMonkey に類似したテストサービス
他の多くの
ユースケースの他のセットは、既存のワークフローエンジンをCadenceで実行するために移植することに基づいています。実際には、既存のエンジンワークフロー仕様言語はすべて、Cadenceで実行するために移植できます。移植された複数の内部Uberシステムがあります。このようにして、単一のバックエンドサービスで複数のドメイン固有のワークフローシステムを強化できます。
どのライブラリ/フレームワークを使用しましたか？
ケイデンスは、Goで記述された自己完結型のサービスであり、 Go および Java のクライアント側ライブラリです。外部依存関係はストレージのみです。 CassandraおよびSQLデータベースがサポートされています。
ケイデンスは、非同期のクロスリージョン（AWSの用語を使用）レプリケーションもサポートしています。
システムのような単純なステートマシン/タスク管理で十分なのはいつですか？
Uber内では、ケイデンスのサービスはチームによって管理されています。そのため、カスタムステートマシン/タスク管理を構築するオーバーヘッドは、Cadenceを使用するよりも常に高くなります。社外では、そのためのサービスとストレージをセットアップする必要があります。既にSQLデータベースがある場合は、Dockerイメージを介してサービスを簡単に展開できます。 Dockerは、パーソナルコンピューターまたはラップトップで開発するために、ローカルのCadenceサービスを実行するためにも使用されます。
カタログ作成、画像処理のための送信（リダクションswで作業）、必要に応じて検証への送信、リリース、最終的にクライアントへの返送-ドキュメントの段階的な処理をサポートするために、独自のワークフローエンジンをロールしました。私たちの場合、処理するドキュメントが大量にあるため、配信とリソースの使用を制御するために各サービスを個別に実行する必要がある場合があります。コンセプトはシンプルですが、高いパフォーマンスと分散処理が必要でした。また、私たちに代わる商品を見つけることができませんでした。
私は Imixs-Workflow の著者の一人です。 Imixs-Workflowは、BPMN 2.0に基づくオープンソースのワークフローエンジンであり、Java EEテクノロジースタックに完全に統合されています。
10年以上前から自分でワークフローエンジンを開発しています。簡単にあなたの質問に答えようとします：
>解決するためにワークフローエンジンを使用した問題は何ですか？
ワークフローエンジンについて考え始めたときの私の個人的な目標は、アプリケーション内のビジネスロジックのハードコーディングを避けることでした。ビジネスアプリケーションの多くのものを再利用できるため、それらを構成可能にしておくのが理にかなっています。例えば：
- 通知を送信する
- 開いているタスクを表示する
- 人にタスクを割り当てた
- 現在のタスクを説明する
この機能リストから、人間中心のワークフローについて話していることがわかります。要するに、人間中心のワークフローエンジンが質問に答えます。誰がタスクを担当し、誰に次に通知する必要があるのでしょうか。そして、これらはビジネス要件の典型的な質問です。
>どのライブラリ/フレームワークを使用しましたか？
5年前に、 BPMN 2. に重点を置いてImixs-Workflowエンジンの再実装を開始しました。 BPMNは、プロセスモデリングの一般的な標準です。そして、私にとって驚くべきことは、視覚化して実行できる非常に複雑なビジネスプロセスでさえも突然記述できたことです。ビジネスプロセスのモデリングにはBPMNを使用することをお勧めします。
>システムのような単純なステートマシン/タスク管理で十分なのはいつですか？
ビジネスオブジェクトのステータスを追跡するだけの場合は、単純なステートマシンで十分です。これは、オブジェクトモデルに「ステータス」属性を導入し始める場合です。ただし、責任、ロギング、およびフロー制御を伴うビジネスプロセスが必要な場合は、ステートマシンでは不十分です。
>ボーナス：タスク管理とワークフローエンジンをどのように区別しましたか？
これがまさにここで言及した多くのワークフローエンジンが異なる点です。人間中心のワークフローでは、通常、ヒューマンアクター間でタスクを分散するためのタスク管理が必要です。プロセス自動化の場合、この点はそれほど重要ではありません。エンジンが特定のタスクを実行すれば十分です。タスク管理は常にワークフローエンジンの機能であるため、タスク管理とワークフローエンジンを比較することはできません。