...
| # | Issue | Notes | Decision |
|---|---|---|---|
| 1 | Do we need to update existing update notification to send delta notification or delta notification along with existing notification. | 29-Sep-2023: We decided to implement delta notification separately without changing the existing update notification. |
Event Schema
For delta notification we can use the existing cps data update event schema (cps-data-update-event-schema.json).
| 2 | Using Liquibase v. Yang Model for storing new metadata per anchor in CPS Core | 29-Sep-2023: We decided to use yang model to persisting delta notification subscription. No DB change is required. notification subscription information will be stored in Fragment table. | |
| 3 | generic text field OK for future refinement, maybe consider json? | 29-Sep-2023: subscription information will be persisted in JSON format |
Event Schema
proposal for notification schema:
Cloud event Definition
Element | Name | Parent | Type | Mandatory | Description | Format | (example) Value | |
|---|---|---|---|---|---|---|---|---|
| 1 | Header | id | String | Yes | random id for cloud event header. UUID is suggested | |||
| 2 | source | String | Yes | source of information | fixed value |
| urn:cps:org.onap.cps | |||||||
| 3 | specversion | String | Yes | cloud event version spec | fixed value | 1.0 | |
| 4 | type | String | Yes | type of event | fixed value | dataUpdateEvent | |
| 5 | dataschema | String | Yes | data schema | fixed value |
| cps:org.onap.cps:data-updated-event-schema: |
org.onap.cps.data-updated-delta-event"operation": "UPDATE",
"anchorName": "Anchor1",
"dataspaceName": "dataspace1",
"schemaSetName": "schemaset1",
"observedTimestamp": timestamp,
"data":
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
[
{
"action": "ADD",
"xpath": "/bookstore/categories/[@code=3]",
"payload": {
"code": 3,
"name": "kidz"
}
},
{
"action": "DELETE",
"xpath": "/bookstore/categories/[@code=1]",
"payload": {
"code": 1,
"name": "Fiction"
}
},
{
"action": "UPDATE",
"xpath": "/bookstore/categories/[@code=2]",
"payload": {
"name": "Comic"
}
}
] |
}Controlling Notification
It is important to control the delta notification for better performance. we need to decide on below options to control delta notification.
...
Pros:
- Dynamically control notification and per request level.
Cons:
- there could be issue with access control
...
Pros:
- Only allowed dataspace/anchor's delta update will be sent in notification
Cons:
- Not practical because we can't control the notification dynamically.
| 1.0.0 | ||||||||
| 6 | Payload | data | Object | Yes | The actual data payload. Details will be provided below. | |||
| 7 | observedTimestamp | data | String | Yes | The timespamp of the event. | timestamp | 2024-01-17 12:34:43 | |
| 8 | dataspaceName | data | String | Yes | The dataspace name where data is changed. | dataspace01 | ||
| 9 | schemaSetName | data | String | No | The schemaset name for which data is changed. | bookstore | ||
| 10 | anchorName | data | String | Yes | The anchor name for which data is changed. | anchor01 | ||
| 11 | operation | data | String | Yes | The operation performed on data. | CREATE UPDATE DELETE | ||
| 12 | xpath | data | String | Yes | The XPath which is changed | /bookstore |
Controlling Notification
It is important to control the notifications for better performance. Notifications in cps-core will be controlled at Anchor level. By default notifications will be disabled for all anchors. notification can be enabled/disabled for an anchor or all anchors of a dataspace using below REST API.
API to
...
Pros:
- control the notification dynamically.
Cons:
- Need to persist notification information in DB.
...
controlling delta notification
Delta notification can be enabled/disabled by an additional admin API for a given anchor name. New API will be added as below.list of anchors in a dataspace or all anchors in a dataspace.
API : PUT https://localhostIP:8333PORT/cps/api/v2/dataspace/<dataspace-name>/deltanotification/<subscribe or unsubscribe>
Request bodyBody :
{
"anchorName": "["anchor01", "subscribeDeltaNotificationanchor02": true
}
Additional table to persist delta notification
Table Name: AnchorForDeltaNotification
]
Note: if no anchors list provided in request body than notification will be enabled/disabled for all the anchors for given dataspace.
Persisting notification subscription
Add schema for notification subscription and add subscription information in to Fragment table when delta notification is subscribed. delete the fragment when delta notification is unsubscribed.
below actions will be performed when delta notification will be subscribed for the dataspace.
- schema set will be added to the dataspace when notification is subscribed.
- An Anchor will be added to dataspace for notification subscription.
- Subscription data will be added into fragment as per schema set.
schema yaml file to be used as below.
| Code Block | ||||
|---|---|---|---|---|
| ||||
module notifications {
yang-version 1.1;
namespace "org:onap:ccsdk:sample";
prefix delta-notification;
revision "2024-01-10" {
description
"Sample Model";
}
container deltanotification {
leaf notification-subscription {
type string;
}
}
} |
Implementation details of delta notification
...
- For data nodes update operation, generate delta report by comparing previous and current configuration after successful update.
- Process data update delta event and send notification as described in event schema above.