如何解决最佳实践/检索年度 KPI 的预期方法
从 here 开始，我不知道处理往/返 Orion 的年度 KPI 的预期方式/最佳做法是什么？。
考虑以下场景：
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 而是处理实体，并且每年都是 population entity 的一个属性
请不要犹豫，纠正您可能发现的任何错误。任何链接/文档也很棒。
解决方法
顾名思义，上下文代理旨在处理 context data - 即某个时间实例中现实世界的状态。 KPI 有一个现有的 data model，预计代表 KPI 的 NGSI 实体将持有该 KPI 的最新值 - 换句话说，“我们现在做得怎么样” .例如，您的上下文代理可以保存 City 实体，并且该实体的值可以保存当前 KPI - 该值应遵循 KPI 数据模型。
现在，如果上下文代理持有当前 KPI 值，并且该值随时间变化，则历史上下文可以持久保存到数据库（例如使用 Cygnus、Draco 或 QuantumLeap），然后查询上下文代理外部的数据。 NGSI-LD 系统的另一个替代方案是，可以使用标准时间接口。然而，它似乎不太适合这种情况。
检索临时历史记录不适合保存在上下文代理中的上下文数据，因为它与“现在”无关。查询和检索历史数据的明显解决方案是使用数据库而不是上下文代理。
总而言之，如果一个属性，如二进制文件、图像或数据库查询不适合“现在”，它可能不直接属于上下文代理 -如果需要，使用带有文本/URL 值的属性作为链接，并使用更适合历史数据操作的工具来实现您的目的。
,似乎可以使用过滤器轻松解决此问题
GET https://{{ORION}}/v2/entities/city.inhabitants?q=dateCreated=...
但是，将过滤器转发到上下文提供程序似乎不起作用：
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
