ページの先頭行へ戻る
Interstage Big DataComplex Event Processing ServerV1.0.0 ユーザーズガイド
Interstage
第5章 開発 > 5.4 設計 > 5.4.4 ルール定義の設計
前次

5.4.4 ルール定義の設計

ルール定義は、高速フィルター処理で使用するフィルタールールと、複合イベント処理で使用する複合イベント処理ルールの2種類のルールから構成されます。

ここでは、ルールの設計時の留意事項や作成手順など、以下の項目について説明します。

5.4.4.1 高速フィルター処理

高速フィルターで使用するフィルタールールを定義します。

フィルタールール作成時の留意項目

フィルタールール作成において留意すべき項目は以下の通りです。

フィルタールールの処理パターン

高速フィルターでは、フィルタールールを定義することで、イベントの抽出や、マスタデータと組み合わせた抽出処理、および連結処理を記述できます。高速フィルターの出力が、そのまま複合イベント処理の入力となります。

高速フィルターで行う処理は、通常、以下の4パターンと、その組み合わせで表現されます。

5.4.4.1.1 抽出処理

入力イベントから、フィルタールールのif-then文に記述した条件に適合するイベントを抽出します。

大量のイベントの中から必要なイベントだけ抽出したい場合に検討します。

例

抽出処理の例

イベントに含まれる内容（value）を使ってイベントを抽出する例です。

抽出条件として、「value > 10」を定義しています。

作成するルール

上記の例で作成するルールは以下の通りです。

on 入力イベントタイプID {
    if ($value > 10) then output() as 入力イベントタイプID;
}

  • 入力イベントタイプIDは、対象となるイベントタイプ定義の開発資産IDです。

参考

出力するイベントの項目内容を絞り込む

出力するイベントの項目を絞ることも可能です。以下は、前述の例において、keyだけ出力する例です。

入力イベントと異なる形で出力する場合は、対応するイベントタイプ定義（フィルター済み）も必要になります。

詳細については、「開発リファレンス」の「2.7 出力式の書式」を参照してください。

on 入力イベントタイプID {
    if ($value > 10) then output($key) as 出力イベントタイプID;
}

  • 入力イベントタイプIDは、対象となるイベントタイプ定義の開発資産IDです。

  • 出力イベントタイプIDは、項目を絞った結果を表すイベントタイプ定義（フィルター済み）の開発資産IDです。

5.4.4.1.2 マスタデータ照合による抽出処理

入力イベントに含まれるIDやコードなどの値をもとに、マスタデータ(CSVファイル)の該当エントリーを照合し、該当エントリーの値に基づいてイベントを抽出します。

大量のイベントの中から必要なイベントだけ抽出したいが、イベントの中に抽出に必要な情報が含まれていない場合に検討します。

このパターンの処理を行う場合は、マスタ定義の設計も必要です。

例

マスタデータ照合による抽出処理の例

イベントに含まれるkeyを元に、対応するマスタデータのエントリーを参照し、エントリーの中のaddressの値に基づいてイベントを抽出する例です。抽出条件として「address=="福岡"」を定義しています。

作成するルール

上記の例で作成するルールは以下の通りです。

on 入力イベントタイプID {
    if (lookup("マスタ定義ID", $key == $key, string($address)) == "福岡") then output() as 入力イベントタイプID;
}

  • 入力イベントタイプIDは、対象となるイベントタイプ定義の開発資産IDです。

  • マスタ定義IDは、参照するマスタデータに対応するマスタ定義の開発資産IDです。

  • $addressを文字列として比較するため、string($address)で値を取り出しています。

  • $key == $key の左辺は入力イベントの key、右辺はマスタデータの key になります。

注意

lookupにより照合しただけでは入力イベントにマスタデータの情報は付与されません。マスタデータとの結合処理が必要な場合は連結式(join)の記述が必要です。結合処理については、「5.4.4.1.3 マスタデータとの結合処理」を参照してください。

5.4.4.1.3 マスタデータとの結合処理

入力されたイベントと、マスタデータを連結します。次の複合イベント処理で必要なデータを付与したい場合に検討します。

結合した結果を複合イベント処理に渡すためには、結合結果に対応するイベントタイプ定義(フィルター済み)も必要です。

例

マスタデータとの結合処理の例

