背景
ワークフローは、業務システムのプロセス処理機能を実現するアプリケーション開発基盤の重要な部分です。
一般的に、これには 3 つの部分が含まれており、1 つはワークフロー エンジン、もう 1 つはプロセス モデリング、そして 3 つ目は開始プロセス、ToDo、完了したドキュメント、および終了ドキュメントを含む派生支援です。
2020 テクノロジーセレクション
需要が明確な分野であるため、対応する技術コンポーネントがあり、2020年はjbpmとactivitiを中心に、activitiの分割により生じたflowableとcamundaのブランチを中心に技術的な事前調査を実施してきました。コンテキストはおおよそ次のとおりです。
Origin : jBPM3 は、開発者向けの完全なワークフロー システム実装です。
**開発: **jBPM4 は PVM を導入して拡張性を高め、同時に BPMS 機能を強化します。これらの機能には、ビジネス指向の Web モデラーである BPMN のサポートと簡単な統計分析機能の追加が含まれます。
分割:
1. JBPM の主な作成者である Tom Baeyens は、JBPM の将来のアーキテクチャに関してパートナーと大きな意見の相違があったため、Tom は Jboss を離れ、Alfresco に入社し、jBPM4 のコードに従い、Activiti5 を設立しました。Activiti5 は、jBPM4 をベースとしたオープンソースのワークフロー システムです。Alfresco との統合により、プロセスの可視化と管理機能が向上します。同時に、革新的な Activiti Cycle コラボレーション コンポーネントにより、プロセス関連担当者の調整をサポートし、統合機能が強化されます。
2. Jboss 社は、JBPM4 のアーキテクチャを完全に放棄し、Drools Flow に基づいて完全にリファクタリングし、JBPM5 をリリースしました。BPMN をサポートし、Drools との合併を通じて BAM をサポートし、コンテンツ ウェアハウスを通じてプロセス視覚化のサポートを追加します。jBPM4 の PVM の廃止により、エンジンのスケーラビリティが損なわれ、jPDL はサポートされなくなりました。
核分裂
- Activiti の最大の貢献者の 1 人である Camunda 氏は、Activiti が当初開発したより一般的な BPM プラットフォームを無視し、ドキュメント中心のワークフローに対する Alfresco のニーズに制約されすぎている可能性があると述べました。Camunda は、Activiti から新しいオープンソース プロジェクト、つまり camunda BPM をフォークすると発表しました。
- Activiti のコアチームは、プロジェクトの将来の開発方向に関して Alfresco と意見の相違があったため、集団で離れることを選択し、Flowable を作成しました。
- Activiti 自体の発展は遅く、Activiti はここ数年停滞して資金を食い始めています。CMMN/DMN の 2 つの新しい仕様と BPMN のその他の仕様については、Camunda フレームワークが最初に対応してサポートしてきましたが、Activiti5 はまだこれらの仕様をサポートできず、多くのユーザーが失われ、多くのユーザーが Activiti5 に頼ることになりました。カムンダキャンプ。activiti6 と activiti5 の公式コードがメンテナンスの停止を発表しました。Activiti7 はギミックです。コアは activiti6 を使用しており、エンジンに新たな機能を追加することはありません。Activiti の外側の上位層にいくつかのアプリケーションをカプセル化するだけで、クラウドに向けて開発されます。バージョン 6.0 にはフレームワーク レベルのバグが多数残っていると言われていますが、それらは Flowable で修正されました。
さまざまな側面から収集されたデータによると
、activiti は jbpm よりも優れており
、 jbpm が最初に
flowable から抜け出すことができます。
データ 1:
複数の側面から見ると、カムンダはフローアブルよりも優れています
https://blog.csdn.net/qq_30739519/article/details/86682931
情報 2:
Flowable は 6.4.1 バージョンを分水嶺として、商用バージョンの製品を精力的に開発しています。オープンソースバージョンのメンテナンスが間に合わない。フォームジェネレーター（フォームエンジン）、履歴データの他のデータソースへの同期、ESなど、一部の機能はオープンソース版では公開されなくなりました。dmn は現在半完成品であり、camunda ほど安定性も使いやすさも劣っており、dmn 仕様のサポートも弱いです。製品版の一部のコンポーネントは商用化されているため、オープンソース版はメンテナンスされなくなりました。Mongdb は現在商用製品も提供されており、オープンソース版はほとんど使用できません。(出典: https://blog.csdn.net/qq_30739519/article/details/
上記の状況を踏まえ、Activiti の主力部門は荒廃しており、camunda と Flowable の 2 つの部門のうち前者が選択されます。ネイティブワークフローエンジンの統合には多大な労力を要し、主要な機能を実現するまでに数か月を要しましたが、その効果はあまり満足のいくものではありませんでした。
バックエンド ワークフロー エンジンの統合は、私にとってまったく問題ありません。最大の問題は、bpmn2.0に基づくフロントエンドモデリングにあり、フロントエンドモデリングのコンポーネントが複雑でデータが曖昧である一方で、機能を実現するために必要な手法やデータの入手が困難です。繰り返し試行すると長い時間がかかり、最終的にいくつかの機能を間接的に解決するためにバックエンド処理という手法が採用されますが、一方で、activiti (カムンダ) はプロセス処理のあらゆる側面を定義する大規模かつ包括的なコンポーネントであり、そのため、プロセスモデリング時に設定する必要がある設定が多数あり、その中には比較的あいまいなものも含まれます。その名前と概念は、モデリングユーザー、特に国内ユーザーにとって親しみやすいものではありません。
私が非常に感銘を受けたのは、条件付きエッジの設定です。プロセス モデリングが必要な場合は、条件付きエッジを選択し、${contractMoney}>100 0000 などの式をフォームに入力しますが、これは使いにくく、間違いが発生しやすくなります。 。
現在のテクノロジーの選択
3 年後、ワークフロー統合作業が再び再開されましたが、まず第一に、過去数年間に新たな変更やより良い選択肢があったかどうかを確認するために、テクノロジーの事前調査が依然として必要でした。
最近の状況をざっと見たところ、activitiの最新メジャーバージョンはまだ7、flowableはまだ6です。
camunda については、確認しました。以前の統合では 7.13 が使用されていましたが、現在は 8 になっています。ただし、8 は新しいプロセス エンジン Zeebe に置き換えられており、アクティビティのセットではなくなりました。市場で最も人気のあるものは依然として comunda7 または flowable6 に基づいています。
今年3月31日に公開された記事「Activiti5、activiti6、activiti7、flowable、camunda7、camunda8プロセスエンジンの比較分析と選定リファレンス」（ https://blog.csdn.net/wxz258/article/details/ 129884545 ）を発見し、
結論は次のとおりです。
簡単な概要: デプロイメントプロセスエンジンを民営化する必要がある国内ユーザーは、camunda7 を選択することをお勧めします. ほとんどのコンポーネントはオープンソースであり、無料で使用できます. テクノロジーエコロジーが優れており、プログラマは簡単に始めることができます. プロセスの自動化と高い同時実行性に対する大きなニーズがあるお客様は、camunda8 の選択を検討できますが、それには大量の拡張カスタム開発が必要であり、それには高度な技術チームの能力が必要です。国内主流の Yuncheng ローコード プラットフォームはプロセス エンジンとして camunda7 を使用しており、現在、camunda7 は中国で徐々に普及しており、activiti や flowable を超える勢いです。
もう 1 つの方法は、国内での自己研究です。オープンソースのものはほとんどありません。長い間それを行っている人もいます。Jinan は JFlow をギャロップしています ( https://gitee.com/opencc/JFlow?_from=gitee_search )。残念ながら、それはそうです。 vue3 Element PlusではなくAnt UIライブラリを使用したバージョンで、まだオープンソースではありません H5版も使用可能ですが、古いjqueryとlayuiを使用しています 私のプラットフォームに導入すると重くなります。
もう 1 つはhttps://gitee.com/gailunJAVA/dingding-mid-business-java?_from=gitee_searchです。この男はワークフロー分野に焦点を当てています。彼は activiti、camunda、flowerable に精通しており、さまざまなサポートを提供しています。主にバックエンドで動作し、フロントエンドは主に他のオープンソース プロジェクトによってサポートされています。
技術的ソリューションの選択
テクノロジーの事前調査の過程で、テクノロジーの実現に関するアイデアが生まれました。主な理由は、DingTalk プロセスをモデルにしたオープン ソース プロジェクトを見つけるためです ( https://github.com/StavinLi/Workflow-Vue3 )。テクノロジー スタックでは vue3+element plus も使用されており、これは私の現在のプラットフォームと一致しています。実装の効果は次のとおりです。
このモデルは、camunda に付属する bpmn2.0 仕様に基づくプロセス モデリングよりもはるかに簡潔で直感的で便利です。
これをプロセス モデリングの代わりとして使用すると、主な問題は、上記のコンポーネントによって出力された json が解析され、bpmn プロトコルで合意されたデータ形式に変換される場合に発生することです。この部分は自作で実装しており、変換はcamundaのAPIを呼び出すことで実現しています。
上記のソリューションの選択は、プラットフォームの既存のフロントエンド技術スタック (vue3+Element Plus) と、数か月にわたって投資されてきた camunda バックエンド統合の実装に基づいて、さまざまな要素を総合的に考慮して決定されました。プロセスモデラーにとって使いやすい UI そして経験、最終的な決定。
ワークフローは大きなコンポーネントであり、プラットフォームの統合には多くの開発が含まれます。次に、統合のサブカテゴリをオープンしますが、これは依然として毎週のリズムですので、ご期待ください。
開発プラットフォーム情報
プラットフォーム名: One Two Three 開発プラットフォーム
紹介: エンタープライズ レベルの総合開発プラットフォーム
設計情報: csdn コラム
オープン ソース アドレス: Gitee
オープン ソース プロトコル: MIT
オープン ソースは簡単ではありません。お気に入り、いいね、コメントへようこそ。