Fiware orion /op/query 端点工作解释

Question

I'm a student learning the fiware ecosystem. From my previous explorations, I learned how Orion can use proxy services to use external context providers to fetch dynamic context data. Here I understood how different endpoints can provide different responses from the given example code which is an express.js application. But I am confused on a few points and want to know working of these.

1. How is the Orion batch query able to hit the data if there is no /op/query endpoint defined in the example code?

2. In the commented section there is these endpoints of the format /random/temperature/ngsi-ld/v1/entities/ , In these does Orion append the ngsi-ld/v1/entities/ part whenever the context of the Store entity is requested using orion/v2/entities/<entity-id> endpoint?

3. If orion context broker somehow directs these queries to the proxy by altering them, Where can I get code of the context broker itself for better understanding?

I am working on my college project and any help is appreciated. Thanks in advance.

Answer 1

The code for the example application you are using is written for NGSI-LD , not NGSI-v2 - they are not the same. The example written explicitly for NGSI-v2 does indeed contain an /op/query/ endpoint see here

router.post('/catfacts/:type/:mapping/op/query', CatFactsNGSIProxy.getAsNGSIv2);
router.post('/random/:type/:mapping/op/query', RandomNGSIProxy.getAsNGSIv2);
router.post('/static/:type/:mapping/op/query', StaticNGSIProxy.getAsNGSIv2);
router.post('/twitter/:type/:mapping/:queryString/op/query', TwitterNGSIProxy.getAsNGSIv2);
router.post('/weather/:type/:mapping/:queryString/op/query', WeatherNGSIProxy.getAsNGSIv2);

This allows for a simple connection to IoT Agents which just needs to handle the /op/query/ endpoint.

Note :type/:mapping/:queryString are just added to keep the sample code generic, and would not be needed for a simple registrant.

In NGSI-LD , the ETSI committee has decided that a request forwarded to a registrant application shall mimic the original request as far as possible, so a GET is forwarded as a GET, a POST as a POST, a DELETE as a DELETE etc. The equivalent endpoints look like this:

router.get('/catfacts/:type/:mapping/ngsi-ld/v1/entities/:id', CatFactsNGSIProxy.getAsNgsiLD);
router.get('/random/:type/:mapping/ngsi-ld/v1/entities/:id', RandomNGSIProxy.getAsNgsiLD);
router.get('/static/:type/:mapping/ngsi-ld/v1/entities/:id', StaticNGSIProxy.getAsNgsiLD);
router.get('/twitter/:type/:mapping/:queryString/ngsi-ld/v1/entities/:id', TwitterNGSIProxy.getAsNgsiLD);
router.get('/weather/:type/:mapping/:queryString/ngsi-ld/v1/entities/:id', WeatherNGSIProxy.getAsNgsiLD);

In NGSI-LD , the focus is generally on the federated use cases of multiple full context brokers talking to each other, which obviously can handle all NGSI endpoints, however, there are also other common distributed deployment scenarios:

• Support for actuation (IoT Agents)
• Support for “lazy” attributes (IoT Agents)
• Explicit distribution of context information, eg one context source for vehicles, another for bicycles
• Backup context sources eg less frequently updated
• Complex Data Sharing scenarios

To cover this, it is now possible to define a subset of accepted operations - more information can be found here . This decision allows for a much wider range of data sharing scenarios to be catered for.