2016-10-25 3 views
0

私はCumulocityで書いたいくつかのルールをテストしていましたが、私が望む結果が得られなかったので、比較のためにEsper EPL online toolを使ってみました。私は説明できない2つの出力の違いを発見しました。Cumulocity eprとesperの違い

基本的には、ソースで区切られたコンテキストを作成し、「開始」および「停止」イベントで区切られたコンテキストを作成します。私の文脈が終わったら、私は始まりと終わりのイベントの中からいくつかの詳細(タイプと時間)を表示するだけです(私は現時点でのイベントを気にしません)。

ここに私のルールは(スキーマを作成彼らはすでに、「ネイティブ」に定義されているためCumulocityのために除去されなければならない)です。

create schema EventCreated(
    source String, 
    type String, 
    time Date 
); 

create schema CreateMeasurement(
    source String, 
    type String, 
    time Date, 
    fragments Object 
); 



@Name("create_context") 
create context Trip 
    context bySource 
     partition by source from EventCreated, 

    context byEvents 
     start EventCreated(
      type = "c8y_ObdConnectionReport" or 
      type = "c8y_PowerOnReport" or 
      type = "c8y_FixedReport" or 
      type = "c8y_HarshBehaviorReport") as startEvent 

     end EventCreated(
      type = "c8y_ObdDisconnectionReport" or 
      type = "c8y_PowerOffReport" or 
      type = "c8y_SilentTracker") as endEvent; 



@Name("context_end") 
context Trip 
    insert into 
     CreateMeasurement 

    select 
     context.bySource.key1 as source, 
     "Trip" as type, 
     e.time as time, 
     { 
      "startedBy", context.byEvents.startEvent.type, 
      "startedAt", context.byEvents.startEvent.time, 
      "endedBy", e.type, 
      "endedAt", e.time 
     } as fragments 

    from 
     EventCreated e 

    output 
     last when terminated; 

そしてここでは、違いを参照するには、単純なイベントシーケンスです:

EventCreated = { 
    source = '1672192', 
    type = 'c8y_ObdConnectionReport', 
    time = '2016-10-07T10:00:00.000' 
} 

t = t.plus(5 minutes) 

EventCreated = { 
    source = '1672192', 
    type = 'c8y_FixedReport', 
    time = '2016-10-07T10:05:00.000' 
} 

t = t.plus(5 minutes) 

EventCreated = { 
    source = '1672192', 
    type = 'c8y_ObdDisconnectionReport', 
    time = '2016-10-07T10:10:00.000' 
} 

At: 2016-10-07 10:05:00.000 
    Statement: context_end 
     Insert 
      CreateMeasurement={ 
       source='1672192', 
       type='Trip', 
       time='2016-10-07T10:05:00.000', 
       fragments[ 
        'startedBy','c8y_ObdConnectionReport', 
        'startedAt','2016-10-07T10:00:00.000', 
        'endedBy','c8y_ObdDisconnectionReport', 
        'endedAt','2016-10-07T10:10:00.000']} 

この:だからここ

はEPLオンラインsimulatiorを使用した結果であります私が欲しいものです、私は最初と最後のイベントからの詳細を期待通りに得ました。今、これは私がクマロシティで得るものです。

{ 
    "source":{ 
     "id":"1672192", 
     "name":"Tracker 123456789000000", 
     "self":"http://tracker.post-iot.lu/inventory/managedObjects/1672192"}, 
    "type":"Trip", 
    "time":"2016-10-25T11:56:46.983+02:00", 
    "self":"http://tracker.post-iot.lu/measurement/measurements/null", 
    "startedBy":"c8y_ObdConnectionReport", 
    "startedAt":"2016-10-25 11:56:44+0200", 
    "endedBy":"c8y_FixedReport", 
    "endedAt":"2016-10-25 11:56:46+0200" 
} 

(私はCumulocityでリアルタイムで作業しています)。 ご覧のとおり、最後のイベントはDisconnectionReportではなくFixedReportと見なされます。だから、基本的にCumulocity(私は様々な状況を試しました)で起こるのは、コンテキストの終了イベントは毎回で無視されるので、最後のイベントの次のものしか取り出せません。

これは、Esperエンジンとの違いですか?私はそれがすべきだと思うようにこの仕事をするにはどうしたらいいですか?

+0

開始イベントで同じ問題が発生しました(context.byEvents.startEventを使用したときに2番目のイベントのみを取得します)。 –

答えて

0

エッシャーオンラインツールは、最後のイベントではなく累積 - 最後の1つを常に処理することはおそらく偶発的な問題です。発生した場合

は、最初に実行される声明(「create_contextまたは 『context_end』)に依存します。@priority注釈が提供されていないかぎりしかしステートメントの実行の順序はランダムです。

ノートによるとエスパードキュメントの(http://www.espertech.com/esper/release-5.3.0/esper-reference/html/context.html#context_def_nonoverlapping

あなたはコンテキストパーティションの終了条件としてイベントフィルタまたはパターンを指定し、コンテキストを参照するステートメントが指示する@priorityを使用し、同じ条件に一致するイベントフィルタやパターンを指定した場合コンテキスト管理かステートメント評価のどちらが必要か優先順位(優先順位付けされた実行の設定については以下を参照)。たとえば 、あなたのコンテキストの宣言は次のようになります場合:

create context MyCtx start MyStartEvent end MyEndEvent 

、コンテキストによって管理される文はこれです:@priorityを使用することにより

context MyCtx select count(*) as cnt from MyEndEvent output when terminated 

(1 )とカウント文の@Priority(0)カウント・ステートメントは、コンテキスト・パーティション管理が優先されるため、最後のMyEndEventをカウントしません。 作成コンテキストに@Priority(0)、カウントステートメントに@Priority(1)を使用することにより、ステートメント評価が優先されるため、countingステートメントは最後のMyEndEventをカウントします。

修正:@Priority(0)を "create_context"ステートメントに、@Priority(1)を "context_end"ステートメントに追加しました。

+0

私はこれを試してみるつもりですが、期待したように働いたEPLオンラインプラットフォームでいつもそれを味わって、そしていつもそれがCumulocityになかったので、私は本当にこの "ランダムな"側面を信じていません。 また、上記でコメントしたように、開始イベントで同じ問題が発生しましたが、これはコンテキストの最後には取得できません(イベント#2のみ)。 –

+0

私はそれが動作しないことを確認します。 –

関連する問題