Having problems with your account or logging in?
A lot of changes are happening in the community right now. Some may affect you. READ MORE HERE

How to create your own custom topology using OMi policies

Micro Focus Contributor
Micro Focus Contributor
1 4 1,812

Guest post by Carol Park and Tapan Shah 

Operations Manager i's foundation is the topology in the RTSM.  There are many ways to populate the RTSM with out-of-the-box Connectors, Management Packs, Universal Discovery and integrations.  In some cases, the topology is updated to the RTSM in near real time and, in others, on a scheduled basis.

 As an open platform, OMi provides several ways you can discover and populate your own custom topology.  This article is focused on using OMi policies to populate the RTSM.  As such, OMi policies process topology from these sources:

Data source

Policy Type

Policy Editor

Deploy to

Agent process

REST Web Services

Topology from REST Webservice

OMi or OpsCx*

OA 12+ or OpsCx


XML File

Topology from XML File

OMi or OpsCx

OA 12+ or OpsCx


Script / Command

Service Auto-Discovery


OA 11.12+ or OA 12+


* Operations Connector (OpsCx)

The steps involved in producing custom topology via an OMi policy are:

  1. Generate the XML topology
  2. Create a policy to process the XML
  3. Manage the CI lifecycle


Step 1: Generate the XML topology

Irrespective of the data source, the output of the data source must be XML in a particular format for the policy to process it correctly.  The following steps show you how to construct the XML to create this example topology, but you can apply the principles to other types of topology you want to create.  The final XML content is at the end.My running SW.png


  1. Enclose the XML in <Service> </Service>
  1. For each CI instance, create a block of XML in this format:
    <NewInstance ref="uniqueIdentifier">
            <Attribute name="hpom_citype" value="ciType"/>
            <Attribute name="ucmdb_XXX" value="YYY"/>



  • uniqueIdentifier is a unique reference to this CI that you use within this XML document to define CI relationships.
  • <Virtual/> is specified if the CI is not ‘hosted-on’ a Node CI. In other words, as a general rule, you should use this tag.
  • ciType is the type of CI that you want to create. You can find this value in the OMi UI:
    • Navigate to Administration > RTSM Administration > Modeling > CI Type Manager
    • Select the CI Type of interest and click the Details tab on the right pane of the screen.
    • The CI Type is in the Name field.
            • As per the screenshot below, to create a Computer CI, the ciType is host_node.OMi General Details.png

              The rest of the block is to set the values for each attribute of the CI.  The format is ucmdb_XXX where XXX is the name of the CI attribute as defined in the CI Type Manager.  For example, the Computer CI Type has a PrimaryDnsName attribute whose name is primary_dns_name.  Its value can be a string up to 250 characters in length.


              OMi Edit attribute.png


              For example:

              <Attribute name="ucmdb_primary_dns_name" value="computer1.example.com"/>

              The string datatype is assumed.  You can see the datatype for each attribute in the previous screenshot.  You can use these datatypes: boolean, bytes, date, double, float, integer, integer_list, string_list.  If the attribute is not a string, then you need to include the datatype, as in these examples:

              <Attribute name="ucmdb_memory_size" value="4096" datatype=”integer”/>

              <Attribute name="ucmdb_root_enableageing" value="true" datatype="boolean"/>

              <Attribute name="ucmdb_bios_date" value="5/16/17 7:00 AM" datatype="date"/>

              <Attribute name="ucmdb_node_role" value="router,switch" datatype="string_list"/>

              <Attribute name="ucmdb_myfloat" value="1.234" datatype="float"/>

              <Attribute name="ucmdb_myintlist" value="85,90,95" datatype="integer_list"/>

              Note: For the date datatype, specify the value in the format of the default locale on your server.  For example:

              en_US: 5/16/17 7:03 AM

              fr_FR: 16/05/17 07:03

              Include all the mandatory attributes.  You can see which attributes are required by checking the Details tab.  The Details tab shows the Identification rule which states the attributes that are used to determine whether to create a distinct new CI or to merge with an existing CI.

              For RunningSoftware, an existing RTSM enrichment rule that is scheduled to run once a day may set the Container name attribute.  Thus you may see the Display Label change to MyRunningSW (computer1).

              Note:  If you are using an Operations Connector to create topology and also log metrics for some of the CIs in that topology, in order to graph the metric data in Performance Dashboard, you will also need to set the External ID attribute.  The value of this attribute must match exactly the Related CI you specify in the metric collection policy.  This is how Performance Dashboard knows what instance data to associate with the selected CI.  For example:

              <Attribute name="ucmdb_data_externalid" value="computer1.example.com"/>

               One other attribute is set automatically: the Monitored By attribute.  You don’t need to set this in the XML.  The following table shows what the Monitored By attribute is updated to include, based on the policy type and the target being an Operations Agent or an Operations Connector.

              Policy Type

              Deployed to

              Added to Monitored By

              Topology from REST Webservice


              Topology from XML File








              Service Auto-Discovery





              3. For each CI Relationship instance, create a block of XML in this format:

            <Instance ref="uniqueIdentifier_1"/>
            <Relations type="relationshipType">
                <Instance ref="uniqueIdentifier_2"/>


  • uniqueIdentifier_1 is unique identifier of the parent CI
  • uniqueIdentifier_2 is unique identifier of the child CI
  • relationshipType is the name of the CI relationship type. One simple way you can find a list of valid CI relationship types in the CI Type Manager, is to select both Parent and Child CI Types, right-mouse click and select Add/Remove Relationship.  The pop-up dialog shows a tick box where a CI-Relationship type has been defined.

 OMI add remove relationship.png

 The type of CI Relationship to use between Computer and its RunningSoftware is Composition.  Composition is the display name.  To look up the actual name of the Composition relationship type to use in the XML:

  • In CI Type Manager, select Relationships in the drop list.
  • Select the CI Relationship Type of interest and click the Details tab on the right pane of the screen.
  • The CI Relationship Type is in the Name field.

