CPS-1492: Subscription Create Response Handling

References

CPS-1492 - Getting issue details... STATUS

Subscription Creation Events Handling

Assumptions

#

Assumption

Notes

1

Forwarded Subscription Event Responses communicates asynchronously. (from DMI Plugins to NCMP)

Once off timer would be responsible to consume messages into NCMP.

Then, the NCMP would wait a response(s) within the timeframe agreed on. (30 seconds)

A single step response will be provided in the solution. Since, ACK is not feasible as of now.

2

The NCMP component should create Subscription Create Outcome message and publish it into topic (cm-avc-subscription-response) for Client Apps consumed from.

The Outcome Response schema need to be decided on.

Issues & Decisions

#	Issue	Notes	Decision
1	Possible 'timeframe' period for timeout	DMI to NCMP response timeout	30 sec (Configurable param/property)
2	Response in two steps or in a single step should be discussed with shareholders.	from DMI to NCMP responses	Is the ACK would be required? No DMI-Plugin would publish actual response to NCMP
3	Response schema should be decided	from DMI to NCMP response schemas should be decided for both two steps response and single step response	Should DMI Plugins detail cm-hande IDs in response? Accept or Decline
4	Subscription event outcome schema should be decided	from DMI to Client Apps Possible options for initial response and further updates Status only: COMPLETED / PARTIALLY_COMPLETED Status and % -completed based on # Participating DMI-plugins Status and %-completed based on #cm-handle-ids registered (and participating) per Plugin Status and list of m-handle ids for which NCMP got a response	We include : Initial Response : Status only: COMPLETED / PARTIALLY_COMPLETED Pending cm handle ids for PARTIALLY_COMPLETED or Empty in case of COMPLETED. List of declined cm handles Un-registerred cm handles list Update Responses that comes after timeframe (30 sec) : Status only: COMPLETED / PARTIALLY_COMPLETED Pending cm handle ids for PARTIALLY_COMPLETED or Empty in case of COMPLETED. List of declined cm handles Note : Avoid for wild card * (for all cm handles)

Possible Topic Names

#	Source	Content	Topic Name	Destination
1	Client Apps	Subscription Create Event	cm-avc-subscription	NCMP
2	NCMP	Forwarded Subscription Create Event	ncmp-dmi-cm-avc-subscription-{DMI-DATA-SERVICE-NAME}	DMI Plugins
3	DMI Plugins	Forwarded Subscription Create Event Response	dmi-ncmp-cm-avc-subscription	NCMP
4	NCMP	Subscription Create Event Outcome	cm-avc-subscription-response	Client Apps

Implementation Details

Client apps e.g. DME would publish Subscription Create Event to the topic cm-avc-subscription.
Message Format (Client → NCMP):

Create Event from Clients

{
  "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-network-avc-event.rfc8641"
      "schemaVersion": "1.0"
    },
    "predicates": {
                   “targets” :  [“sdsd”, “slada”, “ccde3”]     #  cmhandle targets
        "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//”  
 
    }
}

The NCMP would consume the messages from cm-avc-subscription topic, and create Forwarded Subscription Event.

Message Format (NCMP→ DMI Plugin):

NCMP to DMI Message Format

{
  "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.dmi:cm-network-avc-event.rfc8641",
      "schemaVersion": "1.0"
    },
    "predicates": {
      "targets": [{
        "cmhandle": "sdsd",
        "cmhandle - properties": {
          "prop1": "prop - value"
        }
      },
        {
          "cmhandle": "slada",
          "cmhandle - properties": {
            "prop - x": "prop - valuex"
          }
        },
        {
          "cmhandle": "ccde3",
          "cmhandle - properties": {
            "prop - y": "prop - valuey"
          }
        }
      ],
      "datastore": "passthrough-operational",
      "datastore-xpath-filter": "//_3gpp-nr-nrm-gnbdufunction:GNBDUFunction/",
      "_3gpp-nr-nrm-nrcelldu": "NRCellDU",
      "_3gpp-nr-nrm-gnbcuupfunction": "GNBCUUPFunction",
      "_3gpp-nr-nrm-nrsectorcarrier": "NRSectorCarrier"
    }
  }
}

TBD Further with external team: Putting predicates back to NCMP does not sense. Since, the predicates and CM Handles are clashing.

The communication between NCMP and DMI-Plugin would be synchronously.
The DMI-Plugin would publish responses in a single step. ACK feature is not feasible as of now.
Then, the NCMP would wait a response(s) within the timeframe (timeout) agreed on e.g. 30 seconds via once-off timer.
1. Response in a single step
  1. Process result response: 2 out of 3 DMI has responded. (The percentage is %66.)
  2. In order to calculate the response ratio, CPS inventory CmHandleQueries could be used.

Finally, the NCMP create outcome message, and publish it to the topic cm-avc-subscription-response.
The outcome message format could be like:

Possible options for initial response and further updates
	Status only: COMPLETED / PARTIALLY_COMPLETED
	Status and % -completed based on # Participating DMI-plugins
	Status and %-completed based on #cm-handle-ids  registered (and participating) per Plugin
	Status and list of m-handle ids for which NCMP got a response