イベントに含まれるkeyを元に、対応するマスタデータを結合して、イベントにaddressを付与した例です。

作成するルール

上記の例で作成するルールは以下の通りです。

on 入力イベントタイプID {
    join("マスタ定義ID", $key == $key) output($key, "マスタ定義ID".$address) as 出力イベントタイプID;
}

  • 入力イベントタイプIDは、ルールの対象となるイベントタイプ定義の開発資産IDです。

  • マスタ定義IDは、参照するマスタデータに対応するマスタ定義の開発資産IDです。

  • 出力イベントタイプIDは、結合した結果を表すイベントタイプ定義（フィルター済み）の開発資産IDです。

5.4.4.1.4 文章の重み付け処理

マスタデータにキーワードへの重み付けを登録しておくことで、入力イベントの文章に重み付けを行うことが可能です。これにより、重み付けの合計が閾値より大きいイベントだけを抽出したり、閾値より大きいイベントを連続して発信していることを検知したりすることができます。

例

文書の重み付け処理の例

イベントに含まれる文章の内容に、マスタデータに定義された検索ワードが含まれているなら、含まれている検索ワードの数と、検索ワードごとに設定された重みの合計値を付与して出力します。

作成するルール

上記の例で作成するルールは以下の通りです。

on 入力イベントタイプID {
    join("マスタ定義ID", $message = $word)
        output($ID, 
               $subject,
               "マスタ定義ID".$word,
               "マスタ定義ID".$weight,
               lookup_count("マスタ定義ID".$word),
               lookup_sum("マスタ定義ID".$weight)) as 出力イベントタイプID;
}

  • 入力イベントタイプIDは、ルールの対象となるイベントタイプ定義の開発資産IDです。

  • マスタ定義IDは、参照するマスタデータに対応するマスタ定義の開発資産IDです。

  • 出力イベントタイプIDは、結合した結果を表すイベントタイプ定義（フィルター済み）の開発資産IDです。

5.4.4.2 複合イベント処理

複合イベント処理で使用するルールを定義します。

複合イベント処理ルール作成時の留意項目

複合イベント処理のルール作成において留意すべき項目は以下の通りです。

複合イベント処理ルールの作成手順

