ベストプラクティスとトラブルシューティング

重要事項： イベント処理機能(Esper)の新規利用は終了し、ご利用中のお客様におかれましてはApama CEPエンジンへの切替完了後、順次サポートを終了いたします。Apama によるカスタムストリーミング処理機能の詳細は カスタムストリーミング処理ガイド をご覧ください。
本章の記載内容は新規利用終了済みのイベント処理機能(Esper)に関する記述になりますのでご注意ください。

イベント言語に関するトラブルシューティング

症状：イベント処理ルールが自動的に無効化される

Things Cloud はイベント処理で利用されるメモリー使用量、処理負荷、そしてイベント処理ルールにおけるエラーも監視しています。イベント処理ルールのいずれかがあまりに多くのメモリーを使用したり、大量のエラーを生成している場合、Things Cloud は自動的にそのルールを無効にします。

メモリー消費によって無効化されたルールに関するトラブルシューティング：

イベント処理ルールがウィンドウ内に多くのイベントを保持していないことを確認してください。たとえば、“win:keepall()” を利用し、多くのイベントがルール内で利用されると、短時間で無効化されます。“win:keepall()” を利用する代わりに、よりメモリーを消費しない “std:lastevent()” のような文を利用してください。

大量のエラー発生により、無効化された場合のトラブルシューティング：

エラーの出る文を探してください。エラーを見つけるために、詳細まで読み込んでください。エラーを見つけ次第、文を修正してください。 誤った文の例： “insert into UpdateAlarm select “CLEARED” as status from…” はエラー文と見なされます。

修正された文の例： “insert into UpdateAlarm select “10201” as ID, “CLEARED” as status from…”

文の命名

@Name アノテーションを使用してモジュールの文を命名できます。単一モジュール内での名前は一意である必要があります。リアルタイム通知 のチャネルで、このことが直接関係します。チャネル名（ひいては文の名前）はリスト表示に利用されるため、アドミニストレーションUIを用いてモジュールをデバッグする際にも便利です。文に命名しない場合、自動的に “statement_{文番号}” と命名されます。

デバイスコンテキストの利用

デバイスコンテキストを必要とする場合、通常、コンテキストにすべての文を設定する必要はありません。例えば、メジャーメントの集計を行う場合、ほとんどの場合、実際に集計する文にのみコンテキストが必要になります。

モジュールを作成する時は、まずコンテキストを全く含まないものを作成し、最後に必要となる文へのみコンテキストを追加すると良いでしょう。

モジュールの分割

モジュールが大きくなってしまった場合、複数のモジュールに分割すると便利です。スキーマや関数は、宣言されるとテナントのすべてのモジュールで利用できます。よい方法は、

モジュール間に依存関係ができることを忘れないでください（例えば、モジュール２はモジュール１で定義されたスキーマを必要とするなど）。循環依存は避けなければなりません。

数値フォーマット

メジャーメント を操作する場合、値は BigDecimal (例えば getNumber() を使う場合)となります。 BigDecimal の計算では、結果が循環小数の場合にエラーとなります。その場合、avg() のような組み込み関数で null 値を返却します。これを回避するには２つの方法があります。

  1. 組み込み関数を使っている場合、一番簡単な方法は BigDecimal を double 値にキャストします

    avg(cast(getNumber(e, “c8y_TemperatureMeasurement.T.value”), double))

  2. 自分で計算ロジックを書く場合、BigDecimal型を保つには数字を丸めるか切り捨てるかする必要があります。

    getNumber(e, “c8y_TemperatureMeasurement.T.value”).divide(new BigDecimal(3), 5, RoundingMode.HALF_UP)