0

Moving forward from here, I don't know What's the expected way/best practice to handle yearly KPIs to/from Orion?.

Consider the following scenario:

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

As doing one registration for each year population seems odd to me, perhaps, when registering the provider, I could use:

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

And then, provider application parsing year from 'city.inhabitants:2020'

Maybe I'm completely wrong, and Fiware is not expected to handle KPIs but entities, and each year is an attribute for population entity

Please, don't hesitate to correct anything you may find wrong. Any link/documentation would be great also.

tanimientras
  • 25
  • 6

2 Answers2

0

As the name suggests, a context broker is designed to deal with context data - that is the status of the real world at an instance of time. There is an existing data model for KPIs, it would be expected that an NGSI entity representing the KPI would hold the latest value of that KPI - in other words "how are we doing right now". Your context broker could then hold City entities for example, and that could have a Property whose value holds the current KPI - and that value should follow a KPI data model.

Now if a context broker holds a current KPI value, and that value changes over time, the historical context could be persisted to a database (e.g. using Cygnus, Draco or QuantumLeap) and then queried for data external of the context broker. Another alternatively for NGSI-LD Systems, the standard temporal interface could be used. However it doesn't seem to be a good fit in this case.

Retrieving ad-hoc historical records is a poor fit for context data held in a context broker as it has nothing to do with "the Now". The obvious solution for querying and retrieving historical data is to use a database rather than a context broker.

In summary, if an attribute, like a binary file, an image, or database query doesn't naturally fit in "the now" it probably doesn't directly belong in a context broker - use a property with a text/URL value as a link if you need it and use tools better suited for historical data manipulation to fulfil to your purpose.

Jason Fox
  • 5,115
  • 1
  • 15
  • 34
  • Understanding and agreeing with your answer, one thought come to my mind (before marking as solved): FIWARE can be seen as a model/architecture-pattern/philosophy to agnosticly-interconnect applications and information sources. In fact NGSI could be understood as "one API to rule them all", and make FIWARE the central point to exchange information, instead of using app->database "outlaw" queries. **In an Open Data scenario, where the information is provided by applications(Context providers) how KPIs would work?** making OpenData backend attack app's DB seems wrong to me. – tanimientras May 12 '21 at 07:28
  • Providing the KPI open data using a **standardized data model** is the way to go - at least if a KPI can be retrieved via a request to a CB and a second request to a DB it is in a known format. Since a context broker has no memory it can't hold the info directly so using a URL Property would work for me. Of course that URL shouldn't be to the DB directly, it should be to a microservice which abstracts the database used (and should be secured in the usual manner (e.g. OAuth, IDSA, whatever) – Jason Fox May 12 '21 at 08:09
  • The process of retrieving a City and making a second request to a URL is no different than traversing the knowledge graph between entities. – Jason Fox May 12 '21 at 08:10
  • Isn't what you are describing essentially how a Context Provider works? Assuming so, seems your suggestion is to make something like: App->CB (entity city, attribute population) -> CP, isnt it? Yet to create another question about how to handle "NOT right now" information, but wondering how would app request "older" census data. Is using a temporal interface/filter the way to go? – tanimientras May 12 '21 at 11:53
  • I was trying to describe a usage of HATEOAS where the Context Broker response leaves the client needing minimal knowledge of how to interact further. Architecturally Context Broker entity attributes should only hold "the now" or static data. – Jason Fox May 12 '21 at 13:29
  • First time I've heard about that. If you don't mind, I'll try to better understand (although I think I got it) before accepting this as a valid answer. However, if you can elaborate/have a working example/more detailed description, and post it as a new answer, I'll gladly accept that. Thanks – tanimientras May 13 '21 at 07:18
0

Seems this could be easily solved using filters

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

however, forwarding filters to Context Providers doesn't seem to work:

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

tanimientras
  • 25
  • 6