Table of Contents |
---|
References
// put in related JIRA tickets and the reference here.
Assumptions
...
#
...
Issue
...
Notes
...
Decisions
...
Issues & Decisions
...
#
...
Issue
...
Notes
...
Decisions
...
Schema of the outcome response message (Schema 5)
...
Open Questions:
- What headers do we need?
- Do we need all Accepted, Rejected, Pending targets?
...
Jira server ONAP 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 425b2b0a-557c-3c0c-b515-579789cceedb key CPS-1616
Impl. Proposal CM Subscriptions : Delete ( Positive Scenarios )
Jira | ||||||
---|---|---|---|---|---|---|
|
Assumptions
# | Issue | Notes | Decisions |
---|---|---|---|
1 |
Issues & Decisions
# | Issue | Notes | Decisions |
---|---|---|---|
1 | Schema of the outcome response message (Schema 5) | Open Questions:
| |
2 | dataType section needs to be confirmed. | kieran mccarthy to confirm for all the events. | |
3 | Grouping of the response for rejected and pending to be finalized. |
Overview
- NCMP will receive the Subscription Request from DME in the form of an Event.
- NCMP will be responsible for the below operations. ( Consumer Code for DME Event )
- Since NCMP already knows the structure of the incoming subscription request it will map the incoming request to java object.
- Persist the request in the subscription-registry model which we already introduced.
- NCMP ( Producer Code and Record the published time )
- Enrich the request with the additional properties and a proper dmiRequestId ( subscriptionId+subscriptionName+dmiServiceName)
- Save the dmiRequestId in the distributed map along with the current-time. ( we can call it published time ) . This will be useful at a later point in time.
- Now forward the subscription request to the dmi-plugins based on the incoming target cmHandles we have. ( Since we have the information that which dmi-plugin is responsible for which cmHandle , we can figure this out ).
- At this level we could have forwarded the event to multiple dedicated topics.
- DMI-Plugin
- It will have a consumer code to listen from a particular topic.
- It will translate the event so that it is able to extract the important information from the event.
- DMI-Plugin is responsible to talk to the underlying Nodes it is managing inorder to register the subscription ( i.e provide the predicate information ) NOTE : We will skip this part in the onap-dmi-plugin implementation.
- DMI-Plugin will respond back with the response as accepted / rejected. We will have a response format which will be discussed in the dedicated place.
- NCMP ( Consumer for DMI-Plugin Response )
- We should continuously be checking if the published time has elapsed for that subscription response and we don't have to wait before sending the response back to the consumer. ( possibly we can discuss a solution using Hzaelcast TTL feature )
- The incoming message will have the dmiRequestId which we can match in the map and check if the timer condition is satisfied ( i.e if the message arrives before the configured time and there are other pending requests , then we wait)
- if we contact multiple dmi plugins and all respond back within time then we collect the response from all of them and send a collective response and we dont have to wait for pre-configured time.
- if we contact multiple dmi plugins and none of them respond back within time then we respond as and when we recieve the response from them.
- if we contact multiple dmi plugins and some of them respond back then we wait for preconfigured time and collect the response. We respond back with what we have till the cutoff time and then later when we receive the
...
Overview
// End to end solution in plaintext can be put in here.
- NCMP will receive the Subscription Request from EDM in the form of an Event.
- NCMP will be responsible for the below operations. ( Consumer Code for EDM Event )
- Since NCMP already knows the structure of the incoming subscription request it will map the incoming request to java object.
- Persist the request in the subscription-registry model which we already introduced.
- NCMP ( Producer Code and Record the published time )
- Enrich the request with the additional properties and a proper dmiRequestId ( subscriptionId+subscriptionName+dmiServiceName)
- Save the dmiRequestId in the distributed map along with the current-time. ( we can call it published time ) . This will be useful at a later point in time.
- Now forward the subscription request to the dmi-plugins based on the incoming target cmHandles we have. ( Since we have the information that which dmi-plugin is responsible for which cmHandle , we can figure this out ).
- At this level we could have forwarded the event to multiple dedicated topics.
- DMI-Plugin
- It will have a consumer code to listen from a particular topic.
- It will translate the event so that it is able to extract the important information from the event.
- DMI-Plugin is responsible to talk to the underlying Nodes it is managing inorder to register the subscription ( i.e provide the predicate information ) NOTE : We will skip this part in the onap-dmi-plugin implementation.
- DMI-Plugin will respond back with the response as accepted / rejected. We will have a response format which will be discussed in the dedicated place.
- NCMP ( Consumer for DMI-Plugin Response )
- We should continuously be checking if the published time has elapsed for that subscription response and we don't have to wait before sending the response back to the consumer. ( possibly we can discuss a solution using Hzaelcast TTL feature )
- The incoming message will have the dmiRequestId which we can match in the map and check if the timer condition is satisfied ( i.e if the message arrives before the configured time and there are other pending requests , then we wait)
- if we contact multiple dmi plugins and all respond back within time then we collect the response from all of them and send a collective response and we dont have to wait for pre-configured time.
- if we contact multiple dmi plugins and none of them respond back within time then we respond as and when we recieve the response from them.
- if we contact multiple dmi plugins and some of them respond back then we wait for preconfigured time and collect the response. We respond back with what we have till the cutoff time and then later when we receive the events we will send them through.
Subscription Architecture Diagram
draw.io Diagram | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
EDM to NCMP
Subscription Create
...
Sequence Diagram
PlantUML Macro |
---|
...
Code Block | ||||
---|---|---|---|---|
| ||||
@startuml "Subsciption Create"
actor rApp as "rApp/Client"
participant DME
participant NCMP
participant DMI_PLUGIN
rApp -> DME
DME -> NCMP: 1. Incoming subscriptionCreate event
NCMP -> NCMP: 2. NCMP to persist incoming subscription request.
NCMP -> DMI_PLUGIN: 3. ncmp to forward event to relevant dmi plugin
DMI_PLUGIN -> DMI_PLUGIN: 4. Apply the requested event and respond with the status
DMI_PLUGIN --> NCMP: 5. Status of the subscriptionCreate request whether accepted/rejected/pending
NCMP --> DME: 6. Respond with the status(rejected/pending) that we received from dmi plugin
DME --> rApp
@enduml |
DME to NCMP
Subscription Create Event (Schema 1)
Code Block | ||||
---|---|---|---|---|
| ||||
topic subscription id generated by client source "SCO-9989752" specversion "1.0" type subscriptionCreated time dataschema org.onap.ncmp.cm.subscription:1.0.0 { "data": { "subscription": { topic subscription id generated by client source "SCO-9989752" specversion "1.0" type subscriptionCreated time dataschema org.onap.ncmp.cm.subscription:1.0.0 data { "data": { "subscription": { "clientID": "SCO-9989752", "name": "cm-subscription-001" }, "dataType": { "dataspace": "ALL", "dataCategory": "CM", "dataProvider": "CM-SERVICE" }, "predicates": { “targets” : [“cmHandle1”, “cmHandle2”, “cmHandle3”] # cmhandle targets "datastoreclientID": “passthrough"SCO-operational9989752", "datastore-xpath-filter"name": "//_3gpp-nr-nrm-gnbdufunction:GNBDUFunction/ cm-subscription-001" }, "dataType": { _3gpp-nr-nrm-nrcelldu:NRCellDU/ | //_3gpp-nr-nrm-gnbcuupfunction:GNBCUUPFunction// | "dataspace": "ALL", "dataCategory": "CM", //_3gpp-nr-nrm-gnbcucpfunction:GNBCUCPFunction/_3gpp-nr-nrm-nrcelldu:NRCellCU// | "dataProvider": "CM-SERVICE" }, "predicates": { //_3gpp-nr-nrm-nrsectorcarrier:NRSectorCarrier//” } } |
NCMP saves in CPS
Code Block | ||||
---|---|---|---|---|
| ||||
{ "clientID": "SCO-9989752", “targets” "subscriptionName": "cm-subscription-001" "isTagged" : "true" #optional "predicates": { "targetCmHandles":[ {"cmHandleId":"cmHandle1", "status":"pending"}, {"cmHandleId":"cmHandle2", "status":"pending"}, {"cmHandleId":"cmHandle3", "status":"pending"} ] "datastore":"passthrough-operational" } } |
// Show input and output schema
// Any logic if we want to discuss and make decision
NCMP to DMI-Plugins
: [“cmHandle1”, “cmHandle2”, “cmHandle3”] # cmhandle targets
"datastore": “passthrough-operational",
"datastore-xpath-filter": "//_3gpp-nr-nrm-gnbdufunction:GNBDUFunction/
_3gpp-nr-nrm-nrcelldu:NRCellDU/ | //_3gpp-nr-nrm-gnbcuupfunction:GNBCUUPFunction// |
//_3gpp-nr-nrm-gnbcucpfunction:GNBCUCPFunction/_3gpp-nr-nrm-nrcelldu:NRCellCU// |
//_3gpp-nr-nrm-nrsectorcarrier:NRSectorCarrier//”
}
}
"javaType": "org.onap.cps.ncmp.events.avcsubscription1_0_0.client_to_ncmp" |
NCMP saves in CPS
Code Block | ||||
---|---|---|---|---|
| ||||
{
"clientID": "SCO-9989752",
"subscriptionName": "cm-subscription-001"
"isTagged" : "true" #optional
"predicates": {
"targetCmHandles":[
{"cmHandleId":"cmHandle1", "status":"pending"},
{"cmHandleId":"cmHandle2", "status":"pending"},
{"cmHandleId":"cmHandle3", "status":"pending"}
]
"datastore":"passthrough-operational"
}
} |
NCMP to DMI-Plugins
Code Block | ||||
---|---|---|---|---|
| ||||
topic: ncmp-dmi-cm-avc-subscription-dminame1
id uuid
source "SCO-9989752"
specversion "1.0"
type subscriptionCreated
time // ncmp will generate
dataschema org.onap.ncmp.dmi.cm.subscription:1.0.0
data
{
"data":{
"subscription":{
"clientID":"SCO-9989752",
"name":"cm-subscription-001",
"isTagged":false
}, | ||||
Code Block | ||||
| ||||
topic: ncmp-dmi-cm-avc-subscription-dminame1 id uuid source "SCO-9989752" specversion "1.0" type subscriptionCreated time // ncmp will generate dataschema org.onap.ncmp.dmi.cm.subscription:1.0.0 data { "data":{ "subscriptiondataType":{ "clientIDdataspace":"SCO-9989752ALL", "namedataCategory":"cm-subscription-001CM", "isTaggeddataProvider":false"CM-SERVICE" }, "dataTypepredicates":{ "dataspace":"ALL""targets":[ {"id" : <cmhandleid>, "dataCategory":"CM", "additional-properties": ["dataProvidershape":"CM-SERVICE"circle"]}, }, {"predicatesid" :{ <cmhandleid>, "targets":[ {"cmHandle1"additional-properties": ["shape":"circletriangle"]}, {"cmHandle2": ["shape":"square"]}, {"cmHandle3 {"id" : <cmhandleid>, "additional-properties": ["shape":"trianglesquare"]} ], "datastore":"passthrough-running", "datastore-xpath-filter":"//_3gpp-nr-nrm-gnbdufunction:GNBDUFunction/_3gpp-nr-nrm-nrcelldu:NRCellDU/ | //_3gpp-nr-nrm-gnbcuupfunction:GNBCUUPFunction// | //_3gpp-nr-nrm-gnbcucpfunction:GNBCUCPFunction/_3gpp-nr-nrm-nrcelldu:NRCellCU// | //_3gpp-nr-nrm-nrsectorcarrier:NRSectorCarrier//" } } } } } "javaType": "org.onap.cps.ncmp.events.avcsubscription1_0_0.ncmp_to_dmi" |
DMI-Plugins to NCMP
Code Block | ||||
---|---|---|---|---|
| ||||
topic: dmi-ncmp-cm-avc-subscription id uuid - generated by dmi-plugins source <dmiName> specversion "1.0" type subscriptionStatussubscriptionCreatedStatus time - generated by dmi correlationid: <clientId>:<subscriptionName> dataschema org.onap.ncmp.dmi.cm.subscription:1.0.0 data { "clientId":"SCO-9989752", "subscriptionName":"cm-subscription-001", "dmiName":"<dmiName>", "subscriptionStatus":[ { id : <cmhandleid>, status : rejected |/ accepted , details : <some message> // only present for rejected }, {...} ] } "javaType": "org.onap.cps.ncmp.events.avcsubscription1_0_0.dmi_to_ncmp" |
Notes
- dmiName in Output Schema is populated from application.yml of DMI-plugin.
- DMI-plugin subscribes to the topic to consume Input Schema given in application.yml of DMI-plugin.
...
Code Block | ||||
---|---|---|---|---|
| ||||
dmi: service: name: ${DMI_SERVICE_NAME:ncmp-dmi-plugin} app: dmi: avc: subscription-topic: ${DMI_CM_AVC_SUBSCRIPTION:ncmp-dmi-cm-avc-subscription-${dmi.service.name}} |
NCMP to Client-Apps
Proposed outcome (Schema 5)
Code Block | ||
---|---|---|
| ||
topic: subscription-response id uuid - generated by NCMP source <NCMP> specversion "1.0" type subscriptionStatussubscriptionCreatedStatus 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 |
Open Question: what headers do we need?
// Draw architecture diagram
// Show input and output schema
...
"javaType": "org.onap.cps.ncmp.events.avcsubscription1_0_0.ncmp_to_client" |
Implementation proposal of DMI Response Timeout
Given that a Subscription Create Event has been received by the NCMP and that NCMP is going to forward that subscription to multiple DMI Plugins.
- The NCMP will create a new thread which will wait 30 seconds.
- The NCMP will add an entry to a hazelcast Map<String,Set<String>> with the clientID and subscriptionName combined as a key and the DMI Plugin names which the subscription has been forwarded to
- Every time a DMI responds to NCMP, NCMP persists the response. The Map entry is for the subscription is then checked
- if the subscription entry still exists in the Map, the NCMP removes the DMI Plugin name from the Set of the relevant Map entry.
- if the Set is now empty, NCMP removes the Map entry and compiles & send a full outcome response
- if the subscription entry does not exists in the Map, the NCMP compiles & sends a partial outcome response
- if the subscription entry still exists in the Map, the NCMP removes the DMI Plugin name from the Set of the relevant Map entry.
- If the Wait thread completes the 30s countdown,
- if the map entry for the subscription exists in the map the thread removes the map entry from the Map. It then sends a partial outcome response
- if the map entry for the subscription does not exist in the map, the thread does nothing
Cloud
...
Event Subscription Event
Excerpt Include CPS Events Structure CPS Events Structure
...