Page History

...

...

For performance optimization, caching dataspace information is considered to avoid requesting the database each time this information is needed.

Pro and cons

• Pros
  • Effort is limited to implement filtering for dataspaces
• Cons
  • Requires evolution in current existing APIs (service and REST) to manage the entity
  • Potential risk to spread notification configuration in many different elements depending on future filtering requirements to be implemented.

Proposition 2: Create new entities dedicated to notification configuration

...

Pro and cons

• 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:

• Application level enabled flag
• A list of datasapces that are enabled for notification. These 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.

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}

Pro and cons

• Pros
  • Simpler and quicker to implement with limited code change to be made. There is no need for an API to persist and manage notification configuration.
  • Good fit for a transition implementation, giving more time to refine future additional notification filtering requirement and design.
• Cons
  • Any change in the configuration requires a service restart
  • Limited basic configuration options

 Conclusion

As per the analysis made for the 3 propositions above, the decision is made to implement Proposition 3 (application properties) for Istanbul release.

All 3 propositions will be re-evaluated during next release depending on the notification filtering requirement that will be considered at that time.