4 ルールセットとルールの使用

ルールセットはOracle Business Rulesデータ・モデル要素で、1つ以上のルールまたはデシジョン表をグループ化するために使用します。ディクショナリ、ネスト・テスト、単純およびツリー・モードのルール、式ビルダーの使用方法を学習します。

詳細は、「ルールセットとは」を参照してください。

4.1 ルールセット、ルールおよびビジネス・フレーズの使用の概要

ビジネス・ルールを使用して、ビジネスの重要な意思決定やポリシーを定義します。

これらの意思決定およびポリシーの例を、次に示します。

  • ビジネス・ポリシー: 消費ポリシーおよび承認マトリックスなど

  • 制約: 有効な構成や規制上の要件など

  • 計算: 割引、割増またはスコアなど

  • 判断機能: 顧客の額に基づくオファーなど

Oracle Business Rulesでは、ルールの作成に複数の方法が用意されています。

  • IF/THENルール: ルールはIF/THEN文で示されます。IF/THENルールには2つのモデル化方法があります。一般的なルールでは、擬似コード言語を使用して、ルール・ロジックを表します。動詞ルールでは、自然言語文を使用してルール・ロジックを表します。

  • デシジョン表では、複数の関連するルールがスプレッドシート形式の単一ビューに表示されます。

ビジネス・フレーズは、動詞ルールのテストおよびアクションの構成のための自然言語のボキャブラリの提供に使用されます。一般ルールでは使用されません。

この章には、IF/THENルールの使用の詳細も含まれています。デシジョン表の使用の詳細は、「デシジョン表の使用」を参照してください。

4.2 ルールセットの使用

ルールセットは、ルールおよびデシジョン表の実行単位となります。また、ルールの共有単位でもあり、ルールはルールセットに属します。複数のルールセットを順番に実行できます。この処理は、ルール・フローと呼ばれます。順序はルールセット・スタックによって決まります。この順序は、ルールセットをスタックにプッシュおよびスタックからポップするルール・アクションによって操作できます。ルールセットでは、ルール優先度によって、ルールを起動する順序が指定されます。

ルールセットには、ルールセットがいつアクティブになるのかを制御する有効日指定も含まれています。ルールセットは次のようにすることができます。

  • 常にアクティブ

  • 時間範囲中はアクティブ

  • 日付範囲中はアクティブ

  • 時間および日付範囲中はアクティブ

4.2.1 ルールセットの作成方法

ルールおよびデシジョン表はすべて、ルールセット内に作成されます。ルールセットにより、ルールとデシジョン表が1つの実行単位として編成されます。

ルール・セットを作成するには、次のようにします。

  1. ルール・デザイナで、「ルールセット」タブに移動します。
  2. 「ルール・セットの作成」ボタンをクリックします。これにより、「ルール・セットの作成」ダイアログが表示されます。
  3. 「名前」フィールドに名前を入力します。

    ノート:

    ルールセットとルールセット別名、ビジネス・ルール、およびその他のルール・オブジェクトの名前は、文字で始まる必要があり、文字と数値のみを使用できます。スペース、または.-_:,""などの特殊文字は使用しないでください。
  4. 「説明」フィールドに説明を入力します。
  5. 「OK」をクリックします。

4.2.2 ルールセットの有効日の設定方法

有効日のサポートにより、ルールセット、ルールまたはデシジョン表の開始日と終了日を指定できます。ルールセットの場合、有効日では、ルールセット内のルールおよびデシジョン表が有効な日付の範囲を定義します。有効日の詳細は、「Date Facts_ Date Functions_の使用および有効日の指定」を参照してください。

ルールセットの有効日を設定するには:

  1. 「ルールセット」タブから、ルールセット名を選択します。
  2. 図4-1に示すように、ルールセット名の横にあるナビゲーション・ボタンをクリックしてルールセット情報を開き、ルールセットの「名前」「説明」および「有効日」フィールドを表示します。

    図4-1 「有効日」フィールドが表示されているルールセット

    図4-1の説明が続きます
    「図4-1 「有効日」フィールドが表示されているルールセット」の説明
  3. 「有効日」エントリを選択します。図4-2に示すように、「有効日の設定」ダイアログが表示されます。

    図4-2 「有効日の設定」ダイアログの使用

    図4-2の説明が続きます
    「図4-2 「有効日の設定」ダイアログの使用」の説明
  4. 「有効日の設定」ダイアログを使用して、ルールセットの有効日を指定します。「日付の設定」ボタンをクリックすると、「開始」および「終了」フィールドのデータ入力に役立つカレンダが表示されます。

ルールセット、ルールまたはデシジョン表の有効開始日または有効終了日、あるいはその両方を指定できます。ルールセットの有効日を指定する方法は、「ルールセットの有効日の設定方法」を参照してください。

4.2.3 ルールの有効日の設定方法

ルールの有効開始日または有効終了日、あるいはその両方を指定できます。

ルールの有効日を設定するには:

  1. 「ルールセット」ナビゲーション・タブで、ルールセット名を選択します。
  2. ルールセット内のルールを選択します。
  3. ルール名の横にある「詳細設定の表示」をクリックします。
  4. 「有効日」フィールドを選択します。「有効日の設定」ダイアログが表示されます。
  5. 「有効日の設定」ダイアログを使用して、ルールの有効日を指定します。「日付の設定」ボタンをクリックすると、「開始」および「終了」フィールドのデータ入力に役立つカレンダが表示されます。
  6. 「有効日の設定」ダイアログで、「OK」をクリックします。

4.2.4 フィルタを使用してルールセット内で一致するルールを表示する方法

ルールセット内のルール数が増加するにつれて、ルール・リストのナビゲートが困難になる可能性があります。ルール・デザイナに対して、ルール・リストをフィルタして必要なルールのみを表示するように指示できます。たとえば、アクティブなルールのみ、または検証警告のあるルールのみを表示できます。

ルール作成の詳細は、「ルールの使用」を参照してください。

フィルタを使用してルールセット内で一致するルールを表示するには:

  1. Rules Designerで、「ルールセット」ナビゲーション・タブからルールセットを選択します。

  2. ルールのフィルタ設定を表示するには、図4-3に示すように、ルールセット名の横にある「フィルタ問合せの表示」をクリックします。

    図4-3 ルール・セットでのフィルタ問合せの表示または非表示

    図4-3の説明が続きます
    「図4-3 ルール・セットでのフィルタ問合せの表示または非表示」の説明
  3. 「フィルタ問合せ」フィールドで「<テストの挿入>」をクリックしてデフォルトのテストを挿入します。

  4. デフォルトのテストを構成します。

    この場合、図4-4に示すように、「<オペランド>」をクリックすると、表4-1に示すルール固有のオプションから選択できます。

    表4-1 ルールのフィルタ問合せのオペランド

    オペランド 説明

    name

    ルール名と照合します。

    description

    ルールの説明と照合します。

    priority

    ルールの優先度と照合します。詳細は、「ルールの優先度の設定方法」を参照してください。

    start date

    ルール開始日と照合します。詳細は、「有効日に関する必知事項」を参照してください。

    end date

    ルール終了日と照合します。詳細は、「有効日に関する必知事項」を参照してください。

    minutes until start date

    ルール開始日までの指定の時間(分)と照合します。詳細は、「有効日に関する必知事項」を参照してください。

    minutes until end date

    ルール終了日までの指定の時間(分)と照合します。詳細は、「有効日に関する必知事項」を参照してください。

    days until start date

    ルール開始日までの指定の日数と照合します。詳細は、「有効日に関する必知事項」を参照してください

    days until end date

    ルール終了日までの指定の日数と照合します。詳細は、「有効日に関する必知事項」を参照してください

    years until start date

    ルール開始日までの指定の年数と照合します。詳細は、「有効日に関する必知事項」を参照してください

    years until end date

    ルール終了日までの指定の年数と照合します。詳細は、「有効日に関する必知事項」を参照してください

    is active

    ルールがアクティブかどうかと照合します。詳細は、「アクティブ・オプションの選択方法」を参照してください。

    is valid

    ルールに検証警告があるかどうかと照合します。詳細は、「ルール検証」を参照してください。

    referenced fact types

    1つ以上のファクト・タイプと照合します。

    図4-4 フィルタ問合せのオペランド

    図4-4の説明が続きます
    「図4-4 フィルタ問合せのオペランド」の説明

    詳細は、「動詞ルールでのテストの定義方法」を参照してください。

  5. 演算子を選択し、比較演算子を選択します。たとえば、名前についてはオペランド・リストから「次を含む」を選択できます。

  6. フィルタ・テストの右の比較オペランドを入力します。たとえば、文字列Policyを入力します。

  7. フィルタ問合せが完成した後、フィルタをルールセット内のルールに適用できます。

    1. フィルタを適用にするには、「フィルタ・オン」チェック・ボックスを選択します。

      ルール・デザイナでは、図4-5に示すように、フィルタ問合せに一致するルールのみが表示されます。

      図4-5 ルール・セットでのフィルタ問合せの有効化

      図4-5の説明が続きます
      「図4-5 ルール・セットでのフィルタ問合せの有効化」の説明
    2. フィルタ問合せを無効化するには、「フィルタ・オン」チェック・ボックスをクリアします。

      ルールセット内のすべてのルールが表示されます。

    3. フィルタ問合せを削除するには、それを選択し、[Del]を押すか「フィルタのクリア」をクリックします。

4.2.5 リストからコンポーネント値を選択するときのオート・コンプリートの使用

ルール・デザイナを使用すると、ビジネス・ルールの次のコンポーネントの値を簡単に設定できます。

  • 条件

  • オペランド

  • アクション

これらのコンポーネントを編集するには、Rules Editorでそのコンポーネントをクリックして、ドロップダウン・リストまたはツリーから必要な値を選択します。リストの最上部にあるテキスト領域に、必要な値の名前を入力することもできます。テキストの入力を開始すると、図4-6のように、オプションのリストがフィルタされます。

図4-6 オート・コンプリート機能の使用

図4-6の説明が続きます
「図4-6 オート・コンプリート機能の使用」の説明

この図では、入力したテキストで始まるオプションのみが表示されています。

4.3 ルールの使用

ファクトを処理し、Oracle Business Rulesで処理できる暫定的な結論を取得するためのビジネス・ルールを作成します。ルールセット内にルールを作成するため、ルールを使用する前にルールセットを作成する必要があります(または、デフォルトのルールセットを使用します)。

ルールセット作成の詳細は、「ルールセットの使用」を参照してください。

ルールは、設計時にテストでき、アプリケーションをデプロイする必要はありません。詳細は、「ルール関数を使用したデシジョン関数のテスト」を参照してください。

ルール・デザイナのルール検証は、不適切または不完全なルールについて警告が表示されるため、ルールを使用する際に役立ちます。検証ログ・ウィンドウを表示するには、「検証」ボタンをクリックするか、または「表示」→「ログ」を選択して、「ビジネス・ルール検証」タブを選択します。ルールをテストまたはデプロイする前に、すべての警告を修正する必要があります。ルール検証の詳細は、「ルール検証」を参照してください。

ルールセット内のルール数が増加するにつれて、ルール・リストをフィルタして必要なルールのみを表示するようにルール・デザイナを構成できます。詳細は、「フィルタを使用してルールセット内で一致するルールを表示する方法」を参照してください。

4.3.1 一般的なルールの追加方法

一般的なルールを作成するには、まずルールをルールセットに追加してから、テストとアクションを挿入します。アクションはパターン照合に関連付けられます。実行時に、ルールの「IF」領域にあるテストが一致すると、Rules Engineにより「THEN」のアクションがアクティブ化され、ルールに関連付けられているアクションの実行が準備されます。

デフォルトでは、ルール・デザイナによって、一致するファクトごとに起動されるルールが作成されます。同じファクト・タイプが2回以上一致するか、まったく一致しないというルールなど、他のオプションを有効化するには、「拡張モード」を選択します。拡張モードおよび詳細設定の表示の詳細は、「ルールおよびデシジョン表での詳細設定の使用」を参照してください。

ルールセットに一般的なルールを追加するには:

  1. ルール・デザイナで、「ルールセット」タブを選択し、「+」をクリックします。
  2. 「概要」タブの「一般的なルール」パネルで「+」をクリックします。または、「一般的なルール」タブで、「ルールの作成」または「作成」(「+」)をクリックします。

    たとえば、図4-8に示すように、「ルールの作成」をクリックしてRule_1という名前のルールを追加します。

    図4-7 ルール・セットへのルールの追加

    図4-7の説明が続きます
    「図4-7 ルール・セットへのルールの追加」の説明

    ノート:

    ルールは、ルール・エディタ領域からのみ「削除」ボタンをクリックして削除してください。ルールは、左側のツリー・ナビゲーションから削除すると正確に削除されません。

4.3.2 動詞ルールの追加方法

動詞ルールは、一般的なルールと類似した形式で作成され、実行されます。ただし、いくつかの相違があります。

動詞ルールを作成するには、まずルールをルールセットに追加してから、テストとアクションを挿入します。動詞ルールを定義する際は、ビジネス・フレーズを追加します。これは、システムから自動的に導出することも、ユーザーが定義することもできます。ビジネス・フレーズは、ルールを記述する前でも後でも定義できます。

動詞ルールでは、拡張モードもツリー・モードもサポートされていません。

ルールセットに動詞ルールを追加するには:

  1. ルール・デザイナで、「ルールセット」タブを選択し、「+」をクリックします。
  2. 「概要」タブの「動詞ルール」パネルで「+」をクリックします。または、「動詞ルール」タブで、「動詞ルールの作成」または「作成」(「+」)をクリックします。

    たとえば、図4-8に示すように、「動詞ルールの作成」をクリックしてVerbalRule1という名前のルールを追加します。

    図4-8 ルール・セットへの動詞ルールの追加

    図4-8の説明が続きます
    「図4-8 ルール・セットへの動詞ルールの追加」の説明

4.3.3 ルールでのテストの定義方法

