...
| Table of Contents |
|---|
Requirements
- support 'basic cm notification subscription requirements define before: CM Event Subscription LCM
Functional
| # | Interface | Requirement | Additional Information | Sign-Off |
|---|---|---|---|---|
| 1 | CPS-E-08.e | NCMP is to merge CM Notification Subscriptions Create request for the same CM Handle & XPath(s) |
| |
| 2 | CPS-E-08.e | Last lights out: upon subscription Delete request only when there is no more subscription for a cm-handle & xpath combination a subscription-delete request wil be send to the relevant DMI(s) | ||
| 3 | CPS-E-08.e | Amalgamation per DMI: all subscription updates originating from a single client request should be send to a single DMI in one request (message). Of course there can be several message if more than 1 DMI is involved. | The need for amalgamation / granularity of message might need to be discussed pending the required characteristics (issue #8). If a single subscriptions can contain all possible cm-handles with many cps-paths it then becomes feasible all CM-Handles refuse all paths or a specific path... Will all that info fit in a single response message. Is that the right thing to do?!!! | |
| 4 | CPS-NCMP-I-01 | CM Handle deletion should update subscription details | do NOT delete dmi-subscription entry until owning subscription is deleted, see issue #4 below | |
| 5 | CPS-E-08.e | backward compatible with 'basic' created/delete operations.. TBD | could use versioning in API–methods and schema's to handle this?! see also issue #12 |
...
We have the below configuration managed by CPS-NCMP
# cmhandle dmi-plugin 1 ch-1 dmi-1 2 ch-2 dmi-1 3 ch-3 dmi-2
We get a Subscription Create Request with unique subscription-id and a list of predicates(list of targets , datastore and list of filters)
Code Block title Subscription Create Request { "subscriptionId" : "A-10", "predicates" : [ { "targets": [ch-1,ch-2], "datastore" : "ncmp-datastore:passthrough-operational", "datastore-xpath-filter" : ["p1/c1","p2/c2"] }, { "targets": [ch-3], "datastore" : "ncmp-datastore:passthrough-operational", "datastore-xpath-filter" : ["p3/c3"] } ] }- We persist the incoming request as is in our persistent store using a relevant subscription model ( this model also needs to be revised )
We also maintain a distributed datastructure in Hazelcast to keep track of the request and response to the client.
SubscriptionId dmi-plugin affectedCmHandles status A-10 dmi-1 ["ch-1","ch-2"] PENDING A-10 dmi-2 ["ch-3"] PENDING - Read the requests from the distributed data structure and form the request for the DMI-Plugin and publish it to the internal kafka channel.
- If the DMI-Plugin responds back within the configured time , so the request will either be ACCEPTED or REJECTED.
- if whole subscription request is ACCEPTED , update the distributed data structure and then store the subscription to the ActiveSubscriptions in cps-cache.
- if whole subscription request is REJECTED , update the distributed data structure and send back the response to the client.
if the DMI Plugin fails to respond then the status would remain PENDING only as there is no change.
SubscriptionId dmi-plugin affectedCmHandles status A-10 dmi-1 ["ch-1","ch-2"] ACCEPTED A-10 dmi-2 ["ch-3"] REJECTED
We store the "ActiveSubscriptions" using a new model which will look like below.
SubscriptionId cmHandle filter A-10 ch-1 p1/c1 A-10 ch-1 p2/c2 A-10 ch-2 p1/c1 A-10 ch-2 p2/c2 Now based on whatever we have in the distributed map , we will send the response to the clients and may be clear the in-memory structure if required.
...