Fiware Context Provider hello world not working

Question

I'm trying to register a Context Provider as source for several KPIs.

So far, it seems registering might be working, as GET http://{{orion}}/v2/registrations returns something similar to what I set in creation:

{
    // each registering a new id is returned: "id": "60991a887032541f4539a71d",
    "description": "City Inhabitants",
    "dataProvided": {
        "entities": [
            {
                "id": "city.inhabitants"
                //,"type": "KeyPerformanceIndicator"
            }
        ]
    },
    "provider": {
        "http": {
            "url": "http://myhost/v2/inhabitants"
        }
        //, "legacyForwarding": false //perhaps there's a bug, cause although unset or set to false, broker still returns true.
    }
}

However GET http://{{orion}}/v2/entities/city.inhabitants results in:

{
    "error": "BadRequest",
    "description": "Service not found. Check your URL as probably it is wrong."
}

GET http://{{orion}}/v2/entities?type=KeyPerformanceIndicator returns [] and context-provider is not being invoked any way.

I'm coding a Node.js application from scratch, to better understand what's going on https://github.com/FIWARE/tutorials.Context-Providers, and using tutorial containers as actual Fiware Broker, so all stores/shelf/products are working but not my KPI.

`"entities": [{"id": "city.inhabitants","type": "KeyPerformanceIndicator"}]` means that only that combined `id` and `type` will return anything. Try removing `id` or using a regex — Jason Fox, May 10 '21 at 12:04
`legacyForwarding` is to return in NGSI-v1 format - this is no longer requried — Jason Fox, May 10 '21 at 12:05
@JasonFox regarding legacyForwarding: According to https://github.com/telefonicaid/fiware-orion/issues/3068#issuecomment-470882487 if not set should be false, but the broker still returns legacyForwarding=true. Perhaps its a bug? — tanimientras, May 10 '21 at 12:07
Possibly, all I'm saying is that it should not be needed in your example and can be ignored for now. — Jason Fox, May 10 '21 at 12:10
@JasonFox isn't the usage of id+type requiring to use both, as a good practice as stated by : https://fiware-orion.readthedocs.io/en/master/user/context_providers/index.html ? > 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. — tanimientras, May 10 '21 at 12:11
it depends on what you are trying to do. The set of params can be found [here](https://fiware-orion.readthedocs.io/en/master/admin/database_model/index.html#registrations-collection). Yes for that specific example `id` and `type` are specified, but they are not both mandatory in all cases. — Jason Fox, May 10 '21 at 12:17
@JasonFox your link mentions _providingApplication_ but I'm using _provider_ as doc examples [1]. Is using **"provider"** right? [1] https://fiware-orion.readthedocs.io/en/master/user/walkthrough_apiv2/index.html#context-availability-management — tanimientras, May 10 '21 at 12:25

Jason Fox · Accepted Answer · 2021-05-10T14:51:30.160

Using the tutorial application where a microservice is listening on the http://context-provider:3000/random/weatherConditions POST endpoint.

The following registration:

curl -L -X POST 'http://localhost:1026/v2/registrations' \
-H 'Content-Type: application/json' \
--data-raw '{
   "description": "Get Weather data for KPI 1",
   "dataProvided": {
     "entities": [
       {
         "id" : "urn:ngsi-ld:KPI:010",
         "type": "KeyPerformanceIndicator"
       }
     ],
     "attrs": [
      "temperature", "relativeHumidity"
    ]
   },
   "provider": {
     "http": {
       "url": "http://context-provider:3000/random/weatherConditions"
     },
     "legacyForwarding": false
   },
   "status": "active"
}'

Will forward and retrieve data for the following request:

curl -L -X GET 'http://localhost:1026/v2/entities/urn:ngsi-ld:KPI:010'

or

curl -L -X GET 'http://localhost:1026/v2/entities/?type=KeyPerformanceIndicator'

Returns:

{
    "id": "urn:ngsi-ld:KPI:010",
    "type": "KeyPerformanceIndicator",
    "temperature": {
        "type": "Number",
        "value": 11,
        "metadata": {}
    },
    "relativeHumidity": {
        "type": "Number",
        "value": 39,
        "metadata": {}
    }
}

The context broker is forwarding the request to the http://context-provider:3000/random/weatherConditions POST end-point with the following payload:

{
 "entities": [
  {
   "id": "urn:ngsi-ld:KPI:010",
   "type": "KeyPerformanceIndicator"
  }
 ],
 "attrs": [
  "temperature",
  "relativeHumidity"
 ]
}

And that's all true...the only difference I see in what I tried so far is fiware having issues redirecting to http://myhost/v2/inhabitants... — tanimientras, May 10 '21 at 12:56
As trying an internal (docker) endpoint was working, the issue should be related to requests, so _docker logs -f containerid_ dumped a clarifying "Cannot POST /v2/inhabitants/op/query". In fact, my node application was listening to GET requests instead of POST :( Thank you @JasonFox. BTW: Wouldn't it be great to create a Discord channel for FIWARE??? (cough, cough, PLEASE, cough, cough) — tanimientras, May 10 '21 at 13:04

Fiware Context Provider hello world not working

1 Answers1

Linked