0

Things Cloud で書いたいくつかのルールをテストしていましたが、望む結果が得られなかったので、比較のためにEsper EPL オンライン ツールを使用してみました。説明できない 2 つの出力の違いが見つかりました。

基本的に、私がやりたいことは、ソースによって分割され、「開始」イベントと「停止」イベントで区切られたコンテキストを作成することです。次に、コンテキストが終了したら、開始イベントと終了イベントのみの詳細 (タイプと時間) を表示したいと思います (現時点では、その間のイベントは気にしません)。

これが私のルールです (作成スキーマは既に「ネイティブに」定義されているため、Things Cloud では削除する必要があります):

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'
}

EPL オンライン シミュレーターを使用した結果は次のとおりです。

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']}

これは私が望むものです。期待どおり、最初と最後のイベントから詳細を取得しました。これが私が Things Cloud で得たものです:

{
   "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"
}

(日付は無視してください。私は Things Cloud でリアルタイムで作業しています)。ご覧のとおり、最後のイベントは、DisconnectionReport ではなく FixedReport であると見なされます。つまり、Things Cloud で基本的に発生すること (さまざまな状況を試しました) は、コンテキストの終了イベントが毎回無視されるため、最後から 2 番目のイベントしか取得できないということです。

エスパーエンジンとの違いは？私が思うようにこれを機能させるにはどうすればよいですか？

4

1 に答える 1

0

esper オンライン ツールが常に最後のイベントを処理するが、cumulocity - 1 つ前のイベント - を処理するのは、おそらく偶発的な問題です。

どちらの場合が発生するかは、どちらのステートメント (「create_context」または「context_end」) が最初に実行されるかによって異なります。ただし、@Priority アノテーションが提供されない限り、ステートメントの実行順序はランダムです。

esper ドキュメントの注記によると ( 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

そして、コンテキストによって管理されるステートメントは次のとおりです。

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

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

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

于 2016-10-26T13:35:51.723 に答える