...
# | Issue | Notes | Decisions |
---|---|---|---|
1 | Delete the subscription from the database? |
| |
2 | What do we need to send to the DMI Plugin so that they are able to decide that how to delete the ongoing subscription. |
| |
3 | Who should be able to retry and make sure the subscriptions are deleted from the respective DMIs managing the devices. | kieran mccarthy The agenda for the next meeting. We can decide then. More on the "DELETING" stage ( if we want to have it ) | kieran mccarthy As discussed on , The DME should be able to maintain Subscription State and make decision when to retry based on the response outcome we provide to it for create and/or delete use cases. |
4 | DME to NCMP Event to have targets and datastore-xpath-filter information for the subscription delete use case ? | kieran mccarthy As per the discussion today we agreed to use targets , datastore-xpath-filters and datastores for the subscription delete use case. | |
5 | Do we send additional properties from NCMP to DMI | Are additional properties needed to delete the subscription |
...
Algorithm for CM Subscription Delete ( TBD )
- Capture Incoming subscriptionId from the client.
- Query the existing subscriptions we are tracking using the subscriptionId we got from the Cm Subscription Delete request.
- Populate the cmSubscriptionCache with the relevant details ( this will be later used to send the response ) using the above query we did.
- Now check if the details we have are ALL the last subscribers or not.
- if all are NOT the last subscribers then we can right away delete it from the DB and send back the response to the client.
- if we have mixed records then we need to make a call to the DMI for the "last lights out" to get Acceptance from DMI.
- if DMI accepts it , then whatever we have in the cache can be used to DELETE the rows from the DB ( similar to what we did for create )
- Once the rows are deleted then we can send back the response to the client.
Subscription Delete Sequence Diagram
...