ルールはルールに従うものであり、操作ルールと操作ルールが続きます。ルールはどこにでもあり、社会活動におけるルールは通常、何をすべきか、何をすべきではないかという形で表現される伝統と公知によって形成されます。コンピュータアプリケーションシステムでは、アクションを処理・実行する際に、同時に他の条件も成立させる必要があり、その条件判断のロジックがルールとして抽象化され、大量に適用されるケースがよくあります。ルールの管理と使用により、システムを柔軟に管理し、ビジネス ルールに抽象化されたシナリオに柔軟に適用できます。特に、複数のシナリオで同じルールを使用することで、再利用によるコスト削減や業務管理の一貫性を実現できます。
ビジネス ルールの抽象化は、特に多くの大規模なビジネス システムの実装において、優れた設計パターンとなっています。従来のハイコード開発であろうとローコード実装であろうと、アプリケーション開発は必然的にルールの開発と使用の問題に直面します。
この記事は、ローコード モードでの開発活動におけるルールの処理について説明することを目的としており、この記事で実際にサポートされているプラットフォームは Haojing Lingxi 開発プラットフォームです。
ビジネスルールの抽象化
オンラインショッピングの経験から、本を購入する場合、割引がないことが多いことがわかりました。ただし、注文合計金額が一定の条件を満たした場合、300個以上の注文で50割引や送料無料、プレゼントなどの割引を受けることができます。実は本だけでなく他の商品を購入する際にもさまざまな割引や特典があります。
しかし、ECプラットフォーム上の商品の種類や数量は非常に多いため、システム導入の際に商品ごとにプロモーションロジックを開発すると、開発者の負担は膨大になってしまいます。
実際、多くの加盟店では、注文量や商品の数量、特産品の属性などによってプロモーション活動を行っています。これは一般的なプロモーション ルールに抽象化できます。注文された商品に応じて、優先条件が判断され、優先計算が実行され、最終的に優先結果が出力されます。販売者は商品の割引戦略を設定するだけでよく、システムはさまざまなプロモーション シナリオを実現するためのロジックを自動的に計算できます。
システムでは、上記のルールを実装するロジックは次のとおりです。
まず、考慮する必要があるデータには、ユーザーが注文した商品情報と販売業者が設定した商品の割引戦略情報が含まれます。これらのデータは、ルールの論理的な実装に使用されます。
次に、論理的判断プロセスには次のステップが含まれます。
-
優先ポリシーがあるかどうかを確認します。商品情報は、商品に優先ポリシーが設定されているかどうかを判断するためのルールの入力パラメータとして使用されます。
-
優遇条件が成立しているかを判定します。注文された商品情報と加盟店が設定した割引戦略に基づいて、割引条件が満たされるかどうかを計算します。
-
割引計算。設定された割引方法に応じて、割引計算、ギフト計算、送料無料計算などが行われます。
-
割引結果を出力します。ルールにより算出された優遇結果は業務システムに出力され、商品価格の調整が完了する。
次に、上記のルールをローコードで設定する方法を紹介します。
ビジネスルールの設定
ローコードでは、複雑なルール構成の開発は、主に「入力パラメータ + コンポーネント + 出力パラメータ」という直感的なグラフィカル構成インターフェイスに依存し、単純なドラッグ アンド ドロップと構成操作を通じて、ルール データ構成、ロジックを実現します。構成と結果のフィードバック。
最初のステップの パラメータ設定には次の側面が含まれます。
入力パラメータ データ: 視覚化機能を通じて、ユーザーはルールの入力パラメータ データを定義できます。
ルールの入力パラメータが注文された製品のリストである場合からわかるように、パラメータ設定はフォームの形式で実行され、構造ツリーの形式での表示をサポートし、さまざまな形式の属性、オブジェクト、配列などのパラメータ設定。
アプリケーション データ: アプリケーションのビジネス データをルールで使用する必要がある場合があります。したがって、ルール開発プロセスでは、統合 SQL サービス、オーケストレーション サービス、オブジェクト操作サービスなどをサポートしてデータを取得し、これらのデータをルールの論理コンポーネントと組み合わせて適用できる必要があります。
この場合、商品優遇政策情報は、加盟店がシステム内に設定したデータに属する。Haozing Lingxi 開発プラットフォームでは、さまざまなオブジェクト操作コンポーネントをカプセル化するオブジェクト エンジンが組み込まれており、オブジェクト、アクション、条件を選択するだけで簡単に完了できるため、ルール ロジックの配置中に内部データを取得するのが非常に簡単です。以下の図に示すように、データ操作:
入力データとアプリケーション パラメーターに加えて、多くのルールの実装には外部データとシステム変数も関係します。
- 外部データ: このアプリケーションには存在せず、インターフェースを通じて取得する必要があるデータを指します。これは、外部インターフェイスの視覚的な統合、データへのアクセス、および操作をサポートする必要があります。
- システム変数：ログイン情報や環境情報などのシステム変数も論理的な判断には欠かせないデータです。したがって、これらの変数の操作を視覚的にサポートすることも重要な機能です。
ステップ 2 : 論理構成
ローコード プラットフォームでロジックを実装する方法は、データとアクションの組み合わせによって行われます。さまざまなロジック要件に対して、次のようなさまざまなロジック コンポーネントの構成を提供する必要があります。
比較: ルール ロジックの構成プロセス中に、ルール条件の定義を実現するための文字列、データ、属性、オブジェクト、配列の比較をサポートします。たとえば、2 つの文字列が等しいかどうかを判断する、データのサイズを比較する、オブジェクトに属性が存在するかどうかを判断する、または配列に特定の要素が含まれているかどうかを判断するなどです。
計算: データ計算、文字または配列の長さの計算など、さまざまな計算関数の設定を提供します。
プロセス制御：ループ、飛び出し、分岐、終了などの判定条件に応じてプログラムの実行経路を設定できます。
コンポーネントの合成: コンポーネントの実行順序を定義することで連結を実現し、コンポーネントの合成を可能にします。
マーチャントが設定した優遇ポリシー情報を取得し、商品に優遇ポリシーがあるかどうかを判断し、割引計算プロセスを実行するには、商品の優遇ポリシー情報を取得するための「データ コンポーネント」を設定するだけで済みます。優遇施策の有無を判断する「比較コンポーネント」と、割引計算を行うことで簡単にルールロジックの整理が完了します。
ステップ 3 : 結果のフィードバック
設定プロセスでは、ルールの戻りパラメータが明示的な方法で設定されるため、ルールの開発と理解が容易になります。
ステップ 4 : テスト検証
デバッグ中、実行されたノードが強調表示されて実行回路図が形成されます。各ノードの実行時間、期間、入力パラメータ、出力パラメータ、実行ステータスが実行順序に従って表示されるため、ルール実行プロセス中のトラブルシューティングに非常に優れた手段となります。
以上がルール設定の手順ですが、続いてルールの使い方を紹介していきます。
ビジネスルールの使用法
多くのシナリオでは、完全なビジネス検証を完了するには、ビジネス システムが複数のルールに合格する必要があります。商品の注文シナリオを例にとると、注文が送信される前にビジネス検証が実行され、数百もの検証ルールが存在する可能性があります。したがって、ルールのオープンコールをより適切に実現するには、ルールをルールイベントの次元でカプセル化し、同時に従来のアプリケーションとローコードアプリケーションの統合をサポートする必要があります。
まず、イベントの構成について説明します。イベントとは、ビジネス システムがルールを呼び出すタイミングやアクションを指します。これは、さまざまなコードでビジネス システムの埋もれた点を説明および区別するために使用され、同時に、システムのパラメータ要件を標準化するために使用されます。埋もれたポイント。イベント設定では主に次の 2 つの操作が完了します。
- パラメータ仕様定義：業務システムの要件に応じて、組み込みポイントのパラメータ仕様を各業務システムに合わせてカスタマイズします。同じイベントのすべてのルールは、統一されたパラメーター仕様に従います。
- ルール実行のポリシー オーケストレーション: 条件付き、シリアル、パラレルなどのさまざまなポリシーを含む、イベント内のルールの実行順序とポリシーのオーケストレーションをサポートします。
次に、ルールの統合です。さまざまなアプリケーションに応じて、ルールの統合には 2 つの方法があります。
- API メソッド: 従来のアプリケーションの場合、ルール イベントの呼び出しを実現するには、システム コードにポイントを埋め込む必要があります。
- サービス ノード方式: ローコード アプリケーションの場合、ビジネス ロジックは主にオーケストレーション サービスを通じて実装されます。したがって、オーケストレーション サービスでは、ルールの呼び出しを実現するために、「イベント」コンポーネントを介してイベント サービスのバインドをサポートする必要があります。
ビジネスルール管理
ルール管理には、ルール構成の開発とオープンな使用に加えて、ルールのリリースとオンライン、ルールの生成と障害管理、ルールのログ分析も含まれます。
リリースと起動: ローコード実装が異なればルールを保存する方法も異なり、通常は Java、PHP、または Python や Groovy スクリプトを使用してコンパイルされたファイルの形式で保存されます。Lingxi プラットフォームは、データをデータの形式で保存することを選択します。ルールを公開する場合、ルール データをエクスポートし、そのデータを実行環境にインポートするだけでルールのリリースを実現できます。環境の展開やコードのコンパイルと構築などの複雑な操作は必要ありません。この方法により、ルールの公開プロセスが簡素化され、開発効率が向上します。
発生/失敗の管理: ルールの設計では、ルールの有効時間と有効期限を設定でき、ルールは指定された期間内にのみ有効になります。この機能は、季節ルールや期間限定のプロモーション ルールで、有効期限が切れた後もルールが適用され続けることを回避し、不必要な競合や問題を回避するのに非常に役立ちます。同時に、ルールの生成・失敗状況の管理も非常に重要です。ルールの状態を制御することで、ビジネス要件に応じてルールの調整と意思決定を適時に実行できます。
ルール ログ: ログには、ルール管理において 2 つの重要な部分があります。まず、操作ログには、ルールの論理的な調整やステータスの変更などの操作が記録され、問題の追跡が容易になります。次に、操作ログには、入力パラメーター、出力結果、実行時間、ルール実行の時間のかかる原因や異常な原因が記録され、問題を迅速に特定して解決するのに役立ちます。
視覚的およびグラフィカルなルールの開発、使用、および管理機能をサポートすることに加えて、構成の効率性と構成の柔軟性にも重点を置く必要があります。
0 1 構成効率の問題
ルールを構成するプロセスでは、複雑さの異なるパラメータ オブジェクトによって構成効率が低下するため、複数ルールの開発シナリオが発生すると、効率の問題がさらに顕著になります。したがって、自動生成、デフォルトのデフォルト、ワンクリック操作、バッチ処理などを通じて効率の問題に対処するために、ツール自体の機能を強化する必要があります。
パラメータを自動的に生成する: イベント上で、ルール作成用のエントリを追加します。ルールの作成時に、イベントのパラメータ仕様を通じてルールのパラメータが自動的に生成され、パラメータを調整できるようになります。
自動パラメータ割り当て: ルール整理プロセスでの自動パラメータ割り当て機能を実現します。イベント ノードをサービス オーケストレーションに追加するとき、またはイベントにルールを追加するとき、コンテキストを自動的に照合し、パラメーター名に従って値を割り当てることができます。
ワンクリック メッセージ生成パラメータ: イベントおよびルールのパラメータを設定する場合、ワンクリック メッセージ生成パラメータ設定をサポートします。従来の開発プロセスでは、効率的な Ctrl+C および Ctrl+V を適切に適用できます。
ルールをバッチで追加する: イベント配置にバッチ ルール コンポーネントを追加します。このコンポーネントでは、複数のルールをバッチで選択してイベントに追加できます。グループ内でシリアルまたはパラレルなどのルール実行のポリシーを定義できます。これにより、イベント オーケストレーション キャンバスが簡素化されるだけでなく、ルールの追加効率も向上します。
運用およびメンテナンス ビューを増やす: イベントに関連付けルールのビューを追加し、ルール デザイナーに関連するイベント ビューを追加します。これにより、ルールを調整するときに影響範囲を明確に評価できるようになります。
0 2 構成の柔軟性の問題
従来のルール エンジンとは異なり、ローコード プラットフォームのルール実行戦略はイベント オーケストレーションを通じて実装されますが、実行プロセス中に、すべてのルール実行結果のマージ、同じイベントでのパラメーターの相互依存と共有などの問題が発生します。したがって、ルール結果の要約計算のサポート、イベントレベルのデータバスのサポート、データの共有と送信の実現が技術的に必要です。
ルール結果計算コンポーネントを追加します。ルールが追加または削除されるたびに、ルールの結果と戻りパラメータがコンポーネントに自動的に記録されます。このコンポーネントは、結果の戻り値を設定する戦略をサポートしています。たとえば、すべてのルールが正常に検証された場合に成功を返すか、ルールの 1 つが成功した場合に成功を返します。
イベントレベルの dataBus データ バスを導入します。データバスはイベント開始リンクで初期化され、イベント終了後にデータストレージスペースは破棄されます。このプロセス中に、各ルールはデータ概要にデータを書き込んだり、データ概要からデータを読み取ることができます。
複雑なビジネス ルールの開発のために、Haojing Lingxi 開発プラットフォームは非常に便利な開発ツールを提供し、多くのプロジェクトで使用されています。Haojing Lingxi 開発プラットフォームを通じて、開発者はルールの構成を簡単に完了でき、ビジネス ルールの視覚的な管理とグラフィカルな開発を真に実現し、開発効率を大幅に向上させ、非常に柔軟なリアルタイム リリースを実現できます。将来的には、大規模モデル技術との組み合わせを継続して、よりインテリジェントなビジネス ルール管理と意思決定支援、自動化されたルール検証と修正、ビジネス ルール実行と監視の組み合わせなどの技術的ブレークスルーを達成する予定です。期待される。