ルール内でテストを作成するには、ファクトに対する条件を追加します。たとえば、年間消費額プロパティを持つCustomerOrderサンプル・ファクトを使用し、顧客に関連付けられている年間消費額に基づいて、顧客の注文が高額消費に関連付けられているかどうかを判別するテストを追加できます。値セットを使用して、ルール内のテストおよびアクションの値を制限できます。詳細は、「値セットをルールのオプション値の制約として使用する方法」を参照してください。

図4-9に、このサンプル・ルールを示します。

図4-9 ルールへのテストの追加

図4-9の説明が続きます
「図4-9 ルールへのテストの追加」の説明

実行時には、このルールが処理される際に、Rules Engineにより、一致するファクトを検索するように定義したルール・パターン・テストを基準にしてファクトがチェックされます。このサンプル・ルールRule_1の場合、ファクトが一致すると、Rules Engineによりファクトが変更されて、値プロパティが「High」に変更されます。

ルール内でテストを定義するには:

  1. ルール・デザイナで、「ルールセット」タブから「+」をクリックし、使用するルールを追加または選択(たとえば、Rule_1を選択)します。

  2. 図4-14に示すように、ルールの「IF」領域には左<operand>と右<operand>が含まれています。

    図4-10 左オペランドと右オペランドを使用するルール・テスト

    図4-10の説明が続きます
    「図4-10 左オペランドと右オペランドを使用するルール・テスト」の説明
  3. ルールで、「<テストの挿入>」をクリックし、たとえば、「簡易テスト」を選択します。

  4. テストでは、左オペランドを値で置き換えます。

    そのためには、左の「<オペランド>」を選択します。図4-15に示すように、テキスト入力領域とリストが表示されます。

    図4-11 ルール内のテストの左オペランドの構成

    図4-11の説明が続きます
    「図4-11 ルール内のテストの左オペランドの構成」の説明
    1. 値を入力するには、リストを使用して、値オプションから項目を選択します。

      オプションを表示するには、「一覧で表示」を選択して単一リストを使用する方法と、「ツリー表示」を選択し、ナビゲータを使用する方法があります。

    2. リテラル値を入力するには、値をテキスト入力領域に入力して[Enter]を押します。

      対応するオペランドのタイプと一致する値を入力する必要があります。たとえば、テストIF CustomerOrder.annualSpending > <operand>の場合、<operand>に有効な値は、CustomerOrderフィールドのannualSpendingのタイプと一致する必要があります。

  5. テストでは、表示される演算子を必要な論理演算子で置き換えるか、またはデフォルト(==)を受け入れます。そのためには、デフォルトの==演算子を選択します。フィールドとリストが表示されます。左オペランドのデータ型に応じて、リストには追加の演算子が含まれる場合もあります。たとえば、文字列をテストする場合、左側でStringオペランドを選択すると、図4-16に示すように、追加のString演算子(startsWithおよびequalsIgnoreCaseなど)が使用できるようになります。

    図4-12 ルール内のString演算子の構成

    図4-12の説明が続きます
    「図4-12 ルール内のString演算子の構成」の説明

    同様に、左オペランドと右オペランドの間の論理条件をテストするには、論理演算子==(等号)、!=(等しくない)、>(より大きい)、>=(以上)、<(より小さい)、<=(以下)から1つ選択します。演算子の詳細は、「Oracle Business Rulesの組込みクラスと関数」を参照してください。

  6. テストでは、右オペランドを値で置き換えます。

    <オペランド>プレースホルダを、オペランドに使用できるように構成します。

    たとえば、図4-13に示すように、テキスト入力領域に>25と入力し、[Enter]を押します。

    図4-13 ルール内のテストの右オペランドの構成

    図4-13の説明が続きます
    「図4-13 ルール内のテストの右オペランドの構成」の説明

4.3.4 動詞ルールでのテストの定義方法

動詞ルールでテストを作成するには、導出されたまたはユーザー定義のビジネス・フレーズを選択するか、新しいユーザー定義のビジネス・フレーズ(詳細は後で指定する)を記述します。

動詞ルール・テストにテキストを入力する際は、ルール・エディタによって、関連するビジネス・フレーズのドロップダウン・リストが表示されます。

動詞ルール内でテストを定義するには:

  1. ルール・デザイナで、新しい動詞ルールを追加するか、使用する動詞ルールを選択します。
  2. 図4-14に示すように、ルールの「IF」領域にはプレースホルダ「<テストの挿入>」が含まれています。

    図4-14 左オペランドと右オペランドを使用するルール・テスト

    図4-14の説明が続きます
    「図4-14 左オペランドと右オペランドを使用するルール・テスト」の説明
  3. ルールで、「<テストの挿入>」をクリックし、表示されたテキスト入力ボックスでテストの入力を開始します。
  4. テキスト(たとえば、policyなど)を入力する際は、図4-15に示すように、関連するビジネス・フレーズのリストが表示されます。必要なものを選択します。

    図4-15 動詞ルールでのテストの構成

    図4-15の説明が続きます
    「図4-15 動詞ルールでのテストの構成」の説明
  5. 必要に応じてリストを調整できます。さらに多くの選択肢を表示するには、ビジネス・フレーズを選択して[Tab]キーを押します。次に示すように、選択したものに関連するビジネス・フレーズがリストに移入されます。

    図4-16 動詞ルールでの推奨ビジネス・フレーズの調整

    図4-16の説明が続きます
    「図4-16 動詞ルールでの推奨ビジネス・フレーズの調整」の説明
  6. ビジネス・ルールに'{value}'などのパラメータがある場合、それらをクリックしてそれらの詳細を指定します。
  7. 新しいビジネス・フレーズを記述した場合、そのルールはドラフト・モードになっています。「ビジネス・フレーズ」タブでビジネス・フレーズを定義します。詳細は、「ビジネス・フレーズの作成方法」を参照してください。

4.3.5 Oracle Business Rulesテスト変数に関する必知事項

Oracle Business Rulesテスト変数を使用すると、ルールおよびデシジョン表の条件やアクションで発生する冗長な式を短縮できます。変数およびその値は、インラインのビジネス条件定義と表現されることがあります。テスト変数は、インライン・エイリアスとも呼ばれます。

テスト変数を挿入するオプションは、ルール条件セクションの<insert test>の横にリストとして表示されます。ルール条件の定義の一部として、複雑な式、数学式または関数に対するコールアウトを表す変数を定義できます。

たとえば、SongというXMLファクトがあり、composerという属性にsizeという関数があるとします。この属性を参照するときには、Song.composer.size()を毎回使用するのではなく、次のように単純な変数を定義できます。

lo = Song.composer.size()

これ以降、テストでは、式の一部にloを使用できます。簡単なものから複雑な式まで、あらゆる式にすることが可能です。たとえば、関数の本体で、<insert action>をクリックすると、使用可能なオプションの一部として式を表示できます。

図4-17は、テスト変数を表示しています。

図4-17 ルールのテスト変数

図4-17の説明が続きます
「図4-17 ルールのテスト変数」の説明

インライン・エイリアスを定義したら、それ以降のテスト条件では、オペランドのリスト内でインライン・エイリアスを使用できます。インライン・エイリアスの範囲は、そのインライン・エイリアスが定義された特定のルールにおけるそれ以降のテストに制限されます。ネスト・テストの場合でもインライン・エイリアスを使用できます。ネスト・テストは、そのエイリアスを定義したベース・テストの一部だからです。このことは、ネスト・テスト内で定義するすべてのテストにあてはまります。インライン・エイリアスの範囲は、ベース・テストとそのネスト・テストの条件に対して制限されるだけでなく、そのルールのアクションに対しても制限されます。インライン・エイリアスがネスト・テストの条件の一部として定義され、メインのテスト条件の一部としては定義されていない場合でも、このエイリアスは、メインのネスト・テスト内部または外部のそれ以降のすべてのテスト条件に対して使用できます。

ただし、ネストされていないテスト内部でインライン・エイリアスを定義した場合は、このインライン・エイリアスの範囲は、ネストされていないテスト内部のそれ以降のテストのみに制限され、ネストされていないテストの外部のどのテストにも制限されません。

インライン・エイリアスは、If-Thenルールとデシジョン表のどちらでも使用できます。デシジョン表では、拡張モードで、パターンを表示または非表示にしたり、「<パターンの挿入>」をクリックしてパターンを入力できます。パターンを挿入したら、テストを挿入できます。標準モードでは、テストを表示または非表示にしたり、<insert test>をクリックしてテストを入力できます。

ノート:

「拡張モード」機能は、下位互換性のためにのみ維持されています。簡易モードで拡張テストを使用し、必要な任意の種類の条件を作成することをお薦めします。

拡張モードで実行できることはすべて、簡易モードで実行できます。拡張モード・ルールは、単に「拡張モード」チェック・ボックスをクリアすることで同等の簡易モードに変換できます。

詳細は、「拡張テストの使用」を参照してください

4.3.6 ルールでの範囲テストの定義方法

ルール内で範囲テストを作成するには、ファクトに対する条件を追加します。たとえば、年間消費額プロパティを持つCustomerOrderサンプル・ファクトを使用し、顧客の注文額が上位の範囲と下位の範囲のどちらに該当するかを判別するテストを追加できます。

次にこのサンプル・ルールの概要を示します。

IF  
     CustomerOrder.annualSpending between 100 and 2000
THEN
     Modify CustomerOrder.value = "Normal"

実行時には、このルールが処理される際に、Rules Engineにより、一致するファクトを検索するように定義したルール・パターン・テストを基準にしてファクトがチェックされます。

ルール内で範囲テストを定義するには:

  1. Rules Designerで、「ルールセット」ナビゲーション・タブからルールセットを選択します。

  2. 「表示」フィールドで「IF/THENルール」(Rules Designerのデフォルト)を選択します。

  3. 使用するルールを追加または選択します。たとえば、Rule_1を選択します。

  4. 「Rule_1」「IF」領域で、「<テストの挿入>」を選択します。

  5. ルールの「IF」領域のテストには左<operand>と右<operand>が含まれています。

  6. 範囲テストでは、左オペランドを値で置き換えます。

    そのためには、左の「<オペランド>」を選択します。図4-18に示すように、テキスト入力領域とリストが表示されます。

    図4-18 ルールへのテストの左オペランドの追加

    図4-18の説明が続きます
    「図4-18 ルールへのテストの左オペランドの追加」の説明
    1. 値を入力するには、リストを使用して、値オプションから項目を選択します。

      オプションを表示するには、「一覧で表示」を選択して単一リストを使用する方法と、「ツリー表示」を選択し、ナビゲータを使用する方法があります。

    2. リテラル値を入力するには、値をテキスト入力領域に入力して[Enter]を押します。対応するオペランドのタイプと一致する値を入力する必要があります。

      たとえば、テストIF CustomerOrder.annualSpending > <operand>の場合、<operand>に有効な値は、CustomerOrderフィールドのannualSpendingのタイプと一致する必要があります。

  7. 範囲テストでは、between演算子を選択します。そのためには、デフォルトの==演算子を選択します。テキスト入力領域とリストが表示されます。図4-19に示すように、「between」を選択します。

    図4-19 ルール内の範囲テストの演算子の構成

    図4-19の説明が続きます
    「図4-19 ルール内の範囲テストの演算子の構成」の説明

    これにより、さらに2つの<operand>プレースホルダが追加されます。

  8. 他のオペランドの場合と同様に、これらの<operand>プレースホルダを構成します。

    この例では、このテストがtrueになるのは、左端のオペランド(CustomerOrder.annualSpending)が値1002000の間にある場合です。

4.3.7 ルールでのセット・テストの定義方法

ルール内でセット・テストを作成するには、ファクトに対する条件を追加します。たとえば、ライン品目プロパティを持つCustomerOrderサンプル・ファクトを使用し、ライン品目が任意の製品セットに属しているかどうかを判別するテストを追加できます。

次にこのサンプル・ルールの概要を示します。

IF  
     CustomerOrder.lineItem.sku in 12345, 43255, 76348
THEN
     Modify CustomerOrder.value = "High"

実行時には、このルールが処理される際に、Rules Engineにより、一致するファクトを検索するように定義したルール・パターン・テストを基準にしてファクトがチェックされます。

ルール内でセット・テストを定義するには:

  1. Rules Designerで、「ルールセット」ナビゲーション・タブからルールセットを選択します。

  2. 「表示」フィールドで「IF/THENルール」(Rules Designerのデフォルト)を選択します。

  3. 使用するルールを追加または選択します。たとえば、Rule_1を選択します。

  4. 「Rule_1」「IF」領域で、「<テストの挿入>」を選択します。

  5. ルールの「IF」領域のテストには左<operand>と右<operand>が含まれています。

  6. セット・テストでは、左オペランドを値で置き換えます。

    そのためには、左の「<オペランド>」を選択します。図4-20に示すように、テキスト入力領域とリストが表示されます。

    図4-20 ルールへのテストの左オペランドの追加

    図4-20の説明が続きます
    「図4-20 ルールへのテストの左オペランドの追加」の説明
    1. 値を入力するには、リストを使用して、値オプションから項目を選択します。

      オプションを表示するには、「一覧で表示」を選択して単一リストを使用する方法と、「ツリー表示」を選択し、ナビゲータを使用する方法があります。

    2. リテラル値を入力するには、値をテキスト入力領域に入力して[Enter]を押します。

  7. セット・テストでは、in演算子を使用します。そのためには、デフォルトの==演算子を選択します。テキスト入力領域とリストが表示されます。図4-21に示すように、「in」を選択します。

    図4-21 ルール内のセット・テストの演算子の構成

    図4-21の説明が続きます
    「図4-21 ルール内のセット・テストの演算子の構成」の説明

    これにより、図4-22に示すように、さらに2つの<オペランド>プレースホルダがカンマ区切りリスト形式で追加され、<挿入>プレースホルダも追加されます。

    図4-22 セット・テストのin演算子

    図4-22の説明が続きます
    「図4-22 セット・テストのin演算子」の説明

    リストに別のオペランドを追加するには、「<挿入>」をクリックします。

    リストからオペランドを削除するには、オペランドを右クリックして、テスト式の削除を選択します。

  8. 図4-23に示すように、<オペランド>プレースホルダをオペランドに使用できるように構成します。

    図4-23 ルール内のセット・テストのオペランドの構成

    図4-23の説明が続きます
    「図4-23 ルール内のセット・テストのオペランドの構成」の説明

    このテストがtrueになるのは、左端のオペランド(CustomerOrder.lineItem.sku)の値が12345、43255または76348の場合です。

