Subscriptions to do internal modifications to CB entities

[fgalan]

Is your feature request related to a problem / use case?

Currently we have HTTP and MQTT external notifications (http, httpCustom, mqtt and mqttCustom in the subscription JSON). It would be great to have a subscription-based mechanism to modify internal entities without notifications. In some sense, a kind of internal notifications.

This could be used in combination with JEXL expressions (#4004) in order to generate calculated attributes in entities

Describe the solution you'd like

For instance, let's consider something like this:

{
  "subject": {
    "entities": [
      {
        "idPattern": ".*",
        "type": "T"
      }
    ]
  },
  "notification": {
    "internal": {
      "ngsi": {
        "sum": {
          "value": "${a+b}",
          "type": "Number"
       }
     }
    }
  }
}

So if CB receives an update on entity E1-T with attributes a=2 and b=4 the final state of that entity would be the following attributes:

• a: 2
• b: 4
• sum: 6

Describe alternatives you've considered

We could have a new API to define attribute calculations, but it seem wiser to reuse all the existing logic for subscriptions, enhancing with a new "notification" type.

Describe why you need this feature

• To approach a new use case.

Do you have the intention to implement the solution

• Yes, I have the knowledge to implement this new feature.

[fgalan]

With regards to the syntax to use, with regards to the proposal above:

{
  "subject": {
    "entities": [
      {
        "idPattern": ".*",
        "type": "T"
      }
    ]
  },
  "notification": {
    "internal": {
      "ngsi": {
        "sum": {
          "value": "${a+b}",
          "type": "Number"
       }
     }
    }
  }
}

In involves the definition of a new notification sub-key (internal) which involves extra logic in the CB code.

As alternative, we could reuse httpCustom with the following criteria: if it ommits the url sub-field (currently it's mandatory) it refers to an internal notification:

{
  "subject": {
    "entities": [
      {
        "idPattern": ".*",
        "type": "T"
      }
    ]
  },
  "notification": {
    "httpCustom": {
      "ngsi": {
        "sum": {
          "value": "${a+b}",
          "type": "Number"
       }
     }
    }
  }
}

It's more dirty (as we are using httpCustom for something that has nothing to do with HTTP) but simpler in the CB code.

[fgalan]

Another important thing to take into account is loop protection. For instance, we could have something like this:

{
  "subject": {
    "entities": [
      {
        "idPattern": ".*",
        "type": "T"
      }
    ]
  },
  "notification": {
    "internal": {
      "ngsi": {
        "a": {
          "value": "${a+1}",
          "type": "Number"
       }
     }
    }
  }
}

causing an infinite loop if a E1-T a=1 arrives to the CB.

In the past we implemented a loop protection for HTTP notifications (issue #2937, PR #2941) but it's heavily based on fiware-correlator header in HTTP. Should be improved to take also into account this new internal notification scenario.

[fgalan]

Currently we have four ways of specifying the payload of a notification:

1. No field (NGSI format)
2. json field
3. payload field
4. ngsi field (NGSI patching)

Only 1 and 4 make sense for internal notifications

[mapedraza]

Could this feature be implemented through IoTA?

[fgalan]

Could this feature be implemented through IoTA?

That would involve an external notification. That mechanism already exists, but what we are addressing with this issue is internal modification. It's a way of programming calculations at Orion, but reusing the subscription logic.