Integrating BMC Helix Discovery with BMC Helix CMDB

Key benefits of the integration:

• Provides real‑time visibility into infrastructure and service dependencies.
• Reduces manual effort by automatically populating and updating CIs.
• Improves incident and problem resolution through clear impact paths.
• Strengthens change management with dependable service models and risk insights.
• Increases data quality for compliance, reporting, and audits.
• Supports better operational decision‑making through consistent, trustworthy data.

Infrastructure discovery scope

The infrastructure discovery scope defines which locations, networks, and cloud platforms BMC Helix Discovery must scan. When new regions, platforms, or environments are added, the scope is updated so that BMC Helix Discovery continues to scan everything in the environment. This ensures that all in-scope systems are discovered and that BMC Helix CMDB is populated with accurate, up-to-date configuration data.

The following table shows an example list of colocation sites and cloud platforms included in the defined infrastructure discovery scope:

Service blueprints for multi‑instance modeling

Service blueprints use BMC Helix Discovery rules and predefined templates to build accurate, multi-instance service‑dependency models across Kubernetes environments. They identify service components, assemble service topologies, and synchronize these models with BMC Helix CMDB.

Service blueprint capabilities

• Identifies ITSM, HSSO, and ITOM service components.
• Analyzes namespaces, workloads, and pod relationships.
• Correlates pods with Deployments and StatefulSets.
• Identifies dependencies such as load balancers, messaging layers, storage systems, and caches.
• Supports consistent service modeling across Kubernetes clusters.

For more information about service blueprints, see Creating blueprint definitions

• BMC Helix Discovery is deployed and configured to scan the Kubernetes environment.
• Kubernetes clusters are onboarded with valid credentials.
• Naming conventions follow blueprint requirements.
• External components such as load balancers, databases, messaging services, and identity providers are included in the Discovery scope.
• Service blueprint packages are imported and activated.
• BMC Helix CMDB synchronization is enabled.

Once these requirements are met, you can start creating the service blueprints required for multi‑instance modeling. The examples below provide reference models for different services and illustrate how these blueprints can be structured.

ITSM Business Services model

The following diagram illustrates the reference Information Technology Service Management (ITSM) Business Services model running in a Kubernetes environment:

This model generates an accurate topology of ITSM service components and their dependencies within the Kubernetes cluster, supporting clear service understanding and effective operational management.

HSSO Business Services model

The following diagram illustrates the reference Helix Single Sign-On (HSSO) Business Services model running in a Kubernetes environment.

This model generates a unified topology of HSSO service components and their cross‑cluster dependencies, providing an accurate representation of how HSSO services operate within highly available, distributed Kubernetes environments.

ITOM Business Services model

The following diagram illustrates the reference Information Technology Operations Management (ITOM) Business Services model running in a Kubernetes environment:

This model generates a detailed topology of ITOM service components and their dependencies, providing an accurate view of how ITOM workloads operate within a microservices‑driven Kubernetes environment.

How BMC Helix Discovery determines and enriches location information

BMC Helix Discovery assigns and enriches location information by using metadata from components. It evaluates attributes in a prioritized sequence and applies fallback logic when primary attributes are unavailable. This approach ensures consistent location coverage across on‑premises, cloud, and Kubernetes environments.

Custom TPL patterns analyze each component, select the most reliable source of location data, and create or update the corresponding Location node. This approach provides reliable visibility into where your infrastructure runs, enabling accurate service modeling in BMC Helix CMDB.

Location discovery patterns 

Location discovery patterns run whenever a component is created or confirmed. They evaluate the available metadata, determine the correct location, and maintain the relationship as the environment changes. This real‑time processing keeps location information accurate throughout the component lifecycle and helps ensure that service models remain reliable and current.

The following table lists the patterns used to assign and maintain location information for different component types:

Location discovery methods with prioritized fallback

Location discovery patterns use a structured, priority approach to determine the most accurate location for Kubernetes resources. Each method is evaluated in sequence, starting with the most reliable metadata. If a method cannot produce a valid result, BMC Helix Discovery moves to the next method. 

This approach helps you maintain accurate location information across different Kubernetes deployments. You can continue using your existing tagging standards, annotations, or infrastructure metadata while BMC Helix Discovery assigns each component a location by using the best information available.

• Add the subnet‑to‑location mappings that BMC Helix Discovery will evaluate during this method.
• Verify that each CIDR range is paired with the correct location name to support accurate assignment.
• Keep subnet definitions current so BMC Helix Discovery can reliably match IP addresses to the correct location.

