OpenCAPIF Release 0 documentation

site

# Frequently Asked Questions (FAQ)

### Does the user have to develop the 3 elements of the provider (AEF, AMF and APF)?

No, you only have to make the request to the "/onboarding" endpoint. In it you must specify a CSR for the AEF, APF and AMF and you will receive the certificates for each of them in the response.

### There is one party that publishes the API and another that exposes it, what is the difference?

There are different services, the APF, intended for publishing the APIs, and the AEF, intended so that the invoker can call it. The APF is what connects to the Capif Core Function to publish the service and when the service is up, you need the AEF service so that invokers can connect to it.

### Before publishing an API, do you have to be registered in CAPIF?

Yes, before publishing an API you must register using the POST /register endpoint.

### Where is the registration done?

Registration is done in a REST API outside of the CAPIF specification taht we have implemented.

### Is the username and password chosen by the user when registering or is it assigned when requesting registration to CAPIF public instance?

When you make the request to the "/endpoint" of register, you will be returned a username and a password determined by CAPIF.

### What is a CSR?

A CSR is a Certificate Signing Request. It is a generated data block where the certificate is planned to be installed and contains key information such as public key, organization, and location, and is used to request a certificate from a certificate authority (CA). In CAPIF, 3 CSRs are necessary to register a provider, for AEF, APF and AMF.

### When doing the register_provider where can I find the CSRs that are generated?

When using the "register_provider" command, if you add the "debug" option, it shows you a json with the data used to register the provider. There we can find in the body a list of 3 elements corresponding to AEF, APF and AMF. IN each of them, the apiProbPubKey field corresponds to the CSR.

### How to use the example client (CAPIF_INVOKER_GUI)?

First you have to make a "./run.sh host:port" indicating the address of the public CAPIF. Once the Docker containers are up, you have to do a "./terminal_to_py_netapp.sh" and then a "python main.py". At this point we will find ourselves in a console with some predefined commands to use the Client. If we press tab twice it will bring up the list of available commands.

### Where is the CAPIF public instance located?

The CAPIF public instance can be found at the following URLs:

- capif.mobilesandbox.cloud:37211 (HTTPS)

- capif.mobilesandbox.cloud:37212 (HTTP)

### Do you have to publish 3 APIs? one for each instance?

No, you only have to publish a single API but each component is responsible for a specific service, whether publishing or exposing.

### Once the API is published, is it always active? Or do you have to republish it every time you want to use it?

It is better to unsubscribe the API every time you exit the application since otherwise it could be republished and it would be double.

### Would the same username and password be valid for different invokers?

Yes, a user can have multiple invokers at the same time, and as such, the username and password would be the same.

### What is the notfication destination field in the register_invoker request?

This is the callback URL used to notify events. CAPIF has an Event service to subscribe to that notifies actions such as a subscription to an API, a change in the state of an API...

### Is the notification_destination a required field in the register_invoker

No, it is not mandatory, but if you do not enter it you will not receive any CAPIF events. For example, the APF may delete the API, you will not be notified that the API is no longer available.

### What is the purpose of the "discover_service" function in the invoker client?

The discover_service returns a json with all the services that exist exposed in CAPIF at that moment.

### What is the purpose of the "get_security_auth" function in the invoker client?

Sirve para pedir el token o para refrescarlo en caso de que haya caducado. You have to use that token to call the API from the invoker.

### What is the purpose of the "register_security_context" function in the invoker client?

To consume the API it is necessary to have a Security Context registered with the data and the authentication method.

### Is a user the same as an exposer?

No, a user registers in CAPIF and once done can have the role of invoker, provider or both.

### Where can I put my endpoint?

You have to set your endpoint when doing the "publish_service" functionality:  

    ```

    publish_service capif_ops/config_files/service_api_description_hello.json

    ```

In the file "service_api_description_hello.json" you configure the service that is going to be exposed and by developing one to suit you, you expose your API.

# Architecture

Openslice offers the following main functionalities:

* Service Catalog Management: A CSP will have the ability to manage the Service Catalog Items, their attributes , organize in categories and decide what to make available to Customers

* Services Specifications: A CSP will be able to manage Service Specifications

* Service Catalog Exposure: A CSP will be able to expose catalog to customers and related parties

* Service Catalog to Service Catalog: Openslice able to consume and provide Service Catalog items to other catalogs

* Service Order: The Customer will be able to place a Service Order

* Service Inventory: The Customer and Provider will be able to view deployed Services status

The following figure displays the overall architecture of Openslice.

[![Openslice  architecture](../images/architecture.png)](../images/architecture.png)

Openslice allows Vertical Customers browsing the available offered service specifications. It consists of:

* Web frontend UIs that consist of mainly two portals: i) a NFV portal allowing users self-service management and onboarding VNFDs/NSDs to facility’s NFVO ii) a Services Portal, which allows users to browse the Service Catalog, Service Blueprints specifications and the Service Inventory

