最新のビジネスルールエンジンの構築方法、簡単な概要

4月 22, 2021

admin

これはビジネスルールエンジンアーキテクチャの高レベルの概念的な概要です。実際のコードの上にあります。ビジネスルールエンジンを構築している場合、このテキストが役に立つ可能性があります。それは、通常のソフトウェアアプリケーションから、スケーラビリティ、保守性、および拡張性の厳しい要件を満たす高度で複雑なソリューションへの道でした。このテキストでは、ビジネスルールエンジンが何であるかの概要を説明し、この種のソフトウェアを構築する際に考慮すべき最新のアプローチの 1 つについて説明します。

まず始めに、基本用語を定義しておくことが重要です。ビジネスルールエンジンは、この業界ではかなり長い間、何らかの形で存在しており、これから使用するほとんどの用語について、いくつかの定義が与えられています。まず「ビジネス・ルール」から始めましょう。この用語にはよく知られた定義があります。ビジネスルール」とは、

ビジネスのある側面を定義または制約するステートメントです。ビジネス構造を主張したり、ビジネスの行動を制御または影響することを目的としている。モーガン、ビジネスルールと情報システム。ボストン。 Boston: Addison-Wesley Publishing, 2002

ビジネスルールは非常に広い範囲を持ち、ビジネスのあらゆる側面に適用される可能性があります。たとえば、「顧客が来たら、暖かい笑顔と親しみやすい「こんにちは」で挨拶する」というルールは、会社の従業員が顧客と会うときに適用されます。また、企業内の特定の役割によるルーチンワークの解決方法を定義したり、制約したりすることもある。 CRM システムのようなソフトウェアソリューションが着実に普及し、さまざまなビジネス領域にソフトウェアが完全に統合されたことで、大半のビジネスプロセスは部分的または完全にデータ指向になっています。例えば、「お客様が当店で商品を購入されたら、後日、関連商品を購入されるかどうか電話で問い合わせる」というビジネスルールが、「お客様が当店のオンラインストアで商品を購入されたら、後日、関連商品のリストをメールで送信する」というように、ビジネスルールがソフトウェア指向に変化しているのである。現在、多くの企業が日常業務でデータを扱っています。あらゆる規模のビジネスの大半が、ビジネス活動にソフトウェアソリューションを統合していることを考慮すると、「ビジネスルール」という用語の定義は、T. Morgan による前述の定義に明確化（太字部分）を追加することによって、より具体的に定義することができます。ビジネス構造を主張したり、ビジネスの動作を制御または影響することを目的としています。これは、永続的なストレージにデータ構造として格納され、ビジネスロジックのアトミックパッケージを保持します。

「ビジネスルール」という用語を定義した上で、「ビジネスルールエンジン管理システム」（BRMS）という用語は次のように定義されます：

BRMS とは、ビジネスルールを管理（保存、編集、削除など）し、企業のビジネスプロセスに適用するためのソフトウェアソリューションです。

スタンドアロン型の商用 BRMS は、ライセンスの購入と企業の IT インフラへの統合に非常に費用がかかるため、ビジネスプロセスやその他の種類のプロセスの自動化の必要性が生じた場合、企業はしばしば社内ソリューションを導入します。ビジネスの成功は、そのビジネスルールと、これらのビジネスルールがいかにうまく管理され適用されているかに左右されることがあります。

ビジネスルールデータ構造

ビジネスルールは、一連の原子コマンドとして表現することができます。コマンドは、条件付きデータ解析、時間待ちコマンド、アクション実行コマンドなどを含むことができる。ビジネス・ルールの例では、「顧客がオンライン・ストアで何かを購入したら、後で他の関連商品のリストを電子メールで送る」というのが一般的で良い例であり、他の多くのビジネス・ルールも非常に似た論理構造を持つことができる。

ルール処理フローは、購入が行われると開始し、「購入者に関連商品の提案メールを送信」コマンドを実行することでいくつかのビジネスロジックが適用されます。購入者が電子メールの購読を無効にしていることがあります。

コマンドは結果として実行され、現在データ分析コマンドがあり、購入者が有効なメール購読を持っているかを確認します。もしそうなら、ビジネスルールの次のコマンドの実行に進みます。

購入者は SMS の購読も持っている可能性があり、それがアクティブであれば、「関連するキャンペーンを含む SMS を送信する」という別のコマンドもあるはずです。これにより、ビジネスルールロジックに分岐が導入されます。

ルールの分岐は、互いに独立して処理されます。条件評価コマンドで一方の枝の処理を停止し、別の枝を最後まで処理してもよい。

