ページの先頭行へ戻る
Interstage Big DataComplex Event Processing Server V1.1.0 ユーザーズガイド
FUJITSU Software

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 o
utput() as 入力イベントタイプID;
}
  • 入力イベントタイプIDは、対象となるイベントタイプ定義の開発資産IDです。

参考

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

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

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

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

on 入力イベントタイプID {
if ($value > 10) t
hen 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 マスタデータとの結合処理

入力されたイベントと、マスタデータを連結します。次の複合イベント処理で必要なデータを付与したい場合に検討します。複合イベント処理ルールでRDB参照を行うよりも高速な結合処理が可能です。

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

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

イベントに含まれる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. 処理内容の詳細化

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

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

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

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

    ルールの構成要素

    詳細化した処理内容

    「在宅時」

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

    「雨が降りそう」

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

    「洗濯機の乾燥機能」

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

    「レコメンドする」

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

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

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

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

    参考

    イベントフロー図の凡例

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

    イベントフロー図の例

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

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

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

    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. 洗濯機の乾燥機能の有無を確認するための名前付きウィンドウを作成
    create window ProductFuncWin.vdw:ehcache('ProductFuncCache', 'gatewayId')
    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 unidirectional, ProductFuncWin as product
    where product.gatewayId = tvevnt.gatewayId
    ;

5.4.4.3 Terracotta連携

ここでは、Terracotta連携を行う場合の留意点と、その利用方法について説明します。

5.4.4.3.1 Terracotta連携を利用する場合の留意点

複合イベント処理の外部データ参照において、Terracotta連携を利用する場合に留意すべき項目について説明します。

5.4.4.3.2 Terracottaのキャッシュの構成情報ファイルの準備

Terracottaのキャッシュ(Ehcacheと呼びます)をVirtual Data Window機能により利用するためには、Ehcacheの構成情報ファイル(ehcache.xml)をCEPサーバに配置しておく必要があります。Ehcacheの構成情報ファイルは以下の場所に配置します。

/etc/opt/FJSVcep/config/ehcache.xml

Ehcacheの構成情報ファイルに関する詳細はTerracottaのマニュアルを参照してください。以下には、Terracotta連携機能で必須となる設定項目について説明します。

要素または属性

説明

ehcache

構成情報ファイルのルート要素です。

name

キャッシュを作成するときに指定した、キャッシュマネージャーの名前を指定します。

maxBytesLocalHeap

使用するデータプールのサイズです。

terracottaConfig

Terracottaサーバを定義するための要素です。

url

Terracottaサーバを「ホスト名またはIPアドレス:ポート番号」の形式で、カンマ(,)区切りで列挙します。

cache

キャッシュを定義するための要素です。

1つのehcache要素内に複数のcache要素を記述できます。

name

キャッシュの名前です。vdw:ehcacheで指定するキャッシュ名になります。

terracotta

Terracottaサーバを使用するために定義します。

nonstop

ノンストップキャッシュとして使用するために定義します。

immediateTimeout

ネットワーク切断を検出した時点でタイムアウトの対応を行うかどうか指定します。値にtrueを指定します。

timeoutMillis

タイムアウトになるまでの待機時間を指定します。

timeoutBehavior

タイムアウトが発生したときの動作を指定します。

type

値にexceptionを指定します。

searchable

キャッシュに対して検索を実施するために定義します。

以下に、2台のTerracottaサーバ(192.168.1.1と192.168.1.2)上に構成されたキャッシュCache001をTerracotta連携で使用する場合の例を示します。

<?xml version="1.0" encoding="UTF-8"?>
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd"
name="SearchConfig"
maxBytesLocalHeap="64M"
>
<terracottaConfig url="192.168.1.1:9510,192.168.1.2:9510"/>
<cache name="Cache001">
<terracotta>
<nonstop immediateTimeout="true" timeoutMillis="3000">

<timeoutBehavior type="exception"/>

</nonstop>

<searchable />
</cache>
</ehcache>

5.4.4.3.3 Terracottaのキャッシュの利用方法

Virtual Data Windowの作成方法と、作成したVirtual Data Window の利用方法について説明します。

Virtual Data Windowの作成

複合イベント処理ルールからTerracottaのキャッシュを利用するには、ルール中でVirtual Data Window(以降VDW)を作成します。

具体的には、以下のように記述します。

構文:イベントタイプIDを利用する場合

create window ウィンドウ名.vdw:ehcache("キャッシュ名","キープロパティ名")as イベントタイプID;

構文:型情報を直接指定する場合

create window ウィンドウ名. vdw:ehcache("キャッシュ名","キープロパティ名") as (プロパティ名 , プロパティ名 , ...);

Virtual Data Window (VDW)作成の記述例

Terracottaのキャッシュ(MARKET)を参照するVDW(MarketWindow)の作成例です。

create window MarketWindow.vdw:ehcache("MARKET", "code") as (code string, high int, low int);
  • キープロパティとしてcodeを指定しています。

  • プロパティとして、code(string型)、high(int型)、low(int型)を定義しています。


Virtual Data Windowの利用

作成したVirtual Data Windowは、通常のウィンドウと同じように利用します。ただし、キャッシュデータへのアクセスでは、insert into句、unidirectionalを指定した結合(join)、on select文、on update文、on delete文、on merge文、副問合せを使用します。

作成したVirtual Data Window(VDW)の使用例

MarketEventのイベントをVDWに挿入する例です。

insert into MarketWindow select code, high, low from MarketEvent;

TicketEventのイベントを契機に、VDWのMarketWindowを参照し、条件に合うVDWのイベント(キャッシュのエントリー)のデータを取得する例です。この例ではTicketEventを契機とするために、TicketEventにunidirectionalを指定して結合(join)しています。

select W.high, W.low from TicketEvent as Input unidirectional, MarketWindow as W
where W.code = Input.code;

TicketEventのイベントを契機に、VDWのMarketWindowを参照し、条件に合うVDWのイベント(キャッシュのエントリー)のデータを取得する例です。この例ではon select文を使用しています。

on TicketEvent as Input
select W.high, W.low from MarketWindow as W
where W.code = Input.code;

TicketEventのイベントを契機に、VDWのMarketWindowを参照し、条件に合うVDWのイベント(キャッシュのエントリー)のデータを取得する例です。この例では副問合せを使用しています。

select (select W.high from MarketWindow as W where W.code = Input.code) as high from TicketEvent as Input;

MarketEventのイベントを契機にVDWにある同一のcodeをもつイベントを更新する例です。

on MarketEvent as New
update MarketWindow as W
set high = New.high, set low = New.low
where W.code = New.code;

注意

Virtual Data Window利用時の注意

  • 他のビューを指定しない

    Virtual Data Windowを定義するcreate window文において、vdw:ehcache()の指定と一緒にwin:length(1)などの他のビューを指定しないでください。指定しても構文エラーにはなりませんが、そのビューの指定によりTerracottaのキャッシュのデータは操作できません(win:length(1)を指定したとしても、キャッシュ内のイベントは1つになりません)。

  • insert into句は単なる挿入ではない

    Terracottaのキャッシュにはキープロパティの値に対して1つのイベント(キャッシュのエントリー)だけが保持されます。そのため、insert into句でVirtual Data Windowに新しいイベントを挿入した際に、すでにキャッシュ内に同じキープロパティの値をもつイベントがあった場合、そのイベントは新しいイベントで更新されます。

  • CEPエンジンの外で追加されたキャッシュのエントリーは通知されない

    Virtual Data Windowをfrom句に指定した単純なselect文やunidirectionalを指定していない結合(join)の場合、同一CEPエンジン上の複合イベント処理ルールでinsert into句によりVirtual Data Windowに挿入したイベントは通知されますが、Terracottaアプリケーションや別のCEPエンジンから追加されたイベント(キャッシュのエントリー)は通知されません。キャッシュのデータにアクセスするにはunidirectionalを指定した結合(join)、on select文、副問合せを使用してください。

    以下は単純なselect文の例です。

    select W.high, W.low from MarketWindow;

    以下はunidirectionalを指定していない結合(join)の例です。

    select W.high, W.low from TicketEvent.std:lastevent() as Input, MarketWindow as W
    where W.code = Input.code;

    insert into句でMarketWindowにイベントを挿入した際には、挿入されたイベントがこれらのselect文に通知されますが、CEPエンジンの外で追加されたイベントは通知されません。

  • where句ではキャッシュのエントリーを一意に特定する必要がある

    Virtual Data Window に格納された情報にアクセスする際に利用できるwhere句には、キャッシュのエントリーを一意に特定する条件が含まれる必要があります。キャッシュのエントリーを一意に特定する条件とは、vdw:ehcache()で指定したキープロパティと"="で比較する条件です。以下にその例を示します。

    以下の例では、W.code = T.code でキャッシュのエントリーを一意に特定できるのでOKです。

    create window MarketWindow.vdw:ehcache("MARKET", "code") as (code string, high int, low int);

    on TicketEvent as T
    select W.high, W.low from MarketWindow as W
    where W.code = T.code and ( T.price > W.high or T.price < W.low);

    以下は上記のルールでwhere句だけを変更した場合の、OKな記述例と、NGな記述例です。

    No

    記述例

    OK/NG

    説明

    1

    where W.code = '1111'

    OK

    キープロパティに対する"="による比較で一意に特定できるのでOK

    2

    where ( T.price > W.high or T.price < W.low) and W.code=T.code

    OK

    別の条件が前にあるが、キープロパティに対する"="による比較が含まれ、キャッシュのエントリーを一意に特定できるのでOK

    3

    where W.high = 1000

    NG

    キープロパティに対する"="による比較がないためNG

    4

    where W.code > '1111'

    NG

    キープロパティに対して "="以外の演算を行っているためNG

    5

    where W.code='1111' or W.high=1000

    NG

    キープロパティに対する"="による比較が含まれているが、or条件があり、キャッシュのエントリーを一意に特定できないためNG


5.4.4.4 RDB連携

ここではRDB連携を行う場合の留意点と、その利用方法について説明します。

外部データとしてRDBを参照する場合、RDB参照定義を作成します。RDB参照定義はRDBとの接続情報です。

ここでは次の項目について説明します。

5.4.4.4.1 RDB連携を利用する場合の留意点

以下にRDB連携を利用する場合の留意点を示します。

5.4.4.4.2 複合イベント処理ルールでのRDB参照の指定方法

複合イベント処理ルールのfrom句において、以下の構文で指定する事で、RDBに対する問い合せの結果を利用できます。

構文:

sql:データベース名 [" SQL問合せ "] または
sql:データベース名 [' SQL問合せ ']

データベース名には、RDB参照定義において指定した「開発資産ID」を指定します。

SQL問合せは、二重引用符(")または引用符(')で囲んで、さらにその外側を角括弧“[”および“]”で囲んで指定します。

SQL問合せの中には代替パラメーターを含めることができます。代替パラメーターは ${} の形式で記述し、文の実行時に式が評価されます。


注意

  • RDBの参照は、複合イベント処理機能の性能劣化につながる可能性があるため、必要最小限にしてください。

  • 複合イベント処理言語から参照するテーブル名やテーブルの項目名などのRDB側の定義名には、日本語を使用できません。項目の値には日本語を使用できます。

  • シングルクォートで囲んだSQL問合せの中で、シングルクォートで囲んだ文字定数を記述する場合には、エスケープ表記(\')またはUnicode表記(\u0027)を使います。


RDB参照の使用例

複合イベント処理ルール(select文)の中でのRDB参照の使用例です。

@Name("PutRecommend")
@SoapListener("soap-001")
select tvevnt.gatewayId as gatewayId,
case when db.DRY_FUNC = '1' then 'USE_DRY_FUNC' else 'HANG_LAUNDRY_INSIDE' end as recommendId
from TVControlRain as tvevnt,
sql:app_db[ 'SELECT DRY_FUNC FROM PRODUCTFUNC_TBL WHERE HGW_ID=${tvevnt.gatewayId}' ] as db;
  • 使用するRDB参照定義の開発資産IDは「app_db」を設定しています。

  • RDBのテーブル「PRODUCTFUNC_TBL」を参照しています。

  • RDBのテーブル参照の条件に、代替パラメーター「${tvevnt.gatewayId}」を指定しています。

  • 参照結果には別名「db」をつけ、select文の中で利用しています。


5.4.4.5 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.6 カスタムリスナ

複合イベント処理文の結果をユーザー開発Javaクラスに渡して処理したい場合は、カスタムリスナを使用します。

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

ユーザー開発Javaクラスについては、「5.6.3 ユーザー開発Javaクラスの設計」を参照してください。

構文

@CustomListener(mainClass="ユーザー開発Javaクラス名" [, args={"引数1", "引数2", ...}])
複合イベント処理文(select文)

または、二重引用符(")を引用符(')にした形式。

ユーザー開発Javaクラス名

複合イベント処理文の結果を受けとり処理するJavaクラスの名前をFQCN形式(パッケージ名も含めた形式)で指定します。このJavaクラスは、CustomListenerインターフェースを実装している必要があります。

引数1、引数2、...

ユーザー開発Javaクラスに任意の引数を渡したいときに指定します。引数を渡す必要がない場合は、argsを省略できます。

5.4.4.7 ロギングリスナ

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

ロギングリスナを使用するには、処理結果を記録したい複合イベント処理文(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"