Search for	Example	Results
A single word	`cat`	Topics that contain the word "cat". You will also find its grammatical variations, such as "cats".
A phrase. You can specify that the search results contain a specific phrase.	`"cat food"` (quotation marks)	Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase.

Search for	Operator	Example
Two or more words in the same topic	`AND` `and` `+` (plus symbol) `&` (ampersand)	`cat AND dog` `"cat food"+milk` `"cat food"&"dog food"`
Either word in a topic	`OR` `or` `\|` (pipe)	`cat OR dog` `cat \| dog`
Topics that do not contain a specific word or phrase	`NOT` `not` `!` (exclamation point)	`NOT cat` `! dog`
Topics that contain one string and do not contain another	`^` (caret)	`cat ^ mouse`
A combination of search types	`( )` parentheses	`cat + (dog \| mouse)` `cat \| dog + (! mouse)`

Operations Manager i10.62

Develop > Populate the RTSM > Topology Synchronization

Topology Synchronization

You can use topology synchronization instead of, or in conjunction with, HPE DFM (Data Flow Management) discovery or service auto-discovery policy templates to create CIs in the RTSM. Accurate and up-to-date CI topology data in the RTSM is essential for Topology-based Event Correlation (TBEC), context-specific tools, and OMi-wide service health monitoring (Health Perspective).

Note Alternatively, you can import existing topology information into the RTSM. For details on importing data from Excel Workbooks and other external sources, see the UCMDB Help.

Topology synchronization can be defined as a set of rules that determine how services, nodes, node groups, and node layout groups monitored by OM are mapped to OMi configuration items (CIs) in the operational database (RTSM).

Topology synchronization is a standard part of the OMi license. It offers a solution to populate the RTSM with CIs from service models (or alternatively, service trees or service graphs) defined in OM. Topology synchronization is especially interesting for OM customers who have created their own service model.

Mapping rules used for topology synchronization are contained in topology synchronization packages. The installation copies the topology synchronization rules to the local file system. The rules are then uploaded to the database when synchronization is used for the first time. You can also write your own topology synchronization rules to populate the RTSM based on your service model or the discovered topology data.

To automate the discovery process, you can use service auto-discovery policies. These enable you to run scripts or programs that discover CIs in your managed environment and automatically populate RTSM. For more information, see Configure Service Auto-Discovery Policies.

Learn more

Overview

Topology synchronization makes it possible to share topology data from OM between any supported combination of multiple OM and OMi instances, in a distributed, hierarchical environment.

An OMi instance can be configured to receive topology data from multiple OM and other OMi instances. An OMi instance can also be configured to forward topology data to other OMi instances.

Topology data is forwarded to the OMi instance dynamically, that is, as soon as a topology change is discovered by an HPE Operations Agent (and written to the OM service model). Topology synchronization enables near-real-time discovery of infrastructure changes. For example, if a node is added to the environment, this change is immediately forwarded, and the database updated.

For details of supported OM versions, see Support Matrices for Operations Center products.

When you first configure topology synchronization, the source system (HPE Operations Agent or OM) sends all its topology data to one or more target systems (OM or OMi). After this first synchronization, topology synchronization forwards only the discovered topology changes. Changes in topology of an OMi instance are not forwarded, and not synchronized back to an OM system using topology synchronization.

For details about database synchronization, see the RTSM documentation.

Once configured, topology synchronization runs continuously in the background. Also running continuously in the background is a process that prevents aging in the RTSM by touching all elements from the previous synchronization.

For more details about RTSM aging, see the RTSM Modeling section.

To create CIs in the RTSM, based on mapping rules and using OM topology data as sources, topology synchronization does the following:

Forwards the discovered topology data from configured source forwarding servers to configured target servers, using HTTPS-based communication requiring trusted certificate exchange.
Receives discovered topology data asynchronously.
Converts the topology data into a format compatible with OMi.
Uploads the topology data to the RTSM.
Updates the data in the RTSM on demand.
Performs delta detection and deletes elements from the RTSM that are deleted in OM.
Provides a mapping table for CI resolution.

Note The definition of particular CI types is especially important when synchronizing the topologies of OMi and OM because the topology synchronization process cannot create new CI types. If the topology synchronization process attempts to map to a CI type that does not exist in the RTSM, the topology synchronization process aborts.

Architecture

The following graphic provides an overview of the topology synchronization architecture.

Topology synchronization architecture

The reference numbers in the diagram refer to the following notes:

Reference	Refers to	Note
1	Discovery Server	Controls the synchronization process and passes data from one component to the other. Runs in `hpsbm_wde` process on the gateway servers.
2	Receiving topology data on the Discovery Server	Receive topology data in the form of a discovery XML forwarded from an OM server or another OMi server.
3	Model Adapter	Convert the discovery XML to the synchronization data structure.
4	Scripting	Execute Groovy scripts to manipulate synchronization data.
5	CI Filtering	Use the mapping engine to specify which CIs are part of the synchronized model, and which are not.
6	CI Type Mapping	Map Service Type Definitions (STDs) for RTSM (Run-time Service Model) types.
7	Attribute Mapping	Map OM relations that are not typed to RTSM relations.
8	RTSM Relation Mapping	Create the relations for the RTSM. Map the root container to the CI to be able to create the CI in the RTSM according to the model.
9	Enrichment	Control the whole enrichment process and return the modified synchronization data.
10	RTSM Gateway	Write the synchronization data to the RTSM.
11	CI Resolution Mapping Table	For each synchronized CI, update a mapping table for the CI Resolution component that maps the OM Service ID to the RTSM CI ID.

Synchronization packages and mapping

Topology synchronization uses synchronization packages to create CIs in the RTSM. Topology synchronization packages contain the mapping between one or more services, nodes, or node groups on the OM side to one or more CIs on the RTSM side.

A topology synchronization package consists of XML configuration files (see Mapping files). These files are responsible for transforming OM services, nodes and node groups into CIs in the RTSM, and synchronizing those CIs with data from specified services, nodes, node groups, and node layout groups in OM.

There are two types of topology synchronization packages:

Standard packages provided out-of-the-box as part of the installation package.

For more information, see Standard out-of-the-box synchronization packages.
Additional, out-of-the-box packages that are aligned with a subset of OM SPIs and available content packs.

For more information, see Additional out-of-the-box synchronization packages.

You can also create your own topology synchronization packages. An example of how to configure topology synchronization and create your own synchronization package is provided in the section Configuring Topology Synchronization: ACME Example.

For an out-of-the-box installation, synchronization packages are automatically loaded from the file system to the RTSM. When you make new synchronization packages, or changes to existing packages, you must run a command-line tool to upload the new or changed packages to the RTSM. For details, see Manage synchronization packages.

For more information about synchronization packages and mapping, see Synchronization Packages.

File locations

Initial product installation copies topology synchronization files to the locations specified in this section on the local file system on the OMi data processing server.

You can find the topology synchronization files in the following locations:

Binaries:

Windows: <OMi_HOME>/bin/opr-sdtool.bat

Linux: <OMi_HOME>/bin/opr-sdtool.sh

<OMi_HOME>/opr/lib/opr-ts-*.jar

<OMi_HOME>/opr/lib/OvSvcDiscServer.jar

Log Files:

<OMi_HOME>/log/wde/opr-svcdiscserver.log

<OvDataDir>/log/OvSvcDiscServer.log

Log File Configuration Files:

<OMi_HOME>/conf/core/Tools/log4j/wde/opr-svcdiscserver.properties

Topology Synchronization Packages:

<OMi_HOME>/conf/opr/topology-sync/sync-packages

Schema Files:

<OMi_HOME>/conf/opr/topology-sync/schemas

Manage synchronization packages

The command-line tool opr-sdtool uploads and enables new or changed synchronization packages from the file system to the database and downloads synchronization packages from the database to files.

Send Help Center feedback