Как включить заголовки fiware-service и fiware-servicePath в регистрацию брокера контекста Orion для поставщика контекста? - PullRequest
1 голос
/ 10 января 2020

Мы исследуем технологию Orion Context Broker с использованием локальных контейнеров Docker и пытаемся интегрировать локального Context Broker с внешним поставщиком контекста.

В частности, мы пытаемся получить данные от этого поставщика контекста :

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

Использование заголовков:

fiware-service: environment

fiware-servicePath: / Madrid

Конкретно, наша цель - добиться регистрации нашего брокера контекста на этом узле провайдера, чтобы получить некоторые атрибуты, которых у нас нет в локальной сети (в этом примере атрибут называется «НЕТ». ").

Запрос, который мы отправляем на регистрацию, следующий:

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"
    }
  }
}'

Кроме того, мы создали локальный объект с тем же идентификатором, что и в запросе: Madrid- AirQualityObserved-28079059-latest

После этой информации возникает вопрос:

Можно ли включить указанные c fiware-service и fiware-ser заголовки VicePath в запрос на регистрацию? Как их можно включить?

Заранее спасибо.

РЕДАКТИРОВАТЬ:

Я проводил больше тестов со следующими командами:

Для регистрации в провайдере контекста используйте указанные заголовки c для требуемой услуги. На данный момент локальная сущность не создается в локальном посреднике контекста.

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"
    }
  }
}'

Затем я проверяю, правильно ли зарегистрирована регистрация:

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

Наконец, я попытался получить объект от провайдера:

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

Но ответ указывает, что для этого запроса нет объекта. Из-за этого я создал сущность в локальном посреднике контекста, исключая поле, которое я пытаюсь получить от поставщика «НЕТ».

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"
}'

Однако, если я обращаюсь к сущности с идентификатор Madrid-AirQualityObserved-28079059-новее, я получаю локальные данные, а поле «НЕТ» не получено от провайдера. Вот ответ (пропущено поле НЕТ):

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

Что я делаю не так?

1 Ответ

0 голосов
/ 13 января 2020

Да, это возможно.

Они включены как обычные заголовки. Например, если вы используете curl, это будет что-то вроде -H 'fiware-service: environment' -H 'fiware-servicepath: /Madrid'.

EDIT:

Поиск запроса, который вы используете:

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

Я вижу, что в запрос не включается тип сущности, в отличие от рекомендации в провайдерах контекста и переадресации запроса на документацию :

При пересылке любой тип объекта в обновлении / запросе NGSIv2 соответствует регистрации без типа объекта. Однако обратное не работает, поэтому, если у вас есть регистрации с типами, вы должны использовать ?type в обновлении / запросе NGSIv2, чтобы получить соответствие. В противном случае вы можете столкнуться с проблемами, как описано в этом посте в StackOverflow .

Так что, возможно, вам следует использовать:

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