Frankfurt Release API Requirements Gathering Page

Service Creation ( Macro Mode )

This requirement would like to see Service Ordering capable of ordering ONAP macro mode services. See JIRA EXTAPI-258: "Macro" modeClosed for details

@Adrian OSullivan @Rene ROBERT

Service Modification

This requirements is for handling Service Modification of existing services via Service Order with Action = modify. We would need to explore do we require to supply an "updateType" enum similar to ETSI-SOL 005 update API so SO knows which workflow to call to handle the update (different update types may have different Input characteristics ), or do we just send characteristics that we want to change and let SO figure it out. For both options we would need associated Design for SO / SDC, e.g. how to we mark Inputs or Characteristics as configurable. There is also work in MEF LEGATO SDK on the use of Service Schemas, which may be applicable also to consider v use of Characteristics.

@Adrian OSullivan

TMF 633 Service Catalog - POST

Introduce POST for TMF API 633 – Service Catalog API

This requirement is for 3rd Party Operational Domain Manager use case. There is a need for Ext API to introduce POST in TMF 633 API in order to automatically upload the 3rd Party's Service Definition into ONAP SDC.

Only the consumers defined in ONAP will have access to post service specification via POST of TMF 633. Refer guiding principles on use case wiki (Controlled access to ONAP SDC Catalog) 

As part of the 3rd Party use case, we propose enhancements to SDC to expose the Service Onboarding API as an external API. That work is planned as part of SDC-2378. Once that is available, NBI will be able to upload the service definition into SDC. 

Note - SDC APIs will be built in Frankfurt, this work will come after 

@Atif Husain

@Adrian OSullivan

Supporting Service Specification ID in Service Proxy

NBI's service specification API  gets details of a single service specification which also contains the supporting resource spec details.  For a composite service in SDC (a service supported by one or more other services) , the NBI API response contains the service specification of the composite service with the supporting service shown as a supporting resource (service proxy). The service proxy details do not contain the service specification ID of the supporting service. For a BSS trying to get details about the structure of a service specification e.g. CFS as a composite service and RFS as the supporting service, in order to update its own catalog, it would be useful if it could get the supporting service specification ID. It could then get details of the supporting service specification.  We propose that the service proxy details should contain the service specification ID of the supporting service of a composite service.

@Sangeeta Nitin Bellara

@Former user (Deleted)

@Adrian OSullivan

Service Orders using "object" valuetype

The ExtAPI will need to be able to decompose the Service Order service characteristics of type "object" back into the SO APIs key value pairs. EXTAPI-294: Add support for Service Orders using new "Object" type Closed