References

• CPS Exceptions and REST APIs HTTP Response Codes 

CM Handle Registration Request Payload

{
  "dmiPlugin": "my-dmi-plugin",
  "dmiDataPlugin": "my-dmi-data-plugin",
  "dmiModelPlugin": "my-dmi-model-plugin",
  "createdCmHandles": [
    {
      "cmHandle": "my-cm-handle",
      "cmHandleProperties": {
        "additionalProp1": "my-property",
        "additionalProp2": "my-property",
        "additionalProp3": "my-property"
      },
      "publicCmHandleProperties": {
        "additionalProp1": "my-property",
        "additionalProp2": "my-property",
        "additionalProp3": "my-property"
      }
    }
  ],
  "updatedCmHandles": {
    "cmHandle": "my-cm-handle",
    "cmHandleProperties": {
      "add-my-property": "add-property",
      "update-my-property": "updated-property",
      "delete-my-property": null
    },
    "publicCmHandleProperties": {
      "add-my-property": "add-property",
      "update-my-property": "updated-property",
      "delete-my-property": null
    }
  },
  "removedCmHandles": [
    "[\"my-cm-handle1\",\"my-cm-handle2\",\"my-cm-handle3\"]"
  ]
}

Proposed Changes

As we are using a common payload to handle the Create , Update and Remove operation hence there is a need to streamline the response code in case of successful execution of the request.

For other scenarios , please refer to the page for the exceptions and response codes which will remain as is.

Code Change

	@Override
    public ResponseEntity<Void> updateDmiPluginRegistration(
            final @Valid RestDmiPluginRegistration restDmiPluginRegistration) {
        final DmiPluginRegistration dmiPluginRegistration = convertRestObjectToJavaApiObject(restDmiPluginRegistration);
        networkCmProxyDataService.updateDmiRegistrationAndSyncModule(dmiPluginRegistration);
        return new ResponseEntity<>(HttpStatus.NO_CONTENT);
    }

Project Common Name: 

Project Overview:

Project description:

Scope:

• In Scope: 
• Out of Scope: 
• Features / functionality being developed: 
  • 1st release content:
  • 2nd release content:
  • 3rd release content:
• New interface/API specifications proposed: 

Architecture Alignment:

• Architectural Fit

  • How does this project fit into the rest of the ONAP Architecture?
  • Architecture diagram of your project: 
  • What upstream ONAP projects does this project depend on? 
  • What downstream ONAP projects are expected to leverage this project?
  • Project & Component Overlay:  

• Interoperability  

  • SDO specifications supported: 
  • APIs/Interfaces:
  • Information/data models:
  • If there is an existing ONAP project that does something similar to this project explain why this being a new stand-alone project?

• Other Dependencies

  • Upstream open source projects: 
  • Non ONAP APIs/Interfaces:
  • Specific IDE integration requirements:
  • Integration Testing: 
  • etc.

Community Alignment:

• Vendor Neutrality: 
• Seed code Location (if any):  
• If "In-House" please answer the the following questions:
  • How long before the seed-code could be made available to the community in a public repository? 
  • Has contribution of the code already been approved by your executive leadership and IPR counsel?
  • Have all proprietary trademarks, logos, product names and internal company secrets been removed from the code base already?
• Would any waivers to ONAP policies (including IPR) be required by this project? 
• Plan for providing education to onboard the ONAP developer community : 

Jira Information:

...

Facts

...

Info

...

Release Components: (add/delete rows as necessary)

...

Component Name

...

Repository name

...

Component Description

Resources committed to the project: (add/delete rows as necessary)

...

Role

...

Name (use @ macro)

...

Linux Foundation ID

...

Email Address

...

Location

...