You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

References

CPS-1865 - Getting issue details... STATUS

Requirements

Functional


Interface

Requirement

Additional Information

Signoff
1CPS-E-05eNCMP will define (and publish) additional error information details to be implemented by DMI plugins
NCMP shall forward any such details where applicable


Characteristics

No specific characteristics but obviously the additional error information should not (significantly) impact existing throughput negatively.

Out-of-scope

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

Issues & Decisions


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!

Impl. Proposal

Additional Error Info Structure

  • Rows 1-13 describe the exiting data structure
  • Rows 14-18 Proposed additional (error) fields

Element

Name

Parent

Type

Mandatory/
Optional

Description

Format

(example) Value

1Headerid
StringMandatoryrandom id for cloud event header. UUID is suggested

2source
StringMandatorysource of information

3specversion
StringMandatorycloud event version specfixed value1.0
4type
StringMandatorytype of eventfixed value
5dataschema
StringMandatorydata schemafixed value
6correlationid
StringMandatory
<cmhandle-id>
7Payloaddata
ObjectMandatoryThe actual data payload. Details will be provided below.3GPP TS 28.532 standard
8responsesdataObject[]Mandatory


9operationIdresponses[i]StringMandatory


10idsresponses[i]String[]Mandatory


11statusCoderesponses[i]IntegerMandatory


12statusMessageresponses[i]StringMandatory


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

16correctiveActionerrorInfoMapOptionalkey-value pairs of possible recourse action the client can take in case of error

17retryAftercorrectiveAction<String,Int>Optionalseconds to wait before retry
"retryAfter" : 60
18othercorrectiveAction<String,object>Optionalnon-specific key-value pairs driven by ems or node
“other”: {}
  • No labels