When do we actually delete the subscription from CPS DB ? We plan to do it when we receive response from the DMI plugins and the underlying subscriptions from the devices are deleted.
2
What do we need to send to the DMI Plugin
subscription name + client id
+ cmhandle ids?
+ cmhandle properties?
+ datastore?
Overview
We receive an event of type : subscriptionDeleted from the client ( EDM ) containing the subscription clientId and subscription name along with datastore and dataCategory details.
We check in NCMP that we have an ongoing subscription using clientId and subscriptionName.
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.
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.
After processing the received event from DMI , NCMP will send the final event to the client (EDM).
Subscription Delete Sequence Diagram
EDM to NCMP
Subscription Delete Event (Schema 1)
Subscription Create Event (Schema 1)
topic subscription
idgenerated by client source"SCO-9989752" specversion "1.0" typesubscriptionDeleted time dataschema org.onap.ncmp.cm.subscription:1.0.0 data
Input Schema (Schema 3) - Produced by NCMP and Consumed by DMI Plugins
topic: ncmp-dmi-cm-avc-subscription-dminame1
id uuid source "SCO-9989752" specversion "1.0" type subscriptionDeleted time // ncmp will generate dataschema org.onap.ncmp.dmi.cm.subscription:1.0.0 data
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
{ "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