3.1 IBM Tivoli Application Dependency Discovery Manager (TADDM)

Operations Center can integrate with IBM Tivoli Application Dependency Discovery Manager (TADDM) without the ORB software. Integration requires copying a number of TADDM files to the Operations Center installation directory:

3.1.1 Integrating TADDM

To integrate TADDM:

  1. If integrating with a TADDM 7.0.x and prior, copy the following files from the TADDM installation directory (/sdk/lib) to the /OperationsCenter_install_path/classes/ext directory:

    • api‑client.jar
    • api‑dl.jar
    • platform‑model.jar
    • api‑dep.jar
    • platform‑logger.jar
  2. If integrating with TADDM 7.1.2, copy the following files from the TADDM installation directories to the /OperationsCenter_install_path/integrations/ext/taddm712 directory.

    • IBM/cmdb/dist/sdk/lib/platform‑model.jar
    • IBM/cmdb/dist/lib/platform‑jini.jar
    • IBM/cmdb/dist/sdk/clientlib/taddm-api-client.jar
  3. If integrating with TADDM 7.2.0.x, copy the following files from the TADDM installation directories to the /OperationsCenter_install_path/integrations/ext/taddm712 directory.

    • IBM/cmdb/dist/sdk/lib/platform‑model.jar
    • IBM/cmdb/dist/lib/platform‑jini.jar
    • IBM/cmdb/dist/sdk/lib/taddm-api-client.jar
  4. Create a TADDM adapter for each instance of TADDM on the network.

    For versions prior to TADDM 7.1.2, select the IBM Tivoli Application Dependency Discovery Manager adapter type. For TADDM 7.1.2 and higher, select the IBM Tivoli Application Dependency Discovery Manager 7.x adapter type.

    For instructions, see Section 5.1, Creating an Adapter.

    Note for TADDM 7.x adapter: the xml tag attribute of case=no or case=yes, set in the TADDMHierarchy.xml file and traditionally used to control case of the resulting display data, is ignored.

    For more information about using and modifying hierarchy files, see Section 9.0, Using the HierarchyFile.

  5. Modify the adapter properties.

    For instructions, see Section A.18, IBM Tivoli Application Dependency Discovery Manager (TADDM).

3.1.2 Using TADDMHierarchy.xml to Select Data

Use the TADDMHierarchy.xml file to select objects from TADDM and display them in the Operations Center console. If you are unfamiliar with the XML-based HierarchyFile structure used with various adapters, see Section 9.0, Using the HierarchyFile.

In the hierarchy file, the <generator> element is used to dynamically create Operations Center elements from elements discovered in a different management system, such as TADDM. The field attribute compares specified fields in the incoming data with a target value, as a way to filter and select data.

Select by Data Type

Edit the TADDMHierarchy.xml file to select TADDM data by using the field attribute of the <generator> tag. The field attribute can represent the following data types found in a TADDM discovery:

  • host: TADDM hosts (servers).

  • networkdevice: Network devices.

  • applicationcomponent: TADDM application components.

  • softwareitem: TADDM software items.

  • businessapplication: TADDM business applications.

  • appcompsoftwareitem: An instance of software that defines the application component. This is the main TADDM software item discovered that is most critical for this application server (can exist only under an “applicationcomponent”).

If the class_from_field attribute of the <generator> tag is supplied with an icon_name value, then the integration provides a system default icon to represent the generated nodes above.

For example, assume that you want to see all network devices (subnets, switches, etc.) discovered by TADDM. In the integration hierarchy, define the following tags:

<group class="gen_folder" name="Network Devices">
  <generator class_from_field="icon_name" field="networkdevice"/>
</group>

The resulting view in the Operations Center element hierarchy includes all discovered devices under the Network Devices element:

Figure 3-1 Operations Center Element Hierarchy

Select by Fully Qualified Object Names

Refine the data selection process by using TADDM’s fully qualified object names to identify objects in a discovery. List the object names as field attributes of the <generator> tag. Examples:

  • com.collation.platform.model.topology.sys.hpux.HpUx

  • com.collation.platform.model.topology.sys.UnitaryComputerSystem

  • com.collation.platform.model.topology.sys.windows.WindowsComputerSystem

Use Limited Querying

Limited querying can be used to select objects during discovery. An understanding of TADDM’s Model Query Language is required to use this feature. For example, set the field attribute to OSRunning.OSName==\’Linux\’* to select computers that run the Linux operating system. Quotes for the query are escaped with the “\” character.

The structure of OSRunning.OSName follows the tag structure used in the TADDM Model Query Language:

SELECT ComputerSystem.displayName FROM ComputerSystem WHERE OSRunning.OSName == ‘Linux’

This query returns, as output, an OSName XML tag nested within an OSRunning XML tag, which in turn is nested within a ComputerSystem XML tag.

Assume that you want to see all computers in your network that run HP or Linux. In the integration hierarchy file, define the following, using two different styles of querying in each case:

