Troubleshooting

Make sure the input XML file is written and updated correctly. Each time the topology policy runs, the mapping rules are applied to the whole discovery XML file, not only to appended entries.

For troubleshooting the mapping engine, see Mapping Log Files.

You can use the supplied XML schema definitions to validate the correctness of XML configuration files. You can also use the supplied XML schema definition files to make writing new configuration files easier when using a suitable XML editor (for example Eclipse).

XSD XML Schema Definition is a standard from World Wide Web Consortium (W3C) for describing and validating the contents of XML files. XSD files are provided for all XML configuration files. For more information, see the XML Schema documentation by W3C available from the following Web site: http://www.w3.org/XML/Schema.

Each mapping file is automatically validated against the associated XSD file whenever it is read. If a file cannot be validated, an error message is written to the error log that describes the location of the error in the validated file.

The schema files are stored in the following directory:

%topaz_home%\conf\opr\topology-sync\schemas

The files are:

package.xsd

Validates the package.xml file in each synchronization package.

mapping.xsd

Validates the following mapping files contained in the synchronization packages:

• Context mapping - contextmapping.xml

• Type mapping - typemapping.xml

• Attribute mapping - attributemapping.xml

• Relation mapping - relationmapping.xml

The mapping engine generates the following log file:

%topaz_home%\logs\opr-ts.log

Use following guidelines when writing rules:

• Simplify Rule Development. You can ease the writing of rules by selecting an XML editor that can validate and suggest elements according to an XML schema.

• Avoid Complex XPath Queries. Avoid complex XPath queries, especially in general conditions, where such queries must be applied to every CI. If you cannot avoid a complex XPath query, try to narrow the condition using operators such as OMType, combined using the And operator. Make sure that the simpler, non-XPath conditions are checked first (hint: And is an exclusive operator).

• Match Against Existing Attributes Only. Accessing attributes that do not exist for all CIs is very performance intensive in combination with a relative expression depending on the complexity of the CI hierarchy.

• Avoid Broad XPath Expressions. Certain complex XPath expressions can result in excessive processing loads. For example, XPath expressions that include the following characteristics:

  • Apply to multiple nodes, such as expressions that contain // or descendants:*/

  • Do not match nodes or match only on nodes that are very distant from the current node

  The same applies to the XPathResultList operator that returns all matched values. The time required for such operations grows approximately quadratically with the size of a hierarchy. Avoid such expressions where possible.

  When using the descendants operator, do not use the star symbol (*) as node test, but specify the name of the node of interest. For example, do not use descendants:*/caption but use descendants:ci/caption.

  If you cannot avoid such an XPath expression within a condition, try to limit its execution by using the exclusive And operator and perform simple tests before the XPathResult operand is being used. For example, you could first check for the CI type.

Use the topology command line tool to list all topology repositories, delete repositories, and send the last known delta or repository to the ServiceDiscoveryServer (SvcDscSvr).

The tool is located in

%OvInstallDir%/bin/win64 (Windows systems)

/opt/OV/bin (Linux systems).

Usage

topology -h
-list
-publishrepo <SELECTION>
-publishdelta <SELECTION>
-clean <SELECTION>


<SELECTION>: 
   [-all | -polname <name>[/<src>|/*] | -polid <uuid>[/<src>|/*]]

Option descriptions