|
Jumeiの紹介： LogicFlowは、Didi技術チームのカスタマーサービスにおける経験から生まれました。Didiのインテリジェントミドルプラットフォームエクスペリエンスプラットフォームによって開発されたLogicFlowは、ワークフローを可視化するためのフロントエンドフレームワークです。フローチャートの操作と編集に必要な一連の基本機能に加え、柔軟なノードカスタマイズ、プラグインなどの拡張機能を提供し、業務システムにおけるフローチャート編集者のニーズに迅速に対応できます。現在、LogicFlowは社内外の様々なユーザーのワークフロー構成ニーズにおいて検証されています。 1. 背景 まず、Didiのインテリジェントミドルウェアエクスペリエンスプラットフォーム技術チームは、Didiのほぼすべての事業セグメントのカスタマーサービスシステム要件をサポートしました。多様で急速に変化するビジネスシナリオに対応するため、従来のシナリオベースのプログラミングはコストと時間がかかりました。そこで、オンラインで構成可能な運用システムを構築し、運用チームと製品チームがフローチャートを描画することでオンラインビジネスロジックを変更できるようにしました。例えば、ユーザーからの電話に対するインタラクティブな音声応答、ユーザーの電話に対応する人間のカスタマーサービス担当者のための標準操作手順、ユーザーが自主的に問題を解決するためのH5ページ構成システムなど、ユーザーごとにパーソナライズされたアプリケーションシナリオを作成できます。 第二に、すべてのビジネスシステムはプロセス可視化技術の適用を必要としますが、そのニーズは多岐にわたります。フローチャートやデータ形式に関する要件が比較的シンプルなものもあれば、BPMN仕様に従ってフローチャートを描画する必要があり、より高度なカスタマイズが求められるものもあります。市場にある関連フレームワーク（BPMN.js、X6、Jsplumb、G6-editor）を調査したところ、いずれも特定のニーズを満たしておらず、統合されたテクノロジースタックのコストが非常に高くなることが判明しました。具体的には、以下の通りです。
そこで、さまざまなシステムのプロセス可視化ニーズに対応するため、2020年前半にLogicFlowプロジェクトを立ち上げました。 2. LogicFlowの機能と特徴 LogicFlow の現在の機能を 2 つの部分に分けて紹介します。 ▍ 1.フローチャートエディタを素早く構築する フローチャート編集に必要なすべての機能を提供します。これは LogicFlow の基本機能でもあります。
これらの機能により、フロントエンド開発者はプロセス可視化アプリケーションを迅速かつコスト効率よく構築し、スムーズな製品インタラクションを実現できます。以下は、LogicFlowの組み込みノードとサポート機能を使用して作成されたフローチャートの例です。 ▍ 2. ビジネスシナリオに基づいた拡張 基本機能だけではビジネスニーズを満たせない場合は、ビジネスシナリオに基づいて拡張する必要があります。これは、LogicFlowが複数の顧客サービスシステムをサポートできるようにするコア機能でもあります。
前述の拡張機能をベースに、フロントエンド開発者は実際のビジネスシナリオのニーズに応じて、必要なノードやコンポーネントなどを柔軟に開発できます。以下は、LogicFlow拡張機能に基づいた2つのフローチャートです。 BPMN 承認プロセス ▍ 3.ポジショニング比較 上の図は、LogicFlowの位置付けを理解するために、いくつかの有名なオープンソースフレームワークを2つの軸で比較したものです。横軸はフレームワークのグラフ可視化機能の豊富さを表し、縦軸が高ければ高いほど、ビジネスプロセスアプリケーションにおけるフレームワークの成熟度が高く、初期導入開発コストが低いことを意味します。これらのフレームワークを一つずつ紹介していきましょう。
LogicFlowは、上図のBpmn.jsとX6の間に位置し、両者のギャップを埋める役割を果たします。LogicFlowの中核はフローチャートエディタを提供し、BPMNなどの標準規格で要求されるプロセスノードとデータ形式をサポートするように機能を拡張することで、現在のビジネス要件を満たします。 3. 実装の原則とアーキテクチャ ▍ 1.全体アーキテクチャ図 コアパッケージ @logicflow/core はフローチャートエディターの基本機能を提供しますが、右側の @logicflow/extension は @logicflow/core に基づいて開発された拡張プラグインです。 ▍ 2.フローチャートエディタの設計図 このセクションでは、主にフローチャート エディターを実装するためのキーの選択とソリューション設計について説明します。 2.1 画像レンダリングスキーム フロントエンドのグラフィックレンダリングには、基本的にHTML + CSS、Canvas、SVGの3つの手法があります。これらを比較し、それぞれの長所と短所を列挙しました。 フローチャートのシナリオでは、多数のノード（最大で数千要素）をレンダリングする必要はなく、アニメーションの要件もそれほど高くありません。SVGのDOMベースの性質は、学習と開発のコストが低く、DOMに基づく拡張性が高いという理由から、フローチャート作成に適しています。ただし、SVGタグはdivなどの他のタグの挿入をサポートしていないため、特定の機能を実装する際には、他のHTMLタグと組み合わせる必要があります。 そのため、最終的に画像のレンダリングにはHTML + SVGを使用することにしました。SVGはグラフィックと線を扱い、HTMLはテキスト、メニュー、背景、その他のレイヤーの実装に使用します。2.2 モジュールの抽象化上記のソリューションに基づいて、次のステップはフローチャートの実装を分類および抽象化することです。 上記の図に基づいて:
フローチャートはこれらの基本モジュールによって豊富なインタラクティブ性、あるいはむしろ再編集されているため、次のステップはリッチなインタラクティブソリューションを設計することです。つまり、ユーザーがダイアグラム上で行うあらゆるアクションに対して、ユーザーが反応を示すようにする必要があります。例えば、ノードをドラッグすると、関連する線もそれに応じて移動する必要があるかもしれません。また、システムは特定の水平線上に他のノード（位置合わせ線）があるかどうかを識別できる必要があります。 2.3 MVVM + 仮想DOM まず、グラフエディター全体に大量の状態ストレージがあり、グラフ上の様々なモジュールからのレスポンスを可能にするには状態通信機能が必要であると考えます。次に、やり直し/元に戻すなどの機能を実装する場合、グラフ全体がデータに基づいてレンダリングを導出する必要があります。つまり、fn(state) => View です。より良いアプローチは、モデルを介してビューを制御することです。 最終的に、LogicFlow グラフエディタは、現在のフロントエンドエンジニアリングで広く使用されている設計パターンである MVVM に基づいて構築することにしました。これにより、グラフのビュー層とモデル層を定義でき、コードの分離が可能になります。同時に、状態管理とデータ応答機能を実装するために Mobx を導入しました。各グラフは単一のモデルに基づいて状態をやり取りします。さらに、Mobx を採用したもう一つの理由は、きめ細かなデータバインディング（監視）が可能になり、不要なレンダリングを削減できることです。 以下は、LogicFlow グラフ エディターでの MVVM の概略図です。 上の図に示すように、ビュー層（グラフ、ノードなど）は、データバインディングを通じてモデルの変更に応答／更新します。グラフのレンダリングはSVG + HTMLに基づいていることを既に述べました。したがって、ビュー層の更新には、基本的に命令型と宣言型の2つのオプションがあります。
DOM操作を伴う命令型のシナリオのコード記述が煩雑になるという理由に加え、DOM操作のコストも理由の一つです。UIの更新を状態に基づいて行う設計では、特定のシナリオにおける更新効率の問題を解決するために仮想DOMを導入することが自然と浮かび上がりました。これは、「SVGベースのグラフィックレンダリング」によって発生する可能性のあるレンダリングパフォーマンスの問題も補うことができます。 要約すると、MVVM 設計パターンを選択し、仮想 DOM を導入する最も基本的な 2 つの理由は次のとおりです。
X6とのレンダリング性能比較を実施しました。同一動作環境において、LogicFlowとX6のレンダリング時間を、ノード数／行数を変えて測定しました。理論的には、レンダリング時間が短いほどパフォーマンスが優れていると言えます。 上の表は、LogicFlowのオンデマンドロード機能を有効にしていない場合であっても、LogicFlowがX6の初期レンダリング速度を上回っていることを示しています。これは、LogicFlowの技術選択が正しかったことを示しています。サンプルページでもご確認いただけます。 https://yhlchao.github.io/LF-VS-その他/ 2.4 イベントシステム 「ステータス」と「レスポンス」の設計についてご紹介しました。様々なユーザーの「アクション」を収集し、タイムリーにレポートしてアップするには、イベントシステムが必要です。最も重要なのは、再利用性と統一されたレポート機能です。 再利用とは、すべてのノードとラインにデフォルトのイベント コールバックがあることを確認する方法と、複雑なイベント (ドラッグ アンド ドロップ) の処理ロジックを共有する方法を指します。
2.5 ツールセンター ツールセンターは、前述のBehavior（複雑なイベントのカプセル化）やEventCenterといった特定の種類の問題を解決するためのユーティリティとして位置付けられています。さらに、グラフ編集のプロセスにおいて、優れたインタラクティブ効果を実現するには、実際には多くの複雑な計算ロジックを処理する必要があります。
下の図に示すように、線と図形の間の接点を計算して、線を図形のアンカー以外のポイントに接続できるようにする方法。
▍ 3.スケーラビリティ フローチャートエディタの設計について紹介したところで、LogicFlowのもう一つの重要な特徴である拡張性について説明しましょう。LogicFlowは特定のドメインにおける問題を解決するための開発フレームワークであるため、APIは拡張可能でなければなりません。さらに、LogicFlowはビューレイヤーを提供しており、ユーザーはこれを活用することで二次開発を行うことができます。拡張性のこれらの2つの方向性が決まったら、最も重要なのはビジネスニーズを考慮し、過剰なエンジニアリングを行うことなく、現在のビジネスシナリオだけでなく、近い将来に予測されるビジネスシナリオにも対応できることを確認することです。 3.1 API設計 まず、LogicFlowのユーザーインターフェース層は、完全にオブジェクト指向設計パターンに基づいています。その最大の利点は、ほぼすべてのプログラマーが使い慣れているため、利用コストが低いことです。これは、以下の初期化メソッドを見ればわかります。 LogicFlowクラスを使用すると、ユーザーは一度インスタンス化するだけでフローチャートのインスタンスを取得できます。状態もプライベートであり、lfインスタンスを通じて様々なメソッドを呼び出すことができます。 まとめると、API 拡張の設計に関して次のようになります。
3.2 プラグイン ビュー層の拡張性は、ユーザーが表示をカスタマイズできることに加え、最も重要なのはプラグイン性にあります。これは、ビジネスシナリオによってプロセスの可視化に必要な機能が異なり、LogicFlowではすべてのシナリオをサポートするのが困難だからです。そのため、ユーザーが二次開発を行えるように、優れたプラグイン性を提供することがより良い選択肢となります。現在、UIインターフェースでは以下の2つの機能を開放しています。
プラグインアプローチに基づき、様々なビジネスシステムをサポートしてきました。その過程で、BPMN仕様をサポートするノードなど、より一般的な機能を抽出し、lf-extensionパッケージにカプセル化しました。現在、この拡張機能は主にUIコンポーネント、カスタムノード、API、アダプタの4つのカテゴリに分類されています。 4. 今後の計画 まず、APIの使いやすさと充実度について考えてみましょう。現在のイテレーションプラン（GitHubリポジトリのプロジェクトを参照）に加え、ユーザーのニーズに基づいて優先順位をつけて特定の機能を追加していく予定です。皆様からのフィードバックやご提案もお待ちしております。全体的な方向性としては、LogicFlowワークフローの可視化を維持し、コアAPIを充実させ、拡張機能の機能を強化することを目指しています。 第二に、より包括的なドキュメントとサンプルを提供します。ドキュメントは読みやすく、開発者がコピー＆ペーストできる完全なサンプルとコードが含まれます。現在はReactのサンプルのみ利用可能ですが、Vueのサンプルは2021年4月までに追加される予定です。 最後に、私たちは単なるプロセス可視化ライブラリの提供にとどまらず、包括的なソリューションの提供を目指しています。LogicFlowはフロントエンドのフローチャート編集の技術的な側面のみに対応していますが、グラフデータの定義やプロセスの最終的な実行方法を決定するには、補完的なプロセスエンジンが必要です。 現在、私たちのチームは「プロセスエンジン」に対応するソリューションであるturbo（Java版はオープンソースです：https://github.com/didi/turbo）も開発しています。LogicalFlowとTurboをエンドツーエンドのソリューションに統合し、包括的なアプリケーション例を提供する予定です。さらに、Node.js版のエンジンも計画中ですので、どうぞご期待ください。 5. 結論は この記事でLogicFlowの概要をご理解いただけたかと思います。ビジネスプロセス可視化と高いスケーラビリティが求められる場合、LogicFlowは最適な選択肢となるでしょう。LogicFlowの実装の詳細や、類似のビジネスシナリオへの適用について、皆様のご意見をお待ちしております。今後、LogicFlowの技術設計の詳細や、可視化、ビジネスプロセス、ロジックオーケストレーションに関する私たちの考えを紹介する記事をさらに公開していく予定です。どうぞお楽しみに！ LogicFlow 公式サイト: http://logic-flow.org/ GitHubリポジトリアドレス: https://github.com/didi/LogicFlow |
