Versions Compared

Old Version 8

changes.mady.by.user Toine Siebelink

Saved on

compared with

New Version Current

changes.mady.by.user Toine Siebelink

Saved on

Key

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

Table of Contents

...

Out-of-scope

  1. context-type:application/problem+json. As per decision #1 this is no longer required

...


IssueNotesDecision
1Use of context-type:application/problem+json 

Toine Siebelink raised several concerns:

  1. when is a response exactly a 'problem'. Not clear for partial error-scenarios or answers like 'rejected' 
  2. context-type is simply the WRONG field to say anything about the status of the content it should only define formatting. 

 kieran mccarthy agreed during weekly stakeholder meeting will NOT be required for events (or legacy API call).
It might be used in the future 

2Scope

Scope need to be clearly defined. it could cover both existing and new  (ongoing impl) interfaces I suggest we build it up and this epic can continue in future releases. With different priorities for different user stories. 

Candidates (not a compleet list) 

  1. Async responses from (bulk) dataOperations 
  2. Async response from CM Data Notification Subscriptions
  3. Existing synchronous data requests
  4. (initial) Registration request responses

3'other' ie. undefined keys v. predefined(and documented) keysif 'other' is a key-value pair with any name the schema cannot be defined to have at least one predefined key-value in the map (retryAfter). It has to be either free for all map entries OR a defined structure! At best we can desribe the map if it is NOT defined in the schema but then we need to hardcode validation!

Csaba Kocsis retryAfter is NOT an entry in the 'other' map but a stand-alone property under correctiveAction 

...


Element

Name

Parent

Type

Mandatory/
Optional

Description

Format

(example) Value

1Headerid
StringMandatoryrandom id for cloud event header. UUID
2source
StringMandatorysource of information.
ncmp or dmi		[ncmp | dmi ]ncmp
3specversion
StringMandatorycloud event version specfixed value1.0
4type
StringMandatorytype of eventfixed value

org.onap.cps.ncmp.events.async1_0_0.DataOperationEvent

5dataschema
StringMandatorydata schemafixed valueurn:cps:org.onap.cps.ncmp.events.async:data-operation-event-schema:1.0.0
6correlationid
StringMandatoryncmp generated request if. UUID
7Payloaddata
ObjectMandatoryThe actual data payload. Details will be provided below.

8responsesdataObject[]Mandatory

An array of batch responses which contains both success and failure



9operationIdresponses[i]StringMandatory

Used to distinguish multiple operations using same handle ids



10idsresponses[i]String[]Mandatory

Id's of the cmhandles.
If success contains a single element in the list.
For errors it can contain one or more id.



11resourceIdentifierresponses[i]StringOptional

Optional 'resource path' provided by the DMI Plugin

Depends on DMI Plugin Impl.
12optionsresponses[i]Map<String,Object>Optional

Additional 'options' provided by the DMI Plugin

Depends on DMI Plugin Impl.
13statusCoderesponses[i]IntegerMandatory


14statusMessageresponses[i]StringMandatory


15resultresponses[i]ObjectOptional
application/yang-data+json
16errorInforesponses[i]ObjectOptionaladditional error information for debug and retry purposes, present in case of failure error code<name>
17messageerrorInfoStringOptional message coming from EMS or node

18correctiveActionerrorInfoObjectOptionalkey-value pairs of possible recourse action the client can take in case of error

19retryAftercorrectiveActionIntegerOptionalseconds to wait before retry
60
20othercorrectiveAction<StringMap<String,object>Optionalnon-specific key-value pairs driven by ems or node

...