Page History

...

• Pros
  • Dedicated entity and model does not impact existing ones
  • Information required to determine if a data update should be published or not is not spread in multiple entities, then could be most efficient to retrieve.
  • Generic and flexible solution that should be able to support consistent evolution
• Cons
  • Design is a bit more complex to handle all cases. Need to be refined.
  • Not necessary a con but design for Yang model filtering still need to be detailed:
    • Is it ok to filter using cps path ?
    • Should it be multiple cps path ?
    • Could it be interesting to use Yang extension ? Reference: https://datatracker.ietf.org/doc/html/rfc7950#section-6.3.1

...

Notification configuration is specified in the application.yaml with the following for each type:

• Default behaviour for entities not enabled specificallyApplication level enabled flag
• A list of entities datasapces that are enabled for notification. These entities dataspaces are identified with their name. Regular expressions car be provided to specify multiple names. For application type, such a list is not neededIf the dataspace list is empty, then no publication is made even if it is enabled at the application level.

Ideally, this configuration should be also easily provided using environment variables when the application is starting.

Snippet below represents notification configuration section from application.yaml file.

notification:
  data-updated:
    configuration:
      application:
        default-enabled: false
      dataspacefilters:
        default-enabled: false
        specific-enabled:
          - .*-published
      schema-set:
        default-enabled: false
        specific-enabled:
  -datspaces:
        - .*-published
      anchor:
        default-enabled: false
        specific-enabled:
          - .*-published
  topic: ${CPS_CHANGE_EVENT_TOPIC:cps.cfg-state-events}

...