Orion Context Provider query multiple entities

user_15885950 0
Viewed 159

Tax information system contains all Tax information regarding every citizen in the city.

Following FIWARE principles, seems it might make sense Consumers query Orion about entity(citizen) tax information, and the request being forwarded to Context Provider (ie:TaxInformationSystem).

Query citizen X tax information -> Orion -> TaxInformationSystem_CP

According to documentation, Context Providers can register themselves as source for specific attributes. This, for example, could make this work:

http://{{orion}}/v2/entities/urn:citizenID/attrs/name/tax

However, this seems to require every citizen to be registered as an entity, so tax information system should register multiple times (one per citizen). (And residenceInformationSystem, and healthInformationSystem, and...)

"entities": [
  {
    "id" : "citizenID",      //one per citizen ???
    "type": "taxInformation"
  }
],

and that seems, at least, a lot of unnecessary/superfluous work.

After reading a bit more, seems any workaround is not yet implemented/supported

  • Seems I can't use query parameters http://{{orion}}/v2/entities/tax?citizen=X, as they aren't forwarded to CP
  • Seems I can't query any citizen tax http://{{orion}}/v2/entities/X/tax if the entity hasn't be explicitly created first
  • Seems I can't set idPattern (currently only .* supported), as it would return all citizens tax, as Broker is not forwarding requests filters neither entity to CP
  • Neither typePattern

(IIUC, isPattern seems now deprecated in favour of idPattern/typePattern)

Am I doing something wrong? Is registering once per citizen the only way to go?

fiware fiware-orion
2 Answers

In FIWARE, and in every system or platform, there are features more used and mature and others more experimental and dizzy. The more the real use cases and the real customers ask for some features (and moreover uses at real life and real deployments) they will get more consolidated, proved and extended. That's not the case for registrations, complex federation scenarios are not in current state of the art. I agree that they enable some really interesting experimental use cases, but in real deployments federation scenarios add an extra level of complexity making them undesirable at this stage.

user_11476680

Not sure if I'm fully understanding you case...

You could do a registration for all citizen like this one:

{
  "dataProvided": {
    "entities": [
      {
        "idPattern": ".*",
        "type": "taxInformation"
      }
    ],
    "attrs": [
      ...
  },
  "provider": {
    "http": {
      "url": "http://thetaxsystem.com"
    }
  }
}

So if you want to get tax information of an specific citizen you could do something like this at the CB:

GET /v2/entities/1234567H?type=taxInformation

and that registration would cause the request sent to the tax system as Context Provider.

EDIT: there is an issue at Context Broker (this one) which is precluding this case to work. In particular, second case:

regR = .*, query = 'E', attrs = {null}

EDIT2: the above case has been solved in Orion Context Broker. It is now available in master branch (:latest tag in dockerhub) and will be included in the next Orion Context Broker release (3.1.0).

user_14859260
Related