Proper use of supportedForwardingMode in registrations

[fgalan]

With the implementation of supportedForwardingMode in Orion Context Broker (issue https://github.com/telefonicaid/fiware-orion/issues/3106), the NGSIv2 registrations done by the IOTA Library should be adapted the following way:

• Registrations corresponding to lazy attributes should use "supportedForwardingMode": "query"
• Registrations corresponding to commands should use "supportedForwardingMode": "update"

NGSIv1 and NGSI-LD will be out of the scope of this issue.

[AlvaroVega]

Ngsi registers are handled in https://github.com/telefonicaid/iotagent-node-lib/blob/master/lib/services/devices/registrationUtils.js

[fgalan]

Ngsi registers are handled in https://github.com/telefonicaid/iotagent-node-lib/blob/master/lib/services/devices/registrationUtils.js

It seems IOTA does the registration in a single POST /v2/registrations. To take advantage of this feature, now we need to split into two ones, each one with a different supportedForwardingMode (query and update)

[fgalan]

Some more findings:

1. Looking into the sendRegistrationsNgsi2() function I have found the fragment of the c

    const options = {
        url: cbHost + '/v2/registrations',
        method: 'POST',
        json: {
            dataProvided: {
                entities: [
                    {
                        type: deviceData.type,
                        id: String(deviceData.name)
                    }
                ],
                attrs: []
            },
            provider: {
                http: {
                    url: config.getConfig().providerUrl
                }
            }
        },
        headers: {
            'fiware-service': deviceData.service,
            'fiware-servicepath': deviceData.subservice
        }
    };

So a "wide" registration is being used (note the attrs: []). Not sure if at this point of the code we have access to lazy and commands attributes. Is that information being passed down to the function and accessible to build the registration payload at that point?

2. The registration ID is stored in devices collection in database as an string, i.e.:

"registrationId" : "5f984771106a3ac82b336f3e",

If we are going to use two registrations, the two strings need to be stored (either in an array, a sub-object or as an additional field, e.g. `registrationIdLazy")

[AlvaroVega]

@fgalan is possible that lazy and commands are present at the same time for the same registration ?

[fgalan]

@fgalan is possible that lazy and commands are present at the same time for the same registration ?

Do you mean a single resitration (I mean, one POST /v2/registrations with a resulting registration id) with some attributes in "supportedForwardingMode": "update" and some others "supportedForwardingMode": "query"?

No, it's not possible: the supportedForwardingMode applies to the whole registration. If you need an entity with some attributes of each kind, then two registrations are needed.

[AlvaroVega]

I mean if one registration could involve a device with lazy and command attributes at the same time

[fgalan]

Note that from the point of view of CB "lazy atrribute" and "command" are terms without special semantic. However, if we reformulate this way

lazy attribute = attribute in supportedForwardingMode query command = attribute in supportedForwardingMode update

so the question is:

if one registration could involve a device with attribute in supportedForwardingMode query and attribute in supportedForwardingMod update at the same time?

answer is "no". You need two registrations for that