Page History

References

...

Out-of-scope

• Working with wildcards and subscription update which will be taken care by a separate epic.
• Subscription create ( done as part of a different story ) 
• Merging of the ongoing subscriptions.

Assumptions

Issues & Decisions

Overview

1. We receive an event of type : subscriptionDeleted from the client ( DME ) containing the subscription clientId and subscription name along with datastore and dataCategory details ( DMEtoNCMP )
2. We check in NCMP that we have an ongoing subscription using clientId and subscriptionName.
3. If we have ongoing subscription , we forward the event to dmi-plugins so that the changes are applied in the devices managed by dmi-plugin as well. ( Impl. Proposal CM Event Subscription LCM: Delete ( Positive Scenarios ) )
4. Now if the dmi-plugins have applied the request then we get an event back from dmi-plugin and NCMP will process that event and based on that it will delete the ongoing subscription request from the database itself. If the response from DMI plugins is accepted ( i.e it can delete the subscriptions from the underlying devices and no subscription delete request are in PENDING or REJECTED state )Then we delete the subscriptions from the DB as well. ( Impl. Proposal CM Event Subscription LCM: Delete ( Positive Scenarios ) )
5. After processing the received event from DMI , NCMP will send the final event to the client (DME). (  Impl. Proposal CM Event Subscription LCM: Delete ( Positive Scenarios ) )

Subscription Delete Sequence Diagram

@startuml "Subscription Delete"

actor rApp as "rApp/Client"autonumber

participant DME
participant NCMP
participant "CPS-DB"
participant "DMI_-PLUGIN"

rAppDME --> DME
DME  NCMP : 'Request to delete the CmSubscription using subscriptionId'
NCMP --> NCMP : 1. Incoming subscriptionDelete event 'Check if the CmSubscription is fully shared or exclusive per DMI'
NCMP --> "DMI_-PLUGIN" : 2. ncmp to forward event to dmi plugin
DMI_PLUGIN -> DMI_PLUGIN: 3. Apply the requested event and respond with the status
DMI_PLUGIN 'for exclusive CmSubscription(part of the subscription) notify the "DMI-PLUGIN"s to ACCEPT/REJECT the subscription'
"DMI-PLUGIN" --> NCMP : 'Request ACCEPTED by "DMI-PLUGIN"'
NCMP --> "CPS-DB" : 'Delete the CmSubscription from the database and update the cache with ACCEPTED'
NCMP --> DME : 'Respond with the status as ACCEPTED'

@enduml

@startuml
autonumber

participant DME
participant NCMP
participant "CPS-DB"

DME --> NCMP : 4.'Request Statusto ofDelete the subscriptionDeleteCmSubscription request whether accepted/rejected/pendingusing subscriptionId'
NCMP --> NCMP : 5. If all accepted then only remove the subcription data from DB 'Check if the CmSubscription is fully SHARED or EXCLUSIVE per DMI'
NCMP --> NCMP : 'for SHARED CmSubscription dont notify the "DMI-PLUGIN"s'
NCMP --> "CPS-DB" DME: 'Delete 6.the RespondCmSubscription withfrom the statusdatabase thatand weupdate receivedthe fromcache dmiwith pluginACCEPTED'
DMENCMP --> rApp

 DME : 'Respond with the status as ACCEPTED'

@enduml

DME to NCMP

Subscription Delete Event

...

topic subscription
 
id generated by client
source "SCO-9989752"
specversion  "1.0"
type subscriptionDeleted
time
dataschema org.onap.ncmp.cm.subscription:1.0.0
{
  "data": {
    "subscription": {
      "clientID": "SCO-9989752",
      "name": "cm-subscription-001"
    },
    "dataType": {
      "dataspace": "ALL",
      "dataCategory": "CM",
      "dataProvider": "CM-SERVICE"
    },
      "predicates":{
        “targets” :  [“cmHandle1”, “cmHandle2”, “cmHandle3”]
        "datastore": “passthrough-running",
        "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//”

            }

...

NCMP to DMI-Plugins

Produced by NCMP and Consumed by DMI Plugins

...

DMI-Plugins to NCMP

 Produced by DMI Plugins and Consumed by NCMP

...

topic: dmi-ncmp-cm-avc-subscription
 
id uuid - generated by dmi-plugins
source <dmiName>
specversion  "1.0"
type subscriptionDeletedStatus
time - generated by dmi
correlationid: clientId:subscriptionName
dataschema org.onap.ncmp.dmi.cm.subscription:1.0.0
data
{
   "clientId":"SCO-9989752",
   "subscriptionName":"cm-subscription-001",
   "dmiName":"<dmiName>",
   "subscriptionStatus":[
      {
        id : <cmhandleid>,
        status : rejected | accepted,
        details : <some message>  // only present for rejected
    },
      {...}
   ]
}
 
"javaType": "org.onap.cps.ncmp.events.avcsubscription1_0_0.dmi_to_ncmp"

Notes

1. dmiName in Output Schema is populated from application.yml of DMI-plugin.
2. DMI-plugin subscribes to the topic to consume Input Schema given in application.yml of DMI-plugin.

...

NCMP to DME

Produced by NCMP to send it to the Client-Apps

...

topic: subscription-response
 
id uuid - generated by NCMP
source <NCMP>
specversion  "1.0"
type subscriptionDeletedStatus
time // NCMP would generate
correlationid: clientId:subscriptionName
dataschema org.onap.ncmp.cm.subscription:1.0.0
{
  "data": {
       “statusCode” : 207,  # Some error code reflecting partial success.  **   //  To be discussed with the whole team
       “statusMessage” : “Partially Applied Subscription”,
       “additionalInfo” : {
           “rejected” :  [{
                “details” : “faulty subscription format for target(s)”, // need to finalize the detailed message for grouping.
                “targets” : [“cmhandle1”, “cmhandle2”, “cmhandle3”]
           },
            {
                “details” : “faulty subscription format for target(s) - xyz”, // need to finalize the detailed message for grouping.
                “targets” : [“cmhandle1”]
           }
],
           “pending” : {
                “details” : “EMS/node connectivity issues, retrying”,
                “targets” : [“cmhandle4”, “cmhandle5”, “cmhandle6”]
       }
  }
}
 
// we dont have to send the accepted cmhandle details.
  
** 202 could indicate complete failure –
    "data": {
       “statusCode” : 406,  # Some error code reflecting complete rejection of the request
       “statusMessage” : “Subscription rejected : Faulty Subscription Data”,
       “additionalInfo” : {
           “rejected” :  {
                “details” : “//NRxxCellDU is not a valid subscription type”
           },
 
Have another for Pending CMHandles gone to accepted
 
"javaType": "org.onap.cps.ncmp.events.avcsubscription1_0_0.ncmp_to_client"

DB Logic for subscription delete handling forwarding

1. NCMP receives a subscription delete request
2. IF subscription exists
   1. Set last operation enum to delete

CMHANDLE1:

CMHandle2:

CMHandle3:

DB Logic for subscription delete handling

...

1. If cmhandle is accepted, delete cmhandle is pending
2. If cmhandle is rejected, delete cmhandle is rejected with message like "create subscription was rejected originally"
3. If cmhandle is pending, delete cmhandle is rejected with message like "create subscription for cmhandle is pending" 

...

1. If all respond then send NCMP to ClientApp response
2. If not all respond then send response after 30 seconds

...

If Delete is requested again by client apps

...