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