| Table of Contents |
|---|
Overview
| Jira Legacy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
- This page gives a description of CPS events including their fields
- Events will be split into events and Headers
Issues & Decisions
...
Priyank Maheshwari will need to specify and agreed event structure for DMI AVC Event with stakeholders ie. provide Jira ticket
...
Event Body should be compatible with RFC8641
kieran mccarthy has confirmed.
Priyank Maheshwari created JIRA to create the event body schema.
...
| Table of Contents |
|---|
Overview
| Jira Legacy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
- This page gives a description of CPS events including their fields
- Events will be split into events and Headers
Issues & Decisions
| # | Description | Notes | Decision | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | No Event properties defined for DMI AVC Event | Priyank Maheshwari will need to specify and agreed event structure for DMI AVC Event with stakeholders ie. provide Jira ticket | Event Body should be compatible with RFC8641 kieran mccarthy has confirmed. Priyank Maheshwari created JIRA to create the event body schema. | ||||||||||||||||
| 2 | Bulk Operation events details have not yet be defined (just headers) | Sourabh Sourabh to provide Jira tickets |
| ||||||||||||||||
| 3 | Should all the events have same Headers | kieran mccarthy Possibly Common (base) set of headers but mandatory aspect might differ. In practice we might need a separate headers (schema?) for each event | |||||||||||||||||
| 4 | Clarify the format of the version eventSchemaVersion |
ex: 1.0.0 (without 'v') | kieran mccarthy to check ORAN preference kieran mccarthy confirms through email on to use semantic versioning which ORAN follows https://semver.org. | ||||||||||||||||
| 5 | What to do with additional event headers (from DMI Plugins) | kieran mccarthy if DMI produce additional headers NCMP will discard those i.e. not included in forwarded events | |||||||||||||||||
| 6 | Event(Content) field in DMI Async Request Response Event has inconsistent name (compared with other schemas) |
| CPS Team Create a V2 of the schema and rename eventContent as | ||||||||||||||||
| 7 | NCMP Async Request Response Event (#5) contains both an Event and ForwardedEvent | ForwardedEvent is not wrapped inside Event but question now is if we need 2 events at all?! Sourabh Sourabh and RAVITEJA KARUMURI (EST) can check how it is actually working and then we decide (create a JIRA ticket) Wiki for the Study on NCMPAsyncRequestResponse event schema Conclusion: events not designed as proposed, very inconsistent. Never go a bug because these async events aren't used at all (confirmed by Csaba Koscis) Instead bulk request wil be used for topology use cases. | kieran mccarthy and team agreed to:
| ||||||||||||||||
| 8 | Dmi Data AVC Event, use of eventSource field | Priyank Maheshwari wanted to store 'datastore' in this field but kieran mccarthy explained it to use for different purposes | kieran mccarthy Clients can use this field as per their requirements. | ||||||||||||||||
| 9 |
|
| |||||||||||||||||
| 10 | Depending #10 can schema inherit/extend a common schema for common headers | Commonly define them and then define what are mandatory(required) or optional as per the schema extending it. If a field is not used in the extended schema then it should be able to handle it. extend the POC (on #9) to cover this. Priyank Maheshwari did the POC and the conclusion of that was that :-
| Toine Siebelink agrees to go ahead with separate schema/headers per event. There will be some duplication but it will have its advantage when versioning. | ||||||||||||||||
| 11 | Is anyone using Async Request feature? | See
|
kieran mccarthy Possibly Common (base) set of headers but mandatory aspect might differ. In practice we might need a separate headers (schema?) for each event
v1 or 1.0
EX: 1.0.0 (without 'v')
kieran mccarthy to check ORAN preference
kieran mccarthy confirms through email on to use semantic versioning which ORAN follows https://semver.org.
kieran mccarthy if DMI produce additional headers NCMP will discard those i.e. not included in forwarded events
- Add V2 file
- Deprecate V1
- Support both versions for a while
- Delete the V1 version (after some time)
CPS Team Create a V2 of the schema and rename eventContent as event data. Do it as part of the schema addition.
ForwardedEvent is not wrapped inside Event but question now is if we need 2 events at all?!
Sourabh Sourabh and RAVITEJA KARUMURI (EST) can check how it is actually working and then we decide (create a JIRA ticket)
Wiki for the Study on NCMPAsyncRequestResponse event schema
Conclusion: events not designed as proposed, very inconsistent. Never go a bug because these async events aren't used at all (confirmed by Csaba Koscis) Instead bulk request wil be used for topology use cases.
kieran mccarthy and team agreed to:
Temporary disable the legacy async request feature (task created:
| Csaba Kocsis confirmed this is not used by Ericsson currently. No plans to use soon for single-cmhandle requests either (TBC). Need to decide priority (Csaba Kocsis to find out of fiXing the legacy schema(s) | ||||||||||
| 12 | Do we need additionalProperties for DMI ASync Data Request respondes (events #4, #5) | The original code populates a framework defined 'additionalProperties' field with a singel key-value pair: "response-data",{<json data>}. No other (private) properties are added either in DMI PLugin or NCMP code. The name is just coincidence and misleading. In fact this 'additionalProperties' field should NOT have been used at all! | No, the new schema should NOT add 'additionalProperties' field at all use 'additionalProperties:no' in the schema | ||||||||
| 13 | AVC Subscription Event (DMI → NCMP) (events #3) |
| kieran mccarthy this issue is now no longer relevant as the decision was to use CNCF Cloud Events instead as per decision #14 | ||||||||
| 14 | Align headers with CNCF Cloud Events | Using standard headers as defined by Cloud Events and possibly common header extension See Table below, CNFC Cloud Event alignment CPS will use Cloud Events 3PP for all current and legacy events to ensure common format | kieran mccarthyand Toine Siebelink agreed on general idea but exact list of common headers need to be agreed
|
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
Priyank Maheshwari wanted to store 'datastore' in this field but kieran mccarthy eXplained it to use for different purposes
kieran mccarthy Clients can use this field as per their requirements.
POC to follow. Jira Legacy server System Jira serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 key CPS-1657
Defining header schema.
Integration of header with kafka.
Naming and versioning convention for the header schemas. 'id'
Does the headers schema have a version too?!
Priyank Maheshwari confirmed headers can be described with a separate schema.
Both header schema's and event schemas will be published on https://docs.onap.org/projects/onap-cps/en/latest/cps-events.html
Header schema name and version will be maintained in the 'id' metadata field of header's schema .
Commonly define them and then define what are mandatory(required) or optional as per the schema eXtending it.
If a field is not used in the eXtended schema then it should be able to handle it.
EXtend the POC (on #9) to cover this.
Priyank Maheshwari did the POC and the conclusion of that was that :-
- One schema can eXtend the other schema.
- We cannot override the mandatory/optional parameter from the Parent schema.
Toine Siebelink agrees to go ahead with separate schema/headers per event. There will be some duplication but it will have its advantage when versioning.
See
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
Csaba Kocsis confirmed this is not used by Ericsson currently. No plans to use soon for single-cmhandle requests either (TBC). Need to decide priority (Csaba Kocsis to find out of fiXing the legacy schema(s)
See decision on issue #7
- Want to understand what 'data' is datatype referring to under Subscription Event?
- What value comes under 'schemaName' & 'SchemaVersion' of Datatype definition under AVC Subscription Event?
- Reconfirmation needed on 'schemaName' & 'SchemaVersion' should be in the payload?
In meeting kieran mccarthy updated #3 is ON HOLD to analyse further.
Agreed with Toine Siebelink on that Priyank Maheshwari will look into this from now as they are working on something related to this.
CPS will use Cloud Events 3PP for all current and legacy events to ensure common format
kieran mccarthyand Toine Siebelink agreed on general idea but eXact list of common headers need to be agreed
Jira (first impl.) to be added!
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
During the meeting we saw that the Header fields were prefiXed with "ce_" (or "ce0") so need to check if we are ok with that.
assume "ce_" can be used as all user of the CNCF lib will get this behavio., will check id it can be replaced with no prefiX at all.
Need to check with kieran mccarthy for way forward.
correlationid ?Meeting on Team agreed refer to CNFC doc. and add list of extensions in RTD documentation. (key and value constraints)
Meeting on Team agreed this is the way it is and Toine Siebelink will update to CPS Style section: Contribution and Development#CommonStyleConventions
Event Overview
...
cps:org.onap.cps.ncmp.events:avc-subscription-event:v1
...
cps:org.onap.cps.ncmp.events:dmi-async-request-response-event-schema:v1
...
cps:org.onap.cps.ncmp.events:ncmp-async-request-response-event-schema:v1
...
...
#1 LCM Event (NCMP → Client Apps)
Description
LCM (Life Cycle Management) Event. Sent by NCMP when the state of a CM Handle changes. For diagram see CM-Handle State Changes and Notifications Overview#Notificationhandlingincode
...
| title | LCM Event Details |
|---|
...
| |||
| 15 | During the meeting we saw that the Header fields were prefiXed with "ce_" so we need to check if we are ok with that. | assume "ce_" can be used as all user of the CNCF lib will get this behavior, will check if it can be replaced with no prefix at all. CPS Team recommend to accept this prefix and simply document that this prefer is required when filtering on kafka headers defined by CloudEvenst standard. | team agreed with kieran mccarthy to accept "ce_" prefix on serialzied CE defined headers. |
| 16 | Do will still need/ can we still use schemas for header details with CNCF library ?! | How to publish info about non-standard headers like correlationid ? | Meeting on Team agreed refer to CNFC doc. and add list of extensions in RTD documentation. (key and value constraints) |
| 17 | Inconsistent casing convention for header fields v. json data fields | Just observing. All header ion CNCF are lowercase whereas json field are camelCase. Don't want to change but want to make sure agree... | Meeting on Team agreed this is the way it is and Toine Siebelink will update to CPS Style section: Contribution and Development#CommonStyleConventions |
| 18 | Confirm 'source'. is to be added to ALL events (declared mandatory for CNFC events) | kieran mccarthy confirm is is compulsory and a value will need to be set for all event definition. in NCMP a default value of 'ncmp' can be used if no other source is applicable. Toine Siebelink will update this page were needed to add this field and default value |
Event Overview
| # | Short Name | Source | Destination | Impl. Status | Notes | Full Schema Name | Diagram Ref. |
|---|---|---|---|---|---|---|---|
| 1 | LCM Event | NCMP | Client Apps | In Use | Life Cycle Management Events, when cmHandles are added or removed | cps:org.onap.ncmp.cmhandle.lcm-event:v1 | CM-Handle State Changes and Notifications Overview#Notificationhandlingincode |
| 2 | DMI Data AVC Event | DMI | NCMP | Implemented, Not in use | Attribute Value Change in configuration management (CM) data. | cps:org.onap.cps.ncmp.events:avc-event-schema:v1 | 5 in CPS Data Notifications Overview#ComponentDiagram |
| 3 | AVC Subscription Create Event | Client | NCMP & DMIs | Implemented, Not in use | Create Event Only | cps:org.onap.cps.ncmp.events:avc-subscription-event:v1 | 7 in CPS Data Notifications Overview#ComponentDiagram |
| 4 | DMI Async Request Response Event | DMI | NCMP | In Use | DMI passes response onto Kafka topic specified by client. | cps:org.onap.cps.ncmp.events:dmi-async-request-response-event-schema:v1 | 3b → 4a in CPS-821 Spike: Support Async read-write operations on CPS-NCMP interface#ProposedDesign |
| 5 | NCMP Async Request Response Event | NCMP | Client Apps | In Use | Forward No.4 to client specified topic | cps:org.onap.cps.ncmp.events:ncmp-async-request-response-event-schema:v1 | 4b → 5 in CPS-821 Spike: Support Async read-write operations on CPS-NCMP interface#ProposedDesign |
| 6 | Bulk Response Event (Internal) | DMI | NCMP | In Progress | Internal Kafka topic | cps:org.onap.cps.ncmp.event:dmi-async-bulk-response-event-schema:v1 | 5 in CPS-1515: Spike: Support Multiple CM-Handles for NCMP Get Operation (Data operations)#BulkRequestMessageFlow |
| 7 | NCMP | Client Apps | In Progress | Forwarding the DMI responses to the client topic | cps:org.onap.cps.ncmp.event:ncmp-async-bulk-response-event-schema:v1 | 6 in CPS-1515: Spike: Support Multiple CM-Handles for NCMP Get Operation (Data operations)#BulkRequestMessageFlow |
#1 LCM Event (NCMP → Client Apps)
Description
LCM (Life Cycle Management) Event. Sent by NCMP when the state of a CM Handle changes. For diagram see CM-Handle State Changes and Notifications Overview#Notificationhandlingincode
| Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Current LCM Event Object
Type:Event (cps:org.onap.ncmp.cmhandle.lcm-event:v1)
Type:Values
|
#2 DMI Data AVC Event (ONAP DMI → NCMP)
Description
A normalized AVC Event that ONAP DMI Plugin will send to NCMP. NCMP can process the event and update cached data if needed. See 5 in CPS Data Notifications Overview#ComponentDiagram
Other DMI Plugin might snet similar events, using same headers but different payload and value for 'eventSchema' Depending on the AVC subscription details those events might or might not be forwarded to the Client Apps.
| Expand | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
AVC Event Object
(eXtension fields will be optional now)eXtension
X | Mandatory | standard (data) | N/A | N/A | The version of CNCF Specification | X | Specified by CNCF (value hardcoded)
Type: Event (cps:org.onap.cps.ncmp.cmhandle.lcmevents:avc-event-schema:v1) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Field | Type | Description | Header | Payload | Notes | cmHandleId | string | cmHandle id | X | oldValues | Values | Values that represents the state of a cmHandle | X | Defined by values object below | newValues | Values | Values that represents the state of a cmHandle | X | Defined by values object below | Type:Values
| Field | Type | Description | Header | Payload | Notes |
|---|
State of cmHandle
...
| ||||||
#3 AVC Subscription Event (DME → NCMP)
Description
A normalized AVC Event that ONAP DMI Plugin will send to NCMP. NCMP can process the event and update cached data if needed. See 5 in CPS Data Notifications Overview#ComponentDiagram
Other DMI Plugin might snet similar events, using same headers but different payload and value for 'eventSchema' Depending on the AVC subscription details those events might or might not be forwarded to the Client Apps.Subscription Event (external Clients Apps → NCMP)
Priyank Maheshwari We need to revisit this schema and include the cloud events fields. (At the moment this doesn't have proper fields)
| Excerpt | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| DMI Data
| Mandatory | standard (id) | eventCorrelationId | string | The id identifying the event | X | Optional | eXtension(correlationid) | eventTime|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
Event Object (cps:org.onap.cps.ncmp.events:avc-subscription-event |
The version of the schema that this event adheres to
:v1)
Type: Subscription
|
No Properties defined (entire event treated as single object) See open issue #1
Priyank Maheshwari This is how the event will look like.
#3 AVC Subscription Event (DME → NCMP)
Description
AVC Subscription Event (EXternal Clients Apps → NCMP) : ON HOLD - kieran mccarthy to analyze further
Priyank Maheshwari We need to revisit this schema and include the cloud events fields. (At the moment this doesn't have proper fields)
| Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subscription Event Object
| CloudEvents Mapping | version
|
|
|
|
|
|
Type: Predicates
|
|
|
The datatype content
Additional values to be added into the subscription
|
#4 DMI Async Request Response Event (DMI → NCMP)
Description
This event is for the asynchronous responses from DMI to NCMP following (synchronous) requests (from NCMP) specifying a (response) topic. See 3b → 4a in CPS-821 Spike: Support Async read-write operations on CPS-NCMP interface#ProposedDesign
| Expand | |||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||
DmiAsyncRequestResponse Event Object
string | The client ID X | name |
Field | Type | Description | Header | Payload | Notes |
isTagged | boolean | optional parameter, default is false X | default: false | Type: DataType | ||||||||||||||||||||||||||||
| Expand | |||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||
DmiAsyncRequestResponse Event Object
X | Type: Predicates | ||||||||||||||||||||||||||||||||||||||||
| Field | Type | Description | Header | Payload | Notes | targets | array | CM Handles to be targeted by the subscription | X | datastore | string | datastore which is to be used by the subscription | X | Xpath-filter | string | filter to be applied to the CM Handles through this event | X |
#4 DMI Async Request Response Event (DMI → NCMP)
Description
This event is for the asynchronous responses from DMI to NCMP following (synchronous) requests (from NCMP) specifying a (response) topic. See 3b → 4a in CPS-821 Spike: Support Async read-write operations on CPS-NCMP interface#ProposedDesign
Type: EventContent (cps:org.onap.cps.ncmp.events:dmi-async-request-response-event-schema:v1)
CloudEvents Mapping | eventID
X | standard ( | id) eventCorrelationId | string | The request id passed by NCMP X | eXtensions ( | correlationid)eventTime | string | The timestamp when original event occurred | X | standard ( | time) eventTarget | string | The target of the event | X | eXtensions ( | target)eventType | string | The type of the event | X | standard ( | type) eventSchema | string | The event schema for async request response events X | standard ( | dataschema)
eventSource | string | The source of the event | X | standard ( | source) eventContent | EventContent | The payload of an event | The name of this fields is inconsistent with all other event schemas, see issue #6 standard | (data) Type: EventContent (cps:org.onap.cps.ncmp.events:dmi-async-request-response-event-schema:v1) | |||||||||||||||||||||||||||||||||||||||||||||||||
| Field | Type | Description | Header | Payload | Notes | response-data-schema | string | The schema of response data | X | response-status | string | The status of the response | X | response-code | string | The code of the response | X | response-data | object | The data payload | X | contains payload of type object |
|---|
#5 NCMP Async Request Response Event (NCMP → Client App)
Description
This event is for the asynchronous responses from NCMP to Client Apps following (synchronous) requests (from client) specifying a (response) topic. See 4b → 5 in CPS-821 Spike: Support Async read-write operations on CPS-NCMP interface#ProposedDesign
| Expand | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
NcmpAsyncRequestResponse Event Object
|
#5 NCMP Async Request Response Event (NCMP → Client App)
Description
This event is for the asynchronous responses from NCMP to Client Apps following (synchronous) requests (from client) specifying a (response) topic. See 4b → 5 in CPS-821 Spike: Support Async read-write operations on CPS-NCMP interface#ProposedDesign
| Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
NcmpAsyncRequestResponse Event Object
Type: Event (cps:org.onap.cps.ncmp.events:ncmp-async-request-response-event-schema:v1)
CloudEvents Mapping |
id)
correlationid)
time) eventType
eXtensions ( | target)
standard ( | type)
standard ( | eventSchemaVersiondataschema)
event | Event | The payload of an event | X | Defined by event object below | standard ( | data) forwardedEvent | ForwardedEvent | The payload of a forwarded event | X | Relation to Event field unclear, do we need 2 events at all see issue #7 standard ( | data) See new proposal below
Type: forwardedEvent (cps:org.onap.cps.ncmp.events:ncmp-async-request-response-event-schema:v1)
X | Only in payload in v1 of the payload schema. To be removed in v2 version (will be in the header only)
Proposed New Schema:see
? | Can NCMP put these in the header and remove them from the 'forwardedEvent' | eventCorrelationId | string | The request id passed by NCMP ? | as above | eventTime | string | The timestamp when original event occurred | ? | as above | eventTarget | string | The target of the event | ? | as above | eventType | string | The type of the event | ? | as above | eventSchema | string | The event schema for async request response events ? | as above | eventSchemaVersion | string | The event schema version for async request response events ? | as above | eventSource | string | The source of the event ? | as above | response-data-schema | string | The received schema of response data X | response-status | string | The received status of the response X | response-code | string | The received code of the response X | response-data | object | The data payload X | contains payload of type object | Proposed New Schema:see
Type: Event (cps:org.onap.cps.ncmp.events:ncmp-async-request-response-event-schema:v1)
|
#6 Data Operation (response) Event (DMI → NCMP)
Description
Batch (data) request will always result in asynchronous events (responses) sent to the client. This event is the response from DMI to NCMP. See 5 in CPS-1515: Spike: Support Multiple CM-Handles for NCMP Get Operation (bulk / batch operations)#BulkRequestMessageFlow
| Expand | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
DmiDataOperationEvent Object
| eXtensions(correlationid) | eventTime | string | The timestamp when original event occurred | X | standard (time) | eventSource
|
|
type)
|
source)
|
|
dataschema
|
|
dataschema'data)Type: Event (cps:org.onap.cps.ncmp.events:ncmp-async-request-response-event-schema:v1)
The request id passed by NCMP
The received status of the response
The received code of the response
The data payload
#6 Batch Response Event (DMI → NCMP)
Description
Batch (data) request will always result in asynchronous events (responses) sent to the client. This event is the response from DMI to NCMP. See 5 in CPS-1515: Spike: Support Multiple CM-Handles for NCMP Get Operation (bulk / batch operations)#BulkRequestMessageFlow
...
| title | DMI Async Batch Response Event |
|---|
BatchResponseEvent Object
...
Mandatory. Generated by DMI-Plugin
...
The request id passed by NCMP
...
Optional. The timestamp should follow that on https://www.rfc-editor.org/rfc/rfc3339#section-5. This follows ISO 8601 and is what is used/referenced in 3GPP standards
Example: 1985-04-12T23:20:50.52Z this represents 20 minutes and 50.52 seconds after the 23rd hour of April 12th, 1985 in UTC.
...
The event schema for async request response events
...
The event schema version for async request response events
...
Type: Event (cps:org.onap.cps.ncmp.event.async:dmi-async-batch-response-event-schema:v1)
...
#7 Batch Response Event (NCMP → Client App)
Description
Batch (data) request will always result in asynchronous events (responses) sent to the client. This event is the response from DMI to NCMP. See 6 in CPS-1515: Spike: Support Multiple CM-Handles for NCMP Get Operation (bulk / batch operations)#BulkRequestMessageFlow
| Expand | |||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||
BatchResponseEvent Object
Type: Event (cps:org.onap.cps.ncmp.event.async:dmi-data-operation-event-schema:v1)
| |||||||||||||||||||||||||||||||||||||||||||||||||||||
#7 Data Operation (response) Event (NCMP → Client App)
Description
Batch (data) request will always result in asynchronous events (responses) sent to the client. This event is the response from DMI to NCMP. See 6 in CPS-1515: Spike: Support Multiple CM-Handles for NCMP Get Operation (bulk / batch operations)#BulkRequestMessageFlow
| Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
NcmpDataOperationEvent Object
Type: Event (cps:org.onap.cps.ncmp.event.async:ncmp-data-operation-event-schema:v1)
CloudEvents Mapping | eventID | string | The unique id identifying the event generated by DMI | X | standard ( | id) eventCorrelationId | string | The request id passed by NCMP X | eXtensions ( | correlationid)eventTime | string | The timestamp when original event occurred | X | standard ( | time) eventType | string | The type of the event | X | standard ( | type) eventSchema | string | The event schema for async request response events X | standard ( | dataschema)
dataschema'event | Event | The payload of an event | X | Java object not yet defined by schema, see issue #2 | standard ( | data) Type: Event (cps:org.onap.cps.ncmp.event.async:ncmp-async-batch-response-event-schema:v1) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Field | Type | Description | Header | Payload | Notes | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| No Properties defined (Entire event treated as single object) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CNCF Cloud Event alignment
Introduction
CNCF CloudEvents is a specification for describing event data in common formats to provide interoperability across services, platforms and systems.
- These cloud events will be applied to all the internal and eXternal events we have in CPS , NCMP and DMI Plugin.
- Cloud events will be taking care of the fields which are part of Headers or part of the actual payload (fields other than "data" are sent as Headers)
- These CNCF cloud events will be applied to all the events listed in above sections (LCM , DMI Data AVC etc.)
Library References
- https://github.com/cloudevents/sdk-java
- https://mvnrepository.com/artifact/io.cloudevents
- Examples : https://github.com/cloudevents/sdk-java/tree/main/Examples/kafka/src/main/java/io/cloudevents/Examples/kafka
Common Header Mapping
The table below shows how previously proposed headers should be mapped to pre-defined CNFC headers.
...
Before
...
After
...
eventId
...
id
...
eventSource
...
source
...
N/A
...
specversion (default 1.0)
...
eventType
...
type
...
eventTime
...
time
...
eventSchema
...
dataschema
...
Optional includes the version of the schema
...
withDataContentType()...
Optional This will be part of the eXtensions field in the cloud events and all the restrictions of the attribute field naming applies to it.
i.e these fields will be in the small case.
This is marked as optional as it only applies to some events.
...
| ||||||
CNCF Cloud Event alignment
Introduction
CNCF CloudEvents is a specification for describing event data in common formats to provide interoperability across services, platforms and systems.
- These cloud events will be applied to all the internal and external events we have in CPS , NCMP and DMI Plugin.
- Cloud events will be taking care of the fields which are part of Headers or part of the actual payload (fields other than "data" are sent as Headers)
- These CNCF cloud events will be applied to all the events listed in above sections (LCM , DMI Data AVC etc.)
Library References
- https://github.com/cloudevents/sdk-java
- https://mvnrepository.com/artifact/io.cloudevents
- examples : https://github.com/cloudevents/sdk-java/tree/main/Examples/kafka/src/main/java/io/cloudevents/Examples/kafka
Common Header Mapping
The table below shows how previously proposed headers should be mapped to pre-defined CNFC headers.
Before | After1 | CloudeEvent builder method | Example Value | Notes |
|---|---|---|---|---|
eventId | (ce_)id | .withId() | Mandatory | |
eventSource | (ce_)source | .withSource() | Mandatory | |
N/A | (ce_)specversion (default 1.0) | .v1() | 1.0 | Mandatory - This is the version of the cloud events |
eventType | (ce_)type | .withType() | Mandatory | |
eventTime | (ce_)time | .withTime() | Optional (could be Mandatory for | |
eventSchema | (ce_)dataschema | .withDataSchema() | Optional includes the version of the schema | |
| content-type2 | withDataContentType() | application/json | Optional | |
| eventCorrelationId | (ce_)correlationid | .withExtension() | Optional This will be part of the extensions field in the cloud events and all the restrictions of the attribute field naming applies to it. i.e these fields will be in the small case. This is marked as optional as it only applies to some events. | |
| event | (ce_)data | .withData(json TBC) | Mandatory actual event/payload now would be under "data" field. |
- Note 1 all cloud-event headers will be prefixed during serialization with 'ce_' (this means when filtering on serialized Kafka-headers this prefix need to be applied)
- Note 2 content-type is a a 'default' header name no 'wrapped' by CloudEvents and hence the inconsistency in names and that is does NOT have the 'ce_' prefix.
Common NCMP response staus code & message :
- Status-code 0-99 is reserved for any success response
- Status-code from 100 to 199 is reserved for any failed response.
Status Code | Status Message |
|---|---|
| 0 | Successfully applied changes |
100 | cm handle id(s) is(are) not found |
| 101 | cm handle id(s) is(are) in non ready state |
| 102 | dmi plugin service is not responding |
| 103 | dmi plugin service is not able to read resource data |