Orion Context Provider 查询多个实体
Orion Context Provider query multiple entities
税务信息系统包含城市中每个公民的所有税务信息。
遵循 FIWARE 原则,消费者向 Orion 查询实体(公民)税务信息,并将请求转发给上下文提供者(即:TaxInformationSystem)似乎是有意义的。
Query citizen X tax information -> Orion -> TaxInformationSystem_CP
根据documentation,上下文提供者可以将自己注册为特定属性的源。例如,这可以使这项工作:
http://{{orion}}/v2/entities/urn:citizenID/attrs/name/tax
但是,这个好像要求每个公民都进行实体登记,所以税务信息系统应该多次登记(一个每个公民)。 (还有 residenceInformationSystem、healthInformationSystem 以及...)
"entities": [
{
"id" : "citizenID", //one per citizen ???
"type": "taxInformation"
}
],
这似乎至少有很多 unnecessary/superfluous 工作。
多读了一点之后,seems any workaround is not yet implemented/supported
- 我似乎无法使用查询参数
http://{{orion}}/v2/entities/tax?citizen=X
,因为它们 aren't forwarded to CP
- 似乎我无法查询 any 公民税
http://{{orion}}/v2/entities/X/tax
如果没有先明确创建实体
- 似乎我无法设置 idPattern(目前仅支持 .*),因为它 return all citizens税,因为 Broker 没有转发请求过滤器,既没有 entity 到 CP
- 两者都不 typePattern
(IIUC, isPattern seems now deprecated in favour of idPattern/typePattern)
我是不是做错了什么? 每个公民注册一次是唯一的出路吗?
不确定我是否完全理解你的情况...
您可以像这样为所有公民进行注册:
{
"dataProvided": {
"entities": [
{
"idPattern": ".*",
"type": "taxInformation"
}
],
"attrs": [
...
},
"provider": {
"http": {
"url": "http://thetaxsystem.com"
}
}
}
所以如果你想获得特定公民的税务信息,你可以在 CB 做这样的事情:
GET /v2/entities/1234567H?type=taxInformation
并且该注册将导致请求作为上下文提供者发送到税务系统。
编辑: Context Broker (this one) 存在问题,导致此案例无法正常工作。特别是第二种情况:
regR = .*
, query = 'E', attrs = {null}
EDIT2: 上述情况已在 Orion Context Broker 中得到解决。它现在在 master 分支(dockerhub 中的 :latest
标签)中可用,并将包含在下一个 Orion Context Broker 版本 (3.1.0) 中。
在 FIWARE 中,在每个系统或平台中,都有更常用和更成熟的功能,也有更多实验性和令人眼花缭乱的功能。真实用例和真实客户对某些功能的要求(以及在现实生活和实际部署中的使用)越多,它们就会得到更多的巩固、证明和扩展。注册不是这种情况,复杂的联邦场景不符合当前的技术水平。我同意它们启用了一些非常有趣的实验性用例,但在实际部署中,联合方案会增加额外的复杂性,使其在现阶段不受欢迎。
税务信息系统包含城市中每个公民的所有税务信息。
遵循 FIWARE 原则,消费者向 Orion 查询实体(公民)税务信息,并将请求转发给上下文提供者(即:TaxInformationSystem)似乎是有意义的。
Query citizen X tax information -> Orion -> TaxInformationSystem_CP
根据documentation,上下文提供者可以将自己注册为特定属性的源。例如,这可以使这项工作:
http://{{orion}}/v2/entities/urn:citizenID/attrs/name/tax
但是,这个好像要求每个公民都进行实体登记,所以税务信息系统应该多次登记(一个每个公民)。 (还有 residenceInformationSystem、healthInformationSystem 以及...)
"entities": [
{
"id" : "citizenID", //one per citizen ???
"type": "taxInformation"
}
],
这似乎至少有很多 unnecessary/superfluous 工作。
多读了一点之后,seems any workaround is not yet implemented/supported
- 我似乎无法使用查询参数
http://{{orion}}/v2/entities/tax?citizen=X
,因为它们 aren't forwarded to CP - 似乎我无法查询 any 公民税
http://{{orion}}/v2/entities/X/tax
如果没有先明确创建实体 - 似乎我无法设置 idPattern(目前仅支持 .*),因为它 return all citizens税,因为 Broker 没有转发请求过滤器,既没有 entity 到 CP
- 两者都不 typePattern
(IIUC, isPattern seems now deprecated in favour of idPattern/typePattern)
我是不是做错了什么? 每个公民注册一次是唯一的出路吗?
不确定我是否完全理解你的情况...
您可以像这样为所有公民进行注册:
{
"dataProvided": {
"entities": [
{
"idPattern": ".*",
"type": "taxInformation"
}
],
"attrs": [
...
},
"provider": {
"http": {
"url": "http://thetaxsystem.com"
}
}
}
所以如果你想获得特定公民的税务信息,你可以在 CB 做这样的事情:
GET /v2/entities/1234567H?type=taxInformation
并且该注册将导致请求作为上下文提供者发送到税务系统。
编辑: Context Broker (this one) 存在问题,导致此案例无法正常工作。特别是第二种情况:
regR =
.*
, query = 'E', attrs = {null}
EDIT2: 上述情况已在 Orion Context Broker 中得到解决。它现在在 master 分支(dockerhub 中的 :latest
标签)中可用,并将包含在下一个 Orion Context Broker 版本 (3.1.0) 中。
在 FIWARE 中,在每个系统或平台中,都有更常用和更成熟的功能,也有更多实验性和令人眼花缭乱的功能。真实用例和真实客户对某些功能的要求(以及在现实生活和实际部署中的使用)越多,它们就会得到更多的巩固、证明和扩展。注册不是这种情况,复杂的联邦场景不符合当前的技术水平。我同意它们启用了一些非常有趣的实验性用例,但在实际部署中,联合方案会增加额外的复杂性,使其在现阶段不受欢迎。