複合イベント処理ルールの作成手順について、例を挙げて説明します。

  1. 複合イベント処理で実現したい内容の検討

    複合イベント処理で実現したいことを決定します。この時点ではやりたい事が明確でなくても、収集したイベントを分析することによって、実現したいことが見つかる場合もあります。

    例

    ルールの例

    「在宅時に雨が降りそうな場合は、洗濯機の乾燥機能の使用をレコメンドする。」

  2. イベント、参照する外部データ、出力内容の検討

    ルール作成に必要なイベント、参照用の外部データ、および出力内容について、検討します。また、イベントをメモリ内に保持しておくための名前付きウィンドウについて検討します。

    例

    イベント、外部データ、出力の例

    前述のルール例では、以下のイベント、外部データ、出力内容が考えられます。

    • イベント

      • テレビ操作イベント
        各家庭のホームゲートウェイから送られる家電イベントデータのうち、機器カテゴリのプロパティ値がTelevisionのものとします。

      • 天気予報イベント
        予報は時間と天気で表すものとします。

    • 外部データ

      • 洗濯機の機種情報（乾燥機能の有無）
        ホームゲートウェイのIDから、その家庭の洗濯機の乾燥機能の有無がわかるものとします。

    • 出力内容

      • レコメンド対象の家庭のホームゲートウェイID

      • レコメンド内容

    • 名前付きウィンドウ

      • 天気予報イベント用名前付きウィンドウ
        天気予報イベントを時刻ごとに1日保持することにします。

  3. 処理内容の詳細化

    イベントやそれを検知する複合イベント処理の内容を詳細化(具体化)します。

    ここでの詳細化とは、日常言語で表現された“やりたい事”を、イベントや複合イベント処理の条件、外部データなどの具体的な情報を利用することで、作成するルールに近づけた表現にする作業です。

    例

    複合イベント処理の内容を詳細化する例

    「在宅時に雨が降りそうな場合は、洗濯機の乾燥機能の使用をレコメンドする。」というルールを詳細化すると以下のようになります。

    ルールの構成要素

    詳細化した処理内容

    「在宅時」

    テレビ操作を行った家庭を在宅と判断します（テレビ操作を知らせるイベントを検知します）。

    「雨が降りそう」

    名前付きウィンドウに格納された天気予報情報を参照し、天気予報の時刻と、テレビの操作時刻から、今後雨となる予報が出ているかどうかを確認します。

    「洗濯機の乾燥機能」

    ホームゲートウェイに接続している洗濯機の製品情報を、XTPのキャッシュから取得します。

    「レコメンドする」

    雨予報の場合、洗濯機に乾燥機能がなければ、洗濯物の部屋干しをレコメンドします。

    洗濯機に乾燥機能があれば、乾燥機能の利用をレコメンドします。

  4. イベントフロー図の作成

    処理内容の詳細化が完了したら、イベント処理の流れをまとめてイベントフロー図を作成します。イベントフロー図は、イベントとその処理内容のつながりを図で示したものです。実現しようとする処理内容を確認する上でも役立つため、複合イベント処理ルール言語で処理を記述する前に作成する事を推奨します。

    参考

    イベントフロー図の凡例

    本書で使用するイベントフロー図の凡例です。

    例

    イベントフロー図の例

    「在宅時に雨が降りそうな場合は、洗濯機の乾燥機能の使用をレコメンドする。」のイベントフロー図です。

    1. 天気予報イベントを保持するための名前付きウィンドウを作成します。

    2. 洗濯機の乾燥機能の有無を調べるための名前付きウィンドウ（XTPのキャッシュ）を作成します。

    3. 天気予報イベントを天気予報ウィンドウに格納します。

    4. 家電イベントからTV操作のイベントを検知します。

    5. TV操作のイベントの発生時間から今後の天気予報を確認し、雨予報の場合だけイベントを残します。

    6. TV操作が行われ、かつ天気予報が雨の家庭について洗濯機機能ウィンドウを検索し、洗濯機の乾燥機能のあり/なしに応じてレコメンドすべき情報を付加してユーザー開発Webサービスに送信します。

    7. ユーザー開発Webサービスでは、受け取った情報をもとに、家庭にレコメンドを送信します。ユーザー開発Webサービスでは、同じ家庭に一定期間同じレコメンドを行わないように制御します。

  5. 複合イベント処理ルールの作成

    イベントフロー図のそれぞれの要素に対応させて、複合イベント処理ルールを記述します。

    例

    イベントフロー図に対応する複合イベント処理ルールの例

    ルールの意味については、「開発リファレンス」の「第1章 複合イベント処理言語リファレンス」を参照してください。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    // 1.天気予報イベント用の名前付きウィンドウ作成
    @Name('WeatherWin')
    create window WeatherForecastWin.std:unique(FORCASTIME).win:time(1 day)
      (FORCASTIME long, WEATHER string);
     
    // 2. 洗濯機の乾燥機能の有無を確認するための名前付きウィンドウを作成
    @VDW(cacheName='ProductFuncCache', keyProperty='gatewayId')
    create window ProductFuncWin.isxtp:vdw() as (gatewayId string, dryFunc string);
     
    // 3.天気予報イベントを名前付きウィンドウに登録
    @Name('InputWeather')
    insert into WeatherForecastWin
      select weathfore.FORCASTIME as FORCASTIME, weathfore.WEATHER as WEATHER
        from WeatherForecastEvent as weathfore;
     
    // 4.TV操作イベントを検知
    @Name('ChkTVEvent')
    insert into TVControl
      select heevnt.gatewayId as gatewayId, heevnt.updateTime as updateTime from HEEvent as heevnt
        where heevnt.deviceCategory = 'Television';
     
    // 5.TV操作時点の天気確認（雨予報を検出）
    // 天気予報の時間帯は以下の式で判定。FORCASTIMEはlong（ミリ秒）を想定
    // 天気予報の時刻 <= TVControlのupdateTime <= 天気予報の時刻＋1時間(3600000ミリ秒)
    @Name('GetRainyEvent')
    insert into TVControlRain
      select tvevnt.gatewayId as gatewayId
        from TVControl as tvevnt unidirectional, WeatherForecastWin as weather
        where updateTimeToMillis(tvevnt.updateTime) between weather.FORCASTIME 
              and (weather.FORCASTIME + 3600000) 
              and weather.WEATHER = 'rainy';
     
    // 6.洗濯機の乾燥機能有無確認とレコメンド送信
    // ProductFuncWin の dryFunc プロパティが乾燥機能有無を示す（'1'：あり）
    // SOAPリスナにより出力をアプリケーションに送信
    // ‘USE_DRY_FUNC’ = 乾燥機能がある場合のレコメンドID
    // ‘HANG_LAUNDRY_INSIDE’ = 乾燥機能がない場合のレコメンドID
    // ロギングリスナにより出力をロギングする
    //    table='ログ格納領域'
    //    properties='出力するプロパティ名（出力結果）をカンマ区切りで設定'
    @Name('PutRecommend')
    @SoapListener('soap-001')
    @LoggingListener(table='/logsoap',properties='gatewayId,recommendId')
    select tvevnt.gatewayId as gatewayId,
      case when product.dryFunc = '1' then 'USE_DRY_FUNC' else 'HANG_LAUNDRY_INSIDE' end as recommendId
      from TVControlRain as tvevnt, ProductFuncWin as product
      where product.gatewayId = tvevnt.gatewayId    ;

