Draft Casablanca (Release 3) Project Plan for ExtAPI
Project Name (from Project Proposal):
Proposed name for the project:
External API Framework
Proposed name for the repository:
externalapi
Project description (from Project Proposal):
This project will describe and define the APIs between ONAP and External Systems, including ONAP interfaces targeted on BSS/OSS, peering, B2B, etc.
Proposed initial focus may be on the Common APIs between ONAP and BSS/OSS; and Inter-Provider ONAP External APIs.
Common APIs between ONAP and BSS/OSS allow Service Providers to utilize the capabilities of ONAP using their existing BSS/OSS environment with minimal customization.
Scope of Work For Casablanca:
Deliver points of interoperability between ONAP and External Systems
Focus on ONAP External APIs to BSS/OSS (i.e., MEF Legato)
Service Catalog
Add notification for serviceCatalog API (stretch goal) EXTAPI-99: Service Catalog - notification webhookOpen
Description:
Allow BSS catalog function to receive service catalog notification as serviceSpec status change or characteristic change (new value in an enum list for example). Could be interesting to track these serviceSpec update to update accordingly productSpec
Relevance:
Complexity: Easy
Prerequisites: It requires to have a notification from SDC because NBI will not pool AAI
Resources:
Improve ServiceCatalog API for service characteristics
Description:
Expose from NBI json (or other format) file describing the serviceSpec characteristic (same type of file we can retrieve on MEF Git Hub to describe an UNISpec for example)
Convert YAML in CSAR to ONAP wide consistent JSON schema for Service Characteristic Input parameters and provide across the ServiceCatalog API
Relevance:
Complexity: Medium
Prerequisites:
Resources:
Service Ordering
Upgrade Service Request Status for serviceOrder API (Systems engineering for documenting Use Case; get service_order, status of order item; identify details of status information) (stretch goal)
Description:
Provide summary and detailed status for both Infrastructure requested VNFs and Customer requested VNFs.
Requestors that create transaction requests on the ONAP Platform, have a need to effectively manage the requests they create. The Requestor is the responsible owner for the transaction and thus, need the ability to have visibility into the status of their requests
BSS/OSS system will call the API providing one of the following options:
1.Specific Service Request ID
2.Many Service Requests based on Selection Criteria such as: Service Request Status and/or Time Frame where appropriate, (e.g., past day completions)ONAP will respond with the current status of the workflow for the selected request(s). The status can include not only a status summary of the requests but also the steps taken, start/stop time of the steps taken, notifications generated, and the remaining steps that need to be taken. Different workflows will have different numbers of steps, so this API will need to provide a name or identifier for any and all steps
Check Request status via GET {{url}}/ecomp/mso/infra/orchestrationRequests/v4/{requestId}
Check requestStatus: it must be equal to (if percentProgress not equal to 100, we’ll pooling SO till percentProgress = 100):
Relevance:
Complexity: Easy
Prerequisites: Could implement in two phases, 1st phase implement status details that are currently available in the Service Orchestration (SO) API, while the 2nd phase would enhance SO and/or the SO API with any additional status information
Resources:
Add notification for serviceOrder API EXTAPI-96: Add notification for serviceOrder APIClosed
Description:
Allow BSS (or any other) system to receive order/OrderItem update. BSS (or any other system) will not have to pool. We can allow several distinct notification (Nice to have: let subscriber specify notification contains). Minimum is to provide ServiceOrderStateChangeNotifications etc to HUB subscriber. After if we’re able to get a notification from SO it will be perfect but initial requirement is only at external API northbound
Notifications related to ServiceOrder: - ServiceOrderCreationNotification - ServiceOrderAttributeValueChangeNotification - ServiceOrderStateChangeNotification - ServiceOrderInformationRequiredNotification - ServiceOrderRemoveNotification
Relevance:
Complexity: Easy
Prerequisites: Nothing for basic deliver…SO notifications to have high performance (without SO notification, NBI will pool SO as of today)
Resources:
Update ServiceOrder to to accommodate Service Chaining. (systems engineering) (implementation stretch goal) EXTAPI-111: Update ServiceOrder to to accommodate Service Chaining.Closed
Description:
Enhance the Service Order API (TMF 641) to allow BSS/OSS the ability to flag services as part of a “group”. Enhance the Service Inventory API (TMF 638) to allow BSS/OSS to retrieve Service Inventory by “group”.
Relevance:
Complexity: Easy
Prerequisites: Service Orchestrator (SO) and its external API, A&AI and its API to SO and its external API
Resources:
Update ServiceOrder to manage Service modification request UC (basic, delete and cr