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

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

症状:イベント処理ルールが自動的に利用できなくなる

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

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

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

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

エラーの出る文を見てください。エラーを見るために、詳細まで読み込む必要があるでしょう。1つずつエラーを修正していきます。 誤った文の例: "insert into UpdateAlarm select "CLEARED" as status from..." はエラー文と見なされます。修正された文の例: "insert into UpdateAlarm select "10201" as ID, "CLEARED" as statud from..."

文の命名

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

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

デバイスコンテキストを必要とする場合、コンテキストにすべての文を設定する必要は通常ありません。例えば、メジャーメントの集計を行う場合、ほとんどの場合、実際に集計する文のコンテキストのみが必要になります。初めにコンテキストを全く含まないモジュールを作成し、必要となる文の最後にコンテキストを追加してください。

モジュールの分割

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

  • モジュール1:入力データをフィルターし、データベースからのデータを追加
  • モジュール2:計算
  • モジュール3:データベースにデータを生成

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

数値フォーマット

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

  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)