4.3.8 一般的なルールでのアクションの定義方法

ルールを作成するには、テストおよびアクションを挿入します。アクションはパターン一致と関連しています。ルールの「IF」領域にあるテストが一致すると、Rules Engineにより「THEN」のアクションがアクティブ化され、ルールに関連付けられているアクションの実行が準備されます。

アクションを追加する場合は、表4-2に示すいずれかのフォームのアクションを使用します。表4-2に示す各フォームでは、ルール・デザイナが表示するオプションは状況依存なので、使用するリストおよび項目の数は、追加するアクション、およびアクションの入力中の選択内容に応じて異なる可能性があります。表4-2には基本のアクションが示されています。拡張モードでは追加のアクションを使用できます。拡張モードの詳細は、「ルールおよびデシジョン表での詳細設定の使用」を参照してください。

一般的なルール内でアクションを定義するには:

  1. Rules Designerで、「ルールセット」ナビゲーション・タブからルールセットを選択します。
  2. 一般的なルールの「THEN」領域で、「<アクションの挿入>」を選択します。図4-27に示すように、「アクションの追加」リストが表示されます。

    図4-24 ルールへのModifyアクションの追加

    図4-24の説明が続きます
    「図4-24 ルールへのModifyアクションの追加」の説明
  3. 「アクションの追加」リストで、追加するアクションのタイプを選択します。たとえば、「modify」を選択します。テキスト領域にアクション名を入力することもできます。テキストの入力を開始すると、使用可能な選択肢のリストが自動的にフィルタされます。この機能は、使用可能なオプションの数が多い場合に便利です。

    assertcallmodifyの範囲の必要なアクションを、ifelseelseifwhileforif (advanced)while (advanced)のような条件アクションにも追加できます。

  4. 「THEN」領域で、「<ターゲット>」を選択してオプション・リストを表示します。図4-25に示すように、「RequestedProduct」を選択します。

    図4-25 ルールへのModifyアクションの追加とターゲットの選択

    図4-25の説明が続きます
    「図4-25 ルールへのModifyアクションの追加とターゲットの選択」の説明
  5. 「<プロパティの編集>」を選択します。「プロパティ」ダイアログが表示されます。
  6. 図4-26に示すように、「プロパティ」ダイアログで、「値」列に"High"と(二重引用符を含めて)入力し、[Enter]を押します。

    図4-26 ルールへのModifyアクションのプロパティと値の追加

    図4-26の説明が続きます
    「図4-26 ルールへのModifyアクションのプロパティと値の追加」の説明
  7. 「プロパティ」ダイアログで、「閉じる」をクリックします。これにより、ルールが表示されます。
4.3.8.1 一般的なルールの基本アクション

表4-2 ルール・アクションのオプション

アクション・フォーム 説明

assert New

新規ファクトをアサートします。

assign,

新規ファクトをアサートします。

call

関数をコールします。

modify

一致したファクトに関連付けられているデータ値を変更します。

retract

ファクトを取り消します。

assert

ファクトをアサートします。

asset tree

ルートが指定されたファクトのツリーをアサートします。

assign new

新しいファクトを割り当てます。

expression

式を実行します。

return

returnアクションは、関数またはルールのアクション・ブロックから戻ります。ルール内のreturnアクションはルールセット・スタックをポップするため、実行は現在ルールセット・スタックの最上部にあるルールセットからのアジェンダに対するアクティブ化に進みます。

RL

入力したOracle RL式を使用します。

synchronized

synchronizedアクションは、複数スレッドのアクションの同期化に役立ちます。synchronizedアクション・ブロックを使用すると、指定したオブジェクトのロックを取得してからアクション・ブロックを実行し、次にロックを解放できます。

throw

例外をスローします。例外はjava.lang.Throwableを実装するJavaオブジェクトである必要があります。スローされた例外は、tryアクション・ブロック内のcatchによって捕捉される場合があります。

try

Oracle RLのtry、catchおよびfinallyは、構文もセマンティクスもJavaに類似しています。catch句またはfinally句が1つ以上必要です。

ifelseelseifforwhile

条件アクション。

4.3.9 動詞ルールでのアクションの定義方法

一般的なルールと同様に、動詞ルールを作成するには、テストおよびアクションを挿入します。動詞ルールのテストおよびアクションは、主としてビジネス・フレーズで構成されています。

動詞ルール内でアクションを定義するには:

  1. Rules Designerで、「ルールセット」ナビゲーション・タブからルールセットを選択します。
  2. 動詞ルールの「THEN」領域で、「<アクションの挿入>」を選択します。図4-27に示すように、ビジネス・フレーズの追加リストが表示されます。

    図4-27 動詞ルールへのアクションの追加

    図4-27の説明が続きます
    「図4-27 動詞ルールへのアクションの追加」の説明
  3. ビジネス・フレーズ・リストで、推奨ビジネス・フレーズのリストを表示するアクションの入力を開始します。

    アクションをフレーズにする方法がよくわからない場合は、キーワードを入力することもできます。たとえば、特定の方法で割増を計算する必要がある場合、calculate Premiumと入力すると、関連するビジネス・フレーズが表示されます。

    図4-28 動詞ルールへのアクションの追加

    図4-28の説明が続きます
    「図4-28 動詞ルールへのアクションの追加」の説明
  4. 必要を満たすビジネス・フレーズがある場合は、それを選択します。
  5. ビジネス・フレーズのリストをさらに調整するには、使用するものに関連するものを選択し、[Tab]キーを押します。

    調整済のビジネス・フレーズのセットが含まれたリストが表示されます。目的のフレーズを選択します。

    図4-29 動詞ルールへのアクションの追加

    図4-29の説明が続きます
    「図4-29 動詞ルールへのアクションの追加」の説明
  6. リスト内のビジネス・フレーズが必要を満たさない場合は、ビジネス・フレーズを入力し、「新規ビジネス・フレーズの追加」を選択して新しいビジネス・フレーズをインスタンス化します。「ビジネス・フレーズ」タブで、ビジネス・フレーズの定義を完了します。

4.3.10 ルール・アクションに関する必知事項

条件の値がアクションによって変更された場合に、ルールのループが発生することがあります。ループは、単一ルール内のルール間、複数のデシジョン表全体、または同一ルールセット内のルールおよびデシジョン表全体で発生する場合があります。ルール条件内で使用されるファクト・プロパティを変更するルール・アクションは作成しないようにする必要があります。このようなルールによって、実行時に無限ループが発生する場合があります。

4.3.11 Oracle Business Rulesのパフォーマンス・チューニングに関する必知事項

ほとんどの場合、ルールを記述する際にパフォーマンスに注意を払う必要はありません。ただし、ルールのパフォーマンスを向上および最大化するのに役立つヒントがありますので、必要に応じて利用してください。

Oracle Business Rulesのパフォーマンス・チューニングの詳細は、『パフォーマンスのチューニング・ガイド』Oracle Business Rulesパフォーマンス・チューニングに関する項を参照してください。

4.4 動詞ルールおよびビジネス・フレーズの概要

動詞ルールはビジネス・フレーズと連携して機能することで、ルールの柔軟なオーサリングを可能にし、自然言語文を使用して、会話言語と同様のドメイン固有文でルール・ロジックを表現できるようにします。

ビジネス・フレーズは、動詞ルールの文構成で使用される条件の背景となるロジックを提供します。

動詞ルールのテストおよびアクションは、導出されたビジネス・フレーズおよびユーザー定義のビジネス・フレーズを使用して作成できます。導出されるビジネス・フレーズは、ファクト、グローバルおよびディクショナリのその他の情報を使用して自動的に作成されますが、ユーザー定義のフレーズは、明示的に作成して導出されたフレーズを補うことができます。さらに、ユーザー定義のフレーズは、事前作成することも、動詞ルールの構成時に必要に応じて作成することもできます。

動詞ルールの作成時は、提案されたビジネス・フレーズを使用したり、その場で独自にインスタンス化して後で実装詳細を指定することもできます。また、最初に動詞ルールで必要なビジネス・フレーズを作成してから、動詞ルールを完成する方法もあります。

4.4.1 ビジネス・フレーズの使用

ビジネス・フレーズは、ルール・デザイナの「ビジネス・フレーズ」タブで作成します。

ビジネス・フレーズは次の3つの部分で構成されています。

  • パラメータ: ビジネス・フレーズに渡すことができる変数のタイプを定義するパラメータ

  • 値: パラメータのプレース・ホルダ(存在する場合)などのビジネス・フレーズの式

  • マッピング: ビジネス・フレーズの条件を定義するロジックの定義

ビジネス・フレーズには2つのタイプがあります。

  • テスト・ビジネス・フレーズ: 条件を定義します。これらは、一般的なルールのIF部分と同じタイプのロジックを提供します。詳細は、「ルールでのテストの定義方法」を参照してください。

  • アクション・ビジネス・フレーズ: 動詞ルールのテスト・ビジネス・フレーズによって定義された条件が満たされた場合に実行するアクションを定義します。これらは、一般的なルールのTHEN部分と同じタイプのロジックを提供します。詳細は、「動詞ルールでのアクションの定義方法」を参照してください。

4.4.1.1 「ビジネス・フレーズ」タブ

テストおよびアクションのビジネス・フレーズは、図4-30に示すように、どちらもルール・デザイナの「ビジネス・フレーズ」タブで作成します。

図4-30 「ビジネス・フレーズ」タブ

図4-30の説明が続きます
「図4-30 「ビジネス・フレーズ」タブ」の説明

このタブには、次のセクションがあります。

「ビジネス・フレーズ」リスト

「ビジネス・フレーズ」リストには、ディクショナリに含まれるビジネス・フレーズが表示されます。

ツールバー・コントロールを使用して、検索によるリストをフィルタリング、リストをリフレッシュ、新しいテストまたはアクションのビジネス・フレーズを追加、および現在選択されているビジネス・フレーズを削除します。

このリストには、ビジネス・フレーズおよびそれらの属性(「値」「フォーム」および「ドラフト」)が表示されます。

ビジネス・フレーズをドラフトとしてマークするには、直接、リスト内の「ドラフト」チェック・ボックスを選択します。

検証エラーが含まれているビジネス・フレーズには、赤い波線のアンダースコアでマークされます。それらの上にカーソルを移動するとポップアップにエラーが表示されます。

パラメータ

「パラメータ」パネルを使用してパラメータを表示および編集します。

「挿入」をクリックし、ビジネス・フレーズの値にパラメータを追加します。「追加」および「削除」を使用してパラメータを作成および削除します。

「フォーム」属性は、パラメータのタイプを定義します。選択肢は次のとおりです。

  • 値: 非定型の値。選択した場合、「タイプ」をboolean、byte、char、double、float、int、long、shortまたはStringから選択できます。

  • 変数: そのビジネス・フレーズのスコープ内ですでに定義されている変数。選択した場合、「タイプ」を、ディクショナリ内の定義済ファクト・タイプの1つから選択できます。

  • 式: 式を入力します。

「値」パネルで、ビジネス・フレーズの定義を編集します。値は、「ビジネス・フレーズ」リストのビジネス・フレーズ、および動詞ルールを作成する場合の選択肢リストに表示されるビジネス・フレーズの表示名としても使用されます。

マッピング

「マッピング」パネルでビジネス・フレーズの条件の論理定義を編集します。ビジネス・フレーズのマッピングには、ビジネス・フレーズのロジックが一般的なルールとして作成された場合のものと類似した論理コンストラクトが含まれています。ビジネス・フレーズのマッピングの作成にも適用される原則と手順は、「ルールの使用」のテストとアクションの説明を参照してください。

4.4.1.2 ドラフトのビジネス・フレーズと動詞ルール

ビジネス・フレーズは、ドラフト・ステータスとしてマークできます。

ビジネス・フレーズのドラフト・ステータスは、ビジネス・フレーズ・リスト「ドラフト」を選択または選択解除することで設定またはオーバーライドできます。

動詞ルールのドラフト・ステータスは参照するビジネス・フレーズから導出され、直接は操作できません。動詞ルールにドラフトとマークされたビジネス・フレーズが含まれる場合、このルールもドラフトとしてマークされます。図4-31に示すように、動詞ルールの説明パネルは単色の青に変更され、「ドラフト」という語がルール名の横に表示されます。動詞ルールで参照しているすべてのビジネス・フレーズからドラフトのマークがなくなった場合、動詞ルールのドラフト・ステータスは解除されます。

図4-31 ドラフトとマークされている動詞ルール

図4-31の説明が続きます
「図4-31 ドラフトとマークされている動詞ルール」の説明

ドラフトのビジネス・フレーズおよび動詞ルールは、検証されず、実行用のディクショナリにも含まれません。これにより、ビジネス・フレーズおよび動詞ルールの改良時にも、ディクショナリの使用またはテストの続行が可能になります。

動詞ルールの作成時には、ディクショナリにまだ存在していないビジネス・フレーズを構成できます。これらは、ビジネス・フレーズのリストに自動的に追加され、ドラフトのマークが付けられ、さらに動詞ルールもドラフトとしてマークされます。

4.4.2 ビジネス・フレーズの作成方法

ビジネス・フレーズは「ビジネス・フレーズ」タブで作成します。ビジネス・フレーズは、動詞ルールの記述中に指定し、後で「ビジネス・フレーズ」タブでその定義を完成することもできます。

「ビジネス・フレーズ」タブを使用して、ビジネス・フレーズを追加、変更、および削除します。

