Jumei のガイド: LogicFlow は、顧客サービス ビジネスにおける Didi の技術チームの実践から生まれました。Didi のインテリジェントなミドルエンド エクスペリエンス プラットフォームによって開発されたプロセス可視化フロントエンド フレームワークです。フローチャートの対話に必要な一連の機能を提供します。編集および柔軟なノードのカスタマイズ、プラグインおよびその他の拡張機能により、ビジネス システムでのクラス フローチャート エディタのニーズに迅速に対応するのに便利です。現在、LogicFlowは社内外のさまざまなユーザーのプロセス構成要件で検証されています。
1.
背景
まず第一に、Didi のインテリジェントなミッドプラットフォーム エクスペリエンス プラットフォームの技術チームは、Didi のすべての事業部門における顧客サービス システムの需要をほぼサポートしています。多様なビジネス シナリオと迅速なロジック変更に直面して、従来のシナリオ指向のプログラミングはコストがかかり、時間がかかります。長い間。そこで当社では、オンラインで設定可能なオペレーションシステムを構築し、オペレーションや製品の学生が、ユーザーからの電話時の自動音声応答やユーザー着信時の手動カスタマーサービスなど、フローチャートを描くことでオンラインのビジネスロジックを変更できるようにしました。手順、ユーザーが自分で問題を解決するためのH5ページ構成システムなど。
次に、各ビジネス システムにはプロセス可視化テクノロジを適用する必要がありますが、その要件は異なります。フローチャートの要件が比較的単純で、グラフのデータ形式も単純なものもあれば、BPMN 仕様に従ってフローチャートを描画する必要があり、カスタマイズの要件がより高いものもあります。市場の関連フレームワーク (BPMN.js、X6、Jsplumb、G6 エディター) を調査しましたが、満足のいくシナリオが存在せず、テクノロジー スタックを統合するコストが非常に高くなっています。具体的には:
BMPN.js と Jsplumb の拡張機能は不十分で、カスタム ノードのサポートのコストが高く、完全にインポートすることしかできず、各システムをオンデマンドでインポートすることもできません。
バックエンドをサポートするプロセス エンジンに適応するコストは比較的高くなります。データ変換やプロセス検証などのビジネス カスタマイズ要件をサポートするものはありません。
ドキュメントやサンプルが健全ではありません。X6 と BPMN の文書は不完全で、例もほとんどありません (2020 年初頭に調査が完了)。
そこで、各システムのプロセス可視化ニーズをサポートするために、2020年上半期にLogicFlowプロジェクトを開始しました。
2.
LogicFlow の機能と特徴
LogicFlow には現在どのような機能がありますか? 2 つのパートに分けて紹介します。
▍ 1. フローチャートエディタを素早く構築する
LogicFlow の基本機能でもある、フローチャートの編集に必要なさまざまな機能を提供します。
グラフを描く能力。SVG に基づいてさまざまな形状のノードとラインを描画し、基本的なノード (長方形、円、多角形など) とライン (直線、ポリライン、曲線) を提供します。
グラフのインタラクション。ノード、線、グラフのさまざまなマウス イベント (ホバー、クリック、ドラッグなど) に応答します。ノードのドラッグ、ドラッグによる接続の作成、線の調整、ノードのダブルクリックによるテキストの編集など。
編集効率を向上させる機能。グリッド、位置合わせ線、前のステップ、次のステップ、キーボード ショートカット、画像のズームインおよびズームアウト、その他のサポート機能を提供して、ユーザーの編集効率を向上させます。
豊富なAPIが提供されています。ホスト R&D は、API 経由でパラメータを渡し、イベントをリッスンすることで、LogicFlow との対話を完了します。
上記の機能により、フロントエンドの研究開発はプロセス視覚化アプリケーションを低コストで迅速に構築し、スムーズな製品インタラクションを提供できます。以下は、LogicFlow の組み込みノードとサポート機能によって作成されたフローチャートの例です。
▍ 2. ビジネスシナリオに基づく展開
基本的な機能がビジネス ニーズを満たせない場合は、ビジネス シナリオに基づいて拡張する必要があります。これは、顧客サービス側で複数のシステムをサポートするための LogicFlow の中核機能でもあります。
図上のすべての要素のスタイルを設定します。たとえば、フロントエンドのスタイル調整のニーズを満たすための、さまざまなノード、線、アンカー ポイント、矢印、配置線などのサイズと色。
API 拡張機能。API 拡張による画像ダウンロードの提供方法の拡張など、LogicFlow へのカスタム メソッドの登録をサポートします。
カスタム ノード、ライン。長方形や円などの組み込みグラフィックス ノードは実際のビジネス ニーズを満たすことができないことが多く、ビジネス上重要なノードを定義する必要があります。LogicFlow は、プロセス承認シナリオの「承認」ノードなど、カスタム グラフィックスとビジネス データを使用してノードをカスタマイズする方法をユーザーに提供します。
拡張コンポーネント。LogicFlow は、SVG レイヤー上に HTML レイヤーと一連の座標変換ロジックを提供し、HTML レイヤー上でのコンポーネントの登録をサポートします。ホスト R&D は、LogicFlow API を介して、ノードの右クリック メニューやコントロール パネルなどの View フレームワークに基づいたコンポーネントを開発できます。
データ変換アダプター。デフォルトでLogicFlowによってエクスポートされるグラフデータは、すべてのビジネスに適しているわけではない可能性がありますが、このとき、アダプターAPIを使用して、LogicFlowからグラフデータを入出力するときに、BPMN標準のグラフデータへの変換などのカスタム変換を行うことができます。 ;
部分拡張機能を内蔵。上記の拡張機能をベースに、BPMN仕様に合わせたノードやデータアダプタ、デフォルトメニューなど、カスタマーサービス業務で発生する共通ノードやコンポーネントを格納するための拡張パッケージも別途提供します。拡張機能は個別にインストールでき、オンデマンドでインポートできることに注意してください。
フロントエンド研究開発では、上記の拡張機能をもとに、実際のビジネスシナリオのニーズに応じて、必要なノードやコンポーネントなどを柔軟に開発できます。以下は、LogicFlow の拡張機能に基づいた 2 つのフローチャートです。
BPMN
承認プロセス
▍ 3. 位置比較
上の図は、LogicFlow の位置付けを理解するために、誰もがよく知っているいくつかのオープンソース フレームワークを水平方向と垂直方向の次元で比較しています。横軸はフレームワークのグラフ視覚化機能の豊富さを示しており、縦軸が高いほどビジネスプロセスアプリケーションにおけるフレームワークの成熟度が高く、初期導入の開発コストが低くなります。これらのフレームワークを個別に紹介しましょう。
ワークフロー エンジンとして、Activiti はフロントエンドおよびバックエンド ソリューションを提供し、一連のビジネス プロセス管理プラットフォームを簡単な二次開発で導入できます。
Bpmn.js: BPMN2.0 仕様に基づいて設計されたフローチャート エディタ。
G6: antv はグラフィック視覚化とさまざまな分析チャートに重点を置いています。生態系ツリー、脳マップ、放射線マップ、インデントマップなど;
X6: グラフ編集エンジン。コア機能はノード、接続、キャンバスです。フローチャートだけでなく、Dag図やER図もサポートしています。
LogicFlow は、上図の Bpmn.js と X6 の間に位置し、中央の隙間を埋めています。コアはフローチャートエディターを提供し、現在のビジネス状況に合わせた拡張機能を通じてBPMNやその他の仕様で必要なプロセスノードとデータ形式をサポートします。
3.
実装原理とアーキテクチャ
▍ 1. 全体構成図
コア パッケージ @logicflow/core はフローチャート エディタの基本機能を提供し、右側の @logicflow/extension は @logicflow/core に基づいて開発されたプラグインです。
▍ 2. フローチャートエディターの設計スキーム
主にフローチャート エディタの重要な選択とスキーム設計を紹介します。
2.1 グラフレンダリングスキーム
フロントエンド描画グラフィックスは HTML + CSS、Canvas、Svg の 3 つの方法にすぎませんが、包括的に比較し、それぞれの長所と短所をリストしました。
フローチャートのシナリオでは、多数のノード (最大数千の要素) をレンダリングする必要はなく、アニメーションの要件も高くありません。Svg の DOM ベースの機能は、学習と開発のコストが低いこと、もう 1 つは DOM ベースの拡張機能が豊富であることにより、私たちにとってより適しています。ただし、Svg タグは div などの他のタグの挿入をサポートしていないため、特定の機能を実装する場合は、他の HTML タグと組み合わせる必要があります。
そのため、最終的には HTML + Svg を使用してグラフのレンダリングを完了することにしました。Svg はグラフィックスと線を担当し、HTML はテキスト、メニュー、背景などのレイヤーの実装に使用されます。
2.2 モジュールの抽象化
上記のスキームに基づいて、次に行う必要があるステップは、フローチャートの実現を分類および抽象化することです。
上の画像から:
機能と機能の拡張を促進するために、さまざまな役割を担う複数のレイヤーを構築しました。最上位のレイヤーは Svg レイヤーであり、すべてのグラフィックス (ノード、ライン、配置ライン、outLine など) は Svg 上にレンダリングされ、グラフ上のさまざまなイベントをリッスンする役割も果たします。Svg の下位レイヤーは、UI コンポーネントの展開を担当するコンポーネント レイヤー、グリッドのレンダリングを担当するグリッド レイヤー、カスタム背景を追加する背景レイヤー、およびカスタム背景を追加する背景レイヤーです。
Shape の責任は主に、Svg によるグラフィックス レンダリングのカプセル化、デフォルト スタイルの提供、ユーザーによって渡された属性の変換などに基づいており、主に Rect、Circle、Ellipse、Polygon、Path、PolyLine、Text などが含まれ、内部処理を容易にします。 LogicFlow の再利用 たとえば、円形ノードとアンカー ポイントの両方に Circle が必要です。
Shape に基づいて、ノードやラインに必要なアンカー ポイント (ライン上の矢印など) など、多くの小さな要素も実装されます。
BaseNode と BaseEdge は、ノードとライン、集約シェイプ、アンカー ポイント、テキストの一般的な機能をカプセル化したもので、イベントとスタイルの処理もカプセル化します。BaseNodeを継承してshapeを渡すことで、RectNodeやCircleNodeなどのレンダリング可能なノードを取得できます。
これらの基本モジュールを使用すると、フローチャートには対話や再編集が豊富に含まれるため、次に行うべきことは、対話スキームの設計が豊富になることです。つまり、図上でユーザーが実行する操作に応答する必要があります。たとえば、ノードのドラッグをトリガーすると、それに応じて関連する線を移動する必要がある場合があり、特定の水平線上に他のノード (位置合わせ線) があるかどうかも識別できます。
2.3 MVVM + 仮想 DOM
まず第一に、グラフエディター全体が大量の状態ストレージを持っていることを考慮し、編集グラフ上の各モジュールの応答を実現するには、状態通信機能を持たなければなりません。第 2 に、やり直し/元に戻すなどの機能を実現する場合は、画像全体をデータに基づいてレンダリングする必要があります (つまり、fn(state) => View)。より良い方法は、モデルを通じてビューを駆動することです。
最終的に、現在のフロントエンド エンジニアリングで広く使用されている設計パターンである MVVM に基づいて LogicFlow のグラフ エディタを構築し、グラフのビュー層とモデル層を定義し、エンジニアリング コードをある程度分離することにしました。同時に、状態管理とデータ応答機能を実現するために Mobx が導入され、グラフはモデルに基づいて状態を伝達します。さらに、Mobx を検討するもう 1 つの理由は、必要に応じて、最もきめの細かいデータ バインディング (観察) を実行できるため、不必要なレンダリングを削減できることです。
以下は、LogicFlow グラフ エディタの MVVM ダイアグラムです。
上の図からわかるように、データ バインディングを通じてモデルが変更された後、ビュー レイヤー (グラフ、ノードなど) が応答/更新されます。グラフのレンダリングは Svg + HTML に基づいていると前述したため、ビュー レイヤーの更新は命令型と宣言型の 2 つのオプションにすぎません。
必須の。たとえば、jQuery の API $('.rectNode').attrs({x: 1, y: 2}) は、この方法で DOM コードを操作するのが実際には非常に面倒で、重い対話シナリオで書かれたコードはより冗長になります。しかし、私たちはついに、命令型の描画を便利にサポートできるライブラリ、antv/g を見つけました。
宣言的。たとえば、React/Vue などの View フレームワークのコア機能の 1 つは、状態 => UI を実現し、宣言的な方法で DOM を構築することであり、状態が変化するたびに UI が更新されます。
DOM 操作シナリオでは命令型コードの煩雑な記述に加えて、DOM 操作のコストも理由として考えられ、State に基づいて UI を更新する設計では、いくつかの問題を解決するために Virtual DOM の導入を当然考えました。また、「Svg ベースのグラフィックスのレンダリング」によって発生する可能性のあるレンダリング パフォーマンスの問題も、シーン内である程度補うことができます。
つまり、MVVM 設計パターンを選択し、Virtual DOM を導入する最も基本的な理由は次の 2 つです。
グラフ エディター シナリオでの開発効率を向上させます。
また、HTML + Svg グラフ レンダリング スキームの下では、より優れたパフォーマンスを追求できます。
X6 とのレンダリング パフォーマンスの比較を行いました。同じ動作環境の下で、LogicFlow と X6 が異なる規模のノード/オフラインでフローチャートをレンダリングするのにかかる時間を測定しました。理論的には、レンダリング時間が短いほどパフォーマンスが向上します。礼儀正しくする。
上記の表から、LogicFlow の初期レンダリング速度が X6 よりも優れていると計算されましたが、これは LogicFlow のオンデマンド読み込み機能をまだ有効にしていないため、テクノロジの選択も検証されました。サンプル ページでテストすることもできます。
https://yhlchao.github.io/LF-VS-Other/
2.4 イベントシステム
「状態」と「レスポンス」で作ったデザインを紹介しましたが、ユーザーの様々な「操作」を収集し、それを時間内にレポートしたりバブリングしたりするには、イベントシステムが必要です。最も重要なことは、レポートの多重化と統合です。
再利用とは、すべてのノードとラインにデフォルトのイベント コールバックがあることを確認する方法と、複雑なイベント (ドラッグ アンド ドロップ) の処理ロジックを共有する方法を指します。
行動。複雑なイベントの処理のために、関数とクラスをパッケージ化しました。たとえば、Drag は、h5 の dragEnter、dragOver、dragEnd、drop イベントをシミュレートするために、mousemove、down、up を使用します。DnD は、抽象的なドラッグソースとドロップターゲットを使用します。インタラクションを実現します。ドラッグ アンド ドロップの間 (ドラッグ アンド ドロップでノードを作成するなど)。
上記のモジュール抽象化セクションで説明したように、内部には BaseNode や BaseEdge などの抽象化があり、組み込みノードとカスタム ノードの両方が基本クラスを継承することで共通の機能を取得するため、LogicFlow 内のデフォルトのイベント コールバックは実際には継承を通じて再利用されます。
イベントセンター。統合レポートはイベント バスを通じて行われ、内部でキャプチャされたすべてのユーザー動作イベントは、特定の仕様と形式の Emit(ev, args) に従って EventCenter にレポートされ、最終的に LogicFlow クラスにバブルされ、ホストと対話します。統一されたやり方。さらに、図エディターのどこにいても、EventCenter を通じてイベントをトリガーおよび監視できます。
2.5 ツールセンター
ツールセンターの位置付けは、前述のBehavior（複雑なイベントのカプセル化）やEventCenterなど、ある種の特定の問題を解決するユーティリティです。さらに、グラフ編集のプロセスでは、より優れたインタラクティブ効果を実現したい場合、実際には多くの複雑な計算ロジックを処理する必要があります。
座標系。ブラウザの clientX 座標系と clientY 座標系、および Svg グラフ自体の座標系は、グラフのズームやパンを行うときに 2 つの座標系が異なるため、イベント処理中に 2 つの座標系間の変換が必要になります。
アルゴリズム。これは、ジオメトリとアルゴリズムを通じて視覚化のいくつかの問題を扱うことに特化しています。たとえば、ノードに複数のポリラインが同じ方向に接続されている場合、次のようにパスを結合して表示をより美しくする方法は次のとおりです。
以下の図に示すように、線がグラフの非アンカー点に接続できる位置に到達するために、グラフに対する線の接点を計算する方法:
歴史。主にやり直し機能と元に戻す機能を提供します。元に戻すとやり直しを保存するために 2 つのスタックが使用され、最大長が制限されていますが、MVVM 設計パターンのおかげで、データの変更やモデル駆動型ビューを観察するのに便利です。
▍ 3. スケーラビリティ
フローチャート エディタの設計スキームを紹介した後、LogicFlow のもう 1 つの重要な機能であるスケーラビリティの設計を紹介しましょう。LogicFlow は、ある分野の問題を解決するための開発フレームワークであり、API がスケーラブルであることが第一ですが、ビュー層も用意されており、ビュー部分で二次開発ができるようにする必要があります。これら 2 つの拡張の方向性が決定したら、最も重要なことは、一定期間予測される現在および将来のビジネス シナリオを満たすようにビジネス ニーズを組み合わせることであり、過剰な設計にならないようにすることです。
3.1 API 上の設計
まず、LogicFlow のユーザー指向層はオブジェクト指向の設計パターンに基づいて完全にカプセル化されており、ほとんどのプログラマが使い慣れており、利用コストが低いことが最大の利点です。それは、次の初期化メソッドを通じて理解できます。
LogicFlow クラスを介して、ユーザーはフローチャートのインスタンスを一度インスタンス化すると取得でき、状態もプライベートであり、lf のインスタンスを介してさまざまな使用メソッドを呼び出すことができます。
API 拡張機能の設計の概要:
オブジェクト指向設計パターン、LogicFlow 内部パッケージ化、ユーザーは継承、インターフェイス/メソッドの書き換えが可能。
メソッドのデザイン。1 つ目は、入力と出力のタイプを固定することです。さらに、LogicFlow は、LogicFlow.use(fn) を通じてプロトタイプ上のメソッドを拡張する extends に似たメソッドも提供します。
オブザーバー モードを通じて通信します。つまり、ホストがさまざまな内部イベントをサブスクライブするための on メソッドを提供します。
グラフデータはカスタマイズ可能です。ノードやラインにどのようなカスタム ビジネス属性があるか、またはフローチャートからエクスポートするデータの種類に関係なく、カスタマイズできる必要があります。
3.2 プラグイン
ユーザーがプレゼンテーションをカスタマイズできる機能に加えて、View レイヤーのスケーラビリティが最も重要なのはプラグインです。プロセスの視覚化においては、ビジネス シナリオごとに異なる機能が必要であり、LogicFlow ではそれが困難であるためです。したがって、優れたプラグインとプラグイン機能を提供し、ユーザーが二次開発を実行できるようにすることをお勧めします。現在、UI インターフェイスで 2 つの機能が公開されています。
ノードとラインは二次開発、つまりカスタム ノードとラインをサポートします。
開発可能なUIコンポーネントはLogicFlowのコンポーネントキャンバスに登録されます。
プラグインの考え方に基づいて、私たちはさまざまなビジネス システムをサポートしてきました。その過程で、BPMN 仕様をサポートするために使用されるノードなど、いくつかの一般的な機能を集約して lf-extension パッケージにカプセル化しました。現在、拡張機能は主に UI コンポーネント、カスタム ノード、API、アダプターの 4 つのカテゴリに分類されています。
4.
これからの計画
1 つ目は API の使いやすさと豊富さです。現在のイテレーション計画（詳細はgithubウェアハウスのプロジェクトを参照）に加えて、特定の機能スコープはユーザーのニーズに応じて優先順位を付けて追加されますので、より多くのコメントやニーズを提供していただければ幸いです。この方向性の基調は、LogicFlow プロセスの視覚的な位置付けを維持し、コアの API を強化し、拡張機能の機能を強化することです。
2 つ目は、より良いドキュメントと例です。主な理由は、ドキュメントが読みやすく完成しやすいことと、開発者がコードをコピーして貼り付けるための完全な例とコードがあることです。現在、例は React バージョンのみであり、vue バージョンの例は 2021.4 より前に追加される予定です。
最後に、これはプロセス視覚化ライブラリであるだけでなく、完全なソリューション セットも期待されています。LogicFlowはフロントエンドのフローチャート編集の技術的問題のみを解決しますが、グラフデータの定義や最終的にどのように処理が実行されるかについては、それをサポートするプロセスエンジンが必要です。
現在、私たちのチームには「プロセス エンジン」に対応するソリューション、ターボ (Java バージョンはオープンソース: https://github.com/didi/turbo) もあり、LogicFlow とターボをエンドツーにします。 - ソリューションの終了、完全なアプリケーション例を提供します。さらに、エンジンの Nodejs バージョンも計画されており、様子を見てみます。
5.
最後に書きます
この記事を通じて、すでに LogicFlow について一般的な理解が得られたと思いますが、ビジネス内でプロセスの視覚化の需要があり、高い拡張性の要件がある場合は、LogicFlow が良い選択となるでしょう。LogicFlow テクノロジー自体の実装の詳細や、同様のビジネスに関する議論についてもお気軽にお問い合わせください。LogicFlowの技術設計の詳細や、可視化、ビジネスプロセス、ロジック配置などの考え方については、今後も記事で紹介していきますので、ご期待ください。
LogicFlow公式サイト： http: //logic-flow.org/
github ウェアハウスのアドレス: https://github.com/didi/LogicFlow
オープンソースチーム
▬
参考文献
▬
内容编辑 | Mango联系我们 | [email protected]