# 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.
**Intended Audience: OpenSlice Administrators**
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.
A typical deployment across domains, involves some typical components:
The following figure shows how openslice could be used in such scenarios:
1. an OSS/BSS to allow customers access the Service Catalog and perform Service Orders,
2. a Service Orchestrator (SO) component for executing the service order workflow
3. a Network Orchestrator (e.g. Kubernetes, NFVO) or respective Resource Controllers
TMF Open APIs are primarily introduced for exposing Catalogues and accepting Service Orders, but also for implementing the East-West interfaces between the domains.
The following figure shows how OpenClice could be used in such scenarios:
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:
In OpenSlice, we use the TMF 632 Party Management model to specify external partner Organizations. Once done, external Organizations 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
This functionality is not only limited between OpenSlice instances, but can be expanded to any external OSS that utilizes TMF v4 APIs.
## Define an external partner Organization to consume services (East-West)
To define an external partner Organization, the user must possess the "ADMIN" role. The Organization management can be executed at the Services or Products Portal, under the `Manage Entities -> Organizations` tab.
When creating a new *federated* Organization, you must define an Organization Name and a Trading Name (optional). Once the Organization is created, you must define the necessary external Organization details as Characteristics for the synchronization process.
By minimum, you must define the following Characteristics:
-**EXTERNAL_TMFAPI_BASEURL**: The Organization's domain, e.g. https://portal.openslice.eu
-**EXTERNAL_TMFAPI_OAUTH2TOKENURI**: The endpoint to obtain the OAUTH2 token, e.g. https://portal.openslice.eu/auth/realms/openslice/protocol/openid-connect/token
-**EXTERNAL_TMFAPI_USERNAME**: The authentication credentials (username), e.g. admin
-**EXTERNAL_TMFAPI_PASSWORD**: The authentication credentials (password), e.g. openslice
-**EXTERNAL_TMFAPI_CLIENTREGISTRATIONID**: An Organization identifier to setup the OAUTH Client, e.g. authOpensliceProvider
-**EXTERNAL_TMFAPI_OAUTH2CLIENTID**: The OAUTH Client ID, e.g. osapiWebClientId
-**EXTERNAL_TMFAPI_OAUTH2CLIENTSECRET**: The OAUTH Client secret, e.g. secret
-**EXTERNAL_TMFAPI_OAUTH2SCOPES**: The OAUTH scopes (*must be ; separated - no space between*), e.g. admin;read
> The above Characteristics define an external Organization registration, which can be validated through the `EXTERNAL_TMFAPI_STATUS` once the partner registration process happens (HH:00 and HH:30, each hour). A successful synchronization populates the Characteristic with a similar value `ISODATE: FULLSPECS SUCCESS`, else a `NOT CONFIGURED` value appears.
**Important Note**: Although an external Organization is registered, you have to define which Service Characteristics shall be synchronized, so as for this process to make sense. Following, there are the available filtering option, all relative to the BASEURL:
-**EXTERNAL_TMFAPI_SERVICE_CATALOG_URLS**: A filter of desired Service Specifications to be synced, e.g. /tmf-api/serviceCatalogManagement/v4/serviceSpecification?type=CustomerFacingServiceSpecification (synchronizes all CFSS).
If not specified, it defaults to "/tmf-api/serviceCatalogManagement/v4/serviceSpecification", which synchronizes everything
**OR**
An organization must have the following characteristics in openslice catalog, like for example:
-**EXTERNAL_TMFAPI_SERVICE_CATEGORY_URLS**: A filter of desired Service Specifications within a Service Category, e.g. /tmf-api/serviceCatalogManagement/v4/serviceCategory/4136c0a2-1f6d-41e6-bb02-ae50c020925d (synchronizes all Service Specifications within the Service Category with the provided ID).
Once the synchronization process is successful, the filtered Service Specifications will appear in your OpenSlice instance under the Service Specifications List (`Manage Service -> Service Specifications -> List Service Specification`). You can distinguish externally synchronized Service Specifications from their description, as illustrated in the following figure.
You can now use the synchronized Service Specification into your Service bundle designs, which, when ordered, will delegate the instantiation to the the partner's Service Orchestrator, while also populating the initiator's Service Inventory.
"EXTERNAL_TMFAPI_OAUTH2CLIENTSECRET", "secret"
"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)
If a partner OSS instance is not following the above URLs, you may define custom ones during the partner Organization definition, populating the following characteristics:
"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**: The endpoint to get Service Specification information, e.g. /tmf/ServiceSpecification
-**EXTERNAL_TMFAPI_SERVICE_ORDER_URLS**: The endpoint to issue a partner Service Order, e.g. /tmf/ServiceOrder