新しいビジネス・フレーズを作成する手順は次のとおりです。

  1. ルール・デザイナで、「ビジネス・フレーズ」タブを選択し、「作成」(「+」)をクリックしてテスト・ビジネス・フレーズを作成します。「テスト・ビジネス・フレーズ」または「アクション・ビジネス・フレーズ」を選択します。

    新しいビジネス・フレーズが作成されます。

  2. 「値」パネルで、ビジネス・フレーズの定義を入力します。未定義のパラメータのプレースホルダは、その名前を中カッコで囲んで入力することで組み込むことができます。次に例を示します。
    {customer} is single
    
  3. 「パラメータ」パネルで、パラメータを定義します。「作成」(+)をクリックして、新しいパラメータを追加します。その名前をダブルクリックし、編集します。その「フォーム」と「タイプ」を指定します。必要に応じて「値セット」を指定します。
  4. ビジネス・フレーズの値にパラメータを追加するには、「挿入」をクリックします。
  5. 「マッピング」パネルで、ビジネス・フレーズのマッピングを定義します。「<テストの挿入>」をクリックして開始します。テストを選択し、オペランドを指定します。必要に応じてさらにテストを追加します。
4.4.2.1 ビジネス・フレーズの作成シナリオの例

この例の場合、ほとんどのプロジェクト定義が完了している保険見積りプロジェクトがあると想定します。多くの場合、顧客がマイナーであるかどうか調べるためと、保険契約を無効化するためのテストをするビジネス・フレーズを追加する必要があります。

新しいテスト・ビジネス・フレーズを作成し、値{customer} is a minorを指定します。

次に、パラメータcustomerを定義し、それを前に定義したCustomerファクトにマッピングします。

ここで、条件を指定するマッピングを指定します。「<テストの挿入>」をクリックし、簡易テストを選択します。左の「<オペランド>」をクリックし、「customer」を開いて、「customer.age」を選択します。右のオペランドをクリックし、値21を指定します。

テスト・ビジネス・フレーズは、次の図4-32のようになります。

図4-32 テスト・ビジネス・フレーズの例

図4-32の説明が続きます
「図4-32 テスト・ビジネス・フレーズの例」の説明

ここで、アクション・ビジネス・フレーズを作成し、控除を高い値に設定し、それに値Set High Deductibleを指定します。

policyという変数を作成し、それを、前に定義したPolicyファクトにマッピングします。

「マッピング」パネルで「<テストの挿入>」をクリックし、「式」を選択します。「<式>」をクリックすると、式エディタが表示されます。policy.deductibleに移動し、それを選択し、「式に挿入」をクリックします。= 2000で式を完成し、「OK」をクリックします。

アクション・ビジネス・フレーズは、次の図4-33のようになります。

図4-33 アクション・ビジネス・フレーズの例

図4-33の説明が続きます
「図4-33 アクション・ビジネス・フレーズの例」の説明
4.4.2.2 ビジネス・フレーズの変換

ディクショナリに追加されたビジネス・フレーズの「値」属性は、元が導出されたビジネス・フレーズであったかユーザー定義のビジネス・フレーズであったかに関係なく、変換できます。

「ビジネス・フレーズ」タブで、変換するビジネス・フレーズを選択し、「値」パネルで「変換バンドルの編集」をクリックします。表示された「バンドル・エディタ」ダイアログで変換を編集します。

4.4.3 動詞ルールにおけるビジネス・フレーズの選択または追加

動詞ルールは、ビジネス・フレーズを使用してIFおよびTHENテストおよびアクションを指定します。

動詞ルールでテストまたはアクションを定義するときに、選択肢のドロップダウン・リストをトリガーするテキストを入力します。このリストから、ディクショナリに既存のビジネス・フレーズの選択、ビジネス・フレーズの自動生成、入力内容に基づく新規ビジネス・フレーズのインスタンス化を実行し、後から「ビジネス・フレーズ」タブで実装詳細を指定できます。

4.4.3.1 動詞ルール作成時の新規ビジネス・フレーズのインスタンス化

新規動詞ルールの作成時に、ドロップダウン・リストから選択するのではなく、テストまたはアクションに入力することによって、新規ビジネス・フレーズをインスタンス化できます。これらのビジネス・フレーズはドラフトとマークされ、このフレーズを使用する動詞ルールもドラフトとマークされます。

次の例では、目的のビジネス・フレーズCustomer is low riskがテストとして入力されています。このビジネス・フレーズは、ドロップダウン・リストには表示されません。これは自動的に生成されたものではなく、事前にディクショナリで定義されていません。

図4-34 ルールへの新しいビジネス・フレーズの追加

図4-34の説明が続きます
「図4-34 ルールへの新しいビジネス・フレーズの追加」の説明

動詞ルールがドラフトとしてマークされます。

図4-35 新しいビジネス・フレーズが追加され、ルールがドラフトとしてマークされる

図4-35の説明が続きます
「図4-35 新しいビジネス・フレーズが追加され、ルールがドラフトとしてマークされる」の説明

ビジネス・フレーズはドラフトとしてマークされ、「ビジネス・ルール」リストに追加されます。パラメータ(存在する場合)およびマッピング情報を指定する必要があります。

図4-36 ドラフトとマークされている動詞ルールから追加されたビジネス・フレーズ

図4-36の説明が続きます
「図4-36 ドラフトとマークされている動詞ルールから追加されたビジネス・フレーズ」の説明
4.4.3.2 動詞ルール作成時のビジネス・フレーズの選択

テストまたはアクションの作成時に、以前のユーザー定義ビジネス・フレーズと自動生成された導出ビジネス・フレーズの両方が含まれ、関連性に従ってソートされた堅牢なリストが自動的に提示されます。

ユーザー定義および導出されたビジネス・フレーズは、ドロップダウン・リストで相互を区別できません。

4.4.3.3 導出されたビジネス・フレーズ

導出されたビジネス・フレーズは、ベースとなっているディクショナリで定義されたとおりのビジネス・オブジェクトおよびデータ・モデルに基づいて、自動的に作成されます。これらは、システムがユーザーによる入力に基づいてユーザーが作成しようとしていると計算したものに基づいて、その場で作成されます。これらは、動詞ルールに追加されていない場合は永続化されません。

導出されたビジネス・フレーズは、動詞ルールに追加されると、単なる通常のビジネス・フレーズになり、パラメータおよび変換がサポートされます。

4.4.3.4 リストに表示するビジネス・フレーズの選択

「設定」タブ→「ディクショナリ設定」→「フレーズ提案」→「値」ドロップダウンを使用して、動詞ルールのテストおよびアクションの作成中に表示されるドロップダウン選択リストに表示されるビジネス・フレーズのタイプを制御します。

選択肢は次のとおりです。

  • すべて: ディクショナリ内のユーザー定義ビジネス・フレーズと導出されたビジネス・フレーズの両方を表示します。

  • 自動提案: 導出されたビジネス・フレーズのみを表示します。

  • ビジネス・フレーズ: ディクショナリからのユーザー定義のビジネス・フレーズのみを表示します。

4.5 ディクショナリの検証

ディクショナリを変更すると、ルール・デザイナではディクショナリ検証が実行されます。ルールまたはデシジョン表の使用時には、ルール・デザイナによる検証が役立ちます。

検証ログ・ウィンドウを表示するには、「検証」ボタンをクリックするか、または「表示」→「ログ」を選択して、「ビジネス・ルール検証」タブを選択します。これにより、不正または不完全なルールに関する警告が表示されます。ルールをテストまたはデプロイする前に、すべての警告を修正する必要があります。

ディクショナリが無効な場合、ルール・デザイナでは警告メッセージのリストが生成されて関連ディクショナリ・オブジェクトがリスト表示されます。検証メッセージ情報は、ディクショナリ・オブジェクトの検索と問題の解決に使用できます。また、検証警告のあるオブジェクトには、図4-37に示すように検証インディケータ(赤い波線による下線)のフラグが付きます。

図4-37 ログと画面に波線による下線で表示された検証警告

図4-37の説明が続きます
「図4-37 ログと画面に波線による下線で表示された検証警告」の説明

ディクショナリが無効な場合は、そのディクショナリを保存できます。ただし、RL Languageを生成できるのは、有効でルール・デザイナの検証ログに警告が表示されないディクショナリの場合のみです。

検証ログでは、各検証メッセージに次の情報が含まれています。

  • メッセージ: メッセージは、Oracle Business Rules例外に関する問題の詳細説明を提供します。

  • ディクショナリ・オブジェクト: このフィールドには、ディクショナリのコンポーネントの識別に必要な詳細を示すパスが表示されます。

  • プロパティ: 警告メッセージに関連するオブジェクトの、プロパティに関する情報を提供します。

検証ログの表示中に、項目を選択し、右クリックしてリストから「エディタでオブジェクトを選択して強調表示」を選択すると、カーソルが移動し、ディクショナリ・オブジェクトが選択されます。一部の検証警告の場合、この機能を使用できないことに注意してください。

4.5.1 データ・モデル検証

ディクショナリを変更すると、ルール・デザイナではディクショナリ検証が実行されます。ルール・デザイナにより警告メッセージが表示された場合、検証ログには、検証警告の原因となったディクショナリ・オブジェクトの検索に役立つメッセージが含まれています。たとえば、次の文字列は、警告がRLFact_1というデータ・モデル・オブジェクトから発生していることを示しています。また、問題はtest_intというプロパティにあります。

CarRental/Data Model/RLFact_1/test_int/Expression

表4-3に、検証メッセージで指定されたディクショナリ・オブジェクト名の各部を示します。

表4-3 検証ログ内のデータ・モデルのディクショナリ・プロパティ

名前 説明

CarRental

ディクショナリ名

Data Model

ディクショナリ内のデータ・モデル・コンポーネント

RLFact_1

データ・モデル内の要素名

test_int

指定された要素内のプロパティ名

Expression

プロパティの式部分

4.5.2 ルール検証の理解

「検証」ボタンをクリックすると、ルール・デザイナにより検証ログが表示されます。ルールを初めて追加すると、図4-38のような検証警告が表示されます。

図4-38 新しいルールに対するビジネス・ルール - ログ検証メッセージ

図4-38の説明が続きます
「図4-38 新しいルールに対するビジネス・ルール - ログ検証メッセージ」の説明

ルールに関する検証メッセージのディクショナリ・オブジェクト名部分には、検証警告に関連するルールセット、ルールおよびルール内の領域を識別できるように詳細が含まれています。たとえば、次のディクショナリ・オブジェクト指定は問題を示しています。

OracleRules1/Ruleset_2/Rules_1/Pattern[1]

検証メッセージでは、ルールのディクショナリ・オブジェクト名に1から始まる索引が使用されます。したがって、最初のパターンはPattern[1]です。

ルールを検証するのみでなく、デザイン時にルール・デザイナでテストすることもできます。詳細は、「ルール関数を使用したデシジョン関数のテスト」を参照してください。

4.5.3 デシジョン表の検証

「検証」ボタンをクリックすると、ルール・デザイナにより検証ログが表示されます。デシジョン表を初めて追加したときは、図4-38に示すように、新しいルールに対して表示されるものに類似した検証警告が表示されます。

図4-39 新しいデシジョン表に対するビジネス・ルール - ログ検証メッセージ

図4-39の説明が続きます
「図4-39 新しいデシジョン表に対するビジネス・ルール - ログ検証メッセージ」の説明

デシジョン表に関する検証メッセージのディクショナリ・オブジェクト名部分には、デシジョン表のうち検証警告に関連する領域を識別できるように詳細が含まれています。たとえば、次のディクショナリ・オブジェクト指定は、デシジョン表の最初のアクション行と最初のアクション・セルに問題があることを示します。

OR1/Ruleset_1/DecisionTable_1/Action[1]/Action Cell[1]

検証メッセージでは、デシジョン表オブジェクトのディクショナリ・オブジェクト名に1から始まる索引が使用されます。たとえば、「条件」領域の第1行の第1条件セルを示すメッセージは次のようになります。

OracleRules1/Ruleset_1/DecisionTable_2/Condition[1]/Condition Cell[1]

この指定は、デシジョン表の「条件」領域のうち、第1行にあるラベルR1が付いたルールの条件セルを示しています。

4.5.4 ディクショナリの検証方法

ディクショナリを変更すると、ルール・デザイナではディクショナリ検証が実行されます。

ディクショナリを検証するには:

  1. ルール・デザイナで、「検証」ボタン(チェックマーク)をクリックします。
  2. メッセージ領域からビジネス・ルール - ログを選択します。
  3. 検証ログの表示中に、項目を選択し、右クリックしてリストから「エディタでオブジェクトを選択して強調表示」を選択すると、カーソルが移動し、ディクショナリ・オブジェクトが選択されます。一部の検証警告の場合、この機能を使用できないことに注意してください。

4.6 ルールおよびデシジョン表での詳細設定の使用

ルールおよびデシジョン表の詳細設定では、詳細オプションを提供する機能を使用できます。これらのオプションは、すべてのOracle Business Rulesユーザーに必要なものではありません。

図4-40に詳細設定機能を示します。

図4-40 詳細設定の表示/非表示

詳細設定の表示/非表示

