...
# | 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 ? |
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 the CM VES Message to a topic which is agreed ( or to be agreed)
- NCMP will have a listener 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.
...