align fiware-service and fiware-servicepath syntax and semantics with Orion

[jmcanterafonseca]

IoTA layer must be aligned with CB layer in the syntax and semantics of fiware-service and fiware-servicepath. Currently it is not aligned. Notably, the definition of the syntax and semantics of both headers is described by

http://fiware-orion.readthedocs.io/en/develop/user/service_path/index.html http://fiware-orion.readthedocs.io/en/develop/user/multitenancy/index.html

and probably we would need a central definition place for both headers and to cross reference it from the different GEs that make use of it.

/cc @fgalan @mrutid

[dmoranj]

Be aware that, for most of the components, the service path is not exactly hierarchical, as they only accept a single level in the hierarchy. The multitenancy mechanism is clearer than the service_path.

[fgalan]

Actually, I'd say that the only one that interprests service path in hierarchicalway in IoTP is Orion. However, this is not a problem, as the single-element case is a particular case of the hierarchical approach.

[dmoranj]

There are currently several issues opened concerning how the service and servicepath flags work in the IoTAgents. I'm going to close all of them and leave this one as a single backlog item. We can also hold the appropriate discussions and requests here.

Summarizing, there are three differences in the behavior between the Orion Context Broker and the IoTAgents:

• Headers are optional in the Context Broker and mandatory in the IoTAgents.
• Servicepath is hierarchical in the Context Broker and treated as a plain string in the IoTAs.
• Wildcards behavior is not well defined in the IoTAgents (this has to do with the strange Provisioning API we are using, that should also be redesigned).

We should add this issue to the component backlog and evaluate its importance.

[dcalvoalonso]

Trying to fix unit tests in LWM2M IOTA, I have discovered an additional issue regarding the alignment of fiware-service and fiware-servicepath with Orion Context Broker.

From https://github.com/telefonicaid/fiware-orion/blob/master/doc/manuals/user/multitenancy.md:

Orion Context Broker interprets the tentant name in lowercase, thus, although you can use tenants such as in updateContext "MyService" it is not advisable, as the notifications related with that tenant will be sent with "myservice" and, in that sense, it is not coherent the tenant you used in updateContext compared with the one that Orion sends in notifyContextRequest.

Actually, the IOTA node library stores devices in its registry with service and subservice including uppercase characters.

• In line 652 of deviceService.js:

function findOrCreate(deviceId, group, callback) {
    getDevice(deviceId, group.service, group.subservice, function(error, device) {
        if (!error && device) {
            callback(null, device, group);
        } else if (error.name === 'DEVICE_NOT_FOUND') {
            var newDevice = {
                id: deviceId,
                service: group.service,
                subservice: group.subservice,
                type: group.type
            };

            if (config.getConfig().iotManager && config.getConfig().iotManager.protocol) {
                newDevice.protocol = config.getConfig().iotManager.protocol;
            }

            registerDevice(newDevice, function(error, device) {
                callback(error, device, group);
            });
        } else {
            callback(error);
        }
    });

• Nevertheless, if we consider an example with a lazy attribute which value is modified in the context broker, the IOTAgent will receive an updateContext request and the service will be completely lowercased. This example can be seen in line 102 of https://github.com/Fiware/iot.IoTagent-LWM2M/blob/master/test/unit/passive-attributes-test.js.

[fgalan]

In order to avoid the problem you mention @dcalvoalonso the recomendation is to use always service and servicepath in lowercase.

[dcalvoalonso]

Then I see two options regarding this point:

• To modify LWM2M IOTA tests to use servicepath in lowercase following this recommendation.
• To implement additional mechanisms in the IOTA library so that servicepath are converted to lowercase.

What do you think @fgalan ?

[fgalan]

You mean the test is failing right now? As far as I see at https://github.com/telefonicaid/iotagent-node-lib/commits/master Travis is ok at the present moment at master...

[dcalvoalonso]

Tests are not passed for LWM2M IOTA. I have run them locally and several (passive attributes and commands) fail due to this problem. As you can see in travis.yml, tests are not automatically executed yet.

[fgalan]

I think that modifying the library to convert to lowercase could have some degree of backward compatibility risk that needs to be carefully analyzed. Specially for existing integrations using IOTA UL or IOTA JSON.

Thus, I think that at the present moment just adjusting the test is enough. In addition, once you fix it I'd suggest to set Travis in automatic mode at LWM2M IOTA repo (in an independent PR). Could you manage with that, please?

[dcalvoalonso]

Ok, it makes sense to me. I am right now working on it! Thanks!!! :)

[dcalvoalonso]

I have just submitted a PR to enable Travis CI for LWM2M IOTA repo and to pass unit tests: https://github.com/telefonicaid/lightweightm2m-iotagent/pull/105

They are still not passed because of https://github.com/telefonicaid/iotagent-node-lib/issues/569

[hylowaker]

Hello. I'm new to Fiware. While following tutorials, I found that a queryContext to Orion with fiware-servicepath headers accepts wildcard ('#'). However, It seems that sending request to /iot/devices/ endpoint returns no result when servicepath has wildcard. Is it just an issue of IoTA-UL used in tutorials? Or is it still unresolved issue for all IoT Agents?

[fgalan]

@hylowaker I think your interpretation is correct. Orion supports # syntax in service paths but currently IOTAs doesn't. This issue is about aligning that but it is still pending.