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