Experience the power of personalized network management with CxOrchestrator. Our platform is designed to address your specific needs and deliver agile, customized solutions.
The CxO product suite is designed to automate business processes and facilitate digital order-to-cash customer journeys. It utilizes a microservices architecture, making it highly scalable and adaptable to various use cases. While the suite's microservices are exposed through TMForum open APIs, they are not limited to the telecommunications industry and can be utilized in any context that requires business process orchestration.
The CxO product suite consists of several individual products that can be deployed and integrated based on the specific needs of customers. These products include:
The CxO General module focuses on party management within the enterprise, which includes individuals or organizations involved in the business processes. Common parties in the system include B2B/B2C customers, providers, resellers, partnering organizations, and portal users. CxO General supports CRUD operations and processes related to party management, defining relationships between parties, and providing RBAC support. It also enables digital identity for portal users, integrating with IDM systems like KeyCloak, Google, or Active Directory.
The CxO General module consists of the following microservices:
This API provides standardized mechanisms for creating, updating, retrieving, and deleting parties. A party can be an individual or an organization that has any kind of relation with the enterprise. Parties are created to record information about individuals or organizations before assigning any specific role.
This API provides standardized mechanisms for customer and customer account management. It supports creating, updating, retrieving, and deleting customers and their associated accounts. A customer can be a person, an organization, or another service provider who purchases products from the enterprise. The customer management API allows the management of identification and financial information about the customer. Customers always have a relationship with the party defined in the Party Management API with a specific role type.
This API provides a standardized mechanism for defining generic relationships between parties. It is similar to the Customer Management API but is more general and applicable to parties with different roles. Party Role Management allows for defining relationship details between parties, such as resellers and the enterprise or employees with the enterprise.
This API enables the identification and authentication of parties, party roles, or resources. It allows parties, party roles, or resources (for an app) to retrieve permissions. Digital Identity is associated with a user created in the IDM (Identity Management System) and registered as a party within the enterprise. At least one credential is needed for an active digital identity, which enables identification and authentication. Digital Identity can be provided to an application to trigger interaction with other systems, such as automatically triggering an order to a supplier.
This API enables applications to request identity information about individuals using the application or to request identity-related information from the system holding such identity information. It relies on industry standards like OpenID Connect for identity information.
This API defines user roles that encompass a set of privileges for various functions and manageable assets. When a user is assigned a role, they are allocated all the privileges defined for that role type, and corresponding permissions are created for that user.
The IDM (Identity Management) component, specifically Keycloak, is used with CxO to provide authentication, authorization, and RBAC for portal users and other applications accessing the APIs. External IDMs like Google or Active Directory can also be integrated with the platform.
The TMF673 API streamlines the management of geographic addresses within an enterprise. It offers standardized procedures for creating, updating, retrieving, and deleting geographic locations, providing a systematic approach for handling spatial data associated with the organization.
The TMF674 API facilitates the standardized management of geo sites within an enterprise system. Geo sites represent specific areas like data centers or project locations. This API allows for the efficient creation, updating, retrieval, and deletion of geo sites, ensuring consistency in spatial data management for the organization.
Comprises a collection of workflows designed to facilitate common scenarios, including:
These workflows are tailored to enhance efficiency and streamline processes across various domains.
The CxO COM module represents the Commercial Order Management platform, which performs various functions related to order management, quote generation, shopping cart support, contract signing, billing and payment updates, integration with logistics or warehouse systems, and triggering equipment delivery. It also maintains real-time inventory of customer products and orders. The COM module exposes a subset of microservices via the TMForum Open APIs.
The microservices within the CxO COM module include:
This microservice enables the management of catalog elements throughout their lifecycle. It allows consultation of catalog elements during various processes such as ordering, campaign management, and sales management. The catalog contains product definitions, determines how products are offered, includes product bundle definitions, and controls the relationship between product specifications and service categories in the SOM module.
The Quote Management microservice provides a standardized mechanism for creating customer quotes with all the necessary parameters. The API interacts with other microservices within the COM module consistently. A customer quote is created based on a product offer defined in the catalog. The quote specifies the products available to the customer, including pricing, special pricing (if applicable), product options, and agreement details.
The SLA API offers a standardized interface for managing the entire life cycle of Service Level Agreements (SLAs). This encompasses various stages, including SLA negotiation, configuration, activation/enforcement, ongoing operations, and handling of SLA violations/consequences. The API serves as a crucial link between a Customer and a Service Provider, particularly one offering products with associated SLAs in its catalogue. Through this interface, customers can seamlessly discover, browse, trigger, and place orders for the specified services.
The Product Ordering microservice provides a standardized mechanism for placing product orders with all the necessary parameters. The API interacts with other microservices within the COM module consistently. A product order is created based on a product offering defined in the catalog. The product offering identifies the available products or product set for the customer, including pricing, product options, and market details. Interactions with other microservice APIs, such as Catalog, Quote, and Service Order Management, are defined in workflows and orchestrated by the Conductor engine.
The Shopping Cart microservice provides standardized functionality for managing shopping carts. It supports the creation, updating, retrieval, deletion, and event notification of shopping carts. Shopping carts are used for temporarily selecting and reserving product offerings in e-commerce and retail purchases. The cart can include both tangible and intangible goods and services. It includes a list of cart items, references to the party or party role (e.g., customer), or contact medium in case of unknown customers. The cart also calculates the total item price, including promotions.
The Product Inventory Management microservice offers a standardized mechanism for retrieving product inventory information. The API interacts with inventory systems consistently. Typically, a product is created and modified as a result of a product order, but it can also be directly modified for administrative purposes.
COM Engine contains set of workflows to support different scenarios and connect various microservices to enable backed support for eCommerce type of portals:
The CxO SOM module, which stands for Service Order Manager, is responsible for enabling network and service orchestration, controlling the order fulfillment process, managing the service catalog, services inventory, and the active and available resources of the enterprise. It also exposes eCare APIs for non-commercial operations and integrates with external OSS (Operations Support Systems) systems such as IPAM (IP Address Management), external inventory systems, RIPE (Réseaux IP Européens) for Internet resources management, and monitoring systems. Additionally, it programs network devices through SDN (Software-Defined Networking) controller's APIs.
This microservice allows the management of the entire lifecycle of service catalog elements and facilitates consultation of service catalog elements during processes like ordering. CRUD operations are supported for catalog elements, and webhook notifications can be enabled for applications using this API.
This microservice maintains a database that holds all services processed through the SOM platform or configured/delivered manually or via other platforms. It ensures consistency and standardization in querying and manipulating the service inventory. The API enables operations such as retrieving a list of stored services based on specific criteria or retrieving details of a specific service from the inventory. Service details in the inventory are updated during workflow execution for different actions/operations using the TMF640 Service Configuration API.
This microservice allows users to retrieve, create, update, and delete services. Typically, this API is not directly exposed to eCare portals but is used as a task within Service Ordering workflows. For example, when a new device is activated through a TMF641 service order, the background workflow utilizes this API to update the status of the corresponding "device" service in the service inventory database.
This microservice serves as the primary component for creating, updating, and retrieving service orders. It orchestrates service ordering workflows for asynchronous service ordering. Orders can consist of one or multiple items, each associated with a catalog service definition. Valid orders are queued, acknowledged, and then processed through workflows. These workflows encompass multiple layers, validating and processing the service order and its items. Each service definition has an associated package processor that utilizes orchestrator workers to configure network devices via SDN controllers, manage IP address inventory, read/write information from/to resource inventory, and update OSS systems. Upon completion, service reconciliation occurs, and the data is saved to Service Inventory databases. Services created through orders can be subsequently modified with additional orders or via the Service Activation Management API.
SOM Engine contains a set of workflows to support different scenarios and connect various microservices to enable service orchestration and provisioning. Main functionality of the SOM engine:
The ROM is the main enabler of the automated, real-time service and resource inventory. It represents the combination of the microservices that are able to automatically discover and persist physical and logical active resources in the network, as well as the services implemented over various sets of the resources. Typical scenarios supported in the ROM are:
This microservice provides a standardized mechanism to query and manipulate resources within the inventory. It includes the model definition and all available operations. The resource inventory database stores information about devices that comprise the enterprise/provider network, as well as available logical resources such as VLANs, RTs (Routing Tables), VPNs, etc. Services stored in the TMF638 service inventory reference resources in the TMF639 database. For instance, in the case of a B2B IPVPN service deployed on a fiber infrastructure, the service ID and characteristics are stored in TMF638. This service has a relationship with the corresponding service ID in TMF639, which describes all the resources involved in providing the service, such as devices, physical ports, VLANs used for L2 connection, MPLS VPN ID, and so on.
The TMF634 API oversees the systematic management of resource catalogs within an enterprise. It provides standardized mechanisms for creating, updating, retrieving, and deleting resources, enabling efficient organization and utilization of assets within the organization's catalog. This includes but is not limited to services, products, or any other defined resources essential to the enterprise's operations.
is a sophisticated microservice designed to streamline resource management through a comprehensive set of workflows. Within its architecture, the engine houses the core logic responsible for the intricate processes of discovering and reconciling both physical and logical resources. By orchestrating these workflows, the ROM Engine ensures a harmonious integration between the tangible infrastructure and its virtual counterpart, providing a robust foundation for efficient resource allocation, optimization, and overall system coherence.
API adapters are implemented as separate microservices, primarily customized for different customers and projects. Codaxy leverages its general knowledge and experience gained from various projects with different companies to expedite development and increase reusability. While it is not feasible to create completely generic microservices due to the varying configurations and usage of systems and applications by different companies, the accumulated experience and knowledge enable CxO to achieve a high percentage of generic solutions and minimize the need for extensive customizations in new implementations.
The integrations are divided into three groups:
These adapters facilitate connections with external IPAM, physical and logical inventory, monitoring, and alarm systems. Codaxy has implemented adapters for systems such as Infoblox, OSS10, RIPE NCC, and Cisco PCP.
These adapters connect to the APIs of various CRM systems, payment organizations, billing systems, and more. Codaxy has implemented adapters for systems like Salesforce, BPay, PayPal, and different banks.
These adapters establish connections to multivendor networks using the APIs of different SDN controllers. Codaxy has integrated CxO with systems such as Frinx Uniconfig, Nokia Altiplano, Huawei CloudOpera, Versa Director, Cisco Meraki, Axiros ACS, Genie ACS, Ruckus WiFi Controller, and Cisco NSO.
CxO contains a generic admin portal that is an integral part of the solution and used for the following purposes:
The platform includes a reference implementation of an eCommerce portal and an eCare portal. However, in most cases, customers have specific UI/UX requirements, and their environments have different use cases and scenarios. Therefore, rebranding and customization are performed for each customer implementation based on their specific needs.
Based on Codaxy's experience, in addition to the custom portals mentioned above, an additional Engineering cockpit is developed for each customer. This cockpit serves engineering and operations purposes, such as zero-touch provisioning of new network elements (PE routers, switches, OLTs), changing global configurations of network elements, ensuring security compliance, and performing link capacity upgrades.
CxO is a highly flexible and modular microservices-based solution suitable for telecom and other industries requiring digitalization and process automation. Different modules of CxO are deployed based on specific use cases and customer requirements. With its microservices architecture, the solution scales well for large service providers, as well as smaller companies with limited infrastructure and a lower volume of orders per day.