* An API gateway that proxies the internal APIs and used by the web front end as well as any other 3rd party service

* A Message Bus where all microservices use it to exchange messages either via message queues or via publish/subscribe topics

* An authentication server implementing Oauth2 authentication scheme

* A microservice offering TMF compliant API services (eg Service Catalog API, Service Ordering APIetc)

* A microservice offering NFV API services (eg VNF/NSD onboarding etc) and allows to store VNFDs and NSDs in a catalog

* A microservice that is capable to interface to an issue management system. For example it raises an issue to all related stakeholders (CSP, NOP, CSC) that a new Service Order is requested

* Central logging microservice that is capable to log all distributed actions in to an Elasticsearch cluster

* A Service Orchestrator solution that will propagate Service Ordering requests to the equivalent SOs and NFVOs 

The following figure depicts how Openslice microservices are deployed

[![Openslice microservices network deployment](../images/microservices_network_deployment.png)](../images/microservices_network_deployment.png)

## Deploying Openslice in multi domain scenarios

A typical deployment across domains, involves today some typical components: i) an OSS/BSS to allow customers access the service catalog and perform service orders, ii) a Service Orchestrator (SO) component for executing the service order workflow, as well as iii) a Network Functions Virtualization Orchestrator (NFVO) for configuring the iv) network resources.

TMF Open APIs are introduced not only for exposing catalogues and accepting service orders, but also implementing the East-West interfaces between the domains, fulfilling also the LSO requirements as introduced by MEF.

The following figure shows how openslice could be used in such scenarios:

[![Openslice  multi-domain-architecture](../images/multi-domain-architecture.png)](../images/multi-domain-architecture.png)

See more [Consuming Services From External Partner Organizations](./consumingServicesFromExternalPartners.md)

# Central Logging

Openslice follows the centralized log management concept, i.e. a type of logging solution system that consolidates the log data from different services and pushes it to a central, accessible and easy-to-use interface. 

For that reason, Elasticsearch is elected as an open-source centralized logging solution for collecting, parsing and storing logs towards a real-time data analytics tool that provides insights from any type of structured and unstructured data source.

 No newline at end of file

# Consuming Services From External Partner Organizations

A typical deployment across domains, involves today some typical components: i) an OSS/BSS to allow customers access the service catalog and perform service orders, ii) a Service Orchestrator (SO) component for executing the service order workflow, as well as iii) a Network Functions Virtualization Orchestrator (NFVO) for configuring the iv) network resources.

TMF Open APIs are introduced not only for exposing catalogues and accepting service orders, but also implementing the East-West interfaces between the domains, fulfilling also the LSO requirements as introduced by MEF.

The following figure shows how openslice could be used in such scenarios:

[![Openslice  multi-domain-architecture](../images/multi-domain-architecture.png)](../images/multi-domain-architecture.png)

In Openslice we can consume services from 3rd parties via Open APIs.

We use the TMF 632 Party Management model to specify Organizations that we can exchange items and other information such as:

- Import Service Specifications

- Create a Service Order

- Use the Service Inventory to query the status of the service ordered to the external partner organization

## Define an Organization as 3rd party to consume services East-West 

An organization must have the following characteristics in openslice catalog, like for example:

"EXTERNAL_TMFAPI_BASEURL", "http://portal.openslice.io"

"EXTERNAL_TMFAPI_CLIENTREGISTRATIONID", "authOpensliceProvider"

"EXTERNAL_TMFAPI_OAUTH2CLIENTID", "osapiWebClientId"

"EXTERNAL_TMFAPI_OAUTH2CLIENTSECRET", "secret"

"EXTERNAL_TMFAPI_OAUTH2SCOPES", scopes

"EXTERNAL_TMFAPI_OAUTH2TOKENURI", "http://portal.openslice.io/osapi-oauth-server/oauth/token"

"EXTERNAL_TMFAPI_USERNAME", "admin"

"EXTERNAL_TMFAPI_PASSWORD", "openslice"

"EXTERNAL_TMFAPI_SERVICE_CATALOG_URLS" = "/tmf-api/serviceCatalogManagement/v4/serviceSpecification?type=CustomerFacingServiceSpecification" (this is optional, fetch a list of service specs it will be relative with the BASEURL. If the url is empty then no specs will be fetched, the EXTERNAL_TMFAPI_SERVICE_CATEGORY_URLS might be used)