5.4.4.3 SOAPリスナ

複合イベント処理文の処理結果をSOAPでユーザー開発Webサービスに送信するには、SOAPリスナを使用します。

SOAPリスナを使用するには、処理結果を送信したい複合イベント処理文(select文)の前に、@SoapListenerアノテーションを付与します。

処理結果の送信先や、SOAPメッセージの内容についての詳細は、「5.4.8 SOAPリスナ定義の設計」を参照してください。

構文

@SoapListener("SOAPリスナ定義ID")
複合イベント処理文(select文)
SOAPリスナ定義ID

処理結果を送信するWebサービスの送信先URLなどを定義した、SOAPリスナ定義の開発資産IDを指定します。

複合イベント処理文(select文)

処理結果を送信したい複合イベント処理文(select文)です。

5.4.4.4 ロギングリスナ

複合イベント処理文の処理結果をロギング機能でイベントログに記録したい場合は、ロギングリスナを使用します。

ロギングリスナを使用するには、処理結果を記録したい複合イベント処理文(select文)の前に、@LoggingListenerアノテーションを付与します。

構文

@LoggingListener(table="ログ格納領域", properties="出力するプロパティ名")
複合イベント処理文(select文)
ログ格納領域

イベントログが記録される、Hadoopシステム内でのパスを絶対パスで指定します。

CEPサーバのエンジンログにイベントを記録する場合（エンジン構成ファイルのtype要素にfileを指定した場合)であっても、イベントを識別するための、スラッシュ(/)から始まる仮想的なパス名（例：“/イベント名”）を指定してください。

注意

tableの指定は必須です。table=""のように、空の値を指定してもCEPエンジンは正常に起動しますが、ロギングは行われません。

出力するプロパティ名

select文の処理結果のうち、ロギングするプロパティ名を指定します。コンマ(,)で区切って複数のプロパティを指定することも可能です。

処理結果がネストしたプロパティの場合、ネストしたプロパティの間をピリオド(.)で連結します。

例

parentプロパティにchildプロパティがネストしている場合

以下のようにparentプロパティとchildプロパティがネストしている場合、childプロパティを指定するには「parent.child」と記述します。

<root>
    <parent>
        <child>aaa</child>
    </parent>
</root>

注意

propertiesの指定は必須です。properties=""のように、空の値を指定してもCEPエンジンは正常に起動しますが、ロギングは行われません。

複合イベント処理文(select文)

処理結果をロギングで記録したい複合イベント処理文(select文)です。

注意

  • イベントタイプ定義で定義するロギングと、ルール定義（ロギングリスナ）で定義するロギングは、出力先となるログ格納領域を分けることが可能です。しかし、異なるHadoopシステムへロギングする事はできません。

  • 出力プロパティの値がnullの場合、空白に変換してイベントログに出力します。

  • 出力プロパティが数値項目の場合、文字列変換してイベントログに出力します。

  • 存在しない出力プロパティ名を指定した場合、空白をイベントログに出力します。

  • データにダブルクォート(")がある場合、データ内にあるダブルクォートを重ねて出力します。

    aa"bb"aaの出力例:

    "aa""bb""aa"
前次
Copyright 2012 FUJITSU LIMITED