1

Our system needs to return several KPIs grouped in different topics:

  • Census:
    • citizens (number of inhabitants)
    • citizens without any studies
    • ...
  • Information desk
    • Phone response time
    • Mail response time
    • ...
  • Tax
    • Online payments
    • Window payments
    • ...

To my understanding, it would make sense to have an entity for each topic and each KPI being a KeyPerformanceIndicator attribute. eg: This could work similar to:

{
    "description": "Census Information system",
    "dataProvided": {
        "entities": [
            {
                "idPattern": ".*"
            }
        ],
        "attrs":[    //THIS SEEMS AN INTERESTING APPROACH, BUT SADLY ALSO INVALID
            {
                "name": "citizens",
                "type": "KeyPerformanceIndicator"
            },
            {
                "name": "citizens_without_studies",
                "type": "KeyPerformanceIndicator"
            },
            //...
        ]
    },
    "provider": {
        "http": {
            "url": "http://myhost/v2/census"
        }
    }
}

(TL;DR: "attrs" supports strings only, so can't return complex/data modeled types, like KPI)

Setting this happy idea aside, what it would be a good approach to solve this?

Must each KPI be an entity?

Is NGSI-LD what I'm looking for?

2 Answers2

2

I think your case can be solved in NGIv2. Let my try to explain.

Must each KPI be an entity?

Yes. That's the usual way of modelling KPIs according to the KPIs datamodel. Each KPI is modeled as an entity of type KeyPerformanceIndicator.

Can KPIs be categorized?

Yes. You can use the category attribute to do that.

For instance, you can have an KPI "Online payments" of category "Tax Information" modeled this way:

{  
  "id": "OnlinePayments",  
  "type": "KeyPerformanceIndicator",  
  ...
  "category": ["taxInformation"],  
  ...
}  

Note that category is an array, so a given KPI could belong to more than one category (although in your use case it seems that each KPI belongs to exactly one category so you don't need this feature)

How can I get KPIs that belong to a given category?

You can use regular Orion Context Broker filtering features for that. For instance, to get all KPIs in category taxInformation you could use this key:

GET /v2/entitites?type=KeyPerformanceIndicator&q=category:taxInformation

or this expression in subscriptions:

{
    "subject": {
        "entities": [
            {
                "idPattern": ".*",
                "type": "KeyPerformanceIndicator"
            }
        ],
        "condition": {
            ...
            "expression": {
               "q": "category:taxInformation"
            }
         }
    },
    ...
}
fgalan
  • 11,732
  • 9
  • 46
  • 89
  • [If query filtering were usable with Context Providers...](https://github.com/telefonicaid/fiware-orion/issues/2282) – tanimientras May 20 '21 at 16:43
  • @fgalan wouldn't it make sense to group kpi's using fiware-service? – tanimientras May 21 '21 at 10:46
  • @Perrolobo CPs were mentioned on the first 2 words of my message ;). On the other hand, Context provides are supposed to be providers of context, so I disagree with your statement. – tanimientras May 21 '21 at 10:53
  • fiware-service is typically used to provide context isolation among clients/project/tenants. E.g. `fiware-service: murcia` for the KPIs of the Murcia city and `fiware-service: cartagena` for the KPIs of the Cartagena city (each fiware-service which it's own authorized users). But of course, this possiblity could also be explored, in the case `category` solution don't suffice your case. – fgalan May 21 '21 at 15:02
  • wouldn't that be servicepath?. category does not work, as query filtering is not working with CP. Mantaining KeyPerfromanceIndicator type as _contract_ + CP only accepting .* pattern implies every CP system would receive every request...so wondering if fiware-service was a valid solution to isolate providers – tanimientras May 24 '21 at 07:25
0

If what you are trying to accomplish is to offer an NGSI interface for your KPI data, you can just create your own adaptor on top of your database that offers a REST interface compliant with NGSI-LD and such service can just return entities of type KeyPerformanceIndicator. Then, you can federate it to a Context Broker with a simple registration i.e. for entities of type KeyPerformanceIndicator. And that's all.

The usage of Linked Data would be recommendable as well, so I would go for NGSI-LD, as it has been officially endorsed by ETSI.

  • Could you please elaborate on CONTEXT ADAPTERS vs CONTEXT PROVIDERS? Any docs or link would be much appreciated – tanimientras May 24 '21 at 08:04
  • It is just the same, that is just a matter of terminology. The main takeaway is that you can just create a REST API following the the NGSI specification and the `KeyPerformanceIndicator` Data Model, on top of your database. – Jose Manuel Cantera May 25 '21 at 20:35
  • +1. dealing with some technical issues now, but the scenario is clear. thanks! – tanimientras May 26 '21 at 08:24