次の機能が含まれます。

  • 拡張モード: ルール内でその他のパターン一致オプションおよびネスト・テストを使用できます。拡張モードは、前に使用したことがある場合にのみ使用してください。簡易モードで拡張テストを使用し、必要な任意の種類の条件を作成することをお薦めします。

    詳細は、次を参照してください。

  • 単純モード: 更新済であり、複雑なルールを構築する場合に使用する必要があります。拡張モードは、前に使用したことがある場合にのみ使用してください。「拡張モード」機能は、下位互換性のためにのみ維持されています。

    詳細は、「拡張テストの使用」を参照してください。

  • ツリー・モード: マスター・ディテール階層(親子リレーションシップにマップされるネストされた要素)を容易に使用できるようにします。このようなファクト間の親子関係は、XMLおよびADFビジネス・コンポーネント・ファクト・タイプにおいて一般的です。このオプションは、「拡張モード」オプションと併用できます。

    詳細は、「単純ツリー・モードのルールの作成方法」を参照してください。

  • アクティブなルール: ルールまたはデシジョン表がアクティブであるか非アクティブであるかを指定します。「アクティブなルール」がクリアされている場合、指定したルールまたはデシジョン表はルール・デザイナによって検証されません。

    詳細は、「アクティブ・オプションの選択方法」を参照してください。

  • 論理: ルールを起動するファクトとルールによりアサートされるファクト間の論理的な依存関係を有効化または無効化できます。

    詳細は、「論理オプションの選択方法」を参照してください。

  • 「ギャップの許可」: (デシジョン表の詳細設定でのみ使用可能)。このチェック・ボックスでは、デシジョン表でギャップが検出された場合に検証メッセージをレポートするかどうかを指定します。その場合の検証メッセージを次に示します。

    RUL-05852: Decision Table has gaps
    

    詳細は、「デシジョン表のギャップ・チェック」および「デシジョン表のギャップ・チェックの実行方法」を参照してください。

  • 優先度: ルールまたはデシジョン表の優先度を指定します。ルールセット内では、優先度の高いルールが実行されてから、優先度の低いルールが実行されます。

    詳細は、「ルールの優先度の設定方法」を参照してください。

  • 競合ポリシー: (デシジョン表の詳細設定でのみ使用可能)。デシジョン表の競合ポリシーとして、次のいずれかを指定します。

    • 手動: 競合ルールごとに競合解決を手動で指定することで、競合を解決します。

    • 自動オーバーライド: 自動競合解決ポリシーを使用して、可能な場合に、オーバーライド競合解決を使用して競合を自動的に解決します。

    • 無視: 競合が無視されます。

    詳細は、「デシジョン表の競合分析」を参照してください。

  • 有効日: ルールまたはデシジョン表の有効日を指定します。

    詳細は、「有効日の指定方法」を参照してください。

4.6.1 ルールまたはデシジョン表の詳細設定の表示と非表示を切り替える方法

ルール・デザイナでは、各ルール名およびデシジョン表名の横に「詳細設定の表示」または「詳細設定の非表示」ボタンがあり、詳細設定の表示と非表示を切り替えることができます。

ルールまたはデシジョン表の詳細設定の表示と非表示を切り替えるには:

  1. 詳細設定を表示するルールセット選択します。

  2. 「表示」フィールドのリストから、「IF/THENルール」を選択するか、またはデシジョン表を選択します。

    1. 詳細設定を表示するには、図4-41に示すように、ルール名の横にある「詳細設定の表示」をクリックします(ルール名の横に、選択されているボタンがあります)。

      図4-41 詳細設定の表示または非表示

      図4-41の説明が続きます
      「図4-41 詳細設定の表示または非表示」の説明
    2. 詳細設定を非表示にするには、ルール名の横にある「詳細設定の非表示」をクリックします。

4.6.2 拡張モード・オプションの選択方法

その他のパターン一致オプションおよびその他のアクションを提供するルールまたはデシジョン表機能を使用するには、「拡張モード」を選択します。詳細は、「拡張モードのルールの使用」を参照してください。

拡張モード・オプションを選択するには:

  1. 拡張モードを設定するルールまたはデシジョン表を選択します。
  2. ルール名またはデシジョン表名の横にある「詳細設定の表示」ボタンをクリックします(「ルールまたはデシジョン表の詳細設定の表示と非表示を切り替える方法」を参照)。
  3. 「拡張モード」を選択します。

図4-42および図4-43は、拡張と簡易の各モードで表示されるルールの例です。

拡張モードと簡易モードでは、パターンの存在と不在のために、同じフォームが異なるもののようになります。

図4-42 「拡張モード」を選択

図4-42の説明が続きます
「図4-42 「拡張モード」を選択」の説明

図4-43は、同じルールの「拡張モード」をクリアした状態を示しています。

図4-43 「拡張モード」をクリア

図4-43の説明が続きます
「図4-43 「拡張モード」をクリア」の説明

4.6.3 アクティブ・オプションの選択方法

Oracle Business Rulesには、ルールまたはデシジョン表がアクティブであるか非アクティブであるかを指定する機能が組み込まれています。アクティブ・オプションは有効日に関係なく設定され、前に指定した有効日を変更または削除せずに設定できます。「アクティブなルール」がクリアされている場合、ルールはルール・デザイナによって検証されません。

アクティブ・オプションを選択するには:

  1. 「アクティブなルール」オプションを設定するルールまたはデシジョン表を選択します。
  2. ルール名またはデシジョン表名の横にある「詳細設定の表示」ボタンをクリックします(「ルールまたはデシジョン表の詳細設定の表示と非表示を切り替える方法」を参照)。
  3. 「アクティブなルール」を選択します。

4.6.4 論理オプションの選択方法

「論理」オプションが選択されているルールセットまたはデシジョン表では、生成されるRL Language内のルールで論理プロパティを使用するように指定されています。論理プロパティを使用すると、ルールを起動するファクトとルールによりアサートされるファクト間の論理的な依存関係を有効化または無効化できます。

論理プロパティが有効化されているルールでは、ルール内のアクション・ブロックによってアサートされた全ファクトが、ルール条件内で一致したファクトに依存します。ルールの条件が適用されなくなるなど、ルール条件で参照されていたファクトに変更があると、ルール条件によってアサートされたファクトは自動的に取り消されます。詳細は、Oracle Business Process Managementルール言語リファレンスルール定義を参照してください。

ルールセットとデシジョン表の「論理」オプションを使用すると、ルールセットまたはデシジョン表内のルールに関連して生成されたRL Languageに対する論理プロパティを有効化または無効化できます。デフォルトでは、「論理」オプションは選択されません。

論理オプションを選択するには:

  1. 「論理」オプションを設定するルールまたはデシジョン表を選択します。
  2. ルール名またはデシジョン表名の横にある「詳細設定の表示」ボタンをクリックします(「ルールまたはデシジョン表の詳細設定の表示と非表示を切り替える方法」を参照)。
  3. 「論理」を選択します。

4.6.5 ルールの優先度の設定方法

ルールまたはデシジョン表の優先度を設定できます。表4-4に示すように事前定義済の名前が付いた優先度のリストから選択する方法と、正または負の整数を入力して独自の優先度レベルを指定する方法があります。ルールセット内では、優先度の高いルールが実行されてから、優先度の低いルールが実行されます。デフォルトの優先度はmedium(整数値0)です。

表4-4 優先度文字列と値のマッピング

名前付き優先度 整数値

最高

3000

より高い

2000

1000

中(デフォルトの優先度)

0

-1000

より低い

-2000

最低

-3000

ルールの優先度を設定するには:

  1. 優先度を設定するルールまたはデシジョン表を選択します。

  2. ルール名またはデシジョン表名の横にある「詳細設定の表示」ボタンをクリックします(「ルールまたはデシジョン表の詳細設定の表示と非表示を切り替える方法」を参照)。

  3. 「優先度」フィールドで、優先度値を指定します。

    1. 名前付きの優先度を指定するには、「優先度」リストから名前付きの優先度を選択します。

    2. 整数による優先度を指定するには、「優先度」フィールドをクリックして正または負の整数値を入力し、[Enter]を押します。

4.6.6 有効日の指定方法

ルールセット、ルールまたはデシジョン表の有効日を指定できます。

有効日を指定するには:

  1. 有効日を設定するルールまたはデシジョン表を選択します。
  2. ルール名またはデシジョン表名の横にある「詳細設定の表示」ボタンをクリックします(「ルールまたはデシジョン表の詳細設定の表示と非表示を切り替える方法」を参照)。
  3. 「有効日」フィールドを選択します。「有効日の設定」ダイアログが表示されます。
  4. 「有効日の設定」ダイアログを使用して有効日を設定します。

4.7 ネスト・テストの使用

ルールまたはデシジョン表では、ネスト・テスト機能を使用して、さらに複雑なテストを作成できます。

ネスト・テストを使用するには:

  1. ネスト・テストを使用するルールを選択します。
  2. 「IF」領域で、「ネスト・テスト」をクリックして選択します。
  3. 図4-44に示すように、テストを選択した状態で、右クリックしてリストを表示します。

    図4-44 ルールへのネスト・テストの追加

    図4-44の説明が続きます
    「図4-44 ルールへのネスト・テストの追加」の説明
  4. 必要に応じてテストを完成します。

4.8 拡張モードのルールの使用

Oracle Business Rulesでは、Oracle Business Rules機能のサポートを追加する詳細なルールを作成できる機能が提供されます。

ノート:

「拡張モード」機能は、下位互換性のためにのみ維持されています。簡易モードで拡張テストを使用し、必要な任意の種類の条件を作成することをお薦めします。

拡張モードで実行できることはすべて、簡易モードで実行できます。拡張モード・ルールは、単に「拡張モード」チェック・ボックスをクリアすることで同等の簡易モードに変換できます。

詳細は、「拡張テストの使用」を参照してください。

Oracle Business Rulesでは、次のOracle Business Rules機能のサポートを追加する詳細なルールを作成できる機能が提供されます。

詳細は、「拡張モードのルールに関する必知事項」を参照してください。

4.8.1 拡張モードのパターン一致オプションの使用方法

拡張モードのパターン一致オプションでは、ルールの起動時期を指定します。表4-5に、使用可能なオプションを示します。

表4-5 拡張モードのパターン一致オプション

オプション 説明

次の各ケース

これは、デフォルトのパターン一致オプションです。一致が存在するたびに(一致するすべてのケースで)ルールを起動する必要があります。

次のケースがある

このオプションでは、一致が1つ以上存在する場合にルールの起動が1つ選択されます。

次のケースがない

この値では、一致がない場合にルールを1回起動するように指定します。

aggregate

このオプションでは、すべての一致に集計関数を適用するように指定します。詳細は、「拡張モードの集計条件の使用方法」を参照してください。

拡張モードのパターン一致オプションを使用するには:

  1. パターン一致オプションを使用するルールまたはデシジョン表を選択します。
  2. ルール名またはデシジョン表名の横にある「詳細設定の表示」ボタンをクリックします(「ルールまたはデシジョン表の詳細設定の表示と非表示を切り替える方法」を参照)。
  3. 「拡張モード」を選択します。
  4. 図4-45に示すように、テスト・パターンを右クリックして「囲む」を選択します。

    図4-45 オプションで囲む

    図4-45の説明が続きます
    「図4-45 オプションで囲む」の説明

    図4-46 「囲む」オプション

    図4-46の説明が続きます
    「図4-46 「囲む」オプション」の説明

    「囲む」ダイアログが表示されます。

  5. 「囲む」ダイアログからパターン・ブロック・オプションを選択し、「OK」をクリックします。

    図4-47に示すように、パターンはデフォルトの「(次の各ケース)」を使用してネスト・パターンで囲まれます。

    図4-47 デフォルトのパターン一致オプション: 「次の各ケース」

    図4-47の説明が続きます
    「図4-47 デフォルトのパターン一致オプション: 「次の各ケース」」の説明
  6. 図4-48に示すように、デフォルトの「(次の各ケース)」オプションを選択し、リストから必要なパターン一致オプションを選択します。

    図4-48 詳細パターン一致オプションの追加

    図4-48の説明が続きます
    「図4-48 詳細パターン一致オプションの追加」の説明

4.8.2 拡張モードの一致したファクト名の使用方法

ルールまたはデシジョン表内で一致したファクト名のフィールド(パターンのバインド変数)を使用すると、1つのルールで同じタイプの複数インスタンスをテストできます。一致したファクト名を使用すると、一致したファクトについて一時的な名前を入力してテストで使用できます。たとえば、図4-49に示すルールでは、一致する帽子品目が注文に1つ以上含まれている場合に靴品目に割引が適用されるルールでの、パターンのバインド変数の使用を示しています。

図4-49 パターンのバインド変数を使用するルール

図4-49の説明が続きます
「図4-49 パターンのバインド変数を使用するルール」の説明

たとえば、図4-50に示すように、顧客の注文で重複している品目を検索するためのルールを作成できます。この例は、ルールでの一致の使用を示しています。

図4-50 注文で重複している品目を検索するルール

図4-50の説明が続きます
「図4-50 注文で重複している品目を検索するルール」の説明

拡張モードの一致したファクト名を使用するには:

  1. 一致したファクト名を追加するルールまたはデシジョン表を選択します。
  2. ルール名の横にある「詳細設定の表示」ボタンをクリックします(「ルールまたはデシジョン表の詳細設定の表示と非表示を切り替える方法」を参照)。
  3. 「拡張モード」を選択します。
  4. 「<ファクト・タイプ>」を選択し、リストからファクト・タイプを入力します。
  5. 図4-51に示すように、表示される一致したファクト名を選択し、必要に応じて変更します。たとえば、一致したファクト名Order$LineItem1を入力して[Enter]を押します。

    図4-51 一致したファクトの変数名の追加

    図4-51の説明が続きます
    「図4-51 一致したファクトの変数名の追加」の説明
  6. 図4-52に示すように、ルールを作成します。一致したファクト名をオペランドとして選択できることに注意してください。オペランド「LineItem1」および「LineItem2」を必要に応じて選択し、ルールを作成します。

    図4-52 一致したファクト変数名のオペランドとしての選択

    図4-52の説明が続きます
    「図4-52 一致したファクト変数名のオペランドとしての選択」の説明

図4-52では、テストによって次の行がチェックされます。

RL.get fact ID(Order$LineItem1) > RL.get fact ID(Order$LineItem2)

Order$LineItemという単一のインスタンスが、Order$LineItemファクト・タイプと一致するどのパターンとも一致しないようにします。異なるインスタンスの異なる組合せに対してルールが実行されないように、「>」が必要になります。詳細は、「自己結合を正しく表現するにはどうすればよいですか。」を参照してください。

4.8.3 拡張モードのアクション・フォームの使用方法

拡張モードでルールを作成する場合、Rules Designerでは表4-6に示す使用可能なアクションのリストが表示されます。表4-6に示す各フォームについて、ルール・デザイナで表示されるオプションは状況依存です。このため、アクション・タイプを使用するときに表示されるリストおよび項目の数は状況依存であり、追加するアクション、およびアクションの入力中の選択内容に応じて異なります。

