Page History

...

The data updated configuration at application level has priority over the configuration at dataspace level. It means, no notification at all can be sent if the configuration is not enabled at application level, no matter which configuration is set at dataspace level.

Proposition 1: Extending existing entities with notification configuration

This proposition consists in extending current existing CPS concepts with additional properties to enable or disabling the notification for a specific instance.

...

At database level, the following column is added to dataspace table (in cps core db schema):

• Name: data_updated_notification_indicator
• Type: boolean
• Nullable: false
• Default value: false

...

Unfortunately, this endpoint does not align with REST conventions and does not prepare for future changes. Then, redesigning the endpoint for improvement is considered:

• POST - /cps/api/v1/dataspaces (or /cps/api/v2/dataspaces ?)
  

with all payload information for the dataspace to be created provided in the HTTP request body ("dataspace-name" being mandatory and "data-updated-notification-indicator" optional):

...

Dataspace modification requires a new endpoint:

• PUT /cps/api/v1/dataspaces?dataspace-name=<name> (or /cps/api/v2/dataspaces?dataspace-name=<name> ?)
  

with all payload information for the dataspace to be created provided in the HTTP request body ("dataspace-name" being mandatory, consistent with the query parameter and "data-updated-notification-indicator" optional):

...

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

This proposition consists in implementing new dedicated entities to support event notification filtering, without impacting existing ones.

A specific class is created for each type of notification that can be configured (application, dataspace, ...). Any instance of these classes is defining if the corresponding entity should be sent for data updated notification. Configuration for application notification can not obviously have more than one instance. Also, a class is created to define the default behaviour, for each type, when no specific configuration is provided for a specific instance.

The implementation includes:

• Entity classes
• Repository classes for persistence
• Model classes
• Service classes to support notification configuration management (create, read, update, delete)
• Controller classes to support web REST API to manage notification configuration (create, read, update, delete)

Below is the entity/model classes diagram and a data sample example:

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

Proposition 3: Use application properties for notification configuration

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:
    enabled: false
    filters:
      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.