...
# | Issue | Notes | Decisions |
|---|---|---|---|
| 1. | CM VES Message format schema. Who will own it ? | In order to process the message DMI plugin / NCMP should be aware of the schema of the incoming message it is going to be consume. | |
| 2. | Topic from where we will receive the CM VES Message | ||
| 3. | Does CPS raise any special event after the events are updated in CPS DB ? | ||
| 4 | Does CPS care about all the attributes in the CM VES Message. If not then we need to list down the attributes which CPS cares about. | The CM update expected would be a change for the GNBDUFunction/nrCellDU/nrPCI ** or for the GNBCUFunction/NRCellCU/NRCellRelation/isHOAllowed . | Need to confirm with the stakeholders. |
| 5 | Do we need to persist the CM VES Message ? | ||
| 6 | Any Performance requirements ? | ||
| 7 |
| ||
| 8 | How to get the cmHandle and the xpaths from the CM VES Messages. | ||
Overview
The Big(ger) Picture
| Gliffy | ||||||
|---|---|---|---|---|---|---|
|
For more details and descriptions see CPS Data Notifications Overview
VES Event flow
- DMI Plugin to receive CM VES Message from the upstream( VES Collector ?? ) via a REST call or DMI will listen to a topic. ( or also can generate a VES message for testing)
- DMI Plugin will have to convert the CM VES Message to DMI Data AVC event and publish the same to an internal topic.
- NCMP will have logic to handle the DMI AVC event received to update the cache. ( See #6 in CPS Data Notifications Overview )
...