As per the screenshot below, to create a Composition relationship, the relationshipType is composition.


OMi workspaces.png

 Note: You cannot set attributes for CI relationships in the XML.  If you want to set the Weight attribute on a relationship CI then this can be done later in the RTSM.

4. Put the blocks together into an XML document. The order of the blocks of XML is unimportant (e.g., could have NewRelationship before NewInstance).  If you specify a relationship, then the corresponding parent and child CIs need to be included in that same XML document.  When you put it all together, the XML looks like this:

    <NewInstance ref="HOST:computer1.example.com">
            <Attribute name="hpom_citype" value="host_node"/>
            <Attribute name="ucmdb_name" value="computer1"/>
            <Attribute name="ucmdb_primary_dns_name" value="computer1.example.com"/>
            <Attribute name="ucmdb_data_externalid" value="computer1.example.com"/>

    <NewInstance ref="MyRunningSW:computer1.example.com">
            <Attribute name="hpom_citype" value="running_software"/>
            <Attribute name="ucmdb_name" value="MyRunningSW"/>
            <Attribute name="ucmdb_discovered_product_name" value="MyRunningSW"/>
            <Attribute name="ucmdb_data_externalid" value="computer1.example.com/MyRunningSW"/>

    <NewInstance ref="CIC:MyAppGroup">
            <Attribute name="hpom_citype" value="ci_collection"/>
            <Attribute name="ucmdb_name" value="MyAppGroup"/>
            <Attribute name="ucmdb_ci_collection_id" value="MyAppGroup_1"/>

            <Instance ref="HOST:computer1.example.com"/>
            <Relations type="composition">
                <Instance ref="MyRunningSW:computer1.example.com"/>

            <Instance ref="CIC:MyAppGroup"/>
            <Relations type="containment">
                <Instance ref="MyRunningSW:computer1.example.com"/>

Step 2: Create a policy to process the XML

You need some way to generate your XML and also create a policy to process it for delivery to OMi.  Choose one of these policy types:

1. Topology from REST Webservice

-This policy is a REST web service listener, which listens by default on port 30005, for the XML topology, which you can send it from a local or remote machine. For example:
curl -k -d @myapp.xml -H 'Content-Type:application/xml' https://managednode.example.com:30005/bsmc/rest/topology/mytopopolicy

- If you deploy to an Operations Connector, you can configure basic authentication on the Operations Connector, if required, using the <OvDataDir>/installation/HPOprBsmc/bsmc-wsconf.[bat|sh]

2. Topology from XML File

-This policy reads an XML File that is locally accessible to the managed node where the policy is deployed.

- Note that the policy will re-read the XML file only if it has been touched or updated since the previous polling interval.

3. Service Auto-Discovery

- This policy executes some script or command, on the managed node where the policy is deployed, at the configured polling interval. The script must generate the XML to stdout.

- Don’t create this policy from scratch. Copy an existing policy such as the ApacheWS-Discovery policy or a similar policy.  Alternatively, you can import an example policy, along with an example Perl script, from the  ITOM Marketplace.

- You need to edit these things in the policy:

  • In the <Schedule> tags, modify how frequently you want the policy to run. For example, while you are testing, you might want it to run more frequently.  You can also create and use a policy parameter so you can adjust when it runs via tuning rather than modifying the policy.  See the online help for the Schedule syntax.
    • Find the two occurrences of CommandLine=, one each for Windows and Unix. Replace the script name with your script name.  The best practice is to put your script into instrumentation which means there is no need to specify a path to script or to manually put the script on the remote node(s).  For convenience, this is a quick summary of creating instrumentation:

i. Create a directory structure:
<OMi Home>/opr/bin/ConfigExchange[.sh|.bat] -createinstrumdir -output <dir>

ii. Put your script(s) into the respective sub-folder(s) of instrumentation directory

iii. Upload the instrumentation to the OMi DB:
<OMi Home>/opr/bin/ConfigExchange[.sh|.bat] -username <user> -upload -instrumname <name> -i <dir>

  • In the Properties tab, de-select the existing instrumentation and select your Instrumentation. Your Instrumentation is available to select only after you have uploaded it to the OMi DB. 


