【问题标题】:Cumulocity epr differences with esper积聚 epr 与 esper 的差异
【发布时间】:2016-10-26 21:35:51
【问题描述】:

我正在测试我在 Cumulocity 中编写的一些规则,由于无法获得我想要的结果,我尝试使用 Esper EPL online tool 进行比较。结果我发现两者之间的输出存在我无法解释的差异。

基本上,我想做的是创建一个由源分区并由“开始”和“停止”事件分隔的上下文。然后当我的上下文结束时,我只想显示我的开始和结束事件的一些细节(类型和时间)(我现在不关心中间的事件)。

这是我的规则(必须为 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'
}

所以这是使用 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']}

这就是我想要的,我从我的第一个和最后一个活动中得到了预期的详细信息。现在这就是我使用 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"
}

(忽略日期,我正在使用 Cumulocity 实时工作)。 如您所见,它认为最后一个事件是 FixedReport 而不是 DisconnectionReport。所以在 Cumulocity 中基本上发生的事情(我尝试过各种情况),每次都会忽略上下文的结束事件,所以我只能检索倒数第二个事件。 p>

这与 Esper 引擎有何不同?我怎样才能使这项工作像我认为的那样工作?

【问题讨论】:

  • 我现在对起始事件有同样的问题(我只在使用 context.byEvents.startEvent 时检索第二个)。

标签: esper cumulocity


【解决方案1】:

esper 在线工具总是处理最后一个事件但累积性 - 一个在最后一个之前,这可能是一个偶然的问题。

哪种情况发生取决于哪个语句(“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

通过将@Priority(1) 用于create-context 并将@Priority(0) 用于计数语句,计数语句不会计算最后一个MyEndEvent,因为上下文分区管理具有优先权。 通过将 @Priority(0) 用于 create-context 并将 @Priority(1) 用于计数语句,计数语句将计算最后一个 MyEndEvent,因为语句评估优先。

修复:在“create_context”语句中添加@Priority(0),在“context_end”语句中添加@Priority(1)。

【讨论】:

  • 我要试试这个,但是我真的不相信它的“随机”方面,因为每次我在 EPL 在线平台上尝试它时它都按预期工作,而且每次它没有在积云上。此外,正如我在上面评论的那样,我现在的开始事件也有同样的问题,我无法在上下文结束时再检索它(仅事件 #2)。
猜你喜欢
  • 2020-08-12
  • 2018-06-18
  • 1970-01-01
  • 2011-01-05
  • 2022-07-24
  • 2022-10-02
  • 1970-01-01
  • 2011-12-05
  • 2016-03-16
相关资源
最近更新 更多