Hello everyone, and welcome to the 3rd installment on the new TSOM Visibility capabilities coming out at February 2025.
In my last blog - TSOM Discovery - inventory discovery from elements, I've focused on patterns based discovery, used to connect directly to network elements and perform discovery from them. In this blog, I'll focus on the 2nd approach, which is targeted at connecting to a Vendor EMS/NMS system (network/element management system) and performing discovery from it, basically discovering all the managed elements from this system from centralised API.
If we're looking at the overall Visibility capabilities diagram below, the previous blog was about that longer arrow to the left, showing connectivity to the network elements, while today's blog is about that shorter arrow to the right, showing connectivity to the Vendors' NMS/EMS systems:
The method we're using to accomplish this type of discovery is leveraging the Service Graph Connectors framework which is part of ServiceNow Platform foundation capabilities.
Service Graph Connectors are predefined integrations that ingest data into the Configuration Management Database (CMDB) from third-party sources (e.g., northbound APIs of EMS/NMS/Controllers, which manage various xNFs) across different network domains, while enabling a structured, telecom-model-aligned view of network resources and services. They can be used alongside any existing Service Graph Connectors, such as those for security, servers, software, monitoring, Internet of Things (IoT), and cloud.
As part of the first TSOM Visibility drop, we'll release one OOTB productized SGC, for connecting with a Nokia Alitplano NMS system, managing the PON domain of the network (this stands for Passive Optical Network, a wireline access technology used in Telecom Networks).
The Nokia Altiplano Service Graph Connector can be used to pull data from the Nokia Altiplano Access SDN Controller via REST API (through a MID Server), ensuring that the CMDB is populated with accurate, up-to-date information about physical network resources such as OLTs and ONTs, among others. This integration provides a telecom-model-aligned view of network resources and their relationships.
As future releases come out, additional OOTB productized SGCs will be delivered by ServiceNow, and partners and vendors will also develop their own SGCs, building up the eco-system and coverage. For example, as can be observed below, in the planned TSOM Discovery delivery for Feb 2025, under the SGC section, Netscout, a technology vendor, is going to provide a SGC of their own as part of the upcoming release.
Let's explore that general Discovery Architecture utilizing Service Graph Connectors by looking at the Nokia Altiplano SGC implementation:
This is an example of the implementation for the Nokia Altiplano Service Graph Connector. The architecture of other connectors may vary.
As we can see from the diagram, these are the major components used in the pipeline:
- IntegrationHub ETL (3.2)
This store app to create and manage ETL transform maps, which integrate third-party data into the CMDB or into non-CMDB tables without compromising the integrity of data. IntegrationHub ETL provides a simplified user interface that guides you through the integration process end-to-end, including a test integration run of sample data.
For more information, please see IntegrationHub ETL (3.2)
- Robust Transform Engine (RTE)
This plugin is used to transform raw source data that is stored in staging tables, into the data that is mapped and integrated into the CMDB. RTE uses ETL transform maps that were created for the integration during data transformation.
For more information, please see Robust Transform Engine (RTE)
- Mid Server
MID Server is a Java application that runs as a Windows service or UNIX daemon on a server within your local network. The ServiceNow® MID Server facilitates communication and data transfer between a ServiceNow instance and external applications, data sources, and services.
For more information, please see MiD Server
- Identification & Reconciliation Engine (IRE)
IRE offers a centralized framework for identifying and reconciling data from multiple sources. It ensures the integrity of the CMDB and some non-CMDB tables when various data sources are used to create or update CI records.
For more information, please see Identification & Reconciliation Engine (IRE)
- CMDB Compliance / Reconciliation Logic
CMDB Compliance is a toolset that enables administrators to certify CMDB data for accuracy and resolve any discrepancies found. In Telecom Reconciliation, we use this feature to discover and analyze discrepancies in the CMDB and trigger resolution workflows.
For more information on how its used for Telecom Reconciliation, please see Exploring Telecom Reconciliation.
For more information on the CMDB Compliance plugin, please see CMDB Compliance.
- TNI Entity Creation Logic
Whenever the system identifies that the customer has TNI installed, it will automatically create a TNI entity record for all network data discovered.
If TNI is installed, a payload like the one below will be added to the IRE payload for each item (with inventory_category populated based on the className😞
As a result, the discovered CI will be in both the cmdb_ci and tni_entity tables.
This is it for today. In my next blog I'll go back to direct network elements discovery and cover CLI based patterns discovery.
As always, I'll be happy to hear from anyone interested in TSOM Visibility, and putting the following reminder on call for Design Patterns for the next evolution of TSOM Visibility:
2 Comments
