send ngsiv2 measure as ngsiv2 request

[AlvaroVega]

Needs telefonicaid/iotagent-node-lib#1520

This PR enables a new endpoint '/iot/ngsiv2' to send a ngsiv2 format
Not sure if it should be a new endpoint or just a new query param flag to existing endpoint. Ideas?

[AlvaroVega]

With this approach ngsiv2 payload as:

curl -i -X POST 'http://localhost:7897/iot/ngsiv2?i=disp5&k=izc9cokegoy7kyfgdd6etipt6' -d '[{
      "id": "disp6:thing2",
      "type": "thing2",
      "temperature": {
         "type":"Number",
         "value":33
      }
   }]' -H 'content-type: application/json'

is progressing to CB as:

msg=Options: {
    "url": "http://iot-orion:1026/v2/op/update",
    "method": "POST",
    "headers": {
        "fiware-service": "smartcity",
        "fiware-servicepath": "/"
    },
    "json": {
        "actionType": "append",
        "entities": [
            {
                "id": "disp6:thing2",
                "type": "thing2",
                "temperature": {
                    "type": "Number",
                    "value": 33
                }
            }
        ]
    }
} | comp=IoTAgent

Measure needs provide a valid apikey and deviceId in order to get service and subservice. But deviceId is not really necessary.

[AlvaroVega]

@fgalan in this feature, which should be a NGSIv2 measure? There are two options.

• Option 1:

{
   "actionType": "append",
   "entities":[ {
      "id": "entity1",
      "type": "type1",
      "temperature": {
         "type":"Number",
         "value":33
      }
    },{
      "id": "entity2",
      "type": "type2",
      "temperature": {
         "type":"Number",
         "value":44
      }
   }]
}

• Option 2:

{
 [ {
      "id": "entity1",
      "type": "type1",
      "temperature": {
         "type":"Number",
         "value":33
      }
   },
   {
      "id": "entity2",
      "type": "type2",
      "temperature": {
         "type":"Number",
         "value":44
      }
   }]
}

[fgalan]

Is you mean the payload for a POST /v2/op/update request, then Option 1 is the right one. Ref: https://github.com/telefonicaid/fiware-orion/blob/master/doc/manuals/orion-api.md#update-post-v2opupdate

[AlvaroVega]

Is you mean the payload for a POST /v2/op/update request, then Option 1 is the right one. Ref: https://github.com/telefonicaid/fiware-orion/blob/master/doc/manuals/orion-api.md#update-post-v2opupdate

Not really for POST /v2/op/update , just what should be the way of represent several ngsiv2 entities which are going to be sent as measures.

[fgalan]

Is you mean the payload for a POST /v2/op/update request, then Option 1 is the right one. Ref: https://github.com/telefonicaid/fiware-orion/blob/master/doc/manuals/orion-api.md#update-post-v2opupdate

Not really for POST /v2/op/update , just what should be the way of represent several ngsiv2 entities which are going to be sent as measures.

Discussed at Teams

Option 2 is the suitable one.

[AlvaroVega]

TBD: do not use iotaUtils.retrieveDevice in new flow to avoid a fake device creation

[fgalan]

No issue number?

[fgalan]

I understand this PR enables a new format to receive measures in the southbound interface. That new format should be documented. Maybe @mapedraza could help with this.

[mapedraza]

@fgalan Ok! I will push a commit with the new doc.

Just a couple of questions regarding this feature:

• There is type verification? I mean, when receiving payloads with entity type different from the one defined in the device provision, it is persisted?
• All parameters (I.E entity ID, type etc) are part of the JEXL context?
• It is compatible with entity name expressions?
• There is any device provision?

Additionaly, it could be interesting:

• Adding a regex expression or JEXL sentence to verify if the entity ID and type to let progress the request only if match

[AlvaroVega]

@fgalan Ok! I will push a commit with the new doc.

Just a couple of questions regarding this feature:

• There is type verification? I mean, when receiving payloads with entity type different from the one defined in the device provision, it is persisted?
• All parameters (I.E entity ID, type etc) are part of the JEXL context?
• It is compatible with entity name expressions?
• There is any device provision?

Additionaly, it could be interesting:

• Adding a regex expression or JEXL sentence to verify if the entity ID and type to let progress the request only if match

I understand the ngsiv2 received is not checked by iotagent, just sent to ContextBroker.

[fgalan]

I understand the ngsiv2 received is not checked by iotagent, just sent to ContextBroker.

I understand the same. IOTA is mostly a pass-through here. In the case of error response from ContextBroker, it should be logged at WARN or ERROR level but no actual checking at IOTA should be done.