...
Interface | Requirement | Additional Information | Signoff | |
|---|---|---|---|---|
| 1 | CPS-E-08e | NCMP 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 |
| |
| 2 | CPS-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. A delete should only be forwarded if there is no other subscription for cmhandle datastore path. |
| |
| 3 | CPS-E-08e | NCMP responds using Kafka message(s) with the result of the LCM operation These messages will use agreed status fields:
| Action: Define error details later | |
| 4 | CPS-E-08e | All events should use Cloud Events format | https://cloudevents.io/ | |
| 5 | CPS-E-08e | Messages 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. | |
| 6 | CPS-E-08.e | NCMP is to merge CM Notification Subscriptions create request and forward those to DMI plugin. (Interface to be added). |
| |
| 7 | CPS-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). | ||
| 8 | CPS-E-08.e | A 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. | ||
| 9 | CPS-E-08.e | Amalgamate 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. |
| |
| 10 | CPS-NCMP-I-01 | CM Handle deletion should NOT update subscription details. | Do NOT delete dmi-subscription entry until owning subscription is deleted, see issue #4 below | |
| 11 | CPS-E-08.e |
Error
...
| Jira Legacy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
...
Error Scenario
...
Expected behavior
...
Sign-off
...
Handling
Error Scenario | Expected behavior | Sign-off | |
|---|---|---|---|
| 1 | Non responding DMIs (configurable timeout) | An error message listing the 'pending' CM Handle IDs. statusMessage/statusCode to be agreed. | |
| 2 | Non Existing or non-valid CM Handle Ids | An error message listing the 'pendingrejected' CM Handle IDs. statusMessage/statusCode to be agreed. | |
| 2 | Non Existing or non-valid CM Handle Ids | An error message listing the 'rejected' CM Handle IDs. | |
| 3 | DMI Plugin without CM Event subscription support | An error message listing the 'rejected' CM Handle IDs | |
| 4 | Late Response (after timeout defined in #1) from DMI | A 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. |
|
| 5 | Create for existing subscription id | The whole subscription will be rejected. statusMessage/statusCode to be agreed. |
|
| 6 | Delete for non-existing subscription id | The whole delete subscription will be rejected. statusMessage/statusCode to be agreed. |
|
| 7 | Error 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 |
...
* Note 1: given the possible combinations the message to DMI needs to be able to specify different xpaths per cm-handle. So a more complex structure is needed for this even ie. an array of CM Handles objects each having their own list of (target) xpaths!
Note 2: as per decision #11'datastore' should be included in all messages as well
Delete Combinations
...
array of CM Handles objects each having their own list of (target) xpaths!
Note 2: as per decision #11'datastore' should be included in all messages as well
Delete Combinations
| # | Existing Subscription A-10 | Existing Subscription B-52 | Client Delete A-10 Request | DMI Sub update/delete request | Data Model* Before Before | Data Model* After Delete | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | CH-1, [ /p/c1, p/c2 ] | CH-1, [ /p/c1 ] | CH-1, [ p/c2 ] |
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2 | CH-1, [ /p/c1] CH-12, [ /p/c1] | CH-2, [ /p/c2[ A-10 c1] CH-3, [ /p/c1] | CH-1, [ /p/c1] | CH-1, [ /p/c1]
| 2 |
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 3 | 52 | CH-21, [ /p/c1][ ACH-10, B-521, [ /p/c1] CH-32, [ /p/c1][ B-52 ] | None | CH-1, [ /p/c1]
| 3 |
| None |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
* Note: as per decision #11'datastore' should be included in the 'DMI susbcription' data model too now.
...
|
* Note: as per decision #11'datastore' should be included in the 'DMI susbcription' data model too now.
Error-Upon-Error Combinations
( To be captured as part of Jira Legacy server System Jira columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 key CPS-1865
)
| server | System Jira |
|---|---|
| columnIds | issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution |
| columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
| serverId | 4733707d-2057-3a0f-ae5e-4fd8aff50176 |
| key | CPS-1865 |
| Previous Interaction | Current Interaction | Expectation | Notes | Sign-Off | |
|---|---|---|---|---|---|
| 1 | any operation on non-existing cm-handle | operation for same non-existing cm-handle | listed in 'rejected' immediately | behavior as normal |
|
| 2 | create operation rejected by DMI | create for same cm-handle/xpath | Submit create request again. |
| |
| 3 | create pending | create for same cm-handle/xpath | Set it to pending without submitting a new request. When we get response for previous interaction it is applied for the current interaction as well. |
| |
| 4 | create pending | delete for same cm-handle/xpath | Set an error 'Conflict/Retry' |
| |
| 5 | delete pending | delete for same cm-handle/xpath | Set it to pending without submitting a new request. When we get response for previous interaction it is applied for the current interaction as well. |
| |
| 6 | delete pending | create for same cm-handle/xpath | Set an error 'Conflict/Retry' - up to client to retry the create operation. |
|
...