ルール定義は、高速フィルター処理で使用するフィルタールールと、複合イベント処理で使用する複合イベント処理ルールの2種類のルールから構成されます。
ここでは、ルールの設計時の留意点や作成手順など、以下の項目について説明します。
高速フィルターで使用するフィルタールールを定義します。
フィルタールール作成時の留意項目
フィルタールール作成において留意すべき項目は以下の通りです。
ルールの作成単位
イベントタイプごとにフィルタールールを作成します。あるイベントタイプに対して、同時に複数のフィルタールールを定義することはできません。
フィルタールールの処理パターン
後述する処理パターンから適したものを選択し、選択したパターンに沿ってルール作成することを推奨します。
フィルタールールの詳細については「開発リファレンス」の「第2章 フィルタールール言語リファレンス」を参照してください。
マスタデータ
フィルタールールの中で参照します。イベントの通信量を節約するために、個々のイベントにはIDやコードといった、限られた情報しか含まれない場合があります。その状態でイベントを処理するルールを書くことは困難なため、IDやコードをキーとして参照可能なマスタデータを利用できます。これにより、ルールの作成が容易になります。
マスタデータは、利用者が事前にCSV形式のファイルとして作成する必要があります。
マスタデータの設計については、「5.4.5 マスタ定義の設計」を参照してください。
フィルタールールのメモリ使用量
フィルタールールの利用には、多量のメモリを必要とします。必要なメモリ使用量の詳細は「3.3.1.1 高速フィルタールール使用時のメモリ量」、および「3.3.1.2 高速フィルターでマスタデータを使用した場合のメモリ量」を参照してください。
フィルタールールの処理パターン
高速フィルターでは、フィルタールールを定義することで、イベントの抽出や、マスタデータと組み合わせた抽出処理、および連結処理を記述できます。高速フィルターの出力が、そのまま複合イベント処理の入力となります。
高速フィルターで行う処理は、通常、以下の4パターンと、その組み合わせで表現されます。
入力イベントから、フィルタールールの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です。
入力イベントに含まれる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 マスタデータとの結合処理」を参照してください。
入力されたイベントと、マスタデータを連結します。次の複合イベント処理で必要なデータを付与したい場合に検討します。複合イベント処理ルールでRDB参照を行うよりも高速な結合処理が可能です。
結合した結果を複合イベント処理に渡すためには、結合結果に対応するイベントタイプ定義(フィルター済み)も必要です。
例
マスタデータとの結合処理の例
イベントに含まれるkeyを元に、対応するマスタデータを結合して、イベントにaddressを付与した例です。
作成するルール
上記の例で作成するルールは以下の通りです。
on 入力イベントタイプID {
join("マスタ定義ID", $key == $key) output($key, "マスタ定義ID".$address) as 出力イベントタイプID;
}
入力イベントタイプIDは、ルールの対象となるイベントタイプ定義の開発資産IDです。
マスタ定義IDは、参照するマスタデータに対応するマスタ定義の開発資産IDです。
出力イベントタイプIDは、結合した結果を表すイベントタイプ定義(フィルター済み)の開発資産IDです。
マスタデータにキーワードへの重み付けを登録しておくことで、入力イベントの文章に重み付けを行うことが可能です。これにより、重み付けの合計が閾値より大きいイベントだけを抽出したり、閾値より大きいイベントを連続して発信していることを検知したりできます。
例
文書の重み付け処理の例
イベントに含まれる文章の内容に、マスタデータに定義された検索ワードが含まれているなら、含まれている検索ワードの数と、検索ワードごとに設定された重みの合計値を付与して出力します。
作成するルール
上記の例で作成するルールは以下の通りです。
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です。
複合イベント処理で使用するルールを定義します。
複合イベント処理ルール作成時の留意項目
複合イベント処理のルール作成において留意すべき項目は以下の通りです。
ルールの作成単位
イベントのパターン検知を行う目的や用途別などに作成します。あるルールに記述したイベントのパターン検知が、別のルールに影響を与えないよう作成単位を決定します。
1つのルール定義に多数の処理を記述することも可能ですが、ルール定義の規模が大きくなり、メンテナンス性の低下につながります。
例えば、家電に関するイベントの処理を行う場合、生活家電と情報家電で検知する内容が大きく異なっていれば、ルール定義は以下の2つを作成します。
生活家電に関するイベントのパターンを検知するルール定義
情報家電に関するイベントのパターンを検知するルール定義
外部データの参照
イベントの処理に、外部データの参照が必要か検討します。外部データとしてTerracottaのキャッシュとRDBの2種類が利用可能です。
Terracottaのキャッシュの参照については「5.4.4.3 Terracotta連携」を参照してください。
RDBの参照については「5.4.4.4 RDB連携」を参照してください。
処理結果の送信または記録の有無
複合イベント処理ルールの処理結果をSOAPで外部のWebサービスに送信する他に、CEPエンジンに配備したJavaクラスで処理したり、ロギング機能でイベントログに記録したりできます。それぞれ、複合イベント処理ルールにSOAPリスナ、カスタムリスナ、ロギングリスナを適用します。
SOAPリスナの使い方については「5.4.4.5 SOAPリスナ」を参照してください。
カスタムリスナの使い方については「5.4.4.6 カスタムリスナ」を参照してください。
ロギングリスナの使い方については「5.4.4.7 ロギングリスナ」を参照してください。
ルールの作成手順
複合イベント処理ルールは、最初からステートメントを記述せず段階的に設計し、目的とするイベントの検知を確実に行えるように開発を進めることを推奨します。以下に複合イベント処理ルールの作成手順を示します。
複合イベント処理ルールの作成手順
複合イベント処理ルールの作成手順について、例を挙げて説明します。
複合イベント処理で実現したい内容の検討
複合イベント処理で実現したいことを決定します。この時点ではやりたい事が明確でなくても、収集したイベントを分析することによって、実現したいことが見つかる場合もあります。
例
ルールの例
「在宅時に雨が降りそうな場合は、洗濯機の乾燥機能の使用をレコメンドする。」
イベント、参照する外部データ、出力内容の検討
ルール作成に必要なイベント、参照用の外部データ、および出力内容について、検討します。また、イベントをメモリ内に保持しておくための名前付きウィンドウについて検討します。
例
イベント、外部データ、出力、名前付きウィンドウの例
前述のルール例では、以下のイベント、外部データ、出力内容、名前付きウィンドウが考えられます。
イベント
テレビ操作イベント
各家庭のホームゲートウェイから送られる家電イベントデータのうち、機器カテゴリのプロパティ値がTelevisionのものとします。
天気予報イベント
予報は時間と天気で表すものとします。
外部データ
洗濯機の機種情報(乾燥機能の有無)
ホームゲートウェイのIDから、その家庭の洗濯機の乾燥機能の有無がわかるものとします。
出力内容
レコメンド対象の家庭のホームゲートウェイID
レコメンド内容
名前付きウィンドウ
天気予報イベント用名前付きウィンドウ
天気予報イベントを時刻ごとに1日保持することにします。
処理内容の詳細化
イベントやそれを検知する複合イベント処理の内容を詳細化(具体化)します。
ここでの詳細化とは、日常言語で表現された“やりたい事”を、イベントや複合イベント処理の条件、外部データなどの具体的な情報を利用することで、作成するルールに近づけた表現にする作業です。
例
複合イベント処理の内容を詳細化する例
「在宅時に雨が降りそうな場合は、洗濯機の乾燥機能の使用をレコメンドする。」というルールを詳細化すると以下のようになります。
ルールの構成要素 | 詳細化した処理内容 |
---|---|
「在宅時」 | テレビ操作を行った家庭を在宅と判断します(テレビ操作を知らせるイベントを検知します)。 |
「雨が降りそう」 | 名前付きウィンドウに格納された天気予報情報を参照し、天気予報の時刻と、テレビの操作時刻から、今後雨となる予報が出ているかどうかを確認します。 |
「洗濯機の乾燥機能」 | ホームゲートウェイに接続している洗濯機の製品情報を、Terracottaのキャッシュから取得します。 |
「レコメンドする」 | 雨予報の場合、洗濯機に乾燥機能がなければ、洗濯物の部屋干しをレコメンドします。 洗濯機に乾燥機能があれば、乾燥機能の利用をレコメンドします。 |
イベントフロー図の作成
処理内容の詳細化が完了したら、イベント処理の流れをまとめてイベントフロー図を作成します。イベントフロー図は、イベントとその処理内容のつながりを図で示したものです。実現しようとする処理内容を確認する上でも役立つため、複合イベント処理ルール言語で処理を記述する前に作成する事を推奨します。
参考
イベントフロー図の凡例
本書で使用するイベントフロー図の凡例です。
例
イベントフロー図の例
「在宅時に雨が降りそうな場合は、洗濯機の乾燥機能の使用をレコメンドする。」のイベントフロー図です。
天気予報イベントを保持するための名前付きウィンドウを作成します。
洗濯機の乾燥機能の有無を調べるための名前付きウィンドウ(Terracottaのキャッシュ)を作成します。
天気予報イベントを天気予報ウィンドウに格納します。
家電イベントからTV操作のイベントを検知します。
TV操作のイベントの発生時間から今後の天気予報を確認し、雨予報の場合だけイベントを残します。
TV操作が行われ、かつ天気予報が雨の家庭について洗濯機機能ウィンドウを検索し、洗濯機の乾燥機能のあり/なしに応じてレコメンドすべき情報を付加してユーザー開発Webサービスに送信します。
ユーザー開発Webサービスでは、受け取った情報をもとに、家庭にレコメンドを送信します。ユーザー開発Webサービスでは、同じ家庭に一定期間同じレコメンドを行わないように制御します。
複合イベント処理ルールの作成
イベントフロー図のそれぞれの要素に対応させて、複合イベント処理ルールを記述します。
例
イベントフロー図に対応する複合イベント処理ルールの例
ルールの意味については、「開発リファレンス」の「第1章 複合イベント処理言語リファレンス」を参照してください。
1 | // 1.天気予報イベント用の名前付きウィンドウ作成 |
ここでは、Terracotta連携を行う場合の留意点と、その利用方法について説明します。
複合イベント処理の外部データ参照において、Terracotta連携を利用する場合に留意すべき項目について説明します。
Terracotta連携の必要性の確認
高速フィルターでマスタデータを利用する場合と異なり、Terracotta連携の場合、随時更新されるデータの参照が可能です(高速フィルターの場合、マスタデータの動的変更で更新可能ですが、プログラムから随時更新することはできません)。
また、イベントを契機に外部キャッシュのデータを追加、更新、削除することも可能です。
Terracottaのキャッシュの構成
複合イベント処理ルールから参照するTerracottaのキャッシュのデータは、キーと値で構成するエントリーとして管理されます。複合イベント処理ルールで使用するキャッシュに格納するキーと値の形式については、「5.5.3 Terracottaのキャッシュ」を参照してください。
Terracottaのキャッシュの参照方法
複合イベント処理ルールからTerracottaのキャッシュを参照するには、Virtual Data Window機能を利用します。Virtual Data Windowの作成方法、および作成したVirtual Data Windowを使ったキャッシュの利用方法については、「5.4.4.3.3 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>
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 (プロパティ名 型, プロパティ名 型, ...);
VDWの作成はcreate window文でvdw:ehcache()を使用して行います。
キャッシュの実体を参照するため、キャッシュ名とデータ参照のためのキープロパティ名の設定が必要です。この2つの設定は、vdw:ehcache()の引数として指定します。
キャッシュ名には、使用するキャッシュの名前を指定します。
キープロパティ名には、エントリーを特定するためのプロパティ名を指定します。イベントタイプIDを利用する場合は、指定されたイベントタイプのプロパティ名を指定します。型情報を直接指定する場合は、任意の名前を指定できます。指定したプロパティの型は、キャッシュのKeyクラスに対応する型である必要があります。
ウィンドウ名には任意の名前を指定します。ここで指定した名前で、複合イベント処理ルールのselect文(insert into句、from句)、on select文、on update文、on delete文、on merge文、副問合せからキャッシュにアクセスできます。
イベントタイプIDには、CSV形式のイベントタイプ定義で定義されたイベントを指定します。(XML形式のイベントタイプ定義は指定できません。)
プロパティ名 型、にはキャッシュのValueに設定するjava.util.HashMapのキーと対応したプロパティ名と型を指定する必要があります。また、キープロパティ名で指定したプロパティ名とその型も指定する必要があります。
指定したプロパティ名が、キャッシュのValueに設定するjava.util.HashMapに設定されていない場合、複合イベント処理ルールでnull値として扱われます。
例
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 |
ここではRDB連携を行う場合の留意点と、その利用方法について説明します。
外部データとしてRDBを参照する場合、RDB参照定義を作成します。RDB参照定義はRDBとの接続情報です。
ここでは次の項目について説明します。
以下にRDB連携を利用する場合の留意点を示します。
RDB連携定義の作成
RDB連携を利用するには、ルール定義の他にRDB参照定義が必要です。RDB参照定義については「5.4.7 RDB参照定義の設計」を参照してください。
RDBの内容
RDBは、入力するイベントから得られないデータやイベントのプロパティに関連する静的なデータで、かつルール照合のために必要なデータは何か、という観点で検討する必要があります。RDBのデータは、複合イベント処理ルール(select文)を発行して参照できます。
例
RDBで用意する情報の例
地域、住所などの情報が考えられます。
イベントの内容から、各顧客を識別するIDは得られても、その顧客のいる地域(住所)はイベント内容に含まれないことがあります。
この場合、顧客IDと地域(住所)の対応関係を登録したRDBを用意することで、イベント内の顧客IDをキーに、その顧客の地域(住所)を参照でき、地域(住所)に基づく処理に活用できます。
日本語利用時の注意
複合イベント処理言語から参照するテーブル名やテーブルの項目名などのRDB側の定義名には日本語を使用できません。RDB参照定義中に記述するデータベース名や、スキーマ名、ユーザー名なども同様です。
項目の値には日本語を使用できます。項目の値に日本語を使用する場合、RDBの文字コード(あるいは文字セット)はユニコードを設定してください。詳細は連携先RDBのマニュアルを参照してください。
期限付きキャッシュの利用
RDBを初回に参照すると、クエリのキーと結果がCEPエンジンの期限付きキャッシュに格納されます。二回目以降の同一キーによるRDB参照は、キャッシュからデータを取得する動作となります。期限付きキャッシュの利用にはRDB参照定義にキャッシュ保持期間とキャッシュ破棄間隔の設定が必要です。RDB参照定義については「5.4.7 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文の中で利用しています。
複合イベント処理文の処理結果をSOAPでユーザー開発Webサービスに送信するには、SOAPリスナを使用します。
SOAPリスナを使用するには、処理結果を送信したい複合イベント処理文(select文)の前に、@SoapListenerアノテーションを付与します。
処理結果の送信先や、SOAPメッセージの内容についての詳細は、「5.4.8 SOAPリスナ定義の設計」を参照してください。
構文
@SoapListener("SOAPリスナ定義ID")
複合イベント処理文(select文)
処理結果を送信するWebサービスの送信先URLなどを定義した、SOAPリスナ定義の開発資産IDを指定します。
処理結果を送信したい複合イベント処理文(select文)です。
複合イベント処理文の結果をユーザー開発Javaクラスに渡して処理したい場合は、カスタムリスナを使用します。
カスタムリスナを使用するには、処理結果を渡したい複合イベント処理文(select文)の前に、@CustomListenerアノテーションを付与します。
ユーザー開発Javaクラスについては、「5.6.3 ユーザー開発Javaクラスの設計」を参照してください。
構文
@CustomListener(mainClass="ユーザー開発Javaクラス名" [, args={"引数1", "引数2", ...}])
複合イベント処理文(select文)
または、二重引用符(")を引用符(')にした形式。
複合イベント処理文の結果を受けとり処理するJavaクラスの名前をFQCN形式(パッケージ名も含めた形式)で指定します。このJavaクラスは、CustomListenerインターフェースを実装している必要があります。
ユーザー開発Javaクラスに任意の引数を渡したいときに指定します。引数を渡す必要がない場合は、argsを省略できます。
複合イベント処理文の処理結果をロギング機能でイベントログに記録したい場合は、ロギングリスナを使用します。
ロギングリスナを使用するには、処理結果を記録したい複合イベント処理文(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文)です。
注意
イベントタイプ定義で定義するロギングと、ルール定義(ロギングリスナ)で定義するロギングは、出力先となるログ格納領域を分けることが可能です。しかし、異なるHadoopシステムへロギングする事はできません。
出力プロパティの値がnullの場合、空白に変換してイベントログに出力します。
出力プロパティが数値項目の場合、文字列変換してイベントログに出力します。
存在しない出力プロパティ名を指定した場合、空白をイベントログに出力します。
データにダブルクォート(")がある場合、データ内にあるダブルクォートを重ねて出力します。
aa"bb"aaの出力例:
"aa""bb""aa"