iotagent-node-lib 4.4.0 → 4.6.0

package/lib/templates/updateDeviceLax.json

@@ -89,29 +89,6 @@
             "description": "Optional entity type for multientity updatess",
             "type": "string",
             "pattern": "^([^<>;'=\"]+)+$"
-          },
-          "reverse": {
-            "description": "Define the attribute as bidirectional",
-            "type": "array",
-            "items": {
-              "type": "object",
-              "additionalProperties": false,
-              "properties": {
-                "object_id": {
-                  "description": "ID of the attribute in the device",
-                  "type": "string"
-                },
-                "type": {
-                  "description": "Type of the attribute in the target entity",
-                  "type": "string",
-                  "pattern": "^([^<>();'=\"]+)+$"
-                },
-                "expression": {
-                  "description": "Optional expression for measurement transformation",
-                  "type": "string"
-                }
-              }
-            }
           }
         }
       }

package/package.json

@@ -2,7 +2,7 @@
   "name": "iotagent-node-lib",
   "license": "AGPL-3.0-only",
   "description": "IoT Agent library to interface with NGSI Context Broker",
-  "version": "4.4.0",
+  "version": "4.6.0",
   "homepage": "https://github.com/telefonicaid/iotagent-node-lib",
   "keywords": [
     "fiware",
@@ -44,7 +44,7 @@
   },
   "dependencies": {
     "async": "2.6.4",
-    "body-parser": "~1.20.0",
+    "body-parser": "~1.20.3",
     "express": "~4.19.2",
     "got": "~11.8.5",
     "jexl": "2.3.0",

package/scripts/legacy_expression_tool/README.md

@@ -249,7 +249,6 @@ The script implements expression detection and translation in the following fiel
 
 -   active.expression
 -   active.entity_name
--   active.reverse
 -   attributes.expression
 -   attributes.entity_name
 -   attributes.expression

package/test/functional/README.md

@@ -21,8 +21,10 @@ 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)
@@ -30,17 +32,19 @@ test cases are automatically generated. Each test case is defined as an object w
     -   `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` 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)
@@ -64,10 +68,10 @@ test cases are automatically generated. Each test case is defined as an object w
 {
     describeName: 'Basic group provision with attributes',
     provision: {
-        url: 'http://localhost:' + config.iota.server.port + '/iot/services',
+        url: 'http://localhost:' + config.iota.server.port + '/iot/groups',
         method: 'POST',
         json: {
-            services: [
+            groups: [
                 {
                     resource: '/iot/json',
                     apikey: '123456',
@@ -199,41 +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 define the test case
-`expectation` as an array, with one object for each measurement. Then, the suite will recognize the array length and will
-expect the same number of NGSI requests. I.E:
+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'`.
 
-```js
-[
-    {
-        id: 'TheLightType2:MQTT_2',
-        type: 'TheLightType2',
-        temperature: {
-            value: 10,
-            type: 'Number'
-        },
-        status: {
-            value: false,
-            type: 'Boolean'
-        }
-    },
-    {
-        id: 'TheLightType2:MQTT_2',
-        type: 'TheLightType2',
-        temperature: {
-            value: 20,
-            type: 'Number'
-        },
-        status: {
-            value: true,
-            type: 'Boolean'
-        }
-    }
-];
-```
-
-You also should define the measure as multimeasure. This is done by defining the `measure` JSON element as an array of
-objects. Each object will be a measure that will be sent to the Context Broker in a different request. 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: {
@@ -246,16 +220,69 @@ measure: {
     json: [
         {
             s: false,
-            t: 10
+            t: 21
         },
         {
             s: true,
-            t: 20
+            t: 22
+        },
+        {
+            s: false,
+            t: 23
+        }
+    ]
+}
+```
+
+And you should define the test case `expectation` as an object, following a Context Broker batch operation. I.E:
+
+```js
+expectation: {
+    actionType: 'append',
+    entities: [
+        {
+            id: 'TheLightType2:MQTT_2',
+            type: 'TheLightType2',
+            temperature: {
+                type: 'Number',
+                value: 21
+            },
+            status: {
+                type: 'Boolean',
+                value: false
+            }
+        },
+        {
+            id: 'TheLightType2:MQTT_2',
+            type: 'TheLightType2',
+            temperature: {
+                type: 'Number',
+                value: 22
+            },
+            status: {
+                type: 'Boolean',
+                value: true
+            }
+        },
+        {
+            id: 'TheLightType2:MQTT_2',
+            type: 'TheLightType2',
+            temperature: {
+                type: 'Number',
+                value: 23
+            },
+            status: {
+                type: 'Boolean',
+                value: false
+            }
         }
     ]
 }
 ```
 
+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
 
 The test suite supports using the internal node lib function `iotAgentLib.update`, `HTTP` or `MQTT` for measure sending.
@@ -309,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
 

package/test/functional/functional-tests-runner.js

@@ -63,12 +63,17 @@ describe('FUNCTIONAL TESTS AUTO', function () {
                 if (testCase.loglevel) {
                     logger.setLevel(testCase.loglevel);
                 }
-                let type = testUtils.groupToIoTAConfigType(
+                let confType = testUtils.groupToIoTAConfigType(
                     testCase.provision.json.services[0],
-                    testCase.provision.headers.fiwareService,
-                    testCase.provision.headers.fiwareServicepath
+                    testCase.provision.headers['fiware-service'],
+                    testCase.provision.headers['fiware-servicepath']
                 );
-                config.iota.types[type.name] = type.type;
+                // Inject device id into config as real typeInformation
+                if (testCase.should[0] && testCase.should[0].measure.qs.i) {
+                    confType.type['id'] = testCase.should[0].measure.qs.i;
+                }
+                config.iota.types[confType.name] = confType.type;
+
                 iotAgentLib.activate(config.iota, function (error) {
                     done(error);
                 });

package/test/functional/functional-tests.js

@@ -115,8 +115,8 @@ describe('FUNCTIONAL TESTS', function () {
         beforeEach(function (done) {
             let type = testUtils.groupToIoTAConfigType(
                 provision.json.services[0],
-                provision.headers.fiwareService,
-                provision.headers.fiwareServicepath
+                provision.headers['fiware-service'],
+                provision.headers['fiware-servicepath']
             );
             config.iota.types[type.name] = type.type;
             iotAgentLib.activate(config.iota, function (error) {
@@ -214,8 +214,8 @@ describe('FUNCTIONAL TESTS', function () {
         beforeEach(function (done) {
             let type = testUtils.groupToIoTAConfigType(
                 provision.json.services[0],
-                provision.headers.fiwareService,
-                provision.headers.fiwareServicepath
+                provision.headers['fiware-service'],
+                provision.headers['fiware-servicepath']
             );
             config.iota.types[type.name] = type.type;
             iotAgentLib.activate(config.iota, function (error) {