from what I can see here: https://github.com/telefonicaid/iotagent-node-lib/blob/master/lib/services/ngsi/ngsiService.js in the createRequestObject only /updateContext and /queryContext are used - so, ONLY NGSI 10 API.
Is NGSI 9 ever used in IoT Agents, and how?
I am surprised, because I expected that registering of device will call NGSI 9 registerContext, but this is not the case, and only NGSI 10 /updateContext is called.
BR,
Drasko
Agents use both NGSI 10 and NGSI 9, but they do not accept NGSI 9 requests. I.e.: Agents work as Context Providers when you define lazy attributes or commands, registering themselves with NGSI 9 in the Context Broker; being Context Providers, they must accept NGSI 10 requests (not NGSI 9), in order for the Context Broker to compose the response to a third party context request. All this behavior is explained with sequence diagrams in the IoTAgent Node.js library: https://github.com/telefonicaid/iotagent-node-lib#device-to-ngsi-mapping. In those diagrams you can see how the IoT Agents send registerContext requests for their lazy/command attributes.
On the other side, IOTAs do not accept NGSI requests, as they don't perform context request redirections (as a Orion do), for the IoT Agents are Context Providers, not Context Brokers.
Related
We are using the following stack :
Kotlin 1.6.0 running on JVM 11
com.netflix.graphql.dgs:graphql-dgs-spring-boot-starter 5.0.4
com.netflix.graphql.dgs:graphql-dgs-subscriptions-websockets 5.0.4
com.netflix.graphql.dgs:graphql-dgs-subscriptions-websockets-autoconfigure 5.0.4
org.springframework.boot:spring-boot-starter-security 2.6.7
org.springframework.boot:spring-boot-starter-oauth2-resource-server 2.6.7
We are authenticating using the Google Identity Platform from the client side and passing the resulting Bearer token to the DGS API.
The pure HTTP requests (DgsQuery, DgsMutation) are able to extract the processed/validated token without an issue - and we are able to determine the userId from this.
Expected Results
When calling a subscription graph call we are expecting to extract the same details from the processed Bearer token - so we can then utilise the User Identification within the business logic.
Actual Results
The SecurityContextHolder returns an authorization value that is null. And passing in an invalid token still correctly returns subscribed results, suggesting that the subscription endpoint is not being hooked into the JWT authentication at all.
Question
What would be the recommended approach in providing the same authentication behavior and availability of Security Context to Subscriptions as is available to both DGSQuery and DGSMutation annotated functions?
From research - I understand that this needs to be performed in the initial handshake and then saved to the session.
Worth mentioning - that when calling the server from the GraphiQL UI - therefore using the newest protocol - the authentication occurs and the Security Context is populated with the correct information. However, this then fails with "Trying to execute subscription on /graphql. Use /subscriptions instead!" - which is to be expected with the incompatible client/server versions.
In my understanding, ContextBroker provides two API models such as NGSI V1 / V2.
Regarding this options, How can I config the ContextBroker configuration?
For example:
Content-Type : application/json
Accep : application/json
http://example_location:1026/v1/queryContext
You don't need to select API version by configuration. CB supports both simultaneously so it is just a matter of "selecting" it by using the proper URL in RESTful operations:
Those URLs starting with /v1 belong to NGSIv1 version
Those URLs starting with /v2 belong to NGSIv2 version
My recommendation is use always version 2. Eventually v1 could be deprecated and removed from Orion in the future.
Maybe you find useful the following document which compares NGSIv1 vs NGSIv2 and shows how the latter is much more flexible, advanced and powerful.
My configuration in "wiring view" has the following components:
NGSI-source: Monitored NGSI Attributes: position
NGSI Entity to Point: Coordinates attribute: position
And these boxes are connected to Map Viewer, but I can't see the points in the map. Could you please answer the following questions?
Where is the problem?
Should I change the name of the attributes?
Seems that your context broker instance doesn't support https notifications. You have to install Rush and configure your context broker for using it. See this post for more info.
Take into account that the "NGSI Source" operator uses subscriptions while other widgets and operators use plain request (like queries) that works without needing https notifications.
I'm trying to trigger an event sending to a consumer according to the DOCS for FIWARE CEP PROTON. There should be a resource in the API to which one can POST and that action should trigger sending output events to consumer.
However, it is not clear if mentioned resource is a literal or variable string. In docs it says: POST localhost:8080/application-name/consumer. I have tried using the name of CEP application I made and deployed to engine, name of the consumer used in that app and combinations with literals from the example, but not one of the resources exist.
Anyone ever used this resource from the API? It would be very helpful to debug with it.
I'm not sure about what your question is. Do you want to POST input events to proton? You can do that using:
POST http://{host}:8080/ProtonOnWebServer/rest/events
application/json
and your event:
{"Name": "event_type_name", "attr1": "value1", "attr2": "value2"}
ProtonOnWebServer is the name of my instance.
You can use any application like POSTER for Firefox.
Hope it helps! :)
If you want the CEP to send output events through REST, you need to add a consumer of type REST to your CEP application definition. In this REST consumer definition, you need to specify the REST service url.
Please note, that this REST service is not a CEP service. The CEP activates external REST service as a client.
In the CEP user guide, under Consumers -> Rest, you can see more details on the various attributes of this consumer definition.
From that user guide:
Rest – this adapter type is a REST client that POSTs events to an external REST
service upon detection of derived events. A Rest type consumer has the following
additional built-in parameters:
URL – the fully qualified URL of the REST service for event push operation
using the POST method.
ContentType – can be "text/plain", "application/xml", or "application/json". This is defined by the REST service.
AuthToken – an optional parameter, that when set, is added as an X-Auth-Token
HTTP header of the request.
I need to write a Java JSON-RPC client that will communicate over RabbitMQ. All the implementations I've found assumed HTTP as the transport, and that won't work for me. RabbitMQ has it's own RPC client/server, but it's JSON-RPC 1.1, not 2.0.
Anyone have any suggestions? Thanks.
JSON-RPC is just a communications protocol based on JSON; JSON is just some UTF-16 text. JSON-RPC is therefore transport protocol-agostic (i.e: the JSON-RPC specification only concerns itself with the CONTENT of messages).
A JSON-RPC "webservice" is necessarily transported via HTTP(s). However, a JSON-RPC "server" can use almost any transport (e.g: raw TCP, SMTP, etc).
You could have a simple line-oriented (process a message when you see a newline) TCP server, and as long as the request is JSON-RPC formatted, and the reply is JSON-RPC formatted, then that is a JSON-RPC "server". If your transport protocol has the ability to receive and send UCS-2/UTF-16 then you can implement JSON-RPC over it.
Folks have already implemented JSON-RPC over "comet", websockets, webRTC, etc.
Some parts of the JSON-RPC 2.0 protocol are easier to implement over certain transports. For example, if your transport doesn't have simultaneous bi-directional communication (e.g: HTTP or HTTPs) then you can only implement a simplified version of the "notification" message. Instead of the "server" sending notification messages to the client whenever it pleases, either it piggy-backs "notification" messages on RPC-style replies (perhaps using "batch" messages), or the client itself "polls" the server for "notification" messages.
RabbitMQ has a plugin called web-stomp which implements websockets so that web browsers can communicate with RabbitMQ using JavaScript. If your target client is a web-browser and you don't need asynchronous notification support, you could easily send JSON-RPC messages over the websockets polyfill provided by web-stomp.
If your client language can already talk to RabbitMQ natively, then you simply encode the UTF-16 into something publishable by RabbitMQ and and decode them on the other side.
EDIT: Of course, websockets are asynchronous, and you can implement proper "notification" style messages over them.