Step 3: Manage the CI lifecycle

After a CI is created via an OMi policy, the OMi server touches the CI every 24 hours.

When does OMi delete a CI if it no longer exists?  The answer depends on:

  1. The policy type used to produce topology data
  2. The XML document
  3. OMi Infrastructure Settings

Policy type

The topology policies send either full or delta XML data to OMi each time there is data to process.  If you generate XML based on checking if some software is installed on the system and later that software is uninstalled, then the RunningSoftware for that node will no longer be included in the XML.

In XML File and REST Web Services policies, if "Detect deltas" is enabled, then "Age to deletion" is applied. This is the number of consecutive policy executions during which the object is not included in the topology data.  Thus, if you set this to three in the policy, then after three consecutive intervals of receiving topology without the object, the agent sends OMi an instance deletion request for that object.

In Service Auto-Discovery policies, the corresponding “Age to deletion” is a global setting applying to all Service Auto-Discovery policies on the agent.  It is set to five by default, but can be modified.  For example:

ovconfchg -ns agtrep -set INSTANCE_DELETION_THRESHOLD 3

ovc -restart agtrep

You can also automate such changes to apply to multiple agents via the profile file during agent installation or via a Node Info policy.

Note: If you remove a Service Auto-Discovery policy from a node, this will trigger instance deletion requests to OMi.  If you don’t want that to happen, run ovagtrep -clearall before removing the policy.

XML document

As shown earlier, CIs and CI relationships are added using the NewInstance and NewRelationship elements respectively.  Similarly, CIs and CI relationships can be deleted using the DeleteInstance and DeleteRelationship elements.  In all other respects, specify the same XML since the attributes and/or relationships are needed to identify the CIs and/or relationships to remove.

OMi Infrastructure Settings

By default, OMi processes the instance deletion requests and removes the corresponding CIs from the RTSM, regardless of whether those CIs are monitored by another tool (eg, SiteScope, Network Node Manager i).

CI deletion can trigger any associated Monitoring Automation assignments, such as aspects and policies, to be removed automatically.  For example, deleting MySoftware CI causes MySoftwareAvailability aspect to be de-assigned and its policies removed from the node now that MySoftware is no longer there.

 It also means that any existing events with the related CI of MySoftware will now display Unknown CI instead.

If you don’t want OMi to act on these instance deletion requests, then in Infrastructure Settings select Applications = Operations Management and set “Skip CI Deletion” to “true”.  In this situation, you would rely on the RTSM’s CI Aging capability to determine if or when to delete the CI.


If you experience problems then one or more of these log files may help.


OMi Gateway


<OMi Home>/log/wde/opr-svcdiscserver.log

<OMi Home>/log/wde/opr-svcdiscserver-citrace.log

<OMi Home>/opr/tmp/datadump/*/* (if Dump Data is true in Infrastructure Settings)


<OMi Home>/log/odb/odb/*.log

Operations Agent



Other resources

If you are creating topology as part of integrating a third-party domain manager monitoring solution, then you can find value in using the Operations Connector SDK.  It includes:

  • A REST API and corresponding out-of-the-box integration policies to receive data create a consistent interface for all data channels. Additionally, example code shows how to submit data to this API. Examples are available in the following programming languages: Python, Java, JavaScript, Go, cURL.
  • The java skeleton project can be used as a starting point for building your own Java-based data integrations.
  • A complete DataDog integration example gives you a model to follow when creating a new integration.
  • Sandbox Mode intercepts and previews incoming data, useful during the development of a new integration, allowing you to target and fix problems before connecting the integration to a running OMi system.

If you are creating topology as part of a monitoring solution for a custom application where your agents are installed, then you can find value in the OMi Management Pack Development Kit.  The MP DevKit provides the user the capability to author an OMi MP using simple Perl modules and YAML configuration files, without needing to understand the details and complexities of underlying monitoring platform components like OMi or OA.  

Explore the full capabilities of the Operations Bridge Suite and technology integrations:



SteveConner Super Contributor.
Super Contributor.

How do i populate multiple RTSM instances using a single OpsCx XML Topology policy ? 

Micro Focus Expert
Micro Focus Expert

Typically, an OpsCx points to one OMi server at a time.  So your OpsCx would post its discovery content to its primary OMi server.  Then you could configure topology sync between that OMi server and other RTSMs/UCMDB to share the topology to others.


ramesh9 Acclaimed Contributor.
Acclaimed Contributor.


How can I create Interface CI using opsConnector XML policy, I tried with following example,

<NewInstance ref="test3-net:Internal-Data0/1">
      <Attribute name="hpom_citype" value="interface"/>
      <Attribute name="ucmdb_name" value="Internal-Data0/1"/>
      <Attribute name="ucmdb_interface_alias" value="Internal-Data0/1"/>

but I am not able to create new Interface CI, is there anything I am missing in XML file.

Gopi D Contributor.

How to write our own topology/event/metric OMi polocies in JSON formate.

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.