JEXL. Use the result of calculated attribute in another calculated attribute

[fgalan]

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

After the implementation of #4004, JEXL is supported in custom notifications. However, a calculated attribute cannot be used in the expression of another calculated attribute.

Note that other platform components (IOTAs in particular) implement this feature.

Describe the solution you'd like

Each time an attribute is calculated, it's added to the existing JEXL context, so it can be used by attributes calculated in sequence.

In order to to this, we have to define the order in which the attributes are processed. Different from IOTAs (in which attributes come in an array, so we can base in the array order), the ngsi (or payload or json) fields in subscription doesn't allow to define an order.

However, we could base that order in attributes.notifications.attrs (which is an array). This field is optional, but would become needed in the case user want to take advantage of this new functionality.

Describe alternatives you've considered

None

Describe why you need this feature

• To approach a new use case.
• To improve or simplify an scenario.

[fgalan]

However, we could base that order in attributes.notifications.attrs (which is an array). This field is optional, but would become needed in the case user want to take advantage of this new functionality.

This is not a good idea, as we could want intermediate attribute calculation that we don't want to get included in the notification. It would be better to have orthogonal mechanism: the one to specify which attributes include in the notification (that is, existing attributes.notifications.attrs) and other mechanism to specify pre-calculations to be used in attributes.

[fgalan]

Proposal1:

"httpCustom": {
  ...
  "ngsi|json|payload": ...,
  "preCalculations": {
    "c1": "<jexl expression>"
    "c2": "<jexl expression>"
    ...
  }
}

So c1, c2, etc, can be used in the ngsi|json|payload.

Proposal2:

"httpCustom": {
  ...
  "ngsi|json|payload": ...,
  "preCalculations": [
    {"name": "c1", "expression": "<jexl expression>"},
    {"name": "c2", "expression": "<jexl expression>"},
    ...
  ]
}

improves proposal1 to specify an order of evaluation (so c2 could use c1 in the JEXL expression), as the cost of a more complex syntax

(preCalculations is a draft name... maybe it could be improved)

[fgalan]

Let's go for proposal2

[fgalan]

Adding a preCalculations field involves complexity in the implementation (defining new classes for preCalculatinon and its array items, plus CRUD of that new field in the subscription API and associated csubs documents in DB).

In order to avoid such complexity, ngsi could be reused. In particular, something like this, defining a new evalPriority builtin metadata, which is not actually included in sent notification but used to define in which order expressions are evaluated.

"httpCustom": {
  ...
  "ngsi": {
    "c1": {
      "value": "<jexl expression>",
      "type": "Calculated",
      "metadata": {
        "evalPriority": {
          "value": 1,
          "type": "Number"
        }
    },
    "c2": {
      "value": "<jexl expression>",
      "type": "Calculated",
      "metadata": {
        "evalPriority": {
          "value": 2,
          "type": "Number"
        }
    },
    "regularAttr1": {
      "value": "<jexl expression using c1 and c2>",
      "type": "Calculated"
    },
  }
}

Expressions would be evaluated in increasing evalPriority order. Thus, first c1 is calculated, next c2 is calculated (implementing the same behaviour we would have with former preCalculations array). After that, regularAttr1 (omission of evalPriority would be considered 99999999 or something like that).

[fgalan]

PR #4590