ビジネスルールを表現するためのBRMSクライアント側アプリケーションのUIは、さまざまな方法で実装できます（どんな種類のツリーグラフィカル表現も機能します）。

ビジネスルール・データ構造は、有向根木グラフ（無向グラフを基礎として木を持った有向無サイクルグラフ）である。ビジネスルールグラフの頂点は、データ解析コマンド、アクション実行コマンド、時間待ちコマンドなど、さまざまな種類のコマンドで表現される。すべての有向根アウトツリーには、ルート（すべてのエッジがそこから伸びている頂点）があります。したがって、すべてのルールは、特別な頂点（グラフ理論でいうところのルート頂点）、つまりルール処理の入口を指定する頂点から始まる。

CRUD 操作によるビジネスルールデータ構造

データ構造は有向根木で表され、他の種類のグラフではないので、RDBMS で一般的なグラフ構造を保存する際に生じる不都合から解放されます (頂点と辺を別々のテーブルに保存すると、単一のルールを検索するための検索回数が増加する場合がある、等々)。 BRMS の通常の運用では、データの検索は、挿入、更新、削除などの他の操作よりもはるかに頻繁に行われることが明らかであるため、これは非常に重要です。これは、コマンドのタイプ、説明、およびその他の補足データなどの属性を持つレコードとして、RDBMS テーブルに保存されます。ツリーでは、すべての頂点は1つだけの親を持つ（親を持たないルート頂点を除く）ので、すべてのレコードは親頂点のIDを保持する必要がある。また、ビジネス・ルールに関連するデータを含むルール・レコードを格納する別のテーブルを用意すると便利である。このアプローチでは、どんな複雑なビジネスルールのデータ構造を格納しても問題はありません。

CRUD 操作はかなり単純です。ビジネスルールの変更には、ルールまたはコマンドのいずれか、または両方のテーブルの更新が必要な場合があります。コマンドを削除または挿入する場合、コマンド間の参照を維持する必要があります (これは本質的にツリーへのノードの削除または挿入です)。

BRMSコンポーネントの1つ (マネージャーと呼びましょう) が、前述のデータベース操作を行い、ビジネスルールのCRUD操作用のAPIを提供します。それは、ユーザーがログインした、購入が行われた、いくらかの金額が送金されたなど、何でもあり得る。このようなアクティビティはトラッキングされ、BRMSは何らかのトランスポートを介してそれについて通知される必要がある。 AMQP はおそらくこの種のタスクに最も適しています。

1. 全体のコンセプトは、マイクロサービス・アーキテクチャで構築されています。ビジネスイベントコンシューマーマイクロサービスは、キューを宣言し、RabbitMQ交換サーバー上の特定の交換にそれをバインドすることによって、すべてのビジネスイベントをリッスンします。メインソフトウェアシステムでビジネス活動（重要であると見なされ、追跡される）が発生すると、メッセージがRabbitMQエクスチェンジサーバーに送信されます。これは、何が起こったかについての情報だけでなく、いくつかの関連する補足データも保持しています。ビジネスイベントは、メッセージで渡された任意の種類の属性で識別するか、ルーティングキーとして使用することができます。メッセージは、次にBRMSビジネスイベントコンシューマママイクロサービスによって消費される。

2. ビジネスイベントコンシューマーマイクロサービスがメインソフトウェアシステムからメッセージを取得すると、それは、ビジネス活動イベントに適したルールトリガを持っているデータベース内の任意のビジネスルールがあるかどうかにマネージャマイクロサービスにクエリを実行します。そして、そのような一致するビジネスルールがある場合、マネージャマイクロサービスはビジネスイベントコンシューマママイクロサービスに初期コマンドデータを返します。マネージャからのこのデータの取得はgRPCを介して行われ、破線で可視化されます。

3. マネージャマイクロサービスが最初のコマンドデータで応答するとすぐに、ビジネスイベント消費者マイクロサービスはビジネスルールの処理を開始する準備ができています。ビジネスイベントコンシューマは、初期コマンドデータ（マネージャマイクロサービスから受信）とメインソフトウェアシステムから受信したビジネスイベントからのデータをカプセル化した別のメッセージを形成します。これは、AMQPを介して内部のBRMS交換に送信されます。メッセージのルーティングキーはコマンドタイプに対応します。