"EXTERNAL_TMFAPI_SERVICE_CATEGORY_URLS" = "/tmf-api/serviceCatalogManagement/v4/serviceCategory/{categoryid}" (this example will fetch all specs in a category. You may define comma separated URLs of categories API URL . This will  fetch  specifications of every defined category. If you want only one specific category put for example the uuid only of one category: "/tmf-api/serviceCatalogManagement/v4/serviceCategory/bda02821-bc4d-4bd6-b64b-d9c2aa5f8e6d". multiple urls should be "/tmf-api/serviceCatalogManagement/v4/serviceCategory/bda02821-bc4d-4bd6-b64b-d9c2aa5f8e6d,/tmf-api/serviceCatalogManagement/v4/serviceCategory/9b6d8bf3-abd2-43c4-8154-c8c6fe5545b2")

"EXTERNAL_TMFAPI_SERVICE_SPEC" = "/tmf-api/serviceCatalogManagement/v4/serviceSpecification"

"EXTERNAL_TMFAPI_SERVICE_ORDER_URLS"= "/test/v1/serviceorder" (this is optional)

An example Organization defined example in json:

```

{

  "uuid": "1a09a8b5-6bd5-444b-b0b9-a73c69eb42ae",

  "@baseType": "BaseEntity",

  "@schemaLocation": null,

  "@type": null,

  "href": null,

  "name": "Openslice.io",

  "id": "1a09a8b5-6bd5-444b-b0b9-a73c69eb42ae",

  "isHeadOffice": null,

  "isLegalEntity": null,

  "nameType": null,

  "organizationType": null,

  "tradingName": null,

  "contactMedium": [],

  "creditRating": [],

  "existsDuring": null,

  "externalReference": [],

  "organizationChildRelationship": [],

  "organizationIdentification": [],

  "organizationParentRelationship": null,

  "otherName": [],

  "partyCharacteristic": [

    {

      "uuid": "3a2f7221-e0a2-4a6b-88d1-534c8e1963f6",

      "@baseType": "BaseEntity",

      "@schemaLocation": null,

      "@type": null,

      "href": null,

      "name": "EXTERNAL_TMFAPI_CLIENTREGISTRATIONID",

      "valueType": null,

      "value": {

        "value": "authOpensliceProvider",

        "alias": null

      }

    },

    {

      "uuid": "c24bb527-f178-4d38-9b93-2027c1732876",

      "@baseType": "BaseEntity",

      "@schemaLocation": null,

      "@type": null,

      "href": null,

      "name": "EXTERNAL_TMFAPI_USERNAME",

      "valueType": null,

      "value": {

        "value": "admin",

        "alias": null

      }

    },

    {

      "uuid": "27e45df8-414b-44c6-a5d5-3f064e2cfd3b",

      "@baseType": "BaseEntity",

      "@schemaLocation": null,

      "@type": null,

      "href": null,

      "name": "EXTERNAL_TMFAPI_PASSWORD",

      "valueType": null,

      "value": {

        "value": "openslice",

        "alias": null

      }

    },

    {

      "uuid": "e0e470b8-6024-4014-8a18-2333e5465ce1",

      "@baseType": "BaseEntity",

      "@schemaLocation": null,

      "@type": null,

      "href": null,

      "name": "EXTERNAL_TMFAPI_OAUTH2CLIENTSECRET",

      "valueType": null,

      "value": {

        "value": "secret",

        "alias": null

      }

    },

    {

      "uuid": "3e0de762-ac80-4c1e-a0a1-f265ff0899b4",

      "@baseType": "BaseEntity",

      "@schemaLocation": null,

      "@type": null,

      "href": null,

      "name": "EXTERNAL_TMFAPI_OAUTH2SCOPES",

      "valueType": null,

      "value": {

        "value": "admin;read",

        "alias": null

      }

    },

    {

      "uuid": "0bbb8314-f7f2-420d-9fed-ba054b15f886",

      "@baseType": "BaseEntity",

      "@schemaLocation": null,

      "@type": null,

      "href": null,

      "name": "EXTERNAL_TMFAPI_OAUTH2TOKENURI",

      "valueType": null,

      "value": {

        "value": "http://portal.openslice.io/osapi-oauth-server/oauth/token",

        "alias": null

      }

    },

    {

      "uuid": "3a567de4-79eb-4006-a500-3e5229b44175",

      "@baseType": "BaseEntity",

      "@schemaLocation": null,

      "@type": null,

      "href": null,

      "name": "EXTERNAL_TMFAPI_OAUTH2CLIENTID",

      "valueType": null,

      "value": {

        "value": "osapiWebClientId",

        "alias": null

      }

    },

    {

      "uuid": "6dca729f-dbe1-46b7-89f1-5c4f9fe89d4e",

      "@baseType": "BaseEntity",

      "@schemaLocation": null,

      "@type": null,

      "href": null,

      "name": "EXTERNAL_TMFAPI_BASEURL",

      "valueType": null,

      "value": {

        "value": "http://portal.openslice.io",

        "alias": null

      }

    }

  ],

  "relatedParty": [],

  "status": null,

  "taxExemptionCertificate": []

}

```

 No newline at end of file