拡張モードのアクション・フォームを使用するには:

  1. Rules Designerで、「ルールセット」ナビゲーション・タブからルールセットを選択します。
  2. ルールまたはデシジョン表を選択または追加します。
  3. ルールまたはデシジョン表で、ルールまたはデシジョン表名の横にある「詳細設定の表示」ボタンをクリックします(「ルールまたはデシジョン表の詳細設定の表示と非表示を切り替える方法」を参照)。
  4. 「拡張モード」を選択します。
  5. 挿入領域が表示された状態で、ルールの「THEN」領域で、「<アクションの挿入>」を選択します。図4-53に示すように、アクション・リストが表示されます。

    図4-53 拡張モードのルールへのアクションの追加

    図4-53の説明が続きます
    「図4-53 拡張モードのルールへのアクションの追加」の説明
  6. リストで、追加するアクションを選択します。

    たとえば、「assign new」を選択します。

  7. 「THEN」領域で、アクションの状況依存パラメータを選択し、適切な値を入力します。
4.8.3.1 ルール・デザイナの拡張モード・アクション・オプション

表4-6 拡張モードのアクション・オプション

アクション・フォーム 説明

Assert

ファクトのアサート

Assert Tree

ルートが指定されたファクトのツリーをアサートします。

Assert New

新規ファクトをアサートします。

Assign

変数に値を割り当てます。

Assign New

新規の変数に値を割り当てます。

Expression

式を実行します。

Call

関数をコールします。

For

Javaに類似したOracle RLにはforループがあります。forループには、変数とコレクションを持つ型が含まれています。型と変数により、ループ内で使用されるコレクション値を保持するループ変数が定義されます。コレクションは、ループ変数に適切な型のコレクションとして評価される式です。forループを使用すると、任意のコレクションを繰り返すことができます。

return、throwまたはhaltによってアクション・ブロックを終了できます。

If

if elseアクションを使用する場合、テストがtrueのときは、最初にアクション・ブロックを実行します。テストがfalseのときは、オプションのelse部分を実行します。これは別のifアクションやアクション・ブロックである場合もあります。Javaと異なり、Oracle RLにはアクション・ブロックが必要であり、単一のセミコロンの終了アクションは許可されていません。

Modify

一致したファクトに関連付けられているデータ値を変更します。

Retract

ファクトを取り消します。

Return

returnアクションは、関数またはルールのアクション・ブロックから戻ります。ルール内のreturnアクションはルールセット・スタックをポップするため、実行は現在ルールセット・スタックの最上部にあるルールセットからのアジェンダに対するアクティブ化に進みます。

rl

入力したOracle RL式を使用します。

synchronized

Javaと同様に、synchronizedアクションは複数のスレッドのアクションを同期化する際に役立ちます。synchronizedアクション・ブロックを使用すると、指定したオブジェクトのロックを取得してからアクション・ブロックを実行し、次にロックを解放できます。

throw

例外をスローします。例外はjava.lang.Throwableを実装するJavaオブジェクトである必要があります。スローされた例外は、tryアクション・ブロック内のcatchによって捕捉される場合があります。

try

Oracle RLのtry、catchおよびfinallyは、構文もセマンティクスもJavaに類似しています。catch句またはfinally句が1つ以上必要です。

while

テストがtrueの間にアクション・ブロックを実行します。return、throwまたはhaltによってアクション・ブロックを終了できます。

4.8.4 拡張モードの集計条件の使用方法

拡張モードでルールを作成する際に、ルール・デザイナではパターン一致集計オプションがサポートされます。1つのみのファクトではなく複数のファクトに基づくルール条件を記述する場合に、集計を使用できます。複数のファクトにわたるビューが条件に含まれている場合は、集計関数を使用します。

拡張モードの集計を使用するには:

  1. 集計関数を使用するルールまたはデシジョン表を選択または作成します。
  2. ルール名またはデシジョン表名の横にある「詳細設定の表示」ボタンをクリックします(「ルールまたはデシジョン表の詳細設定の表示と非表示を切り替える方法」を参照)。
  3. 「拡張モード」を選択して、使用するファクト・タイプを入力します。
  4. 「<パターンの挿入>」を選択してパターンを追加し、そのパターンを選択します。
  5. パターンを右クリックして「囲む」を選択します。「囲む」ダイアログが表示されます。
  6. 「囲む」ダイアログで、パターン・ブロックを選択します。「OK」をクリックします。
  7. パターンで、最初のフィールドを選択します。デフォルトでは、このフィールドには図4-54に示すように「(次の各ケース)」が含まれています。

    図4-54 詳細パターン一致オプションの追加

    図4-54の説明が続きます
    「図4-54 詳細パターン一致オプションの追加」の説明
  8. aggregateオプションを選択します。図4-55に示すように、集計用の状況依存フィールドが追加されます。

    図4-55 ルールでの集計関数の使用

    図4-55の説明が続きます
    「図4-55 ルールでの集計関数の使用」の説明
    • 「<関数>」をクリックし、リストから関数を選択します。

    • 条件で、「<ファクト・タイプ>」をクリックし、リストからファクト・タイプを選択します。

    • 「<式>」をクリックし、リストから式を選択します。

    ルール・デザイナでは、デフォルトで集計パターンの作成時に変数名が作成されます。作成中のルールに必要な場合は、デフォルトの変数名を置き換える変数名を入力します。図4-56に、集計を使用して完成したルールを示します。この例では、わかりやすくするためにルールには変数名total_costおよびitem_xが表示されています。

    図4-56 ルール内で完成した集計関数

    図4-56の説明が続きます
    「図4-56 ルール内で完成した集計関数」の説明
  9. 必要に応じてその他のテストを入力します。この例では、図4-57に示すように、赤色の品目のテストを入力します。

図4-57 赤色合計コスト・ルールでの集計関数の使用

図4-57の説明が続きます
「図4-57 赤色合計コスト・ルールでの集計関数の使用」の説明
4.8.4.1 集計関数の使用

表4-7に、使用可能な集計関数を示します。

表4-7 拡張モードのルール用の集計関数

機能 説明

count

一致するファクトのカウント。

average

一致するファクトの平均。

maximum

一致するファクトの最大値。

minimum

一致するファクトの最小値。

sum

一致するファクトの合計。

collection

一致するファクトのリストを作成します。

たとえば、次のような特別な注文を指定するルールを記述します。

IF 
   an order has more than 5 line items whose price is above a certain value
THEN 
   the order requires manual approval

5つの明細品目は複数のファクトにわたる場合があります。そのため、count集計関数を使用して、このサンプルの特別な注文規則を記述できます。

集計関数を使用する場合、次の手順を実行します。

  • パターンにaggregateを選択します。

  • 表4-7に示すリストから関数を入力します。

  • 値を入力するか、または状況依存メニューから選択します。

    • <variable>: 集計値の名前。

    • <expression> 集計する値(driver.age.など)。選択した集計関数がcount関数の場合、<expression>は使用しません。

たとえば、図4-58に示すように、赤色のすべての明細品目のコストの合計を計算できます。

図4-58 赤色合計コスト・ルールでの集計関数の使用

図4-58の説明が続きます
「図4-58 赤色合計コスト・ルールでの集計関数の使用」の説明

4.8.5 拡張モードのルールに関する必知事項

「拡張モード」のルールを使用する際には、次のような特殊ケースに注意する必要があります。

  • 集計を使用する場合、アクションにはパターン変数が表示されません。パターン変数は、「(次の各ケース...)」パターンを使用する場合のアクション・リストにのみ表示されます。したがって、「集計」、「次のケースがある」パターンまたは「次のケースがない」パターンには、パターン変数を表示できません。

  • 「拡張モード」を選択すると、詳細パターン一致などの詳細オプションをルールで使用しているかぎり、「拡張モード」は選択状態のままで非アクティブ(グレー表示)になっています。「拡張モード」をクリアするには、拡張モード機能を削除するか、または元に戻す必要があります(拡張モードではないルールを作成することからやり直し、その後で拡張モードのルールを削除するほうが容易な場合があります)。

4.8.5.1 拡張モード・オプションをクリアする方法
  1. 「拡張モード」をクリアするルールまたはデシジョン表を選択します。
  2. ルール名またはデシジョン表名の横にある「詳細設定の表示」ボタンをクリックします(「ルールまたはデシジョン表の詳細設定の表示と非表示を切り替える方法」を参照)。
  3. ルールの状態を考慮します。
    • ルールを簡素化して「拡張モード」オプションを有効化(「拡張モード」ボタンがグレー表示でなくなり有効になる)できる場合。ルールを簡素化して、「拡張モード」が有効になったら、「拡張モード」をクリアします。

    • 「元に戻す」を使用して「拡張モード」ルールを作成するために使用したステップを元に戻し、ルールを「拡張モード」ではない状態にできる場合は、この方法を使用してルールを簡素化します。

    • ルールを簡素化できない場合は、ルールを削除して再作成します。

4.9 拡張テストの使用

拡張テストは、複雑なルールを構築する場合に使用する必要があります。拡張テスト、つまり簡易モードは、拡張モード・ルールを置き換えます。

ノート:

「拡張モード」機能は、下位互換性のためにのみ維持されています。拡張モードの詳細は、「拡張モードのルールの使用」を参照してください。

拡張モードで実行できることはすべて、簡易モードで実行できるようになりました。UIは、図4-59に示すように、複雑なルールおよびテストをより簡単に作成できるように合理化され、向上しています。

図4-59 拡張テストのリスト

図4-59の説明が続きます
「図4-59 拡張テストのリスト」の説明

拡張モード・ルールは、「拡張モード」チェック・ボックスをクリアすることで同等の簡易モードに変換できます。

拡張テストは、一般的なルール、デシジョン表、およびビジネス・フレーズの定義中にのみ適用できます。それらは、動詞ルールでは表示されません。

4.9.1 拡張テスト・フォーム

元の4つのテスト(表4-8の最初に示す)に加えて、次の新しいフォームがあります。

表4-8 拡張テスト

フォーム 説明

簡易テスト

これは、条件のビルディング・ブロックです。値を、別の値、範囲またはセットと比較します。

例: Emp.salary > 1000

変数

変数を初期化します。

例: age = Duration.years between(Emp.birthdate,RL.date.get current())

ネストされたテスト()

包含ブロック内にテストをカプセル化します。

例: (age > 50 or Emp.salary > 50000)

否定されたテスト(...)

テストを否定します。

例: not(age > 50 and Emp.salary > 50000)

次のすべて

次のすべてがtrueです。

例: (age > 50 and Emp.salary > 50000)

次のいずれか...

次のいくつかがtrueです。例:

IF
  e is a Emp and  there is no Emp where     Emp.salary < e.salary     <insert test>  <insert test>THEN  assign e.isLowestPaid = true

ファクトを定義します。

例: eはEmpです

ブール式

ブール式をキャプチャします。

例: isEligible(Emp)

次のケースがある

このテストにはANDで接続された1つ以上の子テストがあります。

これらの子テストは、少なくとも1つのケースに対してすべてtrueです。1つのケースは、含まれる「は」テストへのファクトのバインディングです。

「は」子孫を持つ必要があります。

例:

There is a case where

e is a Emp and

d is a Dept and

e.salary > 1000000 and

d.name == "Marketing" and

d.employees contains e

次がある <factType1>,...<factTypeN> 条件#*

このテストにはANDで接続されたN個以上の子テストがあります。

非表示の「<factType><factType>」が最初のN個の子としてテストします。

これらの子テストは、少なくとも1つのケースに対してすべてtrueです。

表示される子テストがないことも有効です。その場合、「条件」キーワードは抑止されます。

例:

IF
  there is a Emp, Dept where
  Emp.salary > 1000000 and
  Dept.name == "Marketing" and
  Dept.employees contains Emp
THEN
  call print "there is a highly paid marketer!"
IF
there is a Emp
THEN  call print "somebody works here!"

次のケースがない

このテストにはANDで接続された1つ以上の子テストがあります。

この子テストはどのケースに対してもtrueになりません(含まれている「は」テストへのファクトのバインディングは、他のどのテストも満たしません)。

「は」子孫を持つ必要があります。

次がない <factType1>,...,<factTypeN> 条件

最初のN個の子としての非表示の「<factType><factType>」

これらの子テストは、どのケースに対してtrueになりません。

集計

このテストにはANDで接続された0個以上の子テストがあります。

「は」子を持つ必要があります(非表示の可能性あり)。

v is the sum|average|minimum|maximum|count|collection of<expression> where

表示される子テストがない場合、「条件」句は省略されます。

IF
  number of employees is the count of Emp
THEN
  call print "number of employees: " + number of employees
 
IF
  number of male employees is the count of Emp where
    Emp.gender == "M"
THEN
  call print "number of male employees: " + number of male employees

前述の両方のルールで、SDKによって、非表示のネストされた「は」テストがEmpに対して作成されることに注意してください。

明示的な「は」を使用することもできます。

IF
  number of male employees is the count of e where
    e is Emp and
    e.gender == "M"
THEN
  call print "number of male employees: " + number of male employees

図4-60は、「次のケースがある」フォームが使用されている例です。

図4-60 拡張テストの例1

図4-60の説明が続きます
「図4-60 拡張テストの例1」の説明

図4-61は、「次のケースがない」フォームが使用されている例です。

図4-61 拡張テストの例2

図4-61の説明が続きます
「図4-61 拡張テストの例2」の説明

複雑なルールの構築方法の詳細は、「ルールの使用」を参照してください。

4.10 ツリー・モードのルールの使用

ツリー・モードのルールを使用すると、親子関係にマップされるネストされた要素が存在するマスター・ディテール階層を容易に使用できます。

ビジネス・プロセスおよびルールを使用して小売発注書(PO)を処理するアプリケーション部分のライフサイクルについて考えます。発注書には、PO全体に適用される取引条件を含むヘッダーがあります。POには、出荷先のリストも含まれています。各宛先には、住所、宛先の住所に出荷される品目のリストおよび出荷のリストが含まれています。

すべての品目のステータスが出荷済または取消し済である場合に、POが完全に出荷済であるとする、というビジネス・ルールについて考えます。

図4-62に、POの例のサンプルXMLスキーマ表現を示します。POのXML文書はツリー構造になっています。これにより、POの自然な表現が可能になります。たとえば、PO自体は最上位レベルの文書要素であり、宛先は品目要素および出荷要素を含むネストされた要素です。出荷要素にも、注文された品目を参照する品目要素が含まれています。ステータスには、有効な値のリストがあります。

