Fiware 检索年度KPI的最佳做法/预期方法

从现在开始，我不知道处理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:'

然后，从“城市居民：2020年”开始计算

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

---

请不要犹豫，纠正任何你可能发现的错误。任何链接/文档都很好。

顾名思义，上下文代理就是用来处理的——这就是某个时刻真实世界的状态。 有一个现有的KPI值，预计代表KPI的NGSI实体将持有该KPI的最新值——换句话说，“我们现在做得怎么样”。例如，您的上下文代理可以持有City实体，并且该实体可以具有一个属性，其值持有当前KPI，并且该值应遵循KPI数据模型

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

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

---

总之，如果一个属性（如二进制文件、图像或数据库查询）不适合“现在”它可能不直接属于上下文代理-如果需要，可以使用带有文本/URL值的属性作为链接，并使用更适合于历史数据操作的工具来实现您的目的。

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

GET https://{{{ORION}}/v2/entities/city.incidents？q=dateCreated=…

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

---

理解并同意您的回答，我想到了一个想法（在标记为已解决之前）：FIWARE可以被视为一种模型/架构模式/哲学，用于不可知地互连应用程序和信息源。事实上，NGSI可以理解为“一个API来管理所有API”，并将FIWARE作为交换信息的中心点，而不是使用app->database“取缔”查询。在开放数据场景中，信息由应用程序（上下文提供者）提供，KPI将如何工作？让OpenData backend attack应用程序的数据库在我看来是错误的。使用标准化数据模型提供KPI开放数据是正确的做法-至少如果可以通过对CB的请求和对DB的第二个请求检索KPI，则KPI的格式是已知的。因为上下文代理没有内存，所以它不能直接保存信息，所以使用URL属性对我来说是可行的。当然，URL不应该直接指向数据库，它应该指向一个对所用数据库进行抽象的微服务（并且应该以通常的方式进行保护（例如OAuth、IDSA等）检索城市并向URL发出第二个请求的过程与在实体之间遍历知识图没有什么不同。您所描述的不是上下文提供者的基本工作原理吗？假设是这样，您的建议似乎是：App->CB（实体城市，属性人口）->CP，不是吗？还有一个关于如何处理“不是现在”信息的问题，但想知道应用程序会如何请求“旧”信息普查数据。使用时态接口/过滤器是可行的方法吗？我试图描述HATEOAS的一种用法，其中上下文代理响应使客户端只需要了解如何进一步交互。架构上，上下文代理实体属性应该只保存“现在”或静态数据。