<group class="formula_organizations" name="Janet's Queried Objects">
  <group class="gen_folder" name="Hp Boxes">
    <generator class="admin_automation" field="com.collation.platform.model.topology.sys.hpux.HpUxUnitaryComputerSystem" />
  </group>
  <group class="gen_folder" name="Linux Boxes">
    <generator class="admin_automation" field="OSRunning.OSName==\'Linux\'" />
  </group>
</group>

The resulting view in Operations Center shows the computer IDs beneath two parent elements: HP Boxes and Linux Boxes:

Figure 3-2 Operations Center Hierarchy View

The TADDM integration can display two types of relationships in Operations Center: explicit relationships and implicit relationships.

Explicit Relationships

Explicit relationships show child data nodes grouped logically beneath parent nodes. These relationships are created by editing the TADDM hierarchy file and nesting <generator> tags of a specific field type.

Table 3-1 contains the valid nesting sequences of data for the hierarchy file (the data in the rows represent the field attribute values of the nested <generator> tags):

Table 3-1 Valid Nesting Sequences for Hierarchy File

Generator Tag field Attribute

Child Generator Tag field Attribute

Grandchild Generator Tag field Attribute

businessapplication

host

networkdevice (a subnet)

businessapplication

host

softwareitem

businessapplication

host

appcompsoftwareitem

businessapplication

applicationcomponent

appcompsoftwareitem

businessapplication

applicationcomponent

networkdevice (a subnet)

businessapplication

host

 

businessapplication

applicationcomponent

 

host

networkdevice (a subnet)

 

host

softwareitem

 

host

appcompsoftwareitem

 

softwareitem

host

 

applicationcomponent

appcompsoftwareitem

 

networkdevice

host

 

For example, assume that you want to show the Application Components that are placed under Business Applications (i.e., a defined logical structure for grouping discovered objects in TADDM). You also want to show the main software that runs under the Application Component, as well as the subnets to which the server belongs.

In the integration hierarchy file, define the following tags:

<group class="formula_organizations" name="Janet’s Business Applications Structure">
  <generator class_from_field="icon_name" field="businessapplication">
    <generator class_from_field="icon_name" field="applicationcomponent">
      <generator class_from_field="icon_name" field="appcompsoftwareitem"/>
      <generator class_from_field="icon_name" field="networkdevice"/>
    </generator>
  </generator>
</group>

A defined logical structure for grouping discovered objects in TADDM:

Figure 3-3 Defined Logical Structure

The element hierarchy indicates that the TADDM server has three Business Applications defined (Demonstration Application, PowerView BSM and RCCM SW License Manager Agent Deployed).

Under the Demonstration Application element, the second child is a server named “csctaddmllg078.can-kan.csc.com”. This server has an application listening on port 8080. Under this server, an HTTP daemon process is running on the server /usr/sbin/httpd on the port 8080, and that the /usr/sbin/httpd” server is on the 20.5.68.0 subnet.

Implicit Relationships

Implicit relationships display in the Operations Center Relationship Browser. Implicit relationships can show:

  • Machines that communicate with one another

  • Software that communicates across machines

  • Host-to-subnet relationships

These relationships are generated automatically when the appropriate nested generator tags exist within the hierarchy file. In other cases (unnested tags), the relationships must be explicitly enabled using a <param> tag.

The Operations Center Relationship Browser provides a graphic view of relationships among elements as well as navigation and layout customization tools. To open the Relationship browser, right-click an element in the Explorer pane, then click Show Relationships. For more information on using the Relationship browser, see the Operations Center 5.0 Service Modeling Guide.

Table 3-2 shows the mapping between <generator> tags and their field attribute values which automatically produces implicit relationships:

Table 3-2 Valid Nesting Sequences for Hierarchy File

Generator Tag field Attribute

Child Generator Tag field Attribute

Grandchild Generator Tag field Attribute

Relationships Mapped

businessapplication

applicationcomponent

appcompsoftwareitem

applicationcomponent to applicationcomponent communication

businessapplication

host

appcompsoftwareitem

appcompsoftwareitem to appcompsoftwareitem communication

applicationcomponent

appcompsoftwareitem

applicationcomponent to applicationcomponent communication

host

appcompsoftwareitem

applicationcomponent to applicationcomponent communication

In cases where generator tags are not nested, use the <param> tag. Nest the <param> tag within a <generator> tag to display the relationships in the Operations Center Relationship Browser.

To enable relationship display, set the <param> tag name attribute to showrelationships, and set the attribute value to True. To disable display, set the attribute value to False (which is the default).

For example, to display relationships between network devices:

<group class="gen_folder" name="Network Devices">
  <generator class_from_field="icon_name" field="networkdevice">
    <param name="showrelationships" value="true" />
  </generator>
</group>

