...
# | 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 | Need topic info to listen to. (NCMP will have a listener configured to listen to the 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.9 | |||
Overview
- DMI Plugin to receive CM VES Message from the upstream( VES Collector ?? ) via a REST call or some other method. ( or also can generate a VES message for testing)
- DMI Plugin will publish have to convert the CM VES Message to a topic which is agreed ( or to be agreed)DMI Data AVC event and publish the same to an internal topic.
- NCMP will have a listener logic to the topic and process the CM VES message.
- CM VES Message should be understood by NCMP.
- NCMP will process the VES message and call the CPS Core APIs to update the CPS DB.handle the DMI AVC event received to update the cache. ( See the highlighted portion in the attached diagram )
| Gliffy | ||||||||
|---|---|---|---|---|---|---|---|---|
|
...