Traversal configuration

Traversal configuration consists of included and excluded relations between objects.

By default, all existing CIs and their relations are traversed during business application composition. Business applications are composed during the grouping pattern processing. However, if you use traversal configuration, some relations can be skipped from processing. It means that the compositor does not go further through excluded relationships. It applies to either implicit relations, which are relations that are defined in Common Data Model, or explicit relations, which can link any CIs and can be created by using TADDM API or UI. However, explicit relations that are generated for implicit relations by using the explicitrel.sh script are ignored by default, and it cannot be configured.

In the following example, first two relation tags exclude completely the whole CI type by excluding all incoming and outgoing relations. The third relation tag excludes only one simple relation.

Example:

<traversalConfiguration>
		<excludedRelationships>
				<exclude relation="{any}" source="admin.AdminInfo" target="{any}"/>
				<exclude relation="{any}" source="{any}" target="admin.AdminInfo"/>
				<exclude relation="only relation.DeployedTo" source="app.j2ee.J2EEApplication" target="app.j2ee.websphere.WebSphereCell"/>
				...
		<includedRelationships>
				<include relation="{any}" source="admin.AdminInfo" target="{any}"/>
				<include relation="{any}" source="{any}" target="admin.AdminInfo"/>
				...

The traversal configuration consists of the following parameters:

excludedRelationships: This parameter contains a series of excluded relationships.
includedRelationships: This parameter contains a series of included relationships. Although all relationships are included by default, this parameter is useful in case of grouping pattern configuration, when you want to include a relation that is excluded in the default configuration.

The excludedRelationships and includedRelationships parameters contain the following elements:

relation

The name of the relation or the dependency type.

source

The name of the relation source object type. If you do not want to define any specific source, you can set the value to {any}.

In TADDM 7.3.0.2, and later, you can also add the hierarchyType attribute of a model object to the source of the relation to be more specific. After the name of the relation source object type, add a colon (:) and the value of the hierarchyType attribute. For example, source="app.AppServer:IBMTivoliEnterpriseConsole".
To make sure about the correct value of the hierarchyType attribute, you can query CI of a given type by using the TADDM APIs.

In TADDM 7.3.0.3, and later, you can also add the hierarchyDomain attribute of a model object to the source of the relation to be more specific. After the name of the relation source object type, add a colon (:) and the value of the hierarchyDomain attribute. When you are applying this filter, you must also add the value of the hierarchyType attribute. For example, source="simple.SSoftwareServer:app.placeholder.client.remote.Unknown", where app.placeholder.client.remote is the value of the hierarchyDomain attribute, and Unknown is the value of the hierarchyType attribute. The hierarchyType attribute is always specified at the end, and is separated from the hierarchyDomain attribute with a dot.
You can also use an asterisk (*), which stands for one or more full parts of the domain name, or for the hierarchyType attribute. Examples:

source="simple.SSoftwareServer:app.placeholder.*.Unknown"
source="simple.SSoftwareServer:app.placeholder.client.remote.*"

target

The name of the relation target object type. If you do not want to define any specific target, you can set the value to {any}.

In TADDM 7.3.0.2, and later, you can also add the hierarchyType attribute of a model object to the target of the relation to be more specific. After the name of the relation target object type, add a colon (:) and the value of the hierarchyType attribute. For example, target="app.AppServer:MySql".
To make sure about the correct value of the hierarchyType attribute, you can query CI of a given type by using the TADDM APIs.

In TADDM 7.3.0.3, and later, you can also add the hierarchyDomain attribute of a model object to the target of the relation to be more specific. After the name of the relation target object type, add a colon (:) and the value of the hierarchyDomain attribute. When you are applying this filter, you must also add the value of the hierarchyType attribute. For example, target="simple.SSoftwareServer:app.placeholder.server.local.Java", where app.placeholder.server.local is the value of the hierarchyDomain attribute, and Java is the value of the hierarchyType attribute. The hierarchyType attribute is always specified at the end, and is separated from the hierarchyDomain attribute with a dot.
You can also use an asterisk (*), which stands for one or more full parts of the domain name, or for the hierarchyType attribute. Examples:

target="simple.SSoftwareServer:*.placeholder.*.Java"
target="simple.SSoftwareServer:app.placeholder.*"

direction

The direction of the dependency traversal defined for a specific relationship. The following values are available:

UP: The exclusion or inclusion rule is applied only when the current traversal direction is up the dependency chain, starting from the source object type.
DOWN: The exclusion or inclusion rule is applied only when the current traversal direction is down the dependency chain, starting from the source object type.
UP_AFTER_DOWN: The exclusion or inclusion rule is applied only when the current traversal direction is down and then up the dependency chain, starting from the source object type. It is the equivalent of the LowerUp option that you can select in Data Management Portal.
DOWN_AFTER_UP: The exclusion or inclusion rule is applied only when the current traversal direction is up and then down the dependency chain, starting from the source object type. It is the equivalent of the HigherDown option that you can select in Data Management Portal.

Traversal configuration is related to relation direction as defined in Common Data Model (relations direction configuration is not taken under consideration). However, in case of explicit dependencies traversal does take direction into consideration because the source and target class is not constrained by Common Data Model (any class can be used as a source or target of explicit relation).

More examples

Skipping a specific relation between a pair of specific objects.

<exclude relation="relation.RunsOn" source="sys.OperatingSystem" target="sys.ComputerSystem"/>

Skipping any relations, for which a particular class is a source.

<exclude relation="{any}" source="net.BindAddress" target="{any}"/>

Skipping any relations, for which a particular class is a target.

<exclude relation="{any}" source="{any}" target="net.BindAddress"/>

Skipping a relation but not its subclasses.
Note: dev.RealizesExtent is a subclass of relation.Realizes and it is processed even though relation.Realizes is skipped.
```
<exclude relation="only relation.Realizes" source="sys.FileSystem" target="sys.FileSystem"/>
```
Skipping any relation, for which IBM Tivoli Enterprise Console object of the AppServer object type is a source.
```
<exclude relation="{any}" source="app.AppServer:IBMTivoliEnterpriseConsole" target="{any}"/>
```
Note: For more information about hierarchyType attribute of custom server templates, see Creating and managing custom server templates.
Skipping a specific relation between a pair of specific objects. Additionally, the relation is skipped only when it is found while traversing the objects down the dependency chain.
```
<exclude relation="relation.RunsOn" source="app.AppServer" target="sys.ComputerSystem" direction="DOWN"/>
```
If this exclusion rule is added to the patten configuration, which is attached to a pattern where ComputerSystem CI is a core CI (traversal starting point), then all AppServers (applications) that run on this core CI are added to the topology, because AppServers depend on ComputerSystem. Other AppServers that are connected with the already added AppServers can also be added to the topology through IpConnection dependencies. However, the exclusion rule provided in the example is applied when the traversal engine tries to add the host ComputerSystems on which these AppServers are running. In this case, the AppServer->RunsOn->ComputerSystem relation is traversed down and the exclusion rule is applied.
Skipping any relation, for which the target is an object with SSoftwareServer type, and has the hierachyDomain attribute set to app.placeholder.client.remote, and the hierarchyType attribute set to Unknown.
```
<exclude relation="{any}" source="{any}" target="simple.SSoftwareServer:app.placeholder.client.remote.Unknown"/>
```

You can also configure BizAppsAgent to traverse only specific set of relations. For example:

<excludedRelationships>
<exclude source="{any}" target="{any}" relation="{any}"/>
</excludedRelationships>
<includedRelationships>
<include target="{any}" source="sys.SystemPComputerSystem" relation="relation.Virtualizes"/>
<include target="{any}" source="sys.linux.LinuxUnitaryComputerSystem" relation="relation.Virtualizes"/>
<include target="{any}" source="only sys.ComputerSystem" relation="relation.Virtualizes"/>
</includedRelationships>