Suscripciones Custom for New Type/New Id

[fgalan]

Implement flexibility in custom notifications, so the id and type of the notified entity can be changed.

To be detailed.

[fgalan]

Draft:

    "httpCustom": {
      "url": "http://127.0.0.1:9999/notify",
      "mapping": {
        "id": "newId",
        "type": "newType"
      }

which could be an interesting extension point if we need in the future more similar mappings.

The new id and type will be used in both:

• Standard NGSIv2 notification payload (payload and json are not in use)
• ${id} and ${type} replacing macros (if payload or json are in use) (see later comment about this)

[fgalan]

What about using macros in the mapping itsef? Eg. to provide a prefix to id:

    "httpCustom": {
      "url": "http://127.0.0.1:9999/notify",
      "mapping": {
        "id": "PREFIX${id}"
      }

[mrutid]

I would add all the "first level" information elements, that is: id, type, service, subservice, auth-token (sometimes you don't want to propagate it).

• service, subservice, auth-token may be manipulated throught http headers but thats an implementation caveat in my opinion.

[mrutid]

Maybe we should have access to the old id/type/S/SS also in the template... You may want a new id but the old id to be part of some attribute composition.
An off topic example may be found in Cygnus NameMappings we use "the NEW" to build the destination, and "the OLD" to populate table values.

NOTE: maybe we just need to hace access to the old ones in the macro language, the new ones always can be built or derivated.

[fgalan]

Somehow related, new macros for service and servicePath are mentioned in #3913

[fgalan]

With regards to:

I would add all the "first level" information elements, that is: id, type, service, subservice, auth-token (sometimes you don't want to propagate it).

• service, subservice, auth-token may be manipulated throught http headers but thats an implementation caveat in my opinion.

This would be a complete mapping including them all:

    "httpCustom": {
      "url": "http://127.0.0.1:9999/notify",
      "mapping": {
        "id": "newId",
        "type": "newType",
        "service": "SS",
        "servicePath": "/newSP",
        "authToken": "..."
      }

Notes:

• For service, servicePath and authToken, in the case of using "" then the corresponding header will not appear
• In the case of having some of them within headers the one in headers takes precedence (as it is more "low-level").
• ${service}, ${servicePath}, {$authToken} macros to be used in payload or json are not currently working, they will be implemented as part of a separate issue.

[fgalan]

NOTE: maybe we just need to hace access to the old ones in the macro language, the new ones always can be built or derivated.

By default, ${id}, ${type}, ${service}, ${servicePaht}, ${authToken} will refer to the old values. Thus, the ones defined in mapping will be used:

• id -> in NGSIv2 payloads with payload and json are not in use
• type -> in NGSIv2 payloads with payload and json are not in use
• service -> in fiware-service header (except if override by headers)
• servicePath -> in fiware-servicepath header (except if override by headers)
• authToken -> in x-auth-token header (except if override by headers)

It seem easy to have also them in a new set of macros, i.e. ${mapping.id}, ${mapping.type}, ${mapping.service}, ${mapping.servicePaht}, ${mapping.authToken}

Example: Considering an entity with id = E1 and type T1 which triggesrs a custom notification like this:

"httpCustom": {
  "url": "http://127.0.0.1:9999/notify",
  "mapping": {
    "id": "new${id}",
    "type": "newType",
    "service": "SS",
    "servicePath": "/newSP",
    "authToken": "..."
  },
  "payload": "this is my old ${id} and this is my new id ${mapping.id}"

Payload resolves to "this is my old E1 and my id newE1"

[fgalan]

• ${service}, ${servicePath}, {$authToken} macros to be used in payload or json are not currently working, they will be implemented as part of a separate issue.

Issue #4159

[fgalan]

With the re-definition of the functionality in the last comments, maybe "mapping" is not a proper name (it was good when they were actually mappings, but if ${id}, etc. uses the old info, then it is not an actual mapping). Thus, maybe "overrides" is a better name (and the macro to access to overrides would be something like this ${overrides.id})

[fgalan]

We are going to re-define this, based on the payload concept. So, in a custom notification, there would be three ways of defining a payload:

• As a custom text payload (currently supported with the payload field)
• As a custom JSON payload (currently supported with the json field)
• As a NGSIv2 normalized payload (the purpose of this issue)

The third mode will be associated to the entity field, at the same level than payload and json (note: payload, json and entity are mutually exclusive, i.e. only one of them can be used).

The value of entity will allow to defined entity fields (id, type or attributes) that will be added or mapped in the entity subject of the notification.

---

So, let's consider the following updated entity

{
  "id": "E",
  "type:" "T",
  "A": {
    "value": 1,
    "type": "Number"
  }
}

Lets consider several cases:

A. Nothing to do

Eg:

"entity": {}

will notify:

{
  "id": "E",
  "type:" "T",
  "A": {
    "value": 1,
    "type": "Number"
  }
}

Note2: "entity": {} would be equivalente to "payload": "" or omitting payload/json case in the current implementation.

B. Add new attribute

Eg:

"entity": {
  "B": {
    "value": 2,
    "type": "Number
  }
}

will notify:

{
  "id": "E",
  "type:" "T",
  "A": {
    "value": 1,
    "type": "Number"
  },
  "B": {
    "value": 2,
    "type": "Number
  }
}

C. Map id, type or attribute

Eg:

"entity": {
  "id": "EEEE",
  "A": {
    "value": 10,
    "type": "Number
  }
}

will notify:

{
  "id": "EEEE",
  "type:" "T",
  "A": {
    "value": 10,
    "type": "Number"
  }

D. Any combination of B and C

Eg:

"entity": {
  "id": "EEEE",
  "B": {
    "value": 2,
    "type": "Number
  }
}

will notify:

{
  "id": "EEEE",
  "type:" "T",
  "A": {
    "value": 1,
    "type": "Number"
  },
  "B": {
    "value": 2,
    "type": "Number"
  }

---

Substitution macros would be allowed in the entity fields, eg:

"httpCustom": {
  "url": "http://127.0.0.1:9999/notify",
  "headers": {
    "fiware-servicepath": "/mappedSS"
  }
  "entity": {
    "id": "prefix-${id}",
    "type": "MappedT",
    "originalId": {
      "value": "${id}",
      "type": "Text"
    },
    "originalType": {
      "value": "${type}",
      "type": "Text"
    },
    "originalServicePath": {
       "value": "${servicePath}",
       "type": "Text"
    }
  }

[fgalan]

entity -> ngsi as field name

[fgalan]

PR #4229

[fgalan]

PR #4243 adds additional test cases