図4-62 ツリー・モードのルールのサンプルのPOスキーマ

図4-62の説明が続きます
「図4-62 ツリー・モードのルールのサンプルのPOスキーマ」の説明

次のサンプル発注書(PO)スキーマの例に、図4-62で示したサンプルの発注書のXMLスキーマを示します。

<?xml version= '1.0' encoding= 'UTF-8' ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.example.org"
targetNamespace="http://www.example.org"
     elementFormDefault="qualified">
    <xsd:element name="PO">
        <xsd:annotation>
            <xsd:documentation>A sample element</xsd:documentation>
        </xsd:annotation>
        <xsd:complexType>
            <xsd:sequence>
                <xsd:element name="header">
                    <xsd:complexType>
                        <xsd:attribute name="status" type="Status"/>
                        <xsd:attribute name="order-date" type="xsd:date"/>
                        <xsd:attribute name="customer-value"/>
                    </xsd:complexType>
                </xsd:element>
                <xsd:element name="billing">
                    <xsd:complexType>
                        <xsd:sequence>
                            <xsd:element name="address"/>
                            <xsd:element name="payment"/>
                        </xsd:sequence>
                    </xsd:complexType>
                </xsd:element>
                <xsd:element name="destination" maxOccurs="unbounded">
                    <xsd:complexType>
                        <xsd:sequence>
                            <xsd:element name="address"/>
                            <xsd:element name="item" maxOccurs="unbounded">
                                <xsd:complexType>
                                    <xsd:attribute name="ID"/>
                                    <xsd:attribute name="status"/>
                                    <xsd:attribute name="quantity" type="xsd:int"/>
                                    <xsd:attribute name="availability-date" type="xsd:date"/>
                                    <xsd:attribute name="qoh" type="xsd:int"/>
                                    <xsd:attribute name="price"
                                                   type="xsd:decimal"/>
                                </xsd:complexType>
                            </xsd:element>
                            <xsd:element name="shipment" minOccurs="0" maxOccurs="unbounded">
                                <xsd:complexType>
                                    <xsd:sequence>
                                        <xsd:element name="item" maxOccurs="unbounded">
                                            <xsd:complexType>
                                                <xsd:attribute name="ID"/>
                                                <xsd:attribute name="quantity"/>
                                            </xsd:complexType>
                                        </xsd:element>
                                    </xsd:sequence>
                                    <xsd:attribute name="ship-date"/>
                                    <xsd:attribute name="method"/>
                                </xsd:complexType>
                            </xsd:element>
                        </xsd:sequence>
                        <xsd:attribute name="status" type="xsd:string"/>
                    </xsd:complexType>
                </xsd:element>
            </xsd:sequence>
        </xsd:complexType>
    </xsd:element>
    <xsd:simpleType name="Status">
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="open"/>
            <xsd:enumeration value="partially shipped"/>
            <xsd:enumeration value="fully shipped"/>
        </xsd:restriction>
    </xsd:simpleType>
</xsd:schema>

4.10.1 サンプルのPOのXMLインスタンス(要約)

例4-1に、POスキーマのインスタンスのXMLの一部を示します。ツリー・モードのルールを使用するために、1つ以上の取引条件をテストするルールを作成でき、テストにパスした場合は1つ以上の取引条件が追加または変更されます。Oracle Business Rulesには、サンプルのPOインスタンスのようなファクト・ツリーでのエラーのないルール作成を有効化する特別なサポートがあります。

たとえば、次のように指定するPOスキーマのインスタンスのルール作成について考えます。

IF the time between the order date and the date for availability of an item is more than 30 days
THEN cancel the item

例4-1 サンプルのPOのXMLインスタンス(要約)

<PO xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.example.org ../../../../Temp/PO.xsd"
    xmlns="http://www.example.org">
  <header/>
  <billing>
    <address/>
    <payment/>
  </billing>
  <destination>
    <address/>
    <item ID="a01"/>
    <item ID="a02"/>
    <item ID="a03"/>
    <shipment>
      <item ID="a01"/>
      <item ID="a02"/>
    </shipment>
  </destination>
</PO>

4.10.2 ツリー・モードのルール(非拡張モード)

「拡張モード」オプションが選択されておらず、「ツリー・モード」が選択されている場合は、非拡張ツリー・モード、つまり単純ツリー・モードを使用します。このモードでは、ルール・デザイナにより、ルート・ファクト・タイプを入力するROOT: <fact type>が表示されます。

「ツリー・モード」を選択し、「拡張モード」をクリアしてルールを作成すると、修飾名を使用してツリー内のプロパティを参照できます。次に例を示します。

  • PO/destination/item.quantityitem.quantityに似ていますが、POのdestinationである品目のみが一致します。

  • PO$Destination$item.quantityList<item>を参照します。この参照は、非ツリー・モードから変更されていません。

単純ツリー・モードでは、選択できるのは多対多結合や集計を必要としない条件のみです。

詳細は、「単純ツリー・モードのルールの作成方法」を参照してください。

4.10.3 拡張ツリー・モードのルール

「拡張モード」オプションが選択されており、「ツリー・モード」オプションが選択されている場合は、拡張ツリー・モードを使用します。このモードでは、Rules Designerにより、図4-63に示すように、ルート・ファクト・タイプを入力するROOT: 「<ファクト・タイプ>」が表示されます。ルール・デザイナでは、ツリー構造のファクトのパターンが表示されますが、親ファクトと子ファクトを結合する単純テストは非表示です。

図4-63 拡張ツリー・モード

図4-63の説明が続きます
「図4-63 拡張ツリー・モード」の説明

拡張ツリー・モードでは、ツリー・モードのパターン(ルート以外)は次のように表示されます。

<演算子> <変数> is a <ファクト・パス>

<ファクト・パス>は、ルートから始まる1対1および1対多関係をたどるXPathに類似したパスです。たとえば、各ファクト・パスにはPO/destinationなどの名前が付いており、POはルート・ファクト・タイプで、destinationはタイプListのプロパティです。ファクト・パス内の1対多関係は、PO/destinationのように/で示されます。

ファクト・パス内の1対1関係は、.で示されます。これは非ツリー・モードから変更されていません。たとえば、item.availabilityDateです。

拡張モードはパターンの概念を公開しており、その最も単純な形式はis aパターンです。たとえば、p is a POではpはすべてのPOファクトと繰り返し一致し、d is a p/destinationではdpのすべてのdestinationと一致します。is aの左側は変数であり、右側はファクト・タイプまたはファクト・パスです。デフォルトでは、Oracle Business Rulesによってファクト・タイプまたはファクト・パスと等しい変数名が設定されます。たとえば、PO is a POです。パターンにはパターン・ブロックを使用することもできます。パターン・ブロックには、ブロック内でネストされたパターンおよびテストに適用される論理数量子、否定または集計があります。

詳細は、「拡張ツリー・モードのルールの作成方法」を参照してください。

拡張ツリー・モードのルールを使用する場合、ルール・デザイナでは、直積を回避しながら、様々な子フォレストからの条件を同じルールに結合するために、集計パターン(有無など)を使用する必要があります。

4.10.4 単純ツリー・モードのルールの作成方法

次の手順で、30日以内に入荷しない品目をキャンセルするPOルールを作成します。

IF the time between the order date and the date for availability of an item is more than 30 days
THEN cancel the item

単純ツリー・モードのルールを作成するには:

  1. ルールセットにIF/THENルールを作成し、詳細設定を表示します。

    一般的なルールの追加についての詳細は、「一般的なルールの追加方法」を参照してください。

    詳細設定の詳細は、「ルールまたはデシジョン表の詳細設定の表示と非表示を切り替える方法」を参照してください。

  2. 「ツリー・モード」を選択します。ROOTの横にある「<ファクト・タイプ>」プレースホルダをクリックし、リストから選択します。

    図4-64 単純ツリー・モード: ルートの構成

    図4-64の説明が続きます
    「図4-64 単純ツリー・モード: ルートの構成」の説明
    • 「<テストの挿入>」を選択し、リストから選択します。

      IF文がIF <オペランド> == <オペランド>となります。

    • 左の「<オペランド>」を選択し、リストからオプションを選択します。

  3. 図4-65のように、「式ビルダー」ボタンを選択します。

    図4-65 単純ツリー・モードの式の追加

    図4-65の説明が続きます
    「図4-65 単純ツリー・モードの式の追加」の説明
    • 「式ビルダー」ダイアログで、「式」領域に表示されている品目をコピーして削除します。

    • 式ビルダーで、「関数」タブを選択します。

    • ナビゲータで、「Duration」を開き、「daysbetween」関数をダブルクリックします。

    • daysbetween引数テンプレートを削除します。

    • 「daysbetween」関数の2番目の引数として前に切り取った値を貼り付けます。

    • 「式ビルダー」ダイアログで、「変数」タブを選択します。

    • 「daysbetween」関数の最初の引数について、ナビゲータを使用して「PO」を開き、「header」を開いて「orderDate」をダブルクリックします。

    • 「式ビルダー」ダイアログで「OK」をクリックします。

      詳細は、「式ビルダーの概要」を参照してください。

  4. リストで、「式」領域で[Enter]を押します。「operator」を選択して>を入力します。
  5. 図4-66に示すように、右の「<オペランド>」を選択し、値30を入力して[Enter]を押します。

    図4-66 単純ツリー・モード: 右オペランドの値30

    図4-66の説明が続きます
    「図4-66 単純ツリー・モード: 右オペランドの値30」の説明
    • 「<アクションの挿入>」をクリックし、リストから「modify」を選択します。

      THEN文がTHEN modify <ターゲット>となります。

    • 「<ターゲット>」をクリックし、リストから「PO/destination/item」を選択します。THEN文は次のようになります。

      THEN modify PO/destination/item ( <add property> )
      
    • 「<プロパティの追加>」をクリックします。「プロパティ」ダイアログが表示されます。

      「プロパティ」ダイアログで、図4-67に示すように、status名に値"canceled"を入力します。

      図4-67 単純ツリー・モード: アクション

      図4-67の説明が続きます
      「図4-67 単純ツリー・モード: アクション」の説明
  6. 「プロパティ」ダイアログで、「閉じる」をクリックします。

    図4-68に示すように、完成したルールが表示されます。

    図4-68 単純ツリー・モードのルールの最終的なルール

    図4-68の説明が続きます
    「図4-68 単純ツリー・モードのルールの最終的なルール」の説明

modify文では、PO/destination/itemは特定のitemインスタンス・メンバーを参照することに注意してください。

4.10.5 拡張ツリー・モードのルールの作成方法

次の手順で、次のように要約できる送料無料ルールを作成します。

IF the total cost of "free shipping eligible" items to a given destination is greater than $40
THEN shipping of those items is free

拡張ツリー・モードのルールを作成するには:

  1. ルールセット内にIF/THENルールを作成します。

    詳細は、「一般的なルールの追加方法」を参照してください。

  2. 詳細設定を表示します。
  3. 図4-69に示すように、「拡張モード」を選択し、「ツリー・モード」を選択します。

    図4-69 無料出荷用の拡張ツリー・モードのルール

    図4-69の説明が続きます
    「図4-69 無料出荷用の拡張ツリー・モードのルール」の説明
  4. 「<ファクト・タイプ>」プレースホルダを選択し、リストから「PO」を選択します。
  5. 図4-70に示すように、無料出荷ルールを完成します。

図4-70 拡張ツリー・モードの無料出荷ルール

図4-70の説明が続きます
「図4-70 拡張ツリー・モードの無料出荷ルール」の説明

4.10.6 ツリー・モードのルールに関する必知事項

「ツリー・モード」を選択し、ルート・ファクト・タイプを選択すると、オプション・リストには使用可能なすべてのファクト・タイプが表示されます(ルート・ファクト・タイプの子のみではありません)。これにより、ルート・ファクト・タイプの子以外にも使用可能なすべてのファクト・タイプを表示できます。選択したルート・ファクト・タイプの子のみを表示するようにオプション・リストを制限することはできません。

4.11 日付ファクトの使用、日付関数および有効日の指定

Oracle Business Rulesでは、時刻と日付の操作を容易にする機能が提供され、時刻と日付に基づいてルールがいつ有効かを決定できる有効日機能が提供されます。

  • CurrentDateファクトを使用すると、現在の日付を表すファクトに基づいて判断できます。

  • 「有効日」を使用すると、ルールセット内のすべてのルールとデシジョン表、個々のルールまたは個々のデシジョン表が有効な日付または日時の範囲を定義する開始日と終了日を指定できます。

表4-9に、使用可能な「有効日」のオプションを示します。

表4-9 有効日に可能な値

有効日 説明

常に有効

「開始」も「終了」も設定しないことを指定します。

開始(「終了」日付設定なし)

特定の日付から不特定の将来にかけて有効です。

終了(「開始」日付設定なし)

現在から特定の日付まで有効です。

「開始」設定と「終了」設定

2つの日付の間のみ有効です。

「常に」以外の有効日指定には、次のいずれかを使用できます。

  • 日付のみ指定、時間指定なし: この場合、有効日は各タイムゾーンの指定日の午前0時とみなされます。

  • 日付、タイムゾーンを指定、時間指定なし: この場合、有効日は指定のタイムゾーンの指定日の午前0時とみなされます。

  • 日付、タイムゾーン、時間を指定: この場合、日付と時間を完全に指定します。

  • 時間指定のみで、日付およびタイムゾーン指定なし: すべての日の指定の時間に適用されます。

  • 時間とタイムゾーンを指定、日付指定なし: すべての日の指定の時間に適用されます。

4.11.1 現在の日付ファクトの使用方法

ルールまたはデシジョン表で現在の日付ファクトを使用できます。

CurrentDateファクトを使用するには:

  1. 「ルールセット」ナビゲーション・タブで、ルールセットを選択します。
  2. ルールセット内のルールを選択します。
  3. 図4-71に示すように、「IF」領域で、CurrentDateファクトおよびCalendarタイプの日付メソッドを使用する条件を追加します。

    図4-71 CurrentDateファクトを使用する条件を持つルール

    図4-71の説明が続きます
    「図4-71 CurrentDateファクトを使用する条件を持つルール」の説明

