Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...


Interface

Requirement

Additional Information

Signoff
1CPS-E-08eNCMP will forward 'CM Notifications Subscription' LCM Create events to the appropriate DMI Plugins responsible for the CM Handles (ids) defined in the LCM Events. 
The message sent to DMI should include the private properties for each CM-Handle

 

2CPS-E-08e

NCMP will forward 'CM Notifications Subscription' LCM Delete events to the appropriate DMI Plugins responsible for the CM Handles is defined in the LCM Events. 
The message sent to DMI should include the private properties for each CM-Handle.

'Basic' delete we be implemented followed by a more advanced delete operation depending on Merge functionality: 

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyCPS-1812

A delete should only be forwarded if there is no other subscription for cmhandle datastore path.


 

3CPS-E-08eNCMP responds using Kafka message(s) with the result of the LCM operation
These messages wil will use agreed status fields:
  • StatusCode  (to be included in documentation)
  • StatusMessage
  • result
  • errorInfo  (NEW to be fleshed out)
Action: Define error details later


4CPS-E-08eAll events should use Cloud Events formathttps://cloudevents.io/

5CPS-E-08eMessages should be processed in the order they are created (received)It will depend on DMIs responding within 30s.
Subscription-id should be used as Kafka 'key' to ensure this.

6CPS-E-08.eNCMP is to merge CM Notification Subscriptions create request and forward those to DMI plugin. (Interface to be added).
  • Prevent unnecessary subscription updates to nodes already involved in a subscription to the same path and datastore.
  • For possible combinations, see table below

7CPS-E-08.e

Last lights out: upon subscription Delete request only when there is no more subscription for a cm-handle & xpath & datastore combination a subscription-delete request will be sent to the relevant DMI(s).


8CPS-E-08.eA single client subscription request should result into a maximum of one request per DMI. Of course there can be several messages if more than 1 DMI is involved.

9CPS-E-08.eAmalgamate response should include rejected/accepted/pending DMI responses received within 30 seconds. A client shall be notified of available DMI subscription information after 30 seconds.  Subsequent DMI subscription updates shall be notified to clients as they become available.
  • Same schema for all notifications.
  • Subsequent notifications contains the state of all cmhandles involved in the subscription. 

10CPS-NCMP-I-01CM Handle deletion should NOT update subscription details. Do NOT delete dmi-subscription entry until owning subscription is deleted, see issue #4 below

11CPS-E-08.eBackward compatible with 'basic' created/delete operations.. 


...

8

Error Scenario

Expected behavior

Sign-off

1Non responding DMIs (configurable timeout)An error message listing the 'pending' CM Handle IDs and statusMessage as "partially applied subscription" with relevant statuscode.. statusMessage/statusCode to be agreed. 
2Non Existing or non-valid CM Handle IdsAn error message listing the 'rejected' CM Handle IDs IDs.
3DMI Plugin without CM Event subscription supportAn error message listing the 'rejected' CM Handle IDs 
4Late Response (after timeout defined in #1) from DMIA message contain the status message as "fully applied subscription" with relevant status code.list of outcomes (complete status on how many cmhandles are pending/rejected/accepted) from client subscription is returned in response. 

statusMessage/statusCode to be agreed. 

 

5Create for existing subscription idThe whole subscription will be rejected. statusMessage/statusCode to be agreed. 

 

6delete Delete for non-existing cm handle subscription id(silently?) ignore7delete for non-existing subscription idThe whole delete subscription will be rejected. statusMessage/statusCode to be agreed. 

 

7Error upon error

An error scenario on a second subscription for the same cm-handle/xpath as a previous subscription which did not complete successfully (yet)

to be discussed, see Error Upon Error Combinations


...


Parameter

Expectation

Notes

Sign-off

1Frequency of LCM Subscription EventsNo high volume of such events is expected
For testing purposed purpose 1 LCM event per minute would suffice.

kieran mccarthy confirmed

 

2Number of SubscriptionsMax: 200

kieran mccarthy confirmed

3CM Handles per Subscription

Avg: 200

Max: 500 (document only)

kieran mccarthy to confirm
Note: consider limit and future 'simple' ALL (wildcard) option when above that limit

4Xpaths per Cm HandleAvg: 10

5Status update processing time(Order of 30) seconds (NCMP side)

...