2

We are researching about the Orion Context Broker technology using local Docker containers and trying to integrate the local Context Broker with an external Context Provider.

Specifically, we are trying to retrieve data from this Context provider:

https://streams.lab.fiware.org/v2/entities?type=AirQualityObserved&options=keyValues

Using the headers:

fiware-service: environment

fiware-servicePath: /Madrid

Concretely, our objective is to achieve a registration from our Context Broker to this node of the provider, in order to get some attributes that we don't have in local (in that example, the attribute is called "NO").

The request we are sending for the registration is the following one:

curl -iX POST \
  'http://localhost:1026/v2/registrations' \
  -H 'Content-Type: application/json' \
  -d '{
  "description": "Air Quality Madrid",
  "dataProvided": {
    "entities": [
      {
        "id": "Madrid-AirQualityObserved-28079059-latest",
        "type": "AirQualityObserved"
      }
    ],
    "attrs": [
      "NO"
    ]
  },
  "provider": {
    "http": {
      "url": "https://streams.lab.fiware.org"
    }
  }
}'

Additionally, we have created a local entity with the same id as in the request: Madrid-AirQualityObserved-28079059-latest

After that information, the question is:

Is it possible to include the specific fiware-service and fiware-servicePath headers into the registration request? What is the way to include them?

Thanks in advance.

EDIT:

I've been doing more tests with the following commands:

For registering to the context provider, using the specific headers for the desired service. For now, the local entity is not created in the local context broker.

curl -iX POST \
  'http://localhost:1026/v2/registrations' \
  -H 'Content-Type: application/json' \
  -H 'fiware-service: environment' \
  -H 'fiware-servicepath: /Madrid' \
  -d '{
  "description": "Air Quality Madrid",
  "dataProvided": {
    "entities": [
      {
        "id": "Madrid-AirQualityObserved-28079059-latest",
        "type": "AirQualityObserved"
      }
    ],
    "attrs": [
      "NO"
    ]
  },
  "provider": {
    "http": {
      "url": "https://streams.lab.fiware.org"
    }
  }
}'

Then, I've check if the registration has been correctly registered:

curl -X GET http://localhost:1026/v2/registrations \
    -H 'fiware-service: environment'   
    -H 'fiware-servicepath: /Madrid'

Finally, I've tried to retrieve the entity from the provider:

curl -X GET http://localhost:1026/v2/entities/Madrid-AirQualityObserved-28079059-latest \
  -H 'fiware-service: environment' \
  -H 'fiware-servicepath: /Madrid'

But the response indicates that there is not any entity for that request. Because of that, I've created the entity in the local context broker, excluding the field that I'm trying to obtain from the provider "NO".

curl -iX POST \
  'http://localhost:1026/v2/entities' \
  -H 'Content-Type: application/json' \
  -H 'fiware-service: environment' \
  -H 'fiware-servicepath: /Madrid' \
  -d '
{
    "id": "Madrid-AirQualityObserved-28079059-latest",
    "type": "AirQualityObserved"
}'

However, if I consult the entity with the ID Madrid-AirQualityObserved-28079059-latest, I'm receiving the local data, and the field "NO" is not being retrieved from the provider. That is the response (missing the NO field):

{
    "id": "Madrid-AirQualityObserved-28079059-latest",
    "type": "AirQualityObserved"
}

What I am doing wrong?

Carlos
  • 41
  • 6

1 Answers1

0

Yes, it's possible.

They are included as regular headers. For instance, if you are using curl, it would be something like -H 'fiware-service: environment' -H 'fiware-servicepath: /Madrid'.

EDIT:

Looking to the query request you are using:

curl -X GET http://localhost:1026/v2/entities/Madrid-AirQualityObserved-28079059-latest \
  -H 'fiware-service: environment' \
  -H 'fiware-servicepath: /Madrid'

I see are not incluing the entity type in the query, contrary to the recomendation in the context providers and request forwarding documentantation:

On forwarding, any type of entity in the NGSIv2 update/query matches registrations without entity type. However, the opposite doesn't work, so if you have registrations with types, then you must use ?type in NGSIv2 update/query in order to obtain a match. Otherwise you may encounter problems, like the one described in this post at StackOverflow.

So maybe you should use:

curl -X GET http://localhost:1026/v2/entities/Madrid-AirQualityObserved-28079059-latest?type=AirQualityObserved \
  -H 'fiware-service: environment' \
  -H 'fiware-servicepath: /Madrid'
fgalan
  • 11,732
  • 9
  • 46
  • 89
  • Hi @fgalan. We would really appreciate it if you could review the edit of the first post. Thanks! – Carlos Jan 14 '20 at 09:22
  • I have updated also my answer. Not sure if what I describe can be the cause, hope it helps... – fgalan Jan 14 '20 at 19:33
  • Hi. It is still not working after adding the type parameter. Any other suggestion? Do you have any example of a registration to an specific service and servicepath of a provider? Thanks in advance. – Carlos Jan 16 '20 at 08:12
  • In fact, we thought the Context provider was exclusively another Orion CB instance but, after some researching, we discovered that the provider is a custom app that is connected to different data sources (APIs, etc.). Is this correct? If so, is it possible to persist the retrieved information from the provider in the local Orion CB or it is not supported (it is just a proxy)? – Carlos Jan 16 '20 at 10:25
  • So maybe the problem is not in the forwarded request sent by Orion to the custom app acting as provider, but in the custom app itself... Could you check if Orion is sending the forwareded request to the custom app (i.e. tcpdump, etc.)? Is there anything relevant in the Orion logs when you do the tests? – fgalan Jan 27 '20 at 12:11