EPL モニター
症状：イベント処理ルールが自動的に無効になる
モニターがonloadまたはリスナーから例外をスローし、例外がキャッチされない場合、モニターは終了します。例外をキャッチするか、例外が発生する原因を回避してください。
同様に、モニターがイベントの処理を完了し、有効なリスナーが残っていない場合、再度トリガーすることはできず、自動的に自身を削除します。
モニターごとの過剰なメモリ使用を避ける
イベント処理ルールがリスナーをリークすることのないよう注意してください。たとえば、リクエストとレスポンスのオペレーションを行うときは、レスポンスの処理後、またはタイムアウトが発生してレスポンスがない場合、有効なリスナーを残さないようにします。
数値の形式
Things Cloudのメジャーメントでは、float型を使用します。 タイムスタンプはfloatとして保存されることを注記してください。（1970年1月1日00:00 UTCからの秒数）
チャネルやコンテキストを購読する
コンテキストは、Apama内の並列処理ユニットです。 モニターインスタンスは、spawn...to構文を使用して複数のコンテキストに展開できます。チャネルを購読すると、コンテキスト内のすべてのモニターインスタンスが購読しているチャネルのイベントを受信します。したがって、異なるコンテキストでは購読する対象は変更することをお勧めします。コンテキストを使用すると、アプリケーションの一部がアプリケーションの他の部分へのオーバーロードや影響を与えるのを防ぐことができます。
コンテキストはユーザーが判別しやすい名前で作成され、コンテキストオブジェクトの個々のインスタンスは、同じ名前であっても異なるコンテキストに対応します。
例えば:
action onload() {
context subContext := context("Worker");
spawn worker() to subContext;
}
action worker() {
monitor.subscribe(Measurement.SUBSCRIBE_CHANNEL);
on all Measurement() as m {
...
}
}
Things CloudにおけるApamaの制限
独立型のApamaを使用する場合、Things Cloud環境内でのApamaの使用には、必然的にいくつかの機能制限がでてきます。
Things Cloud内でApamaにアセットをデプロイする方法はいくつかあり、制限はそれらのメカニズムによって異なります:
- EPL Apps - Apamaアセットを完全にマネージされたApamaコリレーターにデプロイする最もシンプルなメカニズム。基本機能 > アプリケーションのデプロイをご覧ください。
あらゆる形式のThings Cloud環境内にデプロイされるApamaソリューションを設計する際には、次の点を考慮してください。
EPL Appsを使用する場合の特定のApamaの制限
-
使いやすくするために、コリレーターの起動はThings Cloudによって制御されます。したがって、構成設定ファイルまたはコマンドラインオプションの変更を必要とする機能にはアクセスできません。
この影響を受けるApama機能は次のとおりです:
- 永続性
- 接続性プラグイン
- コマンドセントラルを介したマネージメント
-
セキュリティ上、コリレーターが使用するファイルシステムにはアクセスできません。
この影響を受けるApama機能は次のとおりです:
- 入力ログへのアクセス
- カスタムプラグインの使用
- 強化のためのファイルシステムアセットの使用
-
簡略化のために、独立したEPLインジェクションのみを行うことができます。各モニターは独立してマネージされるため、異なるモニター間の依存関係は作成できません。
この影響を受けるApama機能は次のとおりです:
- *.monファイルにはパッケージステートメントを含めることはできません（これを行うとエラーになります）
- 個別の*.monファイル間でイベント定義を共有することはできません。
- Apamaクエリを使用することはできません。
- Software AG Designerを使用したアプリケーション開発でリストされたバンドルのみ使用できます。
これらの制限はすべて、Things Cloud内でEPLアプリケーションを円滑かつ安全にオペレーションするために実装されています。