アプリケーション開発プラットフォーム統合ワークフロー - ノード変換を処理するプロセスモデリング機能の設計と実装

背景

不親切なプロセス設定の問題については、国内のDingTalkがbpmnの仕様とは関係なく、プロセスモデリングモード一式を別途設計・実装しており、それを誰かが模倣してオープンソース化しました（https://github.com/StavinLi/ワークフロー -Vue3 ) の効果図は次のとおりです:

実装の一般原則は、無限にネストされた子ノードに基づいており、json データを出力し、それをバックエンドに渡します。バックエンドが解析した後、Camunda エンジンの API を呼び出します。それをプロセス モデルに変換し、永続化します。

前回の記事ではモデル変換フレームワークの構築を行いましたが、今回はタスク処理ノードの扱い方に焦点を当てます。ここでいうタスク処理には、承認やレビューだけでなく、タスクの処理も含まれます。タスク処理を使用した方が適用範囲が広く、ビジネス上の意味でより正確です。結局、承認はリーダーから部下へのタスクであることが多いのです。

Camunda のユーザータスクの概念に相当するノードの処理は最も一般的でよく使用され、モデル変換の重要な前作業であり、実際にはこの種のノードの構成を最初に設計する必要があります。

基本的な属性

ノード自身の識別 ID、名前、タイプ type は共通であり、Camunda モデルの UserTask クラスの基本属性でもありますが、その関係は明らかであり、対応関係は十分なので繰り返しません。

拡張属性

ワークフロー エンジンは、特に中国式の承認を満たすために特定の機能を実行するために、プラットフォームと統合する必要があります。より使いやすく便利にするために、いくつかの属性を追加する必要があります。ユーザーはプロセッサを指定する必要があります。 。
ノードを管理するには、処理モードを構成することが非常に重要です。
初期の頃は、Camunda 付属のモデラーを使用し、フロントエンドの動作には bpmn-js を使用していましたが、開発が面倒であったため、ノードの構成情報を格納するために自作のデータベース テーブルを使用していました。
この統合はカスタム フロントエンド方式を採用しており、自己構築データベース テーブル ストレージ ノード構成情報モードとの互換性が高く、プロセス モデリングの描画インターフェイスでノードをクリックすることで直接構成できます。

ノード設定の管理

設計原則

ノード処理の中心はプロセッサを設定することであり、人員設定はいくつかの原則に従う必要があります。
1. システムの運用と保守の便宜上、すべてのリンクにプロセッサの役割が設定され、特定のプロセッサは指定されません。退職や転勤の可能性があるため、このような理由でアップグレードする場合 プロセステンプレートのバージョンが非常に無理がある ロールによる人材の維持は、システムに大きな柔軟性をもたらします。
2. 複数人の連署、並列処理のみを使用し、シリアル機能は使用しません。並列効率が高く、ビジネス状況により適合します。シリアルが必要な場合、通常、連署者は異なる作業を行うため、必要に応じてより多くのことを行います。プロセス テンプレートの設計 このリンクからアクセスする方が適切です。ユーザーはプロセッサの順序を指定する必要がなく、プロセスの表示と追跡から現在の進行状況を確認する方が簡単です。
3. リンク処理者を指定する必要がある場合、前のリンクから指定される場合と、通常は「近い」場合とがありますが、実際の業務では明確なルールがないため、システムが自動的に属性を区別して振り分ける場合があります。 、手動による選択が必要です。2 つ目は、契約の法的レビューなど、記入および報告プロセス中にプロセスの開始者によって指定されます。多くの役割がありますが、多くの場合オフラインです。特別な人によって処理され、管理者には適していません。稟議書を掴む役割も担っており、担当副社長もおり、部門長と同様の立場である。
4. ロールを設定すると、そのロールの下に人は 1 人だけになります。現時点では手動で指定する必要はありませんが、運用プロセス中に変動する可能性があります。たとえば、ある日ロールに人を追加する必要があるなどです。この場合、ロールの下にある人物は表示されます ユーザーによって選択され、フロントエンドから人間化された便利な方法で処理できます 取得する人物が 1 人だけの場合は、その人物を直接選択できますユーザーはプルダウンして指定する必要はありません。

シナリオ

上記の原則に従って、どのような状況にあるのかを整理すると、次のようになります:

さらに、上図に従って、設定する必要があるノード属性を分類します タイプの観点からは、2 つのカテゴリがあります プロセッサの数に応じて、それらは複数人の副署と単一人の副署に分けられます）、カテゴリの下で、処理担当者を手動で指定するかどうかを区別するために属性が必要です。
副署名：担当者を指定するかどうかをさらに設定する必要があります、指定しない場合は全員が参加します
シングルサインオフ：担当者を指定するかどうかをさらに設定する必要があります、指定しない場合はサインオフとなります

