Skip to content

[WIP] Task/remove memory registry #1472

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Draft
wants to merge 5 commits into
base: master
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion config.js
Original file line number Diff line number Diff line change
@@ -46,7 +46,7 @@ var config = {
password: 'iotagent'
},
deviceRegistry: {
type: 'memory'
type: 'mongodb'
},
types: {
Light: {
3 changes: 2 additions & 1 deletion doc/admin.md
Original file line number Diff line number Diff line change
@@ -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

3 changes: 2 additions & 1 deletion doc/api.md
Original file line number Diff line number Diff line change
@@ -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:

4 changes: 2 additions & 2 deletions doc/index.md
Original file line number Diff line number Diff line change
@@ -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

19 changes: 4 additions & 15 deletions lib/fiware-iotagent-lib.js
Original file line number Diff line number Diff line change
@@ -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(
35 changes: 20 additions & 15 deletions test/functional/README.md
Original file line number Diff line number Diff line change
@@ -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

2 changes: 2 additions & 0 deletions test/unit/examples/iotamRequests/registrationWithGroups.json
Original file line number Diff line number Diff line change
@@ -18,6 +18,8 @@
"type": "Boolean"
}
],
"static_attributes": [],
"internal_attributes": [],
"lazy": [
{
"name": "luminescence",
Original file line number Diff line number Diff line change
@@ -25,6 +25,8 @@
"values": "123,12"
}
],
"internal_attributes": [],
"lazy": [],
"commands": [
{
"name": "wheel1",
17 changes: 15 additions & 2 deletions test/unit/general/contextBrokerKeystoneSecurityAccess-test.js
Original file line number Diff line number Diff line change
@@ -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 () {
4 changes: 2 additions & 2 deletions test/unit/lazyAndCommands/commandRegistry_test.js
Original file line number Diff line number Diff line change
@@ -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');
Loading
Loading