[Do not merge] New config groups API endpoint

CHANGES_NEXT_RELEASE

@@ -3,4 +3,5 @@
 - Fix: service header to use uppercase in case of update and delete (#1528)
 - Fix: Allow to send to CB batch update for multimeasures for NGSI-LD (#1623)
 - Add: new JEXL transformations for including into an array keys that have a certain value: valuePicker and valuePickerMulti
+- Add /iot/configGroups API endpoints (as equivalent to /iot/services) (#752)
 - Add: attribute metadata and static attributes metadata added to jexl context (#1630)

doc/admin.md

@@ -125,9 +125,9 @@ allowing the computer to interpret the rest of the data with more clarity and de
 ```
 
 Under mixed mode, **NGSI v2** payloads are used for context broker communications by default, but this payload may also
-be switched to **NGSI LD** at group or device provisioning time using the `ngsiVersion` field in the
-provisioning API. The `ngsiVersion` field switch may be added at either group or device level, with the device level
-overriding the group setting.
+be switched to **NGSI LD** at group or device provisioning time using the `ngsiVersion` field in the provisioning API.
+The `ngsiVersion` field switch may be added at either group or device level, with the device level overriding the group
+setting.
 
 #### `server`
 
@@ -306,7 +306,8 @@ added `agentPath`:
 
 #### `types`
 
-This parameter includes additional groups configuration as described into the [Config group API](api.md#config-group-api) section.
+This parameter includes additional groups configuration as described into the
+[Config group API](api.md#config-group-api) section.
 
 #### `service`
 
@@ -415,7 +416,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

@@ -136,9 +136,9 @@ For every config group, the pair (resource, apikey) _must_ be unique (as it is u
 which device). Those operations of the API targeting specific resources will need the use of the `resource` and `apikey`
 parameters to select the appropriate instance.
 
-Config groups can be created with preconfigured sets of attributes, service and subservice information, security information and other
-parameters. The specific parameters that can be configured for a given config group are described in the
-[Config group datamodel](#config-group-datamodel) section.
+Config groups can be created with preconfigured sets of attributes, service and subservice information, security
+information and other parameters. The specific parameters that can be configured for a given config group are described
+in the [Config group datamodel](#config-group-datamodel) section.
 
 ### Devices
 
@@ -218,7 +218,7 @@ device preprovisioning). Device measures can have four different behaviors:
     an attribute in the device's entity, for which the IoT Agent will be regitered as Context Provider. The IoT Agent
     will return an immediate response to the Context Broker, and will be held responsible of contacting the device to
     perform the command itself using the device specific protocol. Special `status` and `info` attributes should be
-    update. For each command, its `name` and `type` must be provided. For further information, please refer to 
+    update. For each command, its `name` and `type` must be provided. For further information, please refer to
     [Command execution](#command-execution) section.
 
 All of them have the same syntax, a list of objects with the following attributes:
@@ -565,17 +565,18 @@ expression. In all cases the following data is available to all expressions:
 -   `id`: device ID
 -   `entity_name`: NGSI entity Name (principal)
 -   `type`: NGSI entity type (principal)
--   `service`: device service (`Fiware-Service`) 
+-   `service`: device service (`Fiware-Service`)
 -   `subservice`: device subservice (`Fiware-ServicePath`)
 -   `staticAttributes`: static attributes defined in the device or config group
 
 Additionally, for attribute expressions (`expression`, `entity_name`), `entityNameExp` and metadata expressions
 (`expression`) the following is available in the **context** used to evalute:
 
-- measures, as `<AttributeName>`
-- metadata (both for attribute measurement in the case of NGSI-v2 measurements and static attribute) are available in the **context** under the following convention:
-`metadata.<AttributeName>.<MetadataName>` or `metadata.<StaticAttributeName>.<MetadataName>` in a similar way of defined
-for [Context Broker](https://github.com/telefonicaid/fiware-orion/blob/master/doc/manuals/orion-api.md#metadata-support)
+-   measures, as `<AttributeName>`
+-   metadata (both for attribute measurement in the case of NGSI-v2 measurements and static attribute) are available in
+    the **context** under the following convention: `metadata.<AttributeName>.<MetadataName>` or
+    `metadata.<StaticAttributeName>.<MetadataName>` in a similar way of defined for
+    [Context Broker](https://github.com/telefonicaid/fiware-orion/blob/master/doc/manuals/orion-api.md#metadata-support)
 
 ### Examples of JEXL expressions
 
@@ -736,7 +737,8 @@ e.g.:
 }
 ```
 
-Note that there is no order into metadata structure and there is no warranty about which metadata attribute expression will be evaluated first.
+Note that there is no order into metadata structure and there is no warranty about which metadata attribute expression
+will be evaluated first.
 
 ## Measurement transformation
 
@@ -1070,21 +1072,21 @@ As part of the device to entity mapping process, the IoT Agent creates and updat
 attribute called `TimeInstant`. This timestamp is represented as two different properties of the mapped entity:
 
 -   An attribute `TimeInstant` is added to updated entities in the case of NGSI-v2, which captures as an ISO8601
-    timestamp when the associated measurement was observed. With NGSI-LD, the Standard
-    `observedAt` property is used instead
+    timestamp when the associated measurement was observed. With NGSI-LD, the Standard `observedAt` property is used
+    instead
 
--   With NGSI-v2, an attribute metadata named `TimeInstant` per active or lazy attribute mapped, which captures as an ISO8601
-    timestamp when the associated measurement (represented as attribute value) was observed. With NGSI-LD, the Standard
-    `observedAt` property-of-a-property is used instead.
+-   With NGSI-v2, an attribute metadata named `TimeInstant` per active or lazy attribute mapped, which captures as an
+    ISO8601 timestamp when the associated measurement (represented as attribute value) was observed. With NGSI-LD, the
+    Standard `observedAt` property-of-a-property is used instead.
 
 If timestamp is not explicily defined when sending the measures through the IoT Agent (for further details on how to
 attach timestamp information to the measures, please refer to the particular IoT Agent implementation documentation),
 the arrival time on the server when receiving the measurement will be used to generate a `TimeInstant` for both the
 entity attribute and the attribute metadata.
 
-This functionality can be turned on and off globaly through the use of the `timestamp` configuration flag or `IOTA_TIMESTAMP`
-variable as well as `timestamp` flag in device or group provision (in this case, the device or group level flag takes
-precedence over the global one). The default value is `true`.
+This functionality can be turned on and off globaly through the use of the `timestamp` configuration flag or
+`IOTA_TIMESTAMP` variable as well as `timestamp` flag in device or group provision (in this case, the device or group
+level flag takes precedence over the global one). The default value is `true`.
 
 The `timestamp` configuration value used, according to the priority:
 
@@ -1104,6 +1106,7 @@ the IoTA behaviour is described in the following table:
 | false                  | No                             | TimeInstant and metadata updated with server timestamp |
 | Not defined            | Yes                            | TimeInstant and metadata updated with measure value    |
 | Not defined            | No                             | TimeInstant and metadata updated with server timestamp |
+
 Some additional considerations to take into account:
 
 -   If there is an attribute which maps a measure to `TimeInstant` attribute (after
@@ -1724,7 +1727,7 @@ Config group is represented by a JSON object with the following fields:
 
 The following actions are available under the config group endpoint:
 
-#### Retrieve config groups `GET /iot/services`
+#### Retrieve config groups GET `/iot/configGroups` or `GET /iot/services`
 
 List all the config groups for the given `fiware-service` and `fiware-servicepath`. The config groups that match the
 `fiware-servicepath` are returned in any other case.
@@ -1748,14 +1751,14 @@ Successful operations return `Content-Type` header with `application/json` value
 
 _**Response payload**_
 
-A JSON object with a services field that contains an array of services that match the request. See the
+A JSON object with a configGroups or services field that contains an array of services that match the request. See the
 [config group datamodel](#service-group-datamodel) for more information.
 
 Example:
 
 ```json
 {
-    "services": [
+    "configGroups": [
         {
             "resource": "/deviceTest",
             "apikey": "801230BJKL23Y9090DSFL123HJK09H324HV8732",
@@ -1792,7 +1795,7 @@ Example:
 }
 ```
 
-#### Create config group `POST /iot/services`
+#### Create config group `POST /iot/configGroups` or `POST /iot/services`
 
 Creates a set of config groups for the given service and service path. The service and subservice information will taken
 from the headers, overwritting any preexisting values.
@@ -1806,14 +1809,14 @@ _**Request headers**_
 
 _**Request payload**_
 
-A JSON object with a `services` field. The value is an array of config groups objects to create. See the
-[config group datamodel](#service-group-datamodel) for more information.
+A JSON object with a `configGroups` or `services` field. The value is an array of config groups objects to create. See
+the [config group datamodel](#service-group-datamodel) for more information.
 
 Example:
 
 ```json
 {
-    "services": [
+    "configGroups": [
         {
             "resource": "/deviceTest",
             "apikey": "801230BJKL23Y9090DSFL123HJK09H324HV8732",
@@ -1847,11 +1850,11 @@ _**Response headers**_
 
 Successful operations return `Content-Type` header with `application/json` value.
 
-#### Modify config group `PUT /iot/services`
+#### Modify config group `PUT /iot/configGroups` or `PUT /iot/services`
 
-Modifies the information of a config group, identified by the `resource` and `apikey` query parameters. Takes a service
-group body as the payload. The body does not have to be complete: for incomplete bodies, just the attributes included in
-the JSON body will be updated. The rest of the attributes will remain unchanged.
+Modifies the information of a config group, identified by the `resource` and `apikey` query parameters. Takes a
+configuration/service group body as the payload. The body does not have to be complete: for incomplete bodies, just the
+attributes included in the JSON body will be updated. The rest of the attributes will remain unchanged.
 
 _**Request query parameters**_
 
@@ -1887,7 +1890,7 @@ _**Response code**_
 -   400 MISSING_HEADERS if any of the mandatory headers is not present.
 -   500 SERVER ERROR if there was any error not contemplated above.:
 
-#### Remove config group `DELETE /iot/services`
+#### Remove config group `DELETE /iot/configGroups` or `DELETE /iot/services`
 
 Removes a config group, identified by the `resource` and `apikey` query parameters.
 

doc/devel/development.md

@@ -1831,9 +1831,9 @@ iotAgentLib.startServer(config, iotAgent, function (error) {
 
 ### Configuration management
 
-For some IoT Agents, it will be useful to know what devices or config groups were registered in the Agent, or to do
-some actions whenever a new device is registered. All this configuration and provisioning actions can be performed using
-two mechanisms: the provisioning handlers and the provisioning API.
+For some IoT Agents, it will be useful to know what devices or config groups were registered in the Agent, or to do some
+actions whenever a new device is registered. All this configuration and provisioning actions can be performed using two
+mechanisms: the provisioning handlers and the provisioning API.
 
 #### Provisioning handlers
 

doc/getting-started.md

@@ -10,22 +10,22 @@ custom settings may also be required dependent upon the actual IoT Agent used.
 
 ```javascript
 config = {
-    logLevel: "DEBUG",
+    logLevel: 'DEBUG',
     contextBroker: {
-        host: "orion",
-        port: "1026",
+        host: 'orion',
+        port: '1026'
     },
     server: {
         port: 4041,
-        host: "0.0.0.0",
+        host: '0.0.0.0'
     },
     deviceRegistry: {
-        type: "memory",
+        type: 'memory'
     },
-    service: "openiot",
-    subservice: "/",
-    providerUrl: "http://iot-agent:4041",
-    defaultType: "Thing",
+    service: 'openiot',
+    subservice: '/',
+    providerUrl: 'http://iot-agent:4041',
+    defaultType: 'Thing'
 };
 ```
 
@@ -43,8 +43,8 @@ All configuration settings can also updated using Docker environment variables.
 ### Provisioning a Config Group
 
 Settings which are common to a group of devices can be passed to the IoT Agent using the Config Group API. The
-`fiware-service` and `fiware-service-path` to be used to access the API are defined within the `config.js`. Each config group
-may override values previously defined in the global configuration if necessary.
+`fiware-service` and `fiware-service-path` to be used to access the API are defined within the `config.js`. Each config
+group may override values previously defined in the global configuration if necessary.
 
 ```bash
 curl -iX POST \
@@ -138,8 +138,8 @@ curl -iX POST \
 ```
 
 The IoT Agent South port is listen to the path defined in the config group, and the API key is recognized to match, so
-the config group configuration will be used. No mappings will be made for the Entity `id` or the attribute names and
-the following entity will be created:
+the config group configuration will be used. No mappings will be made for the Entity `id` or the attribute names and the
+following entity will be created:
 
 ```json
 {