4.11.2 有効日に関する必知事項

デフォルトでは、Oracle Business Rules Engineにより、CurrentDateファクトおよび有効日に関連付けられるクロックは暗黙的に管理され、それぞれシステム日付の値に設定されます。RL Language関数setCurrentDate()およびsetEffectiveDate()を使用すると、現在の日付および有効日を明示的に設定できます。詳細は、『Oracle Business Process Managementルール言語リファレンス』組込み関数に関する項を参照してください。

有効開始日とは、その日からルール、デシジョン表またはルールセットがルール評価と起動に関連させることができる日のことです。したがって、ルールが有効であれば条件が満たされた場合に起動でき、ルールが有効でなければ条件が満たされるかどうかに関係なく起動しません。

有効終了日とは、その日からルール、デシジョン表またはルールセットがルール評価に関連しなくなる日のことです(有効ではないということは、ルールが起動しないということを意味します)。

有効開始日と有効終了日はデシジョン表に設定できますが、デシジョン表内のルールに対して個別に設定することはできません。

ルールとデシジョン表には、「アクティブなルール」オプションも組み込まれています。このオプションは有効日に関係なく設定され、指定の有効日を変更または削除することなく日付を有効にします。「アクティブなルール」オプションの使用の詳細は、「アクティブ・オプションの選択方法」を参照してください。

ルールセットとルールセット内のルールまたはデシジョン表の両方に対して有効日が定義されている場合、その優先度は次のようになります(最上位の優先度は1です)。

  1. ルールセットの「アクティブなルール」オプションがクリアされている場合、そのエンティティのRL Languageは生成されません。

  2. ルールセットの有効日プロパティの一方または両方が選択されている場合、有効開始日と有効終了日では、ルールセット内に定義されているルールまたはデシジョン表について許可された有効日の範囲が定義されます(つまり、「有効日の設定」ダイアログでルールセットの「開始」チェック・ボックスおよび「終了」チェック・ボックスの一方または両方が選択されている場合)。

    したがって、ルールセット内のルールまたはデシジョン表について指定された有効日は、それを含んでいるルールセットによって設定された境界に違反できません。たとえば、ルールには、ルールセットについて指定された有効終了日よりも後の有効終了日を指定できません。

  3. 個別のルールまたはデシジョン表の「アクティブなルール」がクリアされている場合、そのルールまたはデシジョン表のRL Languageは生成されません。

  4. ルールセットの「有効日の設定」ダイアログの「時間」が選択されている場合、またはルールセット内のルールまたはデシジョン表についてこのオプションが選択されている場合、有効日を指定する際にはルールセット内のルールまたはデシジョン表の全インスタンスの「時間」を選択する必要があります。この場合、「両方」または「日付」が選択されている場合は、Rules Designerでは次の検証警告が表示されます。

    RUL-05742: Calendar form incompatibility detected with forms Time and DateTime.
    If the calendar form is set to Time on a rule set or any of the rules or
    decision tables within that ruleset then the calendar form for that entire
    rule set is restricted to Time.

4.11.3 Duration、JavaDate、OracleDateおよびXMLDateメソッドの使用方法

Duration、JavaDateおよびXMLDate、OracleDateおよびOracleDuration拡張メソッドをルールまたはデシジョン表で使用できます。詳細は、「Oracle Business Rulesの組込みクラスと関数」を参照してください。

Durationメソッドを使用するには:

  1. 「ルールセット」ナビゲーション・タブで、ルールセットを選択します。
  2. ルールセット内のルールを選択します(Durationメソッドはデシジョン表で使用することもできます)。
  3. 「IF」領域で条件を追加します。
  4. ルール条件のオペランドを選択します。
  5. リストから「式ビルダー」を選択します。詳細は、「式ビルダーの概要」を参照してください。
  6. 式ビルダーで、「関数」タブを選択します。
  7. 「式ビルダー」のナビゲータで、「Duration」フォルダを開きます。
  8. 間隔テストの必要に応じて、適切なメソッドをダブルクリックして選択および挿入します。
  9. 適切な引数をメソッドに指定します。図4-72に示す例を参照してください。
  10. 「OK」をクリックしてルールを確認します。

図4-72 ルールでのDurationメソッドの使用

図4-72の説明が続きます
「図4-72 ルールでのDurationメソッドの使用」の説明

4.12 式ビルダーの概要

Rules Designerの様々な部分から式ビルダーにアクセスできます。たとえば、「グローバルの編集 -」ダイアログや、デシジョン表内で条件を操作するときの「条件」領域、および自由形式の式を選択して拡張モードでルールとデシジョン表を入力するときなどです

式ビルダーを使用して、Oracle Business Rules用の式を作成したり編集できます。

図4-73に、ルール・デザイナの式ビルダーを示します。

図4-73 ルール・デザイナの式ビルダー

図4-73の説明が続きます
「図4-73 ルール・デザイナの式ビルダー」の説明

4.12.1 式ビルダーの使用方法

式ビルダーでは、「変数」または「関数」ナビゲーション・ツリー、または「演算子」タブ、または「定数」タブで項目をダブルクリックすると、項目は「式」領域の式に挿入されます。また、「式」領域でテキストを入力して、式を直接作成または編集することもできます。

式を入力するときは、「変数」は有効な割当ターゲットであり、「定数」は有効な割当ターゲットではないことに注意してください。そのため、作成する式に追加する項目のタイプが明確ではない場合は、両方のタブを使用する必要があります。

「式」フィールド内の関数にカーソルを置き、挿入する式または関数をダブルクリックして、選択した関数の引数を指定します。たとえば、関数のカッコ内にカーソルを置いて変数を選択します。これにより、カーソル位置にある式に変数が挿入されます。

4.12.2 式の使用に関する必知事項

XMLファクト・タイプを使用すると、ルールを記述する際にXMLスキーマのタイプ、要素および属性を使用できます。XMLスキーマに定義されている要素およびタイプをデータ・モデルにインポートし、Javaファクト・タイプやRLファクト・タイプの場合と同様にルールおよびデシジョン表の作成に使用できます。XMLスキーマ定義およびXMLファクト・タイプの間のマッピングには、Java Architecture for XML Binding (JAXB)が使用されます。Oracle Business Rulesでは、デフォルトでOracle Application Serverに同梱されているJAXB 2.0を使用します。JSR-222に定義されているJAXBは、XMLスキーマ定義内のタイプ、名前、規則および、Javaで使用可能なタイプ、許可される名前、規則の間のマッピングを提供します。たとえば、xsd:integerタイプのorder-idという要素は、BigInteger型のorderIDというJava Beanプロパティにマップされます(xsd:intタイプはJavaのintにマップされます)。

Oracle Business Rulesでは式を使用できます。式を使用することで、*+/%、およびプリミティブな数値に対してサポートされたその他の演算子(doubleintなど)や、組込みディクショナリで使用できる数値タイプIntegerLongShortFloatDouble BigDecimalBigIntegerを使用して算術計算ができます。

式を使用すると、任意の2つの数値タイプ間でキャストを行うことができます。たとえば、(short)((BigInteger)1 + (Long)2)のようになります。次のコード例に、タイプとキャストを使用したアクションのその他のサンプル式を示します。

assign new double db = 3.3
assign new BigDecimal bd = 3.3  // no cast required
assign db = bd // no cast required
assign bd = (BigDecimal)db // cast is required 

式プロセッサは型の昇格にXPath/Xqueryルールを使用します(XML Path Language (XPath) 2.0)。たとえば、BigDecimalfloat/doubleに昇格します。別方向へのタイプの昇格にはキャストが必要です(3.3などのリテラルを除く)。

4.13 値セットをルールのオプション値の制約として使用する方法

値リスト値セットと範囲リスト値セットを使用して、ルール内のビジネス条件に対する制約を指定できます。これにより、ルール・デザイナを使用して、指定値が範囲外の場合や、値セットで指定された候補値セットの範囲内にない場合に、可能性のあるエラーに関する検証警告を生成できます。

Oracle Business Rulesでは、値セットを使用して、グローバル初期値、関数の戻り値または関数の引数値の制約を指定することもできます。詳細は、「Oracle Business Rulesグローバルの使用」および「値セットのビジネス条件との関連付け」を参照してください。

4.13.1 範囲リスト値セットをビジネス条件の制約として使用する方法

範囲リスト値セットは、関数結果以外のビジネス条件の制約として使用できます。

値リスト値セットを制約として使用する方法の詳細は、「値リスト値セットをファクト・プロパティの制約として使用する方法」を参照してください。

範囲リスト値セットをファクト・プロパティの制約として使用するには:

  1. 「値セット」タブで、値セットをダブルクリックし、「値セットの編集」ダイアログを開きます。
  2. 対象となる範囲を含んだ値セットを指定し、有効なすべての範囲について「アクションで許可済」を選択します。範囲を含めるには、最上部と最下部のエンドポイントについて「アクションで許可済」をクリアします。
  3. アプリケーションに必要な場合は「含まれるエンドポイント」を選択します。
  4. 「許可されない値をテストに含める」をクリアします。たとえば、有効な等級を定義し、かつ100より大きいまたは0未満の値を許可しない値セットの場合は、値セット・エンドポイントを定義します。

    図4-74 ファクト・プロパティに対する有効な値セット

    図4-74の説明が続きます
    「図4-74 ファクト・プロパティに対する有効な値セット」の説明
  5. この値セットをビジネス条件と関連付けます。この例では、test_math1と値セットを関連付けます。

これで、このファクト・プロパティを使用するテストでルールを定義すると、値が範囲外の場合に検証警告が表示されます。たとえば、値-10の式でルールを定義すると、ルール・デザイナに検証警告が表示されます。

4.13.2 値リスト値セットをファクト・プロパティの制約として使用する方法

値リスト値セットをファクト・プロパティの制約として使用できます。

範囲リスト値セットを制約として使用する方法の詳細は、「範囲リスト値セットをビジネス条件の制約として使用する方法」を参照してください。

値リスト値セットをファクト・プロパティの制約として使用するには:

  1. 対象となる値を含んだLOV値セットを指定し、有効なすべての値について「アクションで許可済」を選択します。詳細は、「値リスト・グローバル値セットの定義方法」を参照してください。
  2. otherwise値セットについて「アクションで許可済」をクリアします。
  3. 「許可されない値をテストに含める」をクリアします。
  4. この値セットをファクト・プロパティに関連付けます。

4.13.3 値セットを使用してテスト式のオプションを指定する方法

LOV値セットを使用して、式およびアクションのオプションを指定できます。

値セットを使用してルール式およびアクションのオプションを指定するには:

  1. ルール・デザイナで、ファクト・プロパティに対応するタイプのLOV値セットを定義します。詳細は、「値リスト・グローバル値セットの定義方法」を参照してください。
  2. この値セットをファクト・プロパティに関連付けます。詳細は、「値セットをファクト・プロパティに関連付ける方法」を参照してください。
  3. 式を入力すると、ルール・デザイナにより「values options」に値が表示されます。たとえば、ファクト・プロパティDriver.eye_testeyesというLOV値セットに値passfailおよびglasses_requiredで関連付け、テスト式でDriver.eye_testを使用した場合、値は制限されます。

4.14 ランタイム・ルールの変更内容のリポジトリからJDeveloperへのインポート

SOAコンポーザで実装されているルールに対する変更をJDeveloperにインポートします。

SOAコンポーザのディクショナリに変更を行った場合は、「Oracle Business Rulesディクショナリの変更のパブリッシュ」に示すように、その変更内容をMDSリポジトリにアップロードする必要があります。ただし、これらの変更はJDeveloperでは更新されません。MDSリポジトリからJDeveloperに、変更内容を手動でインポートする必要があります。

JDeveloperに変更内容をインポートする手順は、次のとおりです。

  1. アプリケーション・ナビゲータで変更を行ったルールを選択します。
  2. 図4-75に示すように、ルール・エディタで「MDSからインポート」ボタンをクリックします。

    図4-75 MDSリポジトリからの変更のインポート

    図4-75の説明が続きます
    「図4-75 MDSリポジトリからの変更のインポート」の説明
  3. 「ディクショナリのインポート」ダイアログからMDSリポジトリを選択します。
  4. 「OK」をクリックします。

    JDeveloperで変更内容が更新され、ルール・エディタに変更内容が表示されます。

4.15 データ・モデルが深い場合のルールのモデル化方法

次のヒントを使用して、複雑すぎるルールを回避してください。

  • ルール・テスト変数(インライン・エイリアス)を使用して、簡易テストを作成します。

  • どの1:1接頭辞も、ファクト・パスから削除できます。

ルール・テスト変数:

ルール・テスト変数(インライン・エイリアス)を使用して、簡易テストを作成します。これは、深いデータ・モデルがある場合のルールのモデル化に役立ちます。

たとえば、ルールが次のようになっているとします。

IF
task/payload/purchaseOrder/line.amount > 100
THEN
modify ...

次のように書き換えることができます。

Root: task 
IF 
amount = task/payload/purchaseOrder/line.amount and 
amount > 100.0 
THEN
modify ... 

(OR)

Root: task 
IF 
line = task/payload/purchaseOrder/line and line.amount > 100.0 and line.amount < 1000.0 
THEN 
modify ...

1:1接頭辞を削除します。

どの1:1接頭辞もファクト・パスから削除できる(それがテストで参照されていない場合)ことに注意してください。たとえば、タスクに最大で1ペイロードがあり、1ペイロードに最大で1つの発注書があり、テストがそのタスクもそのペイロード属性も参照していないとわかっている場合、次のように短い例を使用できます。

Root: PurchaseOrder 
IF 
line = PurchaseOrder/line and 
line.amount > 100.0 and line.amount < 1000.0 
THEN 
...

リレーションシップが1:多であり、どのタスクまたはペイロードにどの発注書が含まれているかを考慮しない場合は、短いパスを使用することもできます。単にすべての発注書を処理することを望んでいます。