さらに、出願人による処理者の指定も考慮する必要がありますが、技術的実装の観点からは、実際には前のリンクの処理者の指定者と同じです。出願人であるか、前のリンクの処理者であるかは関係ありません。 、指定者はプロセス変数を設定し、プロセス インスタンス変数を通じてハンドラーを割り当てます。

注文の署名

このモードは特定のプロセッサを指定しませんが、タスクをロールに割り当てます。このロールは、このロールの下にあるすべての担当者が参照できます。通常、次の 2 つのアプリケーション シナリオで使用されます: 1. タスク処理タスクに対応するロールは同じ責任を持ちます
。書類を処理する能力があるため、これ以上の区別はありません。たとえば、レジ​​担当者
は業務量が多いため、複数の人が同時にタスクを処理する必要があります。

技術的な実装の観点から、リンク候補グループの属性をロールとして設定します。タスクを送信すると、ワークフロー エンジンがサンプルを生成します。ToDo タスクをクエリするときは、2 つの状況を考慮する必要があります。1 つは直接割り当てられます。 1 人、もう 1 人は現在のユーザーが持つロールに割り当てられます。

ビジネス利用の観点から見ると、直面する問題は次のとおりです。
1. 共通タスクと注文取得タスクは同じインターフェイス上に表示される必要があり、できれば同じ次元 (タスクの到着時間など) に従って並べ替えられる必要がありますが、注文取得タスクはできれば並べ替えられる必要があります。マークが付けられ、フィルタリングが可能です (優先度の観点から、人に割り当てられたタスクは「必ず実行しなければならない」タスクですが、役割に割り当てられたタスクは「オプション」のタスクです)

解決策のアイデア:
1. 基盤となる SQL で実現し、役割に応じた役割の割り当てなどのタスクをクエリ可能なデータに変換する
2. 注文の取得と署名の種類のドキュメントをアプリケーション レベルで個別に処理し、データのマージを実行する

リンク要員設定の実現

現状

フロントエンドのオープンソースプロジェクトリンクの設定は下図のようになりますが

、私の設計ではインターフェースのプロパティが大幅に調整され、対応するデータ構造も大幅に変更されます。

変身

バックエンド支援

同じプロセス テンプレートには複数のバージョンがあり、リンク構成はプロセス テンプレートの特定のバージョンに属しているため、プロセス テンプレートを編集するときに、プロセス テンプレート コードのバージョン番号だけでは、対応するリンク構成を特定できません。

当初の計画

ワークフローを統合する前に Camunda モーダルを使用する場合、採用されるスキームは次のとおりです。
Camunda は各プロセス テンプレートに対応し、属性 processDefinitionId を持ちます。この属性は、プロセス コード + バージョン番号 + リリース ID (uuid) の 3 つの部分で構成されます。この属性は、リンク設定の一意の識別として使用されます。
しかし、ここで問題が発生します。リリース ロゴはリリース後にのみ生成されるため、いくつかのシナリオを考慮する必要があります:
1. 新しいプロセス テンプレートを追加し、リンクを構成します。現時点ではリリースはありませんが、リリースはあります。プロセス定義のロゴ
2. 変更 リンク構成用のプロセス テンプレートは、現時点ではプロセス定義 ID とともにリリースされており、プロセス ID はリンク構成と一致しています。 3. プロセス テンプレートをアップグレードし、リンク構成を実行します
。リンク構成が不一致です（このときの構成と変更が実際には次のバージョンになります）

シナリオ 2 は通常の操作であり、直接操作できます。
シナリオ 1 およびシナリオ 3 では、一時的なプロセス定義 ID を生成し、公開後に一時的な ID を実際の ID に更新する必要があります。

プロセスコード + バージョン番号でプロセスを一意に決定できるため、一時的なバージョン番号のプロセス定義識別子は、これら 2 つの部分を組み合わせて生成されます。
よく考えてみると、新しいプロセステンプレートを追加するときに、あらかじめバージョン番号を 1.0.0 に設定しておけば、シナリオ 1 とシナリオ 3 は同じシナリオとみなすことができます。

新しい計画

上記のスキームは属性を組み合わせる必要があるため、追加の処理と解析が追加されますが、フロントエンドは Camunda Modal に適用されなくなったため、制約がなくなり、自由に設計および実装できるようになります。 、リンク構成エンティティで、プロセス テンプレート コードとプロセス テンプレート バージョンの 2 つの属性を直接使用します。

プラン選択

その後の実際の変換プロセスでは、Camunda はタスクなどの多くのエンティティ属性と API で processDefinitionId を使用していましたが、新しいソリューションを使用すると多くの変換作業が必要となるため、元のソリューションを使用して実装されます。

