ビジネスルールエンジン

ビジネスルールエンジンは、ランタイム実稼働環境で1つ以上のビジネスルールを実行するソフトウェアシステムです。これらのルールは、法的規制（「従業員はいかなる理由でも、あるいは理由なく解雇される可能性があるが、違法な理由による解雇は認められない」）、企業ポリシー（「一度に100ドル以上購入するすべての顧客に10%の割引を提供する」）、またはその他のソースから派生する場合があります。ビジネスルールシステムにより、これらの企業ポリシーやその他の運用上の決定を、アプリケーションコードとは独立して定義、テスト、実行、保守できます。

ルール エンジンは通常、ルール、ファクト、優先順位 (スコア)、相互排他性、前提条件、およびその他の機能をサポートします。

ルール エンジン ソフトウェアは、通常、ビジネス ルール管理システムのコンポーネントとして提供され、他の機能の中でも、すべてのルールを登録、定義、分類、管理する機能、ルール定義の一貫性を検証する機能 (「ゴールド レベルのお客様は、注文数量が 10 を超える場合、送料無料の対象となります」および「シルバー レベルのお客様の最大注文数量 = 15」)、異なるルール間の関係を定義する機能、これらのルールの一部を、影響を受ける、または 1 つ以上のルールを適用する必要があるITアプリケーションに関連付ける機能を提供します。

ITユースケース

あらゆるITアプリケーションにおいて、ビジネスルールはアプリケーションコードの他の部分よりも頻繁に変更される可能性があります。ルールエンジンまたは推論エンジンは、ビジネスルールアプローチによってアプリケーションコードから外部化または分離されたビジネスルールを実行する、プラグ可能なソフトウェアコンポーネントとして機能します。この外部化または分離により、ビジネスユーザーはIT部門の介入なしにルールを変更できます。システム全体は、このような外部ビジネスルールへの適応が容易になりますが、QAやその他のテストの通常の要件が排除されるわけではありません。

歴史

Computerworldの記事では、ルールエンジンの起源は1990年代初頭に遡り、Pegasystems、Fair Isaac Corp、ILOG [ 1 ] 、 SapiensのeMerge [ 2 ]などの製品に遡るとされています。

デザイン戦略

多くの組織におけるルール設計の取り組みは、一般的にワークフロー設計と考えられている側面と従来のルール設計の側面を組み合わせたものです。この2つのアプローチを分離できないことで、ビジネスルールとワークフローの両方を再利用・制御する能力に問題が生じる可能性があります。このジレンマを回避する設計アプローチでは、ビジネスルールとワークフローの役割を以下のように分離します。[ 3 ]

  • ビジネス ルールは知識を生み出します。
  • ワークフローはビジネス作業を実行します。

具体的には、ビジネスルールは、ビジネス状況の発生を検知してビジネスイベント（通常はメッセージングインフラストラクチャを介して伝達される）を発生させたり、より高次のビジネス知識（例えば、ローンが引受基準を満たしているかどうかに関する組織、製品、規制に基づく一連のルールを評価するなど）を作成したりします。一方、ワークフローは、ルーティングポイントの過負荷などを示すイベントに応答し、一連のアクティビティを開始します。

この分離は重要です。なぜなら、同じビジネス判断（住宅ローンが引受基準を満たしている）やビジネスイベント（ルーターが過負荷になっている）に対して、複数の異なるワークフローが対応できるからです。ルール駆動型の知識創造への対応として行われる作業をルール自体に組み込むと、ビジネスルールがワークフロー固有のものになり、組織全体でのビジネスルールの再利用性が大幅に低下します。

ビジネスルールエンジンを採用したアーキテクチャを構築するには、イベントに応答したり、ビジネスルールによって定義されたビジネス判断を検証したりするプロセスを基盤とするBPM（ビジネスプロセス管理）プラットフォームとBRM（ビジネスルール管理）プラットフォームの統合を確立することが不可欠です。市場には、この統合をネイティブに提供する製品がいくつかあります。場合によっては、この種の抽象化と統合は、特定のプロジェクトまたは組織内で開発する必要があります。

ほとんどの Java ベースのルール エンジンは、さまざまなアプリケーションとの統合を可能にするために、JSR-94アプリケーション プログラミング インターフェイス(API) 標準に基づいた技術的な呼び出しレベルのインターフェイスを提供し、多くのルール エンジンは、 WSDLやSOAPなどの Web ベースの標準を通じてサービス指向の統合を可能にします。

ほとんどのルールエンジンは、ルールの対象となるビジネスエンティティとリレーションシップを表すデータ抽象化を開発する機能を提供しています。このビジネスエンティティモデルは通常、 XML、POJO、フラットファイルなど、様々なソースから取得できます。ルール自体を記述するための標準言語は存在しません。多くのエンジンはJavaライクな構文を使用していますが、ビジネス向けのカスタム言語を定義できるエンジンもあります。

ほとんどのルールエンジンは呼び出し可能なライブラリとして機能します。しかし、RDBMSの動作に似た汎用プロセスとして実行されることがますます普及しつつあります。ほとんどのエンジンはルールをプロセスインスタンスにロードされる設定として扱いますが、中にはルール実行インスタンス全体のコードジェネレーターとして機能するものや、ユーザーが選択できるものもあります。

