...
title | DRAFT |
---|
...
- 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
...
This proposition consists in a simple and straight forward solution to support dataspace notification filtering by using application configuration properties.
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. If 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.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
notification: data-updated: configuration: enabled: false filters: app: default: false dataspace: default: false specific-enabled: - .*-published schema-set: default: false specific-enabled: - .*-published anchor: default: false specific-enabled: - .*-published enabled-datspaces: - *-published topic: ${CPS_CHANGE_EVENT_TOPIC:cps.cfg-state-events} |
...