A large Telco is building an Orchestration platform to orchestrate workloads that will be deployed in their Private Cloud infrastructure and spread across multiple data centers. Their internal systems must also integrate with the platform, requiring the implementation of TMF APIs.
The Challenge
The customer’s internal environment includes a large set of systems, including Product Ordering, operations support systems (OSS), business support systems (BSS) and catalog systems that are functionally North-bound systems to the Orchestration platform. To effectively integrate these systems, the platform requires implementation of North bound Interfaces (NBI) between the Orchestration platform and those systems.
The core challenge was to ensure that requests for Customer Facing Services (CFS) are translated into necessary actions on the Resource Facing Services (RFS) or Network service instances. These instances are managed by Cloudify in the NFVi Domain to implement the required service changes.
The Aptira Solution
In order to support and enable the customer’s roadmap of transforming these IT systems and to enable seamless integration of these systems with the orchestration platform, a common API framework using standard Telemanagement Forum (TMF) APIs was proposed.
TMF defines a set of guidelines, standardizing the way IT systems interact to manage and deliver complex services such as Customer Facing Service (CFS) and Resource Facing Service (RFS). It defines a suite of APIs (based on the OpenAPI standard) that defines the specifications and data model for each type of function that is invoked by IT systems. Examples include Service Order and Activation, Service Catalog, Service Qualification.
Aptira’s design for the North Bound Interface (NBI) function was to use Google Cloud’s Apigee API Platform as the implementation platform, and to make use of its various configuration and customization capabilities. Apigee provides extensive API mapping and logging functions that they call policies. These policies can then be applied to each API call that transits through the platform. In addition to this, there are multiple options for more extensive customisation through code development.
To handle the TMF API requests from the NBI systems in the Orchestration platform, APIs were implemented in Apigee in following stages, for each TMF-specified function call that need to be handled from north bound systems:
- An API proxy endpoint is created in Apigee using the Apigee administration portal
- Security policies to enable communication between Apigee and NBI systems are configured
- A business workflow is designed by defining actions that need to be triggered based on the TMF APIs data model
- Using Apigee’s language constructs available in the developer portal, a policy is defined that extracts the parameters from the payload of the requests
- Each APIs data model is interpreted in a specific way, creating a workflow policy
For example: To initiate a Heal operation on a network service, the IT systems trigger TMF API 664 Resource Activation and Configuration by specifying the Heal action. The request payload has the following parameters:
- resourceFunction – Identifier of Network service to be healed
- healPolicy – A set of custom scripts/policy to trigger healing
- plus additional parameters
Stage 2
- Once the TMF API payload has been extracted and their parameters are interpreted (based on the workflow defined in Step 1) actions are triggered by making an API call. Apigee adds the Network identifier parameters extracted in Step 1 in the API payload to the south bound systems.
- Each NBI API call is converted into a Southbound Interface API call to the relevant system that will implement the requests. In this case, the main southbound systems were Cloudify Orchestration.
For example: the network identifier in Step 1 identifies the exact deployment instances in the underlying infrastructure environment. Apigee invokes a Cloudify API call to trigger the specific action such as Heal on the network resource.
Since all the operations are designed to be asynchronous, Apigee maintains a transaction state and waits for a response from Cloudify for a completion of the heal action. Once the heal action is completed, a response is sent back to the originating Northbound API using the same API proxy endpoint.
The Result
Utilising Apigee’s API translation mechanism, we were able to demonstrate all the customer use cases that involve NBI system integration with the platform.
The following TMF APIs were implemented:
- TMF 641 Service Activation and Ordering
- TMF 633 Service Catalog
- TMF 664 Resource Function Activation and Configuration
As a result of this exercise, API developers now have a better idea of the extensive set of constructs in Apigee which APIs can be built to develop applications across any technology domain.
OTHER APIGEE CASE STUDIES
- Apigee Case Study 1: Apigee Service Orchestration and Integration
- Apigee Case Study 2: Apigee: On Prem Vs SaaS
- Apigee Case Study 3: Apigee Central Logging
- Apigee Case Study 4: Implementing TMF APIs in Apigee
- Apigee Case Study 5: Apigee Generic API Translation
