We had an internal review with some of our rApp colleagues around some of the recent proposed NCMP batch interface and they came back with some valid comment.
The proposal is that we should not distinguish batch from bulk or other flavours of read/write.
The aim is to only have a single flavour of interface for read or write for clients. Therefore the proposal is to drop “batch” from the interface URL and just act toward “data” (reads/writes/actions)
Additional error (messages) response with all cm-handles that cannot be resolved, also a separate error message wil be sent for each failed DMI
11
Overlap/clash with Deutsche Telekom user story:
Jira
server
ONAP Jira
serverId
425b2b0a-557c-3c0c-b515-579789cceedb
key
CPS-1377
?!
discussed in weekly ONAP meeting the DT user story is affect CPS-Core interface (not NCMP) and the requirement is to execute a query over ALL cm-handles (cached only?!) instead of a given list of cm-handles (~anchors)
1) Agreement required on the structure of the response. Please see response structure below. 2) Does 'eventTime' field which holds the timestamp of the bulk response event, required or can it be dropped?
Code Block
title
Batch Event Headers Schema
collapse
true
{
"$schema": "https://json-schema.org/draft/2019-09/schema",
"$id": "urn:cps:org.onap.cps.ncmp.events.async:batch-event-headers:1.0.0",
"$ref": "#/definitions/BatchEventHeaders",
"definitions": {
"BatchEventHeaders": {
"description": "The header information of the Batch event.",
"type": "object",
"javaType" : "org.onap.cps.ncmp.events.async.v1.BatchEventHeaders",
"properties": {
"eventId": {
"description": "The unique id for identifying the event.",
"type": "string"
},
"eventCorrelationId": {
"description": "The request id received by NCMP as an acknowledgement.",
"type": "string"
},
"eventTime": {
"description": "The time of the event. It should be in RFC format ('yyyy-MM- dd'T'HH:mm:ss.SSSZ').",
"type": "string"
},
"eventTarget": {
"description": "The destination topic to forward the consumed event.",
"type": "string"
},
"eventSource": {
"description": "The source of the event.",
"type": "string"
},
"eventType": {
"description": "The type of the Batch event.",
"type": "string"
},
"eventSchema": {
"description": "The schema of the Batch event payload.",
"type": "string"
},
"eventSchemaVersion": {
"description": "The schema version of the Batch event payload.",
"type": "string"
}
},
"required": [
"eventId",
"eventCorrelationId",
"eventTarget",
"eventType",
"eventSchema",
"eventSchemaVersion"
],
"additionalProperties": false
}
}
}
1. Do we need to send only one response containing all the requested cm handles ? 2. Send single response for each cm handle? 3. Single response message per DMI plugin?
kieran mccarthy - Please share your inputs on the above listed questions.
15
Message format for the batch interface
some non-styandard standard headers wil need to be implemented as 'extensions' and names to be confirmed
We have had some internal discussions including with some O-RAN standards representatives and one of the outcomes is that it would be good if we aligned with the some community standards for event header definitions. IT is proposed (initially from AT&T) that we should follow Cloud Native Computing Foundation (CNCF) specification as defined in their cloudevents incubator project. More details see CPS Events Structure#CNCFCloudEventalignment
