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
  • 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 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 specifically
• A list of entities that are enabled for notification. These entities are identified with their name. Regular expressions car be provided to specify multiple names.

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

notification:
    data-updated:
		configuration:
        	app:
				default: false
			dataspace:
				default: false
				specific-enabled:
					- .*-published
			schema-set:
				default: false
				specific-enabled:
					- .*-published
			anchor:
				default: false
				specific-enabled:
					- .*-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.