Table 3-3 shows the <generator> tag field attributes that can be used with the <param> tag’s showrelationships name attribute, and the resulting relationships:

Table 3-3 Mapping Relationships using the <Param> Tab

Generator Tag field Attribute

Param Tag showrelationships set to True?

Relationships Mapped

networkdevice

Yes

All relationships between network devices

host

Yes

If networkdevice is in the same hierarchy, then display the relationship of host to subnet

applicationcomponent

Yes

The relationship between application components that communicate with one another

Relationships and Scoping of Data in Hierarchy File

The structure of the hierarchy file affects how relationships are mapped between elements displayed in the Relationship Browser. In most cases, elements under the same parent structure of <group> tags are considered to be within the same scope. This means that when relationships are mapped, these elements are mapped to one another.

Consider the following XML tags in the hierarchy file:

<group class="formula_organizations" name="All of my Structures">
  <group class="formula_organizations" name="My First Set of Structures">
    <generator class_from_field="icon_name" field="businessapplication">
      <generator class_from_field="icon_name" field="applicationcomponent">
        <generator class_from_field="icon_name" field="appcompsoftwareitem"/>
      </generator>
    </generator>
  </group>
  
  <group class="formula_organizations" name="My Second Set of Structures">
    <generator class_from_field="icon_name" field="businessapplication">
      <generator class_from_field="icon_name" field="host">
        <generator class_from_field="icon_name" field="appcompsoftwareitem"/>
      </generator>
    </generator>
</group>
</group>

The items under My First Set of Structures are within the same scope and the items under My Second Set of Structures are under a different scope.

However, in some cases, it is necessary to map items that are in different scopes. This occurs in the case of the field types host and network device. Assume that you want to map subnet relationships by setting a <param> tag to showrelationships on the host field attribute of a <generator> tag. If both of these tags are present, then the scope is the parent that they both share.

Consider the following data in the hierarchy file:

<group class="formula_organizations" name="Discovered Objects" >
  <group class="gen_folder" name="Network Devices">
    <generator class_from_field="icon_name" field="networkdevice">
    </generator>
  </group>
  <group class="gen_folder" name="Hosts">
    <generator class_from_field="icon_name" field="host">
      <param name="showrelationships" value="true" />
    </generator>
  </group>
</group>

In this case, items under Network Devices and Hosts are mapped in the resulting subnet/host relationships displayed in the Relationship Browser. This is because they have the common parent Discovered Objects.

Updating TADDM Data

The TADDM adapter properties (see Section A.18, IBM Tivoli Application Dependency Discovery Manager (TADDM)) allow you to set a data refresh interval to make updates from a discovery. Setting a refresh interval is not recommended because relationships are not updated and deleted nodes are not removed. If a new discovery is made in TADDM, the preferred practice is to restart the TADDM adapter. However, if you do set a refresh interval, the minimum allowed poll time is 15 minutes.

Displaying Node Properties

Each TADDM adapter element that in the Operations Center console has a set of properties which can be displayed by right-clicking the element and selecting Properties. In the left pane of the properties window, select TADDM Properties.

3.1.3 Scheduling Updates of Discovery Data

In some cases, a TADDM user might periodically re-run discoveries through the TADDM client on a scheduled basis, potentially causing the discovery data in the Operations Center TADDM integration to become out of date.

A scheduled job to refresh the integration at a specified time can be run to refresh the data. Determine how often this restart of the integration needs to occur and when it needs to take place based on how often a discovery is scheduled to run in TADDM.

To run a job to schedule a restart of TADDM:

  1. In the Explorer pane, navigate to Enterprise >Administration > Time Management > Jobs.

  2. Right-click Jobs and select Create Job. The Create Job dialog opens.

  3. Specify the name and description of the job in the fields provided.

  4. Set the schedule for the job as appropriate.

    For more information about creating and scheduling jobs, see the Operations Center 5.0 Server Configuration Guide.

  5. Specify the script to run by doing the following:

    1. Click the Job Script tab.

    2. Specify the name for the script. For example, updatetaddm.fs.

    3. Paste the following script text into the script editor:

      ////////////////////////////////////////////////////////////////// A utility to stop and then start a TADDM adapter.///////////////////////////////////////////////////////////////////var adapters = formula.server.adapters();// The name of the adapter as appears under the "Adapters" node.var adapterName = "Adapter: IBM Tivoli Application Dependency DiscoveryManager"; for( var i = 0 ; i < adapters.length ; i++ ){ if( adapters[i] != null && adapters[i].key().equals( adapterName ) ) { if( !adapters[i].manageStatus().startsWith( "stop" ) ) { writeln( "Restarting TADDM adapter" ); // Recycle adapters[i].manageStop(); // stop ... adapters[i].manageStart(); // then start. } break; }}

    4. Update the value for the adapterName variable with the name of your TADDM adapter as it appears under the Enterprise > Administration > Adapters in the Explorer pane.

  6. Select Enable Job.