実装

プラットフォームのローコード構成機能を使用して、バックエンド リンク構成エンティティの構成、ライブラリ テーブルの生成、フロントエンド コードとバックエンド コードの生成を実現します。プロセスは表示されなくなります。 、結果のみがスクリーンショットに表示されます。

後でプロセスが承認されるときに、次のステップがどのリンクに流れるかを示すためにこのテーブルを読み取る必要があるため、リンクの名前もリンク構成に含まれます。

フロントエンドの調整

ユーザーのタスクは個別に処理されます

まず、nodeWrap コンポーネントを調整し、ユーザー タイプのコンポーネントを個別に処理します。

 <div class="node-wrap" v-if="nodeConfig.type == 1">
    <div
      class="node-wrap-box"
      :class="
        (nodeConfig.type == 0 ? 'start-node ' : '') +
        (isTried && nodeConfig.error ? 'active error' : '')
      "
    >
      <div class="title" :style="`background: rgb(${bgColors[nodeConfig.type]});`">
        <span>{
   
   { nodeConfig.nodeName }}</span>
        <i class="anticon anticon-close close" @click="delNode"></i>
      </div>
      <div class="content" @click="setUserTaskNodeConfig">
        <div class="text">
          <span class="placeholder" v-if="!showText">请选择{
   
   { defaultText }}</span>
          {
   
   { showText }}
        </div>
        <i class="anticon anticon-right arrow"></i>
      </div>
      <div class="error_tip" v-if="isTried && nodeConfig.error">
        <i class="anticon anticon-exclamation-circle"></i>
      </div>
    </div>
    <addNode v-model:childNodeP="nodeConfig.childNode" />
  </div>

リンク名がリンク構成に含まれているため、本来のクリックキャンセル機能はキャンセルされます。元のプロジェクトでは type 属性を多くの箇所で使用しているため、当面は 1 のままにし、デバッグ後、ビジネス上の意味を持つ独自に定義した USER_TASK に修正します。

独自のリンク構成ページ UserTaskNodeConfig.vue を作成します。インターフェイスの効果は次のとおりです。

ユーザータスクリンク設定プロパティの再定義

新しい属性 userTaskNodeConfig がオープン ソース プロジェクト データ構造に追加され、バックエンド データ構造と一貫性のあるリンク構成を保存するために使用されます。

   // 初始化数据
      defaultNodeConfig: {
        nodeName: '填报',
        nodeId: '1',
        type: 'FIRST_NODE',
        userTaskNodeConfig: {},
        conditionList: [],
        childNode: {}
      }

プロセスが開始した権限変換

オリジナルのオープンソースプロジェクトの場合、最初のリンクにイニシエーター、つまり制御プロセスの開始権限を設定する必要があります。設計上、この方法は無理があると思います 権限制御はプロセステンプレート内に配置されています プロセスイニシエータのスコープを変更したい場合は、プロセスのバージョンアップは必要ありませんが、変更されたエントリをここに置くのは奇妙です。
機能メニューの権限設定など、運用保守に便利なプロセス起動権限をより柔軟に制御できる設計を追求する必要がある。この設計に基づいて、最初のリンクでプロセス権限を設定する必要がなくなったので、オープン ソース プロジェクトは主に次の側面を含むように調整されました。 1. 関連する属性 flowPermission をノード属性から削除します。 2. 担当者を削除し
ます
。選択コンポーネントのプロモータードロワー

ドロワーコンポーネントがダイアログに置き換えられました

リンクを設定する際、元のオープンソース プロジェクトはドロワー コンポーネントを使用しますが、実際のリンクで設定する必要があるコンテンツ項目は限られており、ドロワー コンポーネントは広い領域で空白のままになり、外観に影響を与えるため、ダイアログボックスに置き換えられます。

フォームの権限の設定は後から追加するため、置き換えることは考えていません。

状態管理を削除する

コンポーネント内での状態管理の使用は直感的に重いため、一時期はコードの修正が検討され、コンポーネント内で値を渡すためにpropsが使用されました。コード構造を深く理解した後、ノードは再帰的にネストされており、マルチレベル コンポーネントでは状態管理を使用してプロパティを共有し、値を渡すのが最も合理的であるため、削除と変換はキャンセルされます。

開発プラットフォーム情報

プラットフォーム名: One Two Three 開発プラットフォーム
紹介: エンタープライズ レベルの総合開発プラットフォーム
設計情報: csdn コラム
オープン ソース アドレス: Gitee
オープン ソース プロトコル: MIT
オープン ソースは簡単ではありません。お気に入り、いいね、コメントへようこそ。