ルールエンジンの種類

ルールエンジンには様々な種類があり、一般的にはルールの実行スケジュール方法が異なります。

企業が使用するルール エンジンのほとんどは前向き連鎖であり、さらに次の 2 つのクラスに分類できます。

  • 最初のクラスは、いわゆる生成/推論ルールを処理します。これらのタイプのルールは、IF条件THENアクション型の振る舞いを表現するために使用されます。例えば、このようなルールは、「IF some-condition THEN allow-customer-a-mortgage」という形式のルールを実行することで、「この顧客に住宅ローンを許可すべきか？」という質問に答えることができます。
  • もう一方のタイプのルールエンジンは、いわゆるリアクション／イベント条件アクションルールを処理します。リアクティブルールエンジンは、受信したイベントを検出して反応し、イベントパターンを処理します。例えば、リアクティブルールエンジンは、特定の商品が在庫切れになった場合にマネージャーにアラートを通知するために使用できます。

これらのタイプの最大の違いは、プロダクションルールエンジンはユーザーまたはアプリケーションが呼び出したときに実行され、通常はステートレスな方法で実行されることです。一方、リアクティブルールエンジンはイベント発生時に自動的に反応し、通常はステートフルな方法で実行されます。多くの（そして実際にはほとんどの）一般的な商用ルールエンジンは、プロダクションルールとリアクションルールの両方の機能を備えていますが、どちらか一方のクラスに重点を置いている場合もあります。例えば、ほとんどのビジネスルールエンジンは主にプロダクションルールエンジンですが、複合イベント処理ルールエンジンはリアクションルールに重点を置いています。

さらに、一部のルールエンジンは後方連鎖をサポートしています。この場合、ルールエンジンは特定の目標に適合するようにファクトを解決しようとします。既存の情報に基づいて何かが存在するかどうかを判断しようとするため、 ゴールドリブン型と呼ばれることがよくあります。

別の種類のルール エンジンでは、推論の実行中にバック チェーンとフォワード チェーンを何回か自動的に切り替えます。たとえば、Web 検索で見つけることができるインターネット ビジネス ロジック システムなどがあります。

ルールエンジンの4番目のクラスは、決定論的エンジンと呼ばれるかもしれません。これらのルールエンジンは、前向き連鎖と後向き連鎖の両方を放棄し、代わりにドメイン固有言語アプローチを用いてポリシーをより適切に記述します。このアプローチは実装と保守が容易な場合が多く、前​​向き連鎖や後向き連鎖のシステムよりもパフォーマンス上の利点があります。

ファジー論理に基づく推論がより適切な状況もあり、そのような状況では、ブールルールではなくヒューリスティックがルール処理に用いられます。例としては、顧客分類、欠損データ推論、顧客価値計算などが挙げられます。DARL言語[ 4 ]と関連する推論エンジンおよびエディタは、このアプローチの一例です。

アクセス制御/承認のためのルールエンジン

ルールエンジンの一般的なユースケースの一つは、アプリケーションへの標準化されたアクセス制御です。OASISは、アクセス制御専用のルールエンジンアーキテクチャと標準であるXACML （eXtensible Access Control Markup Language）を定義しています。XACMLルールエンジンとビジネスルールエンジンの主な違いの一つは、XACMLルールエンジンはステートレスであり、データの状態を変更できないことです。ポリシー決定ポイント（PDP）と呼ばれるXACMLルールエンジンは、例えば「アリスはドキュメントDを閲覧できますか？」といった二者択一のYes/Noの質問を受け付け、許可/拒否といった決定を返します。

参照

参考文献

  1. ^ 「あなたの会社のビジネスルールがすべてどこにあるのか知っていますか？」 Computerworld . 39 ( 21). IDG Enterprise (2005年5月23日発行): 25. 2005年5月23日. ISSN 0010-4841 . 2014年2月2日閲覧.ルールエンジンは、マサチューセッツ州ケンブリッジのPegasystems Inc.、ミネアポリスのFair Isaac Corp.、カリフォルニア州マウンテンビューのILOGなどの企業が販売していた1990年代初頭から存在していました。ルールエンジンは、主に金融や保険など、ルールを多用する業界で使用されていました。しかし、ここ数年で多くのベンダーが市場に参入し、ビジネスオペレーションの柔軟性を高める手段としてルールエンジンに注目する企業が増えています。 
  2. ^ 「eMerge ルールベースのソフトウェア開発プラットフォーム」。
  3. ^ルール エンジンはイベント駆動型ですか? http://www.sapiens-tech.com/iDuneDownload.dll?GetFile?AppId=225&FileID=216581&Anchor=&ext=.pdfから取得。2018 年 9 月 30 日、 Wayback Machineにアーカイブ。
  4. ^ 「DARL言語」 。 2018年9月1日時点のオリジナルよりアーカイブ。2018年9月1日閲覧。

参考文献

「 https://en.wikipedia.org/w/index.php?title=Business_rules_engine&oldid=1225758095」より取得