0

I was testing some rules I wrote in Cumulocity, and as I couldn't get the results I wanted I tried using the Esper EPL online tool for comparison. Turns out I found a difference in outputs between the two that I can't explain.

Basically, what I want to do is create a context partitionned by source and delimited by "start" and "stop" events. Then when my context ends, I want to display some details (type and time) from my starting and ending events only (I don't care for the events in between at the moment).

Here's my rule (the create schema have to be removed for Cumulocity because they are already defined "natively"):

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;

And here is a simple event sequence to see the difference:

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

So here is the result using the EPL online simulatior:

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

This is what I want, I got details from my first and last event as expected. Now this is what I get with Cumulocity:

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

(Disregard the dates, I'm working real-time with Cumulocity). As you can see, it considers the last event to be the FixedReport instead of the DisconnectionReport. So what basically happens in Cumulocity (I've tried various situations), is that the ending event of the context is disregarded every time, so I can only retrieve the next-to-last event.

Whis this difference with the Esper engine? How can I do do make this work like I think it should?

Gaetan L.
  • 649
  • 6
  • 20
  • I now have the same problem with the starting event (I only retrieve the second one when I use context.byEvents.startEvent). – Gaetan L. Oct 26 '16 at 12:00

1 Answers1

0

It is probably accidental issue that esper online tool always handle last event but cumulocity - one before last.

Which case occurs depends on which statement ("create_context or "context_end") will be executed first. However the order of statements execution is random unless @Priority annotation is provided.

According to the note in esper documentation (http://www.espertech.com/esper/release-5.3.0/esper-reference/html/context.html#context_def_nonoverlapping)

If you specified an event filter or pattern as the end condition for a context partition, and statements that refer to the context specify an event filter or pattern that matches the same conditions, use @Priority to instruct the engine whether the context management or the statement evaluation takes priority (see below for configuring prioritized execution). For example, if your context declaration looks like this:

create context MyCtx start MyStartEvent end MyEndEvent

And a statement managed by the context is this:

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

By using @Priority(1) for create-context and @Priority(0) for the counting statement the counting statement does not count the last MyEndEvent since context partition management takes priority. By using @Priority(0) for create-context and @Priority(1) for the counting statement the counting statement will count the last MyEndEvent since the statement evaluation takes priority.

Fix: add @Priority(0) to "create_context" statement and @Priority(1) to "context_end" statement.

  • I'm gonna try this, however I don't really believe in the "random" aspect of this because EVERY time I triend it on the EPL online platform it worked as expected, and EVERY time it didn't on Cumulocity. Also, as I've commented above, I now have the same problem with my start event, which I can no longer retrieve at the end of the context (only event #2). – Gaetan L. Oct 26 '16 at 13:55