4. 最初のコマンド処理マイクロサービスはメッセージを消費します（ルーティングキーinitialのメッセージが積み重なるキューをリッスンします）。次に、ロジックを実行し（基本的に初期ブロックにはロジックがありません）、ビジネスルールに後続のコマンドがあるかどうかマネージャに問い合わせます（これらは、parent_idが現在処理中のコマンドのidと等しいコマンドです）。そして、もしあれば、次のコマンドデータを受信し、ビジネスイベントデータと次のコマンドデータの両方を内部のRabbitMQサーバーに送信します。そう、今はリンクリスト・トラバーサルに見え、ルールにブランチがあるとツリー・トラバーサルになるのですこのように、ビジネスルールはコマンドごとに処理されます。ここでもう一つ重要なことは、このコンテキストでは、ビジネス・イベント・データがすべての子コマンドに渡されることです。これは、ビジネス・ルールのユニークな実行のコンテキストです。

説明のために、例のルールが、初期コマンド -> 条件付きデータ分析コマンド -> ビジネスアクションコマンドという構造になっていると仮定してみましょう。

5. 解析コマンド処理系は、内部交換からルーティングキーanalysisを持つメッセージを消費します。ビジネスルールの分析コマンドに記述された条件と、ビジネスイベントデータを用いた評価に基づいて、ルール実行フローはここで継続または停止することができる。停止した場合、それ以降のビジネスルールコマンドは実行されない。実行フローが継続する場合、分析コマンドプロセッサは、次のビジネスルールコマンドをマネージャに問い合わせ、それらを取得し、内部交換サーバに別のメッセージを発行する

6. 最後に、内部交換にメッセージがあり、それはアクションコマンドプロセッサが消費する準備ができています。ビジネスルールの実行フローがこのコマンドまで来たということは、ルールのこのブランチにおいて、データ分析コマンドにあったすべての条件が真であり、実行フローが中断されなかったことを意味する。アクションコマンド処理系では、電子メールの送信などのアクションを実行する。

このようなグラフの走査は深さ優先であり、2つ以上の子コマンドを持つコマンドに遭遇すると、記述したシステムでのビジネスルール処理の非同期性により、すべてのブランチで同時に深さ優先の走査が開始される。

Scaling

The described approach allows a great separation of concerns only not also may save a lot of money when it comes to pay the IaaS bills. エンドユーザーは、さまざまな種類のさまざまな数のコマンドとさまざまな数の分岐を持つ、さまざまなビジネスルールを作成します。しかし、一般的なスケーリングシナリオは次のとおりです。
1. ビジネスイベントの数が増える-ビジネスイベントコンシューマがスケールアップする
2.ビジネスイベントによって関連付けられた（トリガされた）ビジネスルールの数が増える-初期コマンドプロセッサがマネージャとともにスケールアップする
3.ビジネスルールに多くの分析コマンドがある-分析コマンドプロセッサがスケールアップする
4. 実行しなければならないアクションコマンドが多すぎる-アクションコマンドプロセッサがスケールアップする

Reliability

システムの血管は輸送機関である。システムが高負荷下で動作を維持するためには、内部のメッセージ交換が高い信頼性を持つ必要があります。 RabbitMQはクラスタリングを提供し、信頼性の要求をよく満たしている（https://www.rabbitmq.com/clustering.html）。

その他のコマンドタイプ

その他のビジネスロジックは、システムに導入することができます。人気があり、要求の多いコマンド・タイプの1つは、時間待ちコマンドです（例：「45分間待ってから続ける」）。時間待ちコマンドの導入により、ビジネスルールの処理はしばらく中断される可能性があるため、リアルタイム処理ではなくなった。このような変更には、コマンド・プロセッサの追加と、この文章の範囲外であるデータ構造への若干の調整が必要です。時間をいじることは難しく、スケジュールと時間を操作するサービスを書くことは困難です。以下に良い例を挙げます。 https://github.com/nextiva/krolib

サードパーティ製の代替品

ルールエンジン/ワークフローエンジンのよく知られた代替品がありますが、そのうちのトップ 3 (IMHO) を紹介します。 Comunda – 成熟した製品で、コミュニティ版と企業版があり、使用することができます。
2. Luigi – Spotify が社内用に開発したワークフローエンジンツールですが、すでに他の多くの企業で使用されています。
3. Apache Airflow – これも有名な製品で、能力、便利さ、カスタマイズ可能性が証明されています。

これらのツールをまとめると、すべてビジネスルールまたはワークフローを表すデータ構造としてダイレクト非循環グラフを使用していることです。

注目に値する製品は他にもあるかもしれませんが、調査はこの 3 つから始めるべきでしょう。社内のシステムを手に入れるだけでなく、ビジネスの特定の要件に従って構築されるからです。信頼性、拡張性、監視を維持するためには、優れたDevOpsチームが不可欠です。結局のところ、あなたは誇れる素晴らしい製品を手に入れることができるのです

。