Merge pull request #1592 from telefonicaid/task/allow_devices_same_de…

…vice_id_in_same_path_but_apikey

Task/allow devices same device id in same path but apikey

CHANGES_NEXT_RELEASE

@@ -0,0 +1 @@
+- Add: allow devices with the same device_id in the same service and subservice but different apikey (#1589)

doc/api.md

@@ -8,6 +8,7 @@
     -   [IoT Agent information model](#iot-agent-information-model)
         -   [Config groups](#config-groups)
         -   [Devices](#devices)
+        -   [Uniqueness of groups and devices](#uniqueness-of-groups-and-devices)
     -   [Special measures and attributes names](#special-measures-and-attributes-names)
     -   [Entity attributes](#entity-attributes)
     -   [Multientity support)](#multientity-support)
@@ -133,17 +134,17 @@ parameters. The specific parameters that can be configured for a given config gr
 ### Devices
 
 A device contains the information that connects a physical device to a particular entity in the Context Broker. Devices
-are identified by a `device_id`, and they are associated to an existing config group based in `apiKey` matching or
-`type` matching (in the case `apiKey` matching fails). For instance, let's consider a situation in which a config group
-has been provisioned with `type=X`/`apiKey=111` and no other config group has been provisioned.
+are identified by a `device_id`, and they are associated to an existing config group based in `apikey` matching. For
+instance, let's consider a situation in which a config group has been provisioned with `type=X`/`apikey=111` and no
+other config group has been provisioned.
 
 The IoT Agents offer a provisioning API where devices can be preregistered, so all the information about service and
 subservice mapping, security information and attribute configuration can be specified in a per device way instead of
 relaying on the config group configuration. The specific parameters that can be configured for a given device are
 described in the [Device datamodel](#device-datamodel) section.
 
 If devices are not pre-registered, they will be automatically created when a measure arrives to the IoT Agent - this
-process is known as autoprovisioning. The IoT Agent will create an empty device with the group `apiKey` and `type` - the
+process is known as autoprovisioning. The IoT Agent will create an empty device with the group `apikey` and `type` - the
 associated document created in database doesn't include config group parameters (in particular, `timestamp`,
 `explicitAttrs`, `active` or `attributes`, `static` and `lazy` attributes and commands). The IoT Agent will also create
 the entity in the Context Broker if it does not exist yet.
@@ -152,6 +153,13 @@ This behavior allows that autoprovisioned parameters can freely established modi
 creation using the provisioning API. However, note that if a device (autoprovisioned or not) doesn't have these
 parameters defined at device level in database, the parameters are inherit from config group parameters.
 
+### Uniqueness of groups and devices
+
+Group service uniqueness is defined by the combination of: service, subservice and apikey
+
+Device uniqueness is defined by the combination of: service, subservice, device_id and apikey. Note that several
+devices with the same device_id are allowed in the same service and subservice as long as their apikeys are different.
+
 ## Special measures and attributes names
 
 In case of arriving measures with name `id` or `type`, they are automatically transformed to `measure_id` and

lib/errors.js

@@ -107,7 +107,10 @@ class DuplicateDeviceId {
     constructor(device) {
         this.name = 'DUPLICATE_DEVICE_ID';
         this.message =
-            'A device with the same pair (Service, DeviceId) was found:' + device.id + ' and ' + JSON.stringify(device);
+            'A device with the same info (DeviceId, ApiKey, Service, Subservice) was found:' +
+            device.id +
+            ' and ' +
+            JSON.stringify(device);
         this.code = 409;
     }
 }

lib/services/devices/deviceRegistryMongoDB.js

@@ -243,14 +243,7 @@ function getDeviceById(id, apikey, service, subservice, callback) {
 function getDevice(id, apikey, service, subservice, callback) {
     getDeviceById(id, apikey, service, subservice, function (error, data) {
         if (error) {
-            // Try without apikey: apikey will be added to device later
-            getDeviceById(id, null, service, subservice, function (error, data) {
-                if (error) {
-                    callback(error);
-                } else {
-                    callback(null, data);
-                }
-            });
+            callback(error);
         } else {
             callback(null, data);
         }

lib/services/devices/deviceService.js

@@ -615,6 +615,7 @@ function findOrCreate(deviceId, apikey, group, callback) {
         } else if (error.name === 'DEVICE_NOT_FOUND') {
             const newDevice = {
                 id: deviceId,
+                apikey: apikey,
                 service: group.service,
                 subservice: group.subservice,
                 type: group.type