检索年度 KPI 的最佳 practices/Expected 方式

Question

从向前推进，我不知道 处理年度 KPI to/from Orion 的预期 way/best 做法是什么？。

考虑以下场景：

1-Consumers requests per-year city inhabitants KPI (city census in 2020, 2021, and so on).
Sometimes it requests current year, or even a few (ie:drawing population graph) making multiple requests.
2-Orion should forward the request to Context Provider
3-Context Provider returns keyPerformanceIndicator for a valid year

由于每年为人口进行一次注册对我来说似乎很奇怪，也许在注册提供者时，我可以使用：

isPattern: 'true',
id: 'city.inhabitants:'

然后，提供商应用程序从 'city.inhabitants:2020'

解析年份

也许我完全错了，Fiware应该处理的不是KPI而是实体，每年都是人口实体

的一个属性

请不要犹豫，更正您可能发现的任何错误。任何 link/documentation 也很好。

Answer 1

顾名思义，上下文代理旨在处理 context data - 即现实世界在某个时间实例的状态。 KPI 有一个现有的 data model，预计代表 KPI 的 NGSI 实体将持有该 KPI 的最新值 - 换句话说 “我们现在做得如何”。例如，您的上下文代理可以保存 City 实体，并且可以有一个属性其值保存当前 KPI - 并且该值应遵循 KPI 数据模型。

现在，如果上下文代理持有当前 KPI 值，并且该值随时间变化，则可以将历史上下文持久保存到数据库中（例如使用 Cygnus、Draco 或 QuantumLeap），然后在上下文外部查询数据经纪人。对于 NGSI-LD 系统的另一种选择，可以使用标准时间接口。然而，它似乎不太适合这种情况。

检索临时历史记录不适合保存在上下文代理中的上下文数据，因为它与 "the Now" 无关。查询和检索历史数据的明显解决方案是使用数据库而不是上下文代理。

总而言之，如果二进制文件、图像或数据库查询等属性不自然地适合 “现在”，它可能不直接属于在上下文代理中 - 如果需要，使用属性和 text/URL 值作为 link，并使用更适合历史数据操作的工具来实现您的目的。

Answer 2

似乎可以使用过滤器轻松解决这个问题

GET https://{{ORION}}/v2/entities/city.inhabitants?q=dateCreated=...

但是，将过滤器转发到上下文提供程序似乎不起作用：

https://github.com/telefonicaid/fiware-orion/issues/2282

检索年度 KPI 的最佳 practices/Expected 方式

Best practices/Expected way to retrieve yearly KPI

fiware