SO の読者であるあなたが、ワークフロー エンジンを使用して解決した具体的な問題と、独自のライブラリ/フレームワークを作成しなかった場合に使用したライブラリ/フレームワークについて知りたいです。また、ワークフロー エンジンが最適な選択ではなかった場合と、ステート マシンを使用する TaskList/WorkList/Task-Management タイプのアプリケーションなど、より単純なものを選択した場合/どのように選択したかについても知りたいです。
質問:
初体験募集中です。
私がチェックアウトしたリソースのいくつか：
私はStonePathの主な作成者であるため、偏見もあります。
私は、米国国務省、ジュネーブの人道的地雷除去センター、いくつかのフォーチュン 500 クライアント、そして最近ではワシントン DC 公立学校システム向けのワークフロー アプリケーションを開発しました。ビジネス プロセスの 1 つのマスター リファレンスになろうとする「ワークフロー エンジン」を目にするたびに、このツールを回避しようと奮闘している組織を見てきました。これは、これらのソリューションが常にベンダー/製品主導であり、最終的に「コンサルタント」の戦術チームが常にアプリに情報を提供しているという事実による可能性があります...しかし、このため、 「ワークフロー定義を 1 か所に集中させ、反復可能にする」ことを約束するプロセスベースのツールの利点。
そうは言っても、私は Ruote がとても気に入っています。私はそのプロジェクトをしばらくフォローしており、そのようなソリューションが必要な場合は、次のツールとして試してみたいと思っています。StonePath は ruote とは非常に異なる目的を持っています。Ruote は一般的に Ruby に役立ちますが、StonePath は Ruby で書かれた Web フレームワークである Rails を対象としています。Ruote が長期的なビジネス プロセスとそれに関連する定義に関するものであるのに対し、StonePath は状態ベースのワークフローとタスクの管理に関するものです。率直に言って、外から見ているのとの違いは微妙かもしれないと思います.多くの場合、同じ種類のビジネスプロセスはどちらの方法でも表現できます.ただし、状態とタスクに基づくモデルは、私のメンタルモデルにマッピングされる傾向があります.
状態ベースのワークフローのハイライトについて説明します。つまり、住宅ローンやパスポートの更新などの処理を中心に展開するワークフローを想像してみてください。ドキュメントが「オフィス内」を移動するにつれて、州から州へと移動します。あなたがドキュメントの責任者で、上司が数時間おきに進捗状況の更新を求めてきて、簡単な回答を求めているとしたら...「データ入力中です」...「確認中です」などと言うとします。申請者の資格情報を今すぐ」... 「品質審査を待っています」... 「完了しました」... など。これらは、状態ベースのワークフローの状態です。「承認」、「適用」、「キックバック」、「拒否」などの遷移を介して状態から状態に移動します。これらはアクション動詞になる傾向があります。
状態/タスク ベースのワークフローの次の部分は、タスクの作成です。タスクは作業の単位であり、通常は期日と処理手順を持ち、作業項目 (ローンの申し込みやパスポートの更新など) をユーザーの「ボックス内」に結び付けます。タスクは互いに並行して、または連続して発生する可能性があり、状態に入ったときに自動的にタスクを作成し、人々が作業を完了する必要があることに気付いたときに手動でタスクを作成し、新しい状態に移行する前にタスクを完了する必要があります。この種の動作はすべてオプションであり、ワークフロー定義の一部です。
うさぎの穴はこれよりもはるかに深くなる可能性があり、PragPub (Pragmatic Programmer's Magazine) の第 4 号でそれについての記事を書きました。その記事の更新された PDF については、上記の reo リンクをチェックしてください。
ここ数か月、StonePath と協力して、状態ベースのモデルが安らかな Web アーキテクチャに非常によく対応していることがわかりました。特に、タスクと状態遷移は、ネストされたリソースとして適切に対応しています。この件に関して、私からの今後の執筆を期待してください。
私は偏っています。私はruoteの作成者の 1 人です。
バリアント 1) リソース (ドキュメント、注文、請求書、本、家具) にアタッチされたステート マシン。
バリアント 2) タスクという名前の仮想リソースに接続されたステート マシン
バリアント 3) ワークフロー定義を解釈するワークフロー エンジン
これで、質問に「BPM」というタグが付けられ、「ビジネス プロセス管理」に拡張できるようになりました。この種の管理は、各バリアントでどのように行われますか?
バリエーション 1 では、ビジネス プロセス (またはワークフロー) がアプリケーション内に散らばっています。リソースに接続されたステート マシンは、ワークフローのいくつかの側面を強制しますが、リソースに関連する側面のみを強制します。同じビジネス プロセスに従って、独自のステート マシンを持つ他のリソースが存在する場合があります。
バリアント 2 では、ワークフローをタスク リソースに集中させ、そのリソースのステート マシンで表すことができます。
バリアント 3 では、ワークフローは、ワークフロー定義 (またはビジネス プロセス定義) と呼ばれるリソースを解釈することによって制定されます。
ビジネス プロセスが変更されるとどうなりますか? ビジネス プロセスが管理可能なリソースであるワークフロー エンジンを使用する価値はありますか?
ほとんどのステート マシン ライブラリには、1 つのセット ステート + トランジションがあります。ワークフロー エンジンは、そのほとんどがワークフロー定義インタープリターであり、複数の異なるワークフローを一緒に実行できます。
ワークフローの変更にかかる費用は?
バリアントは相互に排他的ではありません。ワークフロー エンジンが複数のリソースの状態を変更する例を数多く見てきましたが、その一部はステート マシンによって保護されています。
私はまた、バリアント 3 + 2 をヒューマン タスクによく使用します。ワークフロー エンジンは、プロセス インスタンスを実行しているいくつかの時点で、タスク (作業項目) を人間の参加者に渡します (リソース タスクが作成され、状態が「準備完了」になります)。 .
バリアント 2 (タスク マネージャーのバリアント) だけで長い道のりを歩むことができます。
また、バリアント 0) について言及することもできます。この場合、ステート マシンもワークフロー エンジンも存在せず、ビジネス プロセスがアプリケーションに散らばっていたり、ハードコーディングされていたりします。
多くの質問をすることができますが、答えを読む時間を取らず、試して実験する時間を取らないと、それほど遠くまで行くことはなく、いつ使用するかについての才能を獲得することは決してありません.これまたはそのツール。
私が取り組んでいた以前のプロジェクトでは、ヘルスケア業界の一連の政府フォームにいくつかのワークフロー タイプのルールを追加しました。
フォームはエンド ユーザーが記入する必要があり、一部の回答によっては、後日他のフォームに記入する予定でした。スケジュールされたフォームをキャンセルしたり、新しいフォームをスケジュールしたりする外部イベントもありました。
サンプルフロー:
患者の入院 -> 初期評価フォームのスケジュール -> 四半期ごとのレビュー フォームのスケジュール -> 患者の死亡 -> レビューのキャンセル -> 退院評価フォームのスケジュール
他の多くの規則は、患者の年齢、入院場所などに基づいていました。
これは ASP.NET アプリで、ルールは基本的にデータベース内のテーブルでした。スクリプトを追加したので、フォームの完了時にスクリプトが実行され、次に何をすべきかが決定されます。これは恐ろしい設計であり、適切なワークフロー エンジンに最適でした。
ドキュメントの段階的な処理をサポートするために、独自のワークフロー エンジンをロールバックしました。カタログ化、画像処理のための送信 (編集 SW を使用)、必要に応じて検証に送信し、リリースして最終的にクライアントに返送します。私たちの場合、処理するドキュメントが大量にあるため、配信とリソースの使用を制御するために、各サービスを個別に実行する必要がある場合があります。コンセプトはシンプルですが、高いパフォーマンスと分散処理が必要であり、私たちにぴったりの市販の製品が見つかりませんでした。
ネットワーク ノードのインフラストラクチャで高性能かつ高スループットのデータ転送プロセスを処理するためにActiviti BPMN 2.0 エンジンを使用した経験があります。基本的なタスクは、このような転送プロセスの構成と監視を許可し、各ネットワーク ノードを制御することでした (つまり、ノード 1 に特定のトランスポート層を介してデータ ファイルをノード 2 に送信するように要求します)。
一度に数千のプロセスが実行され、1 日あたり全体で数万または数十万のプロセスが実行される可能性があります。
さまざまなプロセス定義が多数ありましたが、システムのオペレーターがカスタム ワークフローを作成できる必要は必ずしもありませんでした。したがって、BPM エンジン自体の主な使用例は、堅牢でスケーラブルであり、各プロセス フローを監視できるようにすることでした。
最終的には基本的には機能しましたが、そのプロジェクトから学んだことは、BPMN プラットフォーム、具体的には Activiti エンジンは、このような高スループット システムに最適ではないということでした。
主な課題は、タスクの実行の優先順位付け、DB のロック、BPM 自体に関する実行の再試行などでした。そのため、これらのカスタム処理を開発する必要がありました。たとえば、次のようになります。
他の BPMN エンジンがこのようなシナリオにより適しているかどうかはわかりません。BPMN は主に、パフォーマンスがおそらく私たちの場合と同じ問題ではない、ユーザーとの対話を含む長時間実行されるビジネス タスクを対象としているためです。