The following methods are used in this prioritized fallback process. Method 1 is the most commonly used and recommended approach; however, you can use other methods if you do not receive accurate location information.

Method 1: Subnet-based location mapping (primary method)

This method assigns a location by matching the component’s IP address to predefined subnet ranges. BMC Helix Discovery extracts the subnet, checks it against configured CIDR blocks (for example, /16 or /24), and returns the mapped location when a match is found. This method is the most accurate because it uses stable, infrastructure‑defined network boundaries.

Method 2: Scanned endpoint location (Fallback #1)

If the device IP address does not resolve to a location, the pattern evaluates the DiscoveryAccess endpoint by using the same subnet‑based logic as Method 1. BMC Helix Discovery attempts a /16 match first, then a /24 match.

Method 3: Cloud region extraction from virtual machines (Fallback #2)

If subnet‑based methods do not return a location, the pattern derives the location from the VM’s cloud region. It traverses the cloud service hierarchy to identify the cloud provider and region, then combines them into a standardized location identifier.

Method 4: Cloud region extraction from clusters (Fallback #3)

If VM‑based region extraction is not applicable, the pattern derives the location from the cluster’s cloud region by using the same provider‑region hierarchy.

Cluster-specific location discovery

Cluster‑specific location discovery provides a structured approach for determining and assigning locations to Kubernetes and cloud‑hosted cluster resources. This logic is used when cloud provider metadata is missing, incomplete, or inconsistent, and when additional fallback mechanisms are required.

The discovery patterns evaluate multiple metadata sources associated with the cluster, its nodes, and its workloads, applying them in a prioritized sequence to derive the most reliable location value. This approach ensures consistent mapping across on‑premises, hybrid, and cloud‑managed Kubernetes environments, including those that rely on custom labels or naming conventions.

The following methods are used to determine and assign locations during this cluster‑specific fallback process:

Method 1: Cluster URL parsing

If cloud provider metadata is unavailable, the pattern attempts to extract location information from the cluster API URL. It evaluates multiple subnet lengths (for example, /16 and /24) to identify a matching entry in the subnet‑to‑location lookup table.

Method 2: Name based location extraction

As a final fallback, the pattern can infer a location from cluster naming conventions.

Location data priority rules

The following table outlines the prioritized methods used to determine location data. Each method is evaluated in sequence, and the first method to provide a valid location is used:

The following examples show how the priority rules are applied during different discovery scenarios:

Location assignment and linkage

After the pattern determines the most accurate physical or logical location for the Kubernetes resource, it creates or retrieves the corresponding Location node and establishes the appropriate relationships. The pattern normalizes the location value, ensures that only one authoritative Location node exists for that identifier, and updates any previous relationships. As a result, BMC Helix CMDB always reflects the resource’s current placement.

Key technical features supporting the location discovery methods

The following table lists the technical capabilities that support the location discovery methods and ensure that each method and its fallback logic operate reliably and consistently across diverse environments:

Benefits of the prioritized fallback method

The following table lists the benefits of the prioritized fallback approach and how it improves the accuracy and reliability of location resolution across diverse environments:

Host and cluster location enrichment in BMC Helix CMDB

BMC Helix Discovery uses TPL syncmapping patterns to enrich Configuration Items (CIs) with structured, multi‑layered location metadata. These patterns transform raw location inputs, such as tags, codes, or cloud metadata, into meaningful attributes.

This enrichment makes sure that BMC Helix CMDB accurately reflects where hosts, clusters, and related infrastructure components reside and how they align with your organizational structure.

Four-phase location enrichment model

The enrichment process follows a structured four‑phase model that transforms cryptic location identifiers into normalized, relational data within BMC Helix CMDB.

Phase 1: Data population and attribute enrichment

In the initial phase, BMC Helix Discovery takes the raw location identifiers discovered on hosts or clusters, such as site codes, region tags, or cloud metadata, and enriches them with meaningful attributes.

Each discovered location key is mapped to a set of standardized attributes, including:

• Region (for example, Americas West, APAC, EMEA East)

• Site (Location identifier/key)

• Site Group (Cloud provider or facility type)

• City (Physical city name)

This allows BMC Helix CMDB to receive a complete and standardized set of attributes, even if a host reports only a minimal or cryptic location tag.

Location mapping table

TPL patterns use the following lookup tables to translate location keys into enriched attributes:

Phase 2: Physical Location CI creation

In this phase, for each discovered host or cluster with valid location data, a corresponding BMC_PhysicalLocation CI is created or updated with enriched attributes. The following syncmapping example shows how enriched location attributes are applied to hosts during CI creation.

Phase 3: Configuration Item (CI) attribute augmentation

In this phase, discovered CIs are enriched with location attributes directly, enabling filtering, reporting, and analysis without requiring traversal to Physical Location CIs. The following example shows how location metadata is applied to CIs during attribute augmentation.

Phase 4: Cluster location enrichment

This phase aligns cluster‑level CIs with the same regional, site, and organizational attributes used for hosts, enabling unified reporting, dependency mapping, and operational analysis. The following example shows how location attributes are applied to cluster CIs during enrichment.

Key technical features in the four‑phase model

The following table lists the technical features that support the four‑phase enrichment model by standardizing how location data is retrieved, normalized, and mapped to BMC Helix CMDB CIs:

Data flow summary

The following example shows how location information moves through the enrichment process, from initial discovery to BMC Helix CMDB updates.

Benefits of the four-phase location enrichment model

This model ensures that all discovered infrastructure assets are accurately mapped to their physical and organizational locations.

The table below summarizes the key benefits of the four‑phase enrichment approach and how it improves the accuracy, consistency, and usability of location data across BMC Helix Discovery and BMC Helix CMDB:

Configuring the BMC Helix Discovery dataset in BMC Helix CMDB

Configuring the BMC.HELIX.DISCOVERY dataset ensures that BMC Helix Discovery standardizes and protects incoming data, which in turn strengthens BMC Helix CMDB accuracy, consistency, and overall data quality. 

This configuration ensures that incoming CIs align with the BMC Helix CMDB data model and reconcile cleanly with other data sources. It also preserves the data quality required to support dependable service models, accurate reporting, and sound operational decision‑making.

To configure the discovery dataset, perform the following steps:

1. Select ITSM Mid‑Tier Applications → Atrium Core → Configuration Manager Dashboard → Configurations → Manage Normalization Rules → Data Set Configurations.
2. Locate BMC.HELIX.DISCOVERY.
3. Select Edit to open the dataset configuration panel.
4. Enable the following options by selecting their corresponding checkboxes:
   • Name and CTI Lookup
   • Enable Normalization
   • Preserve Manual Edits
   • Suite Rollup
5. Click Save.

Product catalog integration

BMC Helix Discovery continuously identifies new products and versions. To make sure this information is classified correctly, the Product Catalog is kept up to date. A current catalog allows CIs sourced from BMC Helix Discovery to map correctly to the appropriate manufacturer, product family, and version, improving reporting accuracy, compliance tracking, and service modeling.

Key activities for maintaining an effective Product Catalog

Maintaining the Product Catalog requires ongoing activity to ensure that BMC Helix Discovery data remains normalized, classified, and aligned with organizational standards. The following activities keep the catalog accurate and reliable:

• Add new Products and Product Versions detected in the BMC Helix Discovery dataset.
• Verify that new catalog entries are associated with the correct Company to maintain alignment with organizational structures.
• Review Product Manufacturers after each normalization run to ensure correct mapping and classification.

If the environment does not have an existing Product Catalog, enable Allow New Product Catalog Entry during the initial normalization run. This allows the system to automatically create baseline catalog entries based on BMC Helix Discovery data. Once the baseline is created, disable this option to ensure catalog entries are managed through controlled processes that follow best practices and governance standards.

The following table lists common manufacturer aliases used to improve normalization accuracy:

Location mapping

BMC Helix Discovery sends Region, Site Group, and Site values as part of CI data. These locations must already exist in the ITSM Foundation data before they can synchronize with BMC Helix CMDB. If a CI references a location that is not defined in ITSM, the synchronization fails with the following error:

“The Location Information is not valid. Please use the menus provided on the ‘Region’, ‘Site Group’, and ‘Site’ fields or the type‑ahead return information (ARERR 44897)."

To prevent these failures, ensure that all locations referenced by BMC Helix Discovery exist in the ITSM Foundation data.

The following configuration steps outline how to create or bulk‑load the required Region, Site Group, and Site records so that location validation succeeds during BMC Helix CMDB updates:

1. Select ITSM Mid‑Tier Applications → Administrator Console → Application Administration Console → Location → Create to manually add individual location records.
2. For environments with a large number of locations, use the Data Management spreadsheet load process to bulk‑load entries.

Normalization

Normalization standardizes CI data from BMC Helix Discovery by cleaning attribute values, validating them against Foundation and Product Catalog data, and enriching fields to ensure consistency across the BMC Helix CMDB.

The following table summarizes the normalization run performance across multiple executions:

Reconciliation 

BMC Helix CMDB identification rules ensure each CI is uniquely identified across datasets. Rules exist for multiple CI classes, such as:

• BMC_ADMINDOMAIN
• BMC_APPLICATIONSERVICE
• BMC_APPLICATIONSYSTEM
• BMC_BUSINESSSERVICE
• BMC_CLUSTER
• BMC_COMPUTERSYSTEM
• BMC.CORE:BMC_CLOUDINSTANCE
• BMC.CORE:BMC_CONCRETECOLLECTION
• BMC.CORE:BMC_RESOURCEPOOL
• BMC_DATABASE
• BMC_DOCUMENT
• BMC_HARDWAREPACKAGE
• BMC_HARDWARESYSTEMCOMPONENT
• BMC_IPCONNECTIVITYSUBNET
• BMC_IPENDPOINT
• BMC_LANENDPOINT
• BMC_LOGICALSYSTEMCOMPONENT
• BMC_NETWORKPORT
• BMC_OPERATINGSYSTEM
• BMC_PROCESSOR
• BMC_PRODUCT
• BMC_SOFTWARESERVER
• BMC_SYSTEMRESOURCE
• BMC_TAG
• BMC_VIRTUALSYSTEMENABLE

Reconciliation job runtime

The following table lists the reconciliation job runs and their durations:

Business service source control and qualification rules

Business Service data is primarily sourced through an external integration. BMC Helix CMDB applies precedence rules that retain all BMC_BusinessService attributes from BMC.ASSET dataset, with the exception of the ADDMIntegrationId attribute, which BMC Helix Discovery is allowed to populate. This approach preserves the integrity of externally managed Business Service records and prevents unintended updates from BMC Helix Discovery.

Business Service CIs maintained by the external integration are not updated by BMC Helix Discovery, as these records directly support ITSM processes, reporting, and downstream integrations.

As BMC Helix CMDB and BMC Helix Discovery processes matured, BMC Helix Discovery began identifying additional Business Service CIs that were not part of the external integration but were still required for operational visibility and change management. To support these cases, BMC Helix Discovery was configured to populate a custom BMC Helix CMDB attribute that identifies the BMC Helix Discovery managed business services.

Enhanced qualification rules now allow BMC Helix CMDB to differentiate between:

• Business Services managed by the external integration
• Business Services discovered independently

This approach enables the selective creation of new Business Service CIs in the BMC.ASSET dataset when appropriate, without affecting externally managed records. The result is clearer ownership of Business Service data, more predictable reconciliation behavior, and improved accuracy across ITSM processes that rely on consistent and trustworthy CI information.

Updated reconciliation job design

The reconciliation job that processes data from BMC Helix Discovery was expanded from 2 to 4 activities to provide more granular control over how BMC_BusinessService CIs are evaluated in BMC Helix CMDB.

The original job used a single Identify activity followed by a Merge activity, which applied the same logic to all Business Services regardless of their source.

The updated design introduces three Identification activities and one Merge activity. This structure allows BMC Helix CMDB to distinguish between externally managed and BMC Helix Discovery managed business services, ensuring that each type is reconciled according to its ownership and qualification rules.

Innovation Studio - Asset Automation Application

The Asset Automation Application in Innovation Studio automates the creation and management of asset relationships.

During the initial BMC Helix CMDB implementation phase, this application was not incorporated. However, it will be adopted in future phases to automatically create asset–people relationships for CIs discovered by BMC Helix Discovery.

Based on data supplied in the asset record, the application can create and remove the following relationships:

• Contract
• Location
• People

BMC Helix CMDB reporting plan

The following are example report concepts that end users can build to support ongoing BMC Helix CMDB governance, data quality monitoring, reconciliation oversight, operational visibility, and product catalog accuracy. These reports are grouped by functional category for ease of reference.

BMC Helix CMDB Health dashboard

Key indicators used to assess BMC Helix CMDB data quality and operational health include:

• Percentage of CIs with valid owners
• Percentage of CIs with complete mandatory fields
• Percentage of CIs updated within the last 30 days
• Weekly count of reconciliation failure