Page History

...

1. NCMP is configured at startup with the cm subscription topic information (cm topic name, kafka addressing info).

2. Some app sends a 'CreateSubscription' event to the public cm subscription topic (cm-event-subscription).

   Create Subscription  :   client app → ncmp

   Create Example

   {   "version": "<event type version>",   "eventType": "subscriptionCreated",   "event": {     "subscription": {       "clientID": "<unique identifier for the client >",       "name": "<unique subscription name per client>",       "isTagged": "<yes|no>, optional parameter, default is no"     },     "dataType": {       "dataspace": "<data space>",       "dataCategory": "<data category type>",       "dataProvider": "<data provider type>"       "schemaName": "<schema name>"       "schemaVersion": "<schema version>"     },     "predicates": {       "<parameter>": "<value>",       "param2": [         "value21",         "value22"       ]     }   } }

   {   "version": "1.0",   "eventType": "subscriptionCreated",   "event": {     "subscription": {       "clientID": "SCO-9989752",       "name": "cm-subscription-001"     },     "dataType": {       "dataspace": "ALL",       "dataCategory": "CM",       "dataProvider": "CM-SERVICE"       "schemaName": "org.onap.ncmp.cm-notification-event"       "schemaVersion": "1.0"     },     "predicates": {         "datastore": “passthrough-operational",         "datastore-xpath-filter": "//_3gpp-nr-nrm-gnbdufunction:GNBDUFunction/               _3gpp-nr-nrm-nrcelldu:NRCellDU/ | //_3gpp-nr-nrm-gnbcuupfunction:GNBCUUPFunction// |             //_3gpp-nr-nrm-gnbcucpfunction:GNBCUCPFunction/_3gpp-nr-nrm-nrcelldu:NRCellCU// |             //_3gpp-nr-nrm-nrsectorcarrier:NRSectorCarrier//”       }   } }

   
   

3. NCMP receives consumes the create cm subscription event and processes it as follows : 
   1. Persist the subscription and cm-subscription-filter information to db
   2. Read all CM handles that match the cm-filter-subscription (model matching, cmhandleId matching)
   3. If a subscription is already ongoing for a cmhandle then separate them from the list for later processing (after the existing ongoing cmhandle subscription has completed).
   4. Merge the existing cmhandle filter (if one exists from a previous subscription) with the new cm-filter-subscription
   5. Record the cmhandles whose existing cm subscription filter has been modified after filter merging in step c)
4. For the cmhandle(s) with a new or modified subscription filter, group them according to their controlling dmi-plugin and send one or more bulk subscription request(s) to the appropriate dmi-plugin(s).
            -  the bulk subscription REST request to each dmi-plugin contains either a 'create' (where no previous subscription exists on the cmhandle) or an 'update' subscription for each cmhandle
            - the REST request to the dmi-plugin is asynchronous.  The dmi-plugin shall process the each of the subscription requests per cmhandle and send an event only for cmhandles that fail to subscribe successfully. 

5. dmi-plugin loops through the cmhandle subscriptions and creates a new subscription or modifies an existing subscription for the remote 'device' associated with the cmhandle.
6. dmi-plugin calls back to NCMP to notify of the newly created or updated subscription
7. NCMP updates its subscription registry with the new subscription information 

8. 

Update Subscription

Topics 

...