[WIP] Task/remove memory registry

config.js

@@ -46,7 +46,7 @@ var config = {
         password: 'iotagent'
     },
     deviceRegistry: {
-        type: 'memory'
+        type: 'mongodb'
     },
     types: {
         Light: {

doc/admin.md

@@ -427,7 +427,8 @@ IotAgents, as all Express applications that use the body-parser middleware, have
 size that the application will handle. This default limit for ioiotagnets are 1Mb. So, if your IotAgent receives a
 request with a body that exceeds this limit, the application will throw a “Error: Request entity too large”.
 
-The 1Mb default can be changed setting the `expressLimit` configuration parameter (or equivalente `IOTA_EXPRESS_LIMIT` environment variable).
+The 1Mb default can be changed setting the `expressLimit` configuration parameter (or equivalente `IOTA_EXPRESS_LIMIT`
+environment variable).
 
 ### Configuration using environment variables
 

doc/api.md

@@ -466,7 +466,8 @@ mappings of the provision. If `explicitAttrs` is provided both at device and con
 precedence. Additionally `explicitAttrs` can be used to define which measures (identified by their attribute names, not
 by their object_id) defined in JSON/JEXL array will be propagated to NGSI interface.
 
-Note that when `explicitAttrs` is an array or a JEXL expression resulting in to Array, if this array is empty then `TimeInstant` is not propaged to CB.
+Note that when `explicitAttrs` is an array or a JEXL expression resulting in to Array, if this array is empty then
+`TimeInstant` is not propaged to CB.
 
 The different possibilities are summarized below:
 

doc/index.md

@@ -11,8 +11,8 @@ Broker using their own native protocols. IoT Agents should also be able to deal
 platform (authentication and authorization of the channel) and provide other common services to the device programmer.
 
 Github's [README.md](https://github.com/telefonicaid/iotagent-node-lib/blob/master/README.md) provides a good
-documentation summary. The [API reference](api.md) and the [Development documentation](devel/development.md) cover
-more advanced topics.
+documentation summary. The [API reference](api.md) and the [Development documentation](devel/development.md) cover more
+advanced topics.
 
 ## Background
 

lib/fiware-iotagent-lib.js

@@ -81,9 +81,6 @@ function globalErrorHandler(err) {
  * @param {Function} callback           The callback function.
  */
 function doActivate(newConfig, callback) {
-    let registry;
-    let groupRegistry;
-    let commandRegistry;
     let securityService;
 
     logger.format = logger.formatters.pipe;
@@ -141,19 +138,11 @@ function doActivate(newConfig, callback) {
         }
     }
 
-    if (newConfig.deviceRegistry && newConfig.deviceRegistry.type && newConfig.deviceRegistry.type === 'mongodb') {
-        logger.info(context, 'MongoDB Device registry selected for NGSI Library');
+    logger.info(context, 'MongoDB Device registry selected for NGSI Library');
 
-        registry = require('./services/devices/deviceRegistryMongoDB');
-        groupRegistry = require('./services/groups/groupRegistryMongoDB');
-        commandRegistry = require('./services/commands/commandRegistryMongoDB');
-    } else {
-        logger.info(context, 'Falling back to Transient Memory registry for NGSI Library');
-
-        registry = require('./services/devices/deviceRegistryMemory');
-        groupRegistry = require('./services/groups/groupRegistryMemory');
-        commandRegistry = require('./services/commands/commandRegistryMemory');
-    }
+    const registry = require('./services/devices/deviceRegistryMongoDB');
+    const groupRegistry = require('./services/groups/groupRegistryMongoDB');
+    const commandRegistry = require('./services/commands/commandRegistryMongoDB');
 
     exports.clearAll = function (callback) {
         async.series(

test/functional/README.md

@@ -21,26 +21,30 @@ pattern than the one supported by the test runner).
 Each test case is defined as a JSON object in the `testCases.js` file. This file is loaded by the test suite and the
 test cases are automatically generated. Each test case is defined as an object with the following elements:
 
--   `describeName`: The name of the `DESCRIBE` test case. This will be used to generate the test case name in the mocha. Note this name is prefixed by a pure number (e.g `0010 - Simple group without attributes`) which specifies the group to which the test belong (usually meaning a feature) or by a number preced by the `#` symbol to refer to an issue number (e.g. `#1234 - Bug foobar`).
-    test suite.
+-   `describeName`: The name of the `DESCRIBE` test case. This will be used to generate the test case name in the mocha.
+    Note this name is prefixed by a pure number (e.g `0010 - Simple group without attributes`) which specifies the group
+    to which the test belong (usually meaning a feature) or by a number preced by the `#` symbol to refer to an issue
+    number (e.g. `#1234 - Bug foobar`). test suite.
 -   `provision`: The JSON object that will be sent to the IoTA JSON provisioning API. This will be used to create the
     group. It contains the following elements:
     -   `url`: The URL of the provisioning API (group)
     -   `method`: The HTTP method to use (POST)
     -   `json`: The JSON object that defines the group
     -   `headers`: The headers to send to the provisioning API. This should contain the `fiware-service` and
         `fiware-servicepath` headers.
-    -   `skip`: optional. Allow to skip test cases (at `describe` level). It allows diferent values: `false` (default, meaning that the test is not skipped in any circustance),
-        `true` (meaning the test is always skipped), `"lib"` (meaning the test has to be skipped when running it in IoTA Node lib repo) and
-        `"json"` (meaning the test has to be skipped when running it in IOTA JSON repo). The latter alternatives are useful to skip test cases that are not supported by
-        the lib (I.E: all tests related to the transport) or by the IOTA. Combinations (e.g `"lib,json"`) and negation (e.g. `"!lib"`) are also supported.
+    -   `skip`: optional. Allow to skip test cases (at `describe` level). It allows diferent values: `false` (default,
+        meaning that the test is not skipped in any circustance), `true` (meaning the test is always skipped), `"lib"`
+        (meaning the test has to be skipped when running it in IoTA Node lib repo) and `"json"` (meaning the test has to
+        be skipped when running it in IOTA JSON repo). The latter alternatives are useful to skip test cases that are
+        not supported by the lib (I.E: all tests related to the transport) or by the IOTA. Combinations (e.g
+        `"lib,json"`) and negation (e.g. `"!lib"`) are also supported.
 -   `should`: The array of test cases to execute. Each test case is defined as an object with the following elements:
     -   `transport`: The transport to use to send the measure. This can be `HTTP` or `MQTT`. It uses `HTTP` by default
         or if the `transport` element is not defined. See the "Advanced features" section for more information.
     -   `shouldName`: The name of the `IT` test case. This will be used to generate the test case name in the mocha test
         suite.
-    -   `type`: The type of the test case. This can be `single`, `multimeasure` or `multientity`. See the "Advanced features" section
-        for more information.
+    -   `type`: The type of the test case. This can be `single`, `multimeasure` or `multientity`. See the "Advanced
+        features" section for more information.
     -   `measure`: The JSON object that will be sent to the IoTA JSON measure API. This will be used to send the
         measure. It contains the following elements:
         -   `url`: The URL of the measure API (group)
@@ -199,11 +203,11 @@ as a batch operation (see the following example).
 
 #### Multimeasures
 
-It is also supported to test cases in which is sent more than one measure. To do so, you need to set add to the test case 
-the parameter `should.type` to the value `'multimeasure'`.
+It is also supported to test cases in which is sent more than one measure. To do so, you need to set add to the test
+case the parameter `should.type` to the value `'multimeasure'`.
 
-You must define the measure as multimeasure. This is done by defining the `measure` JSON element as an array of
-objects. I.E:
+You must define the measure as multimeasure. This is done by defining the `measure` JSON element as an array of objects.
+I.E:
 
 ```javascript
 measure: {
@@ -276,8 +280,8 @@ expectation: {
 }
 ```
 
-Then, a batch request would be sent to the Context Broker containing the different measures. More information about
-how the IoT Agent send multimeasures to the Context Broker [here](/doc/api.md#multimeasure-support).
+Then, a batch request would be sent to the Context Broker containing the different measures. More information about how
+the IoT Agent send multimeasures to the Context Broker [here](/doc/api.md#multimeasure-support).
 
 #### Transport
 
@@ -332,7 +336,8 @@ the expectation as an empty object. I.E:
     ...
 ```
 
-Note that this means the CB *must not* receive any payload. In other words, if the CB would receive any payload, the test will fail.
+Note that this means the CB _must not_ receive any payload. In other words, if the CB would receive any payload, the
+test will fail.
 
 ### Debugging automated tests
 

test/unit/examples/iotamRequests/registrationWithGroups.json

@@ -18,6 +18,8 @@
           "type": "Boolean"
         }
       ],
+      "static_attributes": [],
+      "internal_attributes": [],
       "lazy": [
         {
           "name": "luminescence",

test/unit/examples/iotamRequests/registrationWithStaticGroups.json

@@ -25,6 +25,8 @@
           "values": "123,12"
         }
       ],
+      "internal_attributes": [],
+      "lazy": [],
       "commands": [
         {
             "name": "wheel1",

test/unit/general/contextBrokerKeystoneSecurityAccess-test.js

@@ -29,6 +29,7 @@ const request = utils.request;
 const should = require('should');
 const logger = require('logops');
 const nock = require('nock');
+const mongoUtils = require('../mongodb/mongoDBUtils');
 let contextBrokerMock;
 let keystoneMock;
 const iotAgentConfig = {
@@ -82,6 +83,14 @@ const iotAgentConfig = {
             active: []
         }
     },
+    deviceRegistry: {
+        type: 'mongodb'
+    },
+    mongodb: {
+        host: 'localhost',
+        port: '27017',
+        db: 'iotagent'
+    },
     service: 'smartgondor',
     subservice: 'gardens',
     providerUrl: 'http://smartgondor.com',
@@ -107,8 +116,12 @@ describe('NGSI-v2 - Secured access to the Context Broker with Keystone', functio
     });
 
     afterEach(function (done) {
-        iotAgentLib.deactivate(done);
-        nock.cleanAll();
+        iotAgentLib.deactivate(function () {
+            mongoUtils.cleanDbs(function () {
+                nock.cleanAll();
+                done();
+            });
+        });
     });
 
     describe('When a measure is sent to the Context Broker via an Update Context operation', function () {

test/unit/lazyAndCommands/commandRegistry_test.js

@@ -40,7 +40,7 @@ const iotAgentConfig = {
     },
     types: {},
     deviceRegistry: {
-        type: 'memory'
+        type: 'mongodb'
     },
     mongodb: {
         host: 'localhost',
@@ -227,5 +227,5 @@ function testRegistry(registryType) {
     });
 }
 
-testRegistry('memory');
+//testRegistry('memory');
 testRegistry('mongodb');