我使用的是Fiware Orion Context Broker版本0.20。 我注意到,当我创建上下文订阅时,我提供的端点会立即收到有关在创建订阅之前发生的相应上下文元素的更改的通知。
澄清:(注意:我在干净的数据库中使用了这些步骤)
我从测试包/usr/share/contextBroker/tests/accumulator-server.py 1028 /accumulate on
使用http://localhost:1026/v1/updateContext
{
"contextElements": [
{
"type": "Room",
"isPattern": "false",
"id": "Room1",
"attributes": [
{
"name": "temperature",
"value": "20"
}
]
}
],
"updateAction": "APPEND"
}
http://localhost:1026/v1/subscribeContext
{
"entities": [
{
"type": "Room",
"isPattern": "true",
"id": ".*"
}
],
"attributes": [
"temperature"
],
"reference": "http://localhost:1028/accumulate",
"duration": "P1M",
"notifyConditions": [
{
"type": "ONCHANGE",
"condValues": [
"temperature"
]
}
],
"throttling": "PT5S"
}
POST http://localhost:1028/accumulate
Content-Length: 472
User-Agent: orion/0.20.0 libcurl/7.19.7
Host: localhost:1028
Accept: application/xml, application/json
Content-Type: application/json
{
"subscriptionId" : "55521671985dc3976b879780",
"originator" : "localhost",
"contextResponses" : [
{
"contextElement" : {
"type" : "Room",
"isPattern" : "false",
"id" : "Room1",
"attributes" : [
{
"name" : "temperature",
"type" : "",
"value" : "20"
}
]
},
"statusCode" : {
"code" : "200",
"reasonPhrase" : "OK"
}
}
]
}
此外,如果我在添加订阅之前创建了多个contextElements,它们都是通知中contextResponses
的一部分。
对于我的用例,这种行为是不可取的。订阅非常动态(它们在应用程序的整个生命周期中经常出现),而且每次创建订阅时我都不想要整个历史记录。我只希望从T创建订阅的那一刻起收到有关更改的通知。 (不是历史)
我是否忽略了文档中的内容,是否可以通过更改订阅请求的内容来解决此问题?如果没有,这是上下文代理通常接受的行为还是只是一个普通的错误?
答案 0 :(得分:0)
这是预期的行为,如in the manual所述:
如果您实际上没有进行任何更新,您可能想知道为什么accumulator-server.py会收到此消息。这是因为Orion Context Broker认为从“非现有订阅”到“订阅”的转换是一种变化。
我们理解,对于某些用例,这不方便。然而,在开始获得对应于实际变化的通知之前,以opossite方式行为破坏了需要知道“原始状态”的另一个用例。让每个人都满意的最佳解决方案是使其可配置,因此每个客户都可以选择它喜欢的内容。此功能目前已在我们的路线图中(请参阅this issue in github.com)。
虽然这是在Orion中实现的,但在您的情况下,可能的解决方法是忽略属于订阅的第一个收到的nofitication(您可以通过通知中的subscriptionId
字段来标识一个通知所属的订阅有效载荷)。所有以下与该订阅相关的通知都将与实际更改相对应。
编辑:最终在Orion实施了避免初始通知的可能性。详细信息位于this section of the documentation。它现在位于主分支中(因此,如果您使用fiware/orion:latest
docker,您将获得它)并将包含在下一个Orion版本(2.2.0)中。