Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problems with change-based subscriptions and queries for Context Source registrations #1671

Open
daniel-gonzalez-sanchez opened this issue Sep 23, 2024 · 0 comments

Comments

@daniel-gonzalez-sanchez
Copy link

daniel-gonzalez-sanchez commented Sep 23, 2024

Hi everyone,

I was playing around with NGSI-LD Context Source Registration operations when I discovered an issue with change-based subscriptions and queries performed from a Context Consumer to entities provided by the Context Source registered within a Distribution Context Broker. I have been able to debug the problem and it seems that the error may be related to a bad redirection of the requests (i.e., subscription notifications or queries) between the Distribution Context Broker and the Context Source. In addition, I have discovered an error specifying the jsonldContext parameter within the body of the subscription request that is valid for subscription operations in order to indicate the URI of JSON-LD context provider by following the ETSI CIM standard and the specification document for the NGSI-LD API (i.e., GS CIM 009).

Let me reproduce a complete example of the problem:

Environment

  • Both the Context Source and the Distribution Context Broker have been tested with the base implementation of Orion-LD.
  • fiware/orion-ld:latest (using the sample docker-compose file found in the official ORION-LD Context Broker DockerHub repository)

Steps to reproduce
Registering within the Distribution Context Broker the Context Source which can provide TemperatureSensor entities:

curl --location --request POST 'distribution-context-broker:1026/ngsi-ld/v1/csourceRegistrations/' \
--header 'Accept: application/json' \
--header 'Link: <http://context-catalog:8080/context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
--header 'Content-Type: application/json' \
--data-raw '{
    "type": "ContextSourceRegistration",
    "name": "Scorpio Context Source",
    "description": "Context Source Registration for entities TemperatureSensor",
    "information": [
        {
            "entities": [{
                "type": "TemperatureSensor"
            }]
        }
    ],
    "endpoint": "http://context-source:1026"
}'

Creating within the Distribution Context Broker a change-based subscription to a sample TemperatureSensor NGSI-LD Entity for changes within a temperature property and the endpoint of the Context Consumer configured to receive the notifications:

curl --location --request POST 'distribution-context-broker:1026/ngsi-ld/v1/subscriptions/' \
--header 'Content-Type: application/json' \
--header 'Link: <http://context-catalog:8080/context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
--data-raw '{
    "id": "urn:ngsi-ld:Subscription:TemperatureSensor",
    "type": "Subscription",
    "entities": [{
           "type": "TemperatureSensor"
    }],
    "description": "Change-based subscription to TemperatureSensor for changes within temperature property.",
    "notification": {
           "endpoint": {
		   "uri": "http://context-consumer:8082/notify",
		   "accept": "application/json"
           }
    }
}'

, where the header link of the request point out to a microservice which hosts the context associated with the TemperatureSensor entity. For direct subscriptions to a Context Broker, this change-based subscription work well (i.e., in a centralized architecture with only the Context Broker and without a Context Source role). Note here that we can observe an error if we specify the jsonldContext parameter within the body of the subscription request that is valid for subscription operations in order to indicate the URI of JSON-LD context provider. The error response is as follows:

{
    "type": "https://uri.etsi.org/ngsi-ld/errors/BadRequestData",
    "title": "Invalid field for Subscription",
    "detail": "jsonldContext"
}

Creating a sample TemperatureSensor NGSI-LD Entity with a temperature Property within the Context Source:

curl --location --request POST 'http://context-source:1026/ngsi-ld/v1/entities/' \
--header 'Content-Type: application/json' \
--header 'Link: <http://context-catalog:8080/context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
--data '{
    "id": "urn:ngsi-ld:TemperatureSensor:1",
    "type": "TemperatureSensor",
    "temperature": {
        "type": "Property",
        "value": 27.9,
        "unitCode": "CEL"
    }
}'

We then verify that notifications of entities of type TemperatureSensor do not reach the Context Consumer. To debug the issue, I captured traffic with the Wireshark tool on the virtual ethernet interfaces that connect the docker network to the Distribution Context Broker and Context Source microservices. Capturing traffic on the Distribution Context Broker microservice shows the HTTP requests for Context Source registration and subscription creation. Capturing traffic on the Context Source microservice shows only the HTTP request for creating the Temperature Sensor entity, but not the redirection of a creation notification for that entity to the Distribution Context Broker.

For comparative analysis, I perform the same test for a Query Entities operation performed from the Context Consumer to the Distribution Context Source in order to get the TemperatureSensor entities:

curl --location --request GET 'http://distribution-context-broker:1026/ngsi-ld/v1/entities/?type=TemperatureSensor' \
--header 'Accept: application/json' \
--header 'Link: <http://context-catalog:8080/context.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"'

In such a case, the query is not redirected from the Distribution Context Broker to the Context Source and the TemperatureSensor entity is not returned correctly.

Many thanks in advance!

Dani

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant