Synchronization Packages

Topology synchronization packages contain the mapping between one or more service models, nodes, or node groups on the OM side to one or more CIs on the RTSM side.

A topology synchronization package contains a set of XML configuration files that define the mapping rules (context, CI type, attributes, and so on) during topology synchronization. The configuration files are used to:

• Transform topology data (for example, OM services, nodes, node groups, and node layout groups) into CIs in the RTSM.

• Synchronize CIs in the RTSM with topology data from OM.

A topology synchronization package must include the package descriptor file (package.xml) to define the synchronization package (see Package descriptor file: package.xml).

Mapping files that can be part of a synchronization package are:

• contextmapping.xml

• typemapping.xml

• attributemapping.xml

• relationmapping.xml

For more information about the XML configuration files, see Mapping files.

For basic information on mapping, see Mapping Engine and Syntax.

Groovy scripts can also be placed into a topology synchronization package to manipulate the synchronization data during the synchronization process, or to carry out post-synchronization activities, for example, for auditing purposes. You can include the following Groovy scripts in a topology synchronization package:

• preEnrichment.groovy

• preUpload.groovy

• postUpload.groovy

For more information about Groovy scripts, see Groovy scripts.

You can specify the content you want to update when synchronizing the topology between OMi and OM.

There are three out-of-the-box topology synchronization packages:

• default

  Contains basic type mappings for nodes, and basic attribute mappings for nodes and node groups.

  Does not create any CIs in the RTSM.

  Should not be removed from the list of enabled packages.

• operations-agent

  In addition to creating the host CI itself, creates a CI instance of type hp_operations_agent for each OM managed node with an agent, and relates it to the host CI. Also creates CIs of type omserver and relates it to its host and to all the hp_operations_agent CIs.

• nodegroups

  In addition to creating the host CI itself, maps OM node groups to the RTSM CI type ci_group, creates instances of the CI type ci_group, and creates relations for the contained nodes. Also creates CIs of type ipaddress and interface and relates them to their host.

• layoutgroups

  In addition to creating the host CI itself, maps OM layout groups to the RTSM CI type CI Collection (ci_group) CI type CI Collection (ci_group), creates instances of the CI type CI Collection (ci_group), and creates relations for the contained nodes.

  Note ci_group is visually known as CI Collection.

In the Packages for Topology Sync setting in OM Topology Synchronization settings, you can list the packages whose contents should be updated during the topology synchronization process:

Administration > Setup and Maintenance > Infrastructure Settings

Alternatively, click Infrastructure Settings.

Operations Management - HPOM Topology Synchronization Settings > Packages for Topology Sync

Additional topology synchronization packages are provided out-of-the-box in content packs. Content packs include the following:

• ActiveDirectory

• Exchange

• MS SQL Server

• Oracle

• J2EE (includes WebSphere and WebLogic content)

• Infrastructure (includes UNIX and Windows operating systems, Virtualization Systems, and Cluster Systems)

These additional topology synchronization packages are not enabled by default. To enable them:

1. Load the content pack(s) you wish to use.

2. Enable the synchronization packages manually in the Infrastructure Settings:

   Administration > Setup and Maintenance > Infrastructure Settings

   Alternatively, click Infrastructure Settings.

   Operations Management - HPOM Topology Synchronization Settings > Packages for Topology Sync

Topology synchronization packages are written to the following directory:

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

For example, the Oracle content pack uses the package (and directory) name HPOprOra. This is the name you enter in the list if you want the mapping rules to be executed during topology synchronization. If we add the Oracle package to the list of standard out-of-the-box packages we had in the example in the section Standard out-of-the-box synchronization packages), the list would look like this:

default;nodegroups;operations-agent;HPOprOra

A topology synchronization package must include the package descriptor file (package.xml). The package.xml file defines a topology synchronization package and includes:

• <Name> The name of the package must be the same as the name of the subdirectory in which you place the synchronization package:

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

• <Description> Description of the package.

• <Priority> Priority level of the package.

  The highest priority is represented by 1. The default synchronization package is assigned the lowest priority of 10. A higher priority rule result overwrites a result from a lower priority rule.

  Note There may be more than one synchronization package with the same priority. The order of execution of the rules between synchronization packages with the same priority is not specified.

The following mapping files can be included in a topology synchronization packages.

Context Mapping (Filtering): contextmapping.xml

You can determine which elements of an OM service tree you want to include in the topology synchronization for mapping in the RTSM by configuring the filtering file, contextmapping.xml. Filtering involves assigning a context to those CIs you want to synchronize. Configuring the context enables you to apply mapping rules selectively to CIs of the same context.

For example, specified OM services are tagged, and all subsequent mapping rules contained in other configuration files are applied to those tagged services. A service that has no context assigned is not included for synchronization.

Type Mapping: typemapping.xml

The type mapping file typemapping.xml defines the mapping from a service in OM based on their attributes to the type of a CI in the RTSM.

Attribute Mapping: attributemapping.xml

The attribute mapping file attributemapping.xml defines the mapping between the attributes of a service in OM and the attributes of a CI in the RTSM.

Attribute mapping enables you to change CI attributes and add new attributes to better describe a CI and create a more detailed view of the environment.

Relation Mapping: relationmapping.xml

Using the relation mapping file relationmapping.xml, you can define the CI relationships created in the RTSM between specified OM services.

Make sure that the specified OM services are created as CIs in the RTSM. Otherwise it is not possible for topology synchronization to create a relationship in the RTSM.

Scripting enables you to perform additional processing and customization during the synchronization process before the mapping, and before and after the upload of topology data to the RTSM. One pre-mapping, one pre-upload, and one post-upload script can be associated with each synchronization package.

For details, see Scripting. For more information about developing and deploying Groovy scripts, see Groovy scripts.

The sync-packages directory contains dedicated subdirectories for each synchronization package. It is recommended but not essential that you use directory names that match the synchronization package name.

Synchronization packages are deployed by placing them into the following directory:

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