TADDM Connector

Use the TADDM Connector to communicate with IBM® Tivoli® Application Dependency Discovery Manager (TADDM) server using TADDM Java APIs (TADDM SDK).

Introduction to TADDM Connector

TADDM is a management tool that supports configuration items (CIs) and relationships between them. This configuration information is collected through periodic automatic discoveries, which can scan the entire application infrastructure of a business organization. The collected data includes deployed software components, physical servers, network devices, virtual LAN and host data. In addition, TADDM provides a centralized topology view of the discovered data, change and version tracking, and report generation function.

TADDM allows other applications to load data into and retrieve data from its database using one of the following techniques:

• Writing a Java application using TADDM APIs
• Processing XML files (IdML books) and using the TADDM command-line interface
• Calling TADDM SOAP or REST API

The TADDM Connector uses Common Data Model (CDM), an IBM data integration initiative, to represent the transferred data. For more information, see Asset Integration Suite .

The TADDM Connector supports AddOnly, Delete, Iterator, Lookup, Update, and Delta operation modes.

TADDM data representation model

TADDM uses a cyclic hierarchical model for representing its information. For example, the OperatingSystem item can have simple attributes such as Name, Release, and FQDN along with a related ComputerSystem item, where the operating system is installed. The ComputerSystem item can have one or more related CPUs as child attributes as graphically depicted in the following hierarchical data model.

OperatingSystem
	Name=Windows
	Release=1.2.3
	FQDN=www.myfqdn.com
	ComputerSystem (Parent)
		SerialNumber=1234567
		Manufacturer=IBM
		CPU (Parent)
			CPUSpeed=2500000000
			IndexOrder=5
		CPU (Parent)
			CPUSpeed=2500000000
			IndexOrder=5	
			ExternalCache=1000

To support TADDM data model, the TADDM Connector uses the hierarchical capabilities of Tivoli Directory Integrator Entry.

In the preceding data structure, the attributes of the OperatingSystem item, for example, Name, and theComputerSystem item, are child attributes of the Entry. The CPUs are the child attributes of ComputerSystem, and so on. For more information about attribute arrangement, see the Schema comparison section.

Common Data Model

The logical model for representing items and their relationships in an infrastructure is called as Common Data Model (CDM). This model defines the supported items types and relationships (or class types), and the ways they can be linked. In addition, it specifies the attributes supported by each class type and its naming rules.

The attributes of an item provide information about it. The ComputerSystem item holds its serial number and manufacturer details. These two attributes have simple values such as numbers or strings, and are called as explicit attributes.

The implicit attributes are used to represent a relationship in an item. As shown in the following figure, the OperatingSystem is installed on ComputerSystem and shares an installedOn relationship, as defined by CDM, with OperatingSystem as its source and ComputerSystem as its target. The relationship in the OperatingSystem item is represented by its Parent attribute and the ComputerSystem item has an OSInstalled implicit attribute.

Figure 4. Common Data Model

Each naming rule of a class type is composed of one or many implicit and explicit attributes and defines a unique way to identify the items. To register an item in the IdML consumer, provide its attributes to satisfy at least one of the naming rules of the item, to uniquely identify the resource and also to avoid rejection. The attributes in a naming rule are also called as identifying. In the example shown above, the identifying attributes of the OperatingSystem are Name (explicit) and Parent (implicit). Both Name and the ComputerSystem attributes are required for unique identification.

Data representation formats

This section describes various data representation formats used by the products.

TADDM model

TADDM has both implicit and explicit attributes, configuration items, and relationships between them. The attribute names start with lowercase except for names with two or more starting capital letters. For example, Name changes into name while OSInstalled stays unchanged.

TADDM uses the following naming format for the class type:

• Short name for its class types. For example, ComputerSystem instead of sys.ComputerSystem
• Fully qualified names in the TADDM namespace. For example, com.collation.platform.topology.sys.ComputerSystem

The CDM names are used for the class types, if there is a collision when the short names are used. For example, the short name SSLSettings can correspond to both app.SSLSettings and app.lotus.SSLSettings. In this case, the CDM names are used.

IT registry model

IT registry model supports only explicit attribute names except for implicit naming attributes. In this model, the items are registered in a single operation. For example, for the OperatingSystem attribute, you need to provide its naming context (ComputerSystem), along with the explicit attributes. The registration is achieved using ad-hoc attributes, which can either hold the unique identifier of the other item (Guid) or its identifying attributes.

However, the implicit non-identifying attributes are not supported and their meaning is implemented by adding relationships between the items.

IdML book format

The IdML books are XML files that hold information for items and relationships in the context of a particular Management Software System. The attribute and class names match the CDM model.

The IdML book format has no implicit attributes. In this model, the information is stored in a file and you can add the explicit attributes of the ComputerSystem item as an XML element followed by the explicit attributes of the OperatingSystem, and provide an XML element for the relationship between them. Parse the content of entire IdML book before it can be imported into another system. This task can be delegated to bulk loading utilities.

The following table lists the differences among the three data representation models:

Implementing unified schema in TADDM

The TADDM Connector uses a new schema, which is the unification of all the differences from various data formats described in the previous section. The TADDM Connector uses the solutions described in the following sections for the basic differences and problems.

Explicit attribute names and class types

All names are changed to match their corresponding CDM versions and follow the following naming convention:

• Attribute names start with a capital letter, for example, Signature.
• Relationship types have lowercase names without namespaces, for example, installedOn.
• Class types are capitalized names with a namespace, for example app.web.GenericWebServer.

Implicit attributes

Each implicit attribute name consists of relationship type, related class type, and direction of the relationship. For example, the OSRunning implicit attribute of sys.ComputerSystem can be a runsOn relationship to a sys.OperatingSystem item with a reversed direction, that is, from OperatingSystem to ComputerSystem.

Identifiable data

As shown in the example data structure, the TADDM data (CDM format), is hierarchical and linked. If you choose to read an item, for example, a CPU, it might be linked to a ComputerSystem, which in turn is linked to an OperatingSystem. For reading only one type of item, you need to retrieve many attributes. If you need only the CPU, set the value 1 for the Depth parameter and retrieve its explicit attributes. The implicit attributes contain only the Guid of the ComputerSystem. This data is not identifiable if you choose to store in an IdML mode.

The ComputerSystem with CPU defined, has only its Guid and does not comply with any of the naming rules. To solve this problem, additional processing is done for the new schema. Each retrieved item is validated against its naming rules and skips if it does not match any of them. For example, the ComputerSystem is skipped, and if the CPU is identified in its context, this item is also skipped. Alternatively, if the CPU has other attributes, it stays in the retrieved result. You can also increase the value of Depth parameter, which allows you to uniquely define the ComputerSystem item.

The unified schema requires more processing such as name transformations, naming rule retrieval, and validation. Therefore, the TADDM Connector has an optional feature called IdML Mode.

Data representation modes

The TADDM Connector supports the following two modes of data representation:

• Native mode - direct data representation
• IdML mode - unified schema created for consistent data transfer between CDM-aware systems.

Use the native mode if you want to work with TADDM. For example, instance registering of data read from a CSV file. To export all computer systems to an IdML file, use the IdML mode (the IdML Connector is used in this scenario).

IdML mode

In the IdML mode, all explicit attributes are represented with their CDM names capitalized and are prefixed with cdm: For example, attribute managedSystemName becomes cdm:ManagedSystemName. Implicit attributes consist of two parts namely, relationship and a related class. The related class carries information for the relationship direction. Thus, the sys.ComputerSystem's attribute OSRunning changes to cdm-rel:runsOn . cdm-src:sys.OperatingSystem (for clarity, the two parts are separated with additional spaces). The first part, cdm-rel:runsOn, describes the relationship as seen in the prefix cdm-rel. The second part represents a related type of class sys.OperatingSystem and its prefix, if the related item is the source of the relationship.

In the reversed scenario, sys.OperatingSystem has an implicit attribute called Parent. In the unified model, this attribute changes to cdm-rel:runsOn . cdm-trg:sys.ComputerSystem.

In the IdML mode:

• All explicit attributes and class types use the cdm: prefix.
• All implicit attributes are composed of two parts:
  • Relationship name with prefix cdm-rel:
  • Related class type with prefix cdm-src: if the item is source of the relationship, or cdm-trg:, if the item is target of the relationship.

Native mode

In the native mode, there are no modifications to the class types and attribute names. The only addition to the standard TADDM data is that all implicit attributes of an item are added as children attribute of $implicit. For example, if you have an implicit attribute OSInstalled, it changes to $implicit.OSInstalled.

Schema comparison

The following example data structure, in native mode and IdML mode, shows an operating system with installed software.

{
    cdm:Name=Windows
    cdm:Release=3.3.4
    cdm-rel:installedOn {
        cdm-trg:sys.ComputerSystem {
            cdm:Signature=12345
            cdm:Manufacturer=IBM
            cdm:Fqdn=www.sample.com
            cdm-rel:contains {
                cdm-trg:sys.CPU {
                    cdm:IndexOrder=2
                    cdm:ExternalCache=1000
                    cdm:CPUSpeed=2500000000
                }
                cdm-trg:sys.CPU {
                    cdm:IndexOrder=1
                    cdm:CPUSpeed=1500000000
                }
            }
        }
        cdm-src:app.SoftwareInstallation {
            cdm:ProductName=Notes
            cdm:ManufacturerName=IBM
            cdm:InstalledLocation=C:\notes
        }
    }
}

{
    name=Windows
    release=3.3.4
    $implicit {
        parent {
            signature=12345
            manufacturer=IBM
            fqdn=www.sample.com
            $implicit {
                CPU {
                    indexOrder=2
                    externalCache=1000
                    CPUSpeed=2500000000
                }
                CPU {
                    indexOrder=1
                    CPUSpeed=1500000000
                }
            }
        }
        softwareInstallation {
            productName=Notes
            manufacturerName=IBM
            installationLocation=C:\notes
        }
    }
}

You can switch between these two modes of data representation using the IdML Mode option in the Configuration Editor. To check the structure of the current schema, use the Query Schema function of the TADDM Connector.

System attributes

The TADDM Connector supports three system attributes that are used in different situations. When reading the data from TADDM, each returned object (root object and related objects) has the $classType attribute that holds its type. If IdML mode is enabled, the CDM class type is used, for example, sys.ComputerSystem. In native mode, the TADDM class type is used, for example, com.collation.platform.model.topology.sys.ComputerSystem. In AddOnly mode, the attribute can be used for changing the registered item type at run time. For more details, see the Creating new model objects section.

The, $id attribute holds the unique identifier of the processed item. When reading data from TADDM, it holds the Guid of the item (the same value as attribute guid/cdm:Guid). When writing data to TADDM and if it is coming from another system (for example, an IdML book), the $id attribute holds the corresponding ID attribute of the IdML element (a simple identifier without a special format). In AddOnly mode, the attribute is used for resolving cycles and preventing data duplication.

The $cycle attribute is used when a loop in the TADDM data is detected. If you list the content of the first item, you get the second item, through the forward implicit attribute. The second item links back to the first item causing a loop. Such situations are resolved by checking whether the current item is not found anywhere higher in the hierarchy path. If found, only $id is kept as the value of the $cycle attribute.

Using the Connector

Basic configuration

The TADDM Connector depends on TADDM Java API for communicating with a TADDM server. Therefore, you need to specify the path of TADDM SDK in the Configuration Editor. This SDK includes JAR libraries, configuration files, and documentation for the TADDM model.

The host name of the TADDM server must be specified along with a user name and password. If the port number, on which the TADDM server listens, is not specified, the value of property com.collation.api.port from the taddm-sdk/etc/collation.properties file is used. Default port number is 9530. For SSL connections, the value of property com.collation.api.ssl.port is used.

You can manually enter a class type, or click the Select button in the Configuration Editor to select a TADDM supported class type. If you select the IdML Mode check box, the listed types are prefixed with cdm:, and in native mode, the types are not prefixed. Leaving the IdML Mode field blank, results in an iteration of all (regardless of type) items in the TADDM database. For more details, see the Reading configuration items and relationships from TADDM section.

If you select the Configuration Item resource type from the Artifact Type selection list in the Configuration Editor, only the item class types are listed when you click the Select button. If the Relationship resource type is selected, only the known relationships are displayed. This filter option is supported only in native mode. In IdML mode, the relationships are not supported, and the Artifact Type field is disabled.

{
    guid=D234B679309DCE
    hostname=www.sample.com
    VMID=12
    $implicit {
        hostSystem {
            guid=6859GA5934B1
            signature=4530093
            serialNumber=12345
            $implicit {
                CPU {
                    indexOrder=12
                    CPUSpeed=10000
                    guid=0BCA35EF1
                }
            }
        }
     }
}

MSS support

The TADDM Connector supports specifying a Management Software System (MSS) Guid when working with TADDM. Using Tivoli Directory Integrator user interface, you can list all the available MSS and select the required Guid. See the Configuration section for user interface details.

When reading data from TADDM, for example, Iterator or Lookup mode, only the items registered by the selected MSS are retrieved or searched.

When adding new items to TADDM (AddOnly mode), the MSS shows TADDM that the item is being registered for the specific MSS. If you subsequently read this item back, you need to list the MSS data in the Entry, if the MSS Information check box is selected in the Configuration Editor.

Querying TADDM

When you specify the class type, the TADDM Connector retrieves the items from that type. The TADDM Connector forms an MQL query and the query is run against the TADDM database. MQL is a TADDM invention used for retrieving data from its database. The MQL does not support all SQL features and is useful when you need to limit the number of returned items. The following query is constructed when only the class type of the item is provided.

	SELECT * FROM class-type

If depth is 0, the generated query is modified as shown.

	SELECT guid FROM class-type

MQL also supports complex WHERE clauses and INNER JOIN. In Iterator mode, the TADDM Connector uses these capabilities through the MQL Select field in the Configuration Editor. If you provide a query in this field, it overrides the Class Type parameter. The following example query returns all OperatingSystem-s with name "Windows".

	SELECT * FROM OperatingSystem WHERE OSName == 'Windows'

A complex query can, for example, return the names of all Db2Server-s, the ports of which match the OracleInstance-s and in addition each Db2Server that runs on a ComputerSystem manufactured by IBM.

	SELECT Db2Server.* FROM Db2Server, OracleInstance 
   WHERE Db2Server.port == OracleInstance.port 
		AND DB2Server.host.manufacturer contains 'IBM'

This query uses both implicit attributes (the $implicit attribute is not used) and an inner join. For more information about the query language, see the TADDM MQL documentation.

The MQL Select parameter supports parameter substitution. The available objects that can be used are:

• Connector - to access the methods of TADDM Connector
• config - for connector configuration
• mc - for metamerge configuration.

In addition, the MQL Select field supports auto-complete capability and the Link Criteria dialog box transfers the condition into the regular MQL statement.

The MQL Select field is dependent on IdML mode. When IdML mode is enabled, an additional filtering feature is turned on. You can specify both class types and attribute names (implicit and explicit) as defined by the unified schema described in the IdML mode section.

	SELECT cdm:Signature FROM cdm:sys\.ComputerSystem 
WHERE cdm-reln:virtualizes.cdm-trg:sys\.ComputerSystem.cdm:NumCPUs == '3'

This query returns the signatures of all virtual computer systems present on a computer system with 3 CPUs.

The Fetch Size parameter indicates the size of the buffer used when reading data from TADDM. By changing the size, you can fine-tune the performance of your Tivoli Directory Integrator solution. For example, if the connector is to read 100 items (with depth 1) from the TADDM server, and the Fetch Size is more than 100, then a single bulk request is performed and all the data is retrieved.

Retrieving additional attributes

This section describes the additional attributes that TADDM Connector provides.

{
    $mss {
       cdm:process.ManagementSoftwareSystem {
           cdm:MSSName=MSS1
           cdm:Guid=12BA843..2FF
       }
       cdm:process.ManagementSoftwareSystem {
           cdm:Guid=12BA843..2FF
           cdm:Hostname=www.sample.com
           cdm:ProductName=TDI
           cdm:ManufacturerName=IBM
       }
    }
}

Searching for specific model objects

In the Lookup mode of operation, the TADDM Connector searches for a particular item using the TADDM MQL capabilities.

You can search for items either providing link criteria in the Configuration Editor or building advanced criteria from the custom script. The formula for creating the resulting MQL query is:

	SELECT * FROM class-type WHERE criteria

If the value Depth parameter is 0, use the guid attribute instead of ‘*'.

Since MQL offers extended criteria capabilities, all of Tivoli Directory Integrator link criteria match conditions are supported and mapped to their MQL synonyms.

Similarly, to the MQL Select parameter, when IdML Mode is enabled, the criteria in Lookup mode supports unified schema names. Avoid the ’.’ in CDM class types, such as app.db.db2.Db2Server, sys.CPU, and so on.

Reading configuration items and relationships from TADDM

You need to specify the type of item to be read by the TADDM Connector. The TADDM exposes items in a table structure, where the class type of item denotes the table name. See the Querying TADDM section for details.

The TADDM Connector supports working without an explicitly configured class type in both Iterator and Lookup modes and traverses all TADDM items. Using this function, you can either retrieve all items (Iterator mode) or perform a general search over the whole TADDM data (Lookup mode).

Since this behavior is achieved through multiple queries against the configured TADDM server (one for each type), if any of the queries fail, the TADDM Connector does not exit, but logs a debug message and continues with the next query.

When reading all items from the TADDM database, if IdML mode is enabled, the TADDM Connector exits prematurely with the following exception: CTGDJN095E Unable to get the IdML compliant name of attribute 'attr-name' from class 'class-name'. For more details, see the Troubleshooting TADDM Connector section.

Deleting model objects

Use the Delete mode of operation to clear the unwanted items and relationships from TADDM. It performs a Lookup operation and then tries to delete the discovered item. For the delete operation, the TADDM API requires only guid of the item, and the connector uses the $id system attribute.

When the multiple matching items are found, the On Multiple Entries hook is started, and you can iterate the discovered items and delete them. Additionally, you can add all the $id-s of the found items to the first discovered item and provide it to the connector. When the connector detects multiple IDs, they are all deleted in a single TADDM request.

The hook script is as follows:

var first = thisConnector.getFirstDuplicateEntry();

var next = thisConnector.getNextDuplicateEntry();
while (next != null)
{
	var id = next.getString("$id");
	first.addAttributeValue("$id", id);
	next = thisConnector.getNextDuplicateEntry();
}

thisConnector.setCurrent(first);

Creating new model objects

In the AddOnly mode of operation, the TADDM Connector creates objects in TADDM. Due to CDM naming rules, the TADDM considers that the object creation process and object update process are similar. The attributes are updated, if the provided attributes are the same as the existing TADDM object.

To register an item, you need to provide the identifying attributes and is also applicable for the related items. Alternatively, instead of supplying identifying attributes, you can set the $classType and guid attributes of the related item. This data is not sufficient for creating such model objects, but in this case, the TADDM Connector attempts to handle that model object. If such data is found, it is added to the created model object. To take advantage of the guid lookup function, only the $classType and $id attributes are considered. Using this feature, you can add an explicit relationship between two existing items in TADDM.

The $classType system attribute can be modified at run time and enables the TADDM Connector to switch the type of the created item. You can also use the $cycle system attribute in AddOnly mode. This attribute helps to avoid duplicating the identifying attributes of a related item, if it is already specified higher in the hierarchy path of the current entry. You need to set unique identifier of the item in the $cycle attribute to retrieve all the information from its original location.

When the new model object is registered in TADDM, its Guid is returned through the conn Entry. The value can be retrieved by using the following scripting code in the After Add hook:

var guid = conn.getString("$id");

Design-time naming rules validation

The TADDM Connector provides support for validation of attributes, mapped in its Output Map, against the naming rules of the chosen CDM class type

Click the Validate button present in the Output Map of the Connector in the Configuration Editor to validate all attributes and display the results in the Problems view. There is a message for each of the naming rules of the specified class. If at least one naming rule is satisfied, all messages in the Problems view are marked as information. If none is satisfied, messages are marked as error. Each message shows that which attributes need to be added or removed to satisfy the rule.

Updating an existing model object

In the Update operation mode, you can update existing model objects. In TADDM, object creation and update process are same. Refer to the Creating new model objects section for more details. However, there are some additional specifics to be considered when updating an existing model object.

If you try to update a single-valued implicit attribute that does not exist, TADDM creates an attribute. If exists, the attribute is updated.

{
   $classType=sys.ComputerSystem
   Guid=A027...2ECB
   displayName=777-888
   signature=777-888
   $implicit {
      OSRunning{
      $classType=sys.OperatingSystem
      $id=3F62F...B5AD
      guid=3F62...B5AD
      displayName=976063427
      FQDN=fqdn/976063428
      }
   }
}

{
  $implicit {
   OSRunning{
   displayName=976063429
   }
 }

{
   $classType=sys.ComputerSystem
   Guid=A027...2ECB
   displayName=777-888
   signature=777-888
   $implicit {
      OSRunning{
      $classType=sys.OperatingSystem
      guid=3F62...B5AD
      displayName=976063429
      FQDN=fqdn/976063428
      }
   }
}

If you want to update one of the values of a multi-valued implicit attribute, you need to provide its guid in the Output Map. Else, a new value is added instead of updating an existing value.

The update Entry with Guid provided is as follows.

{
   $classType=sys.ComputerSystem
   Guid=A027...2ECB
   displayName=777-888
   signature=777-888
   $implicit {
      OSInstalled{
      $classType=sys.OperatingSystem
      guid=3F62...B5AD
      displayName=976063427
      FQDN=fqdn/976063428
      }
   }
}

{
  $implicit {
    OSInstalled{
    guid=3F62...B5AD
    displayName=976063429
  }
 }

{
   $classType=sys.ComputerSystem
   Guid=A027...2ECB
   displayName=777-888
   signature=777-888
   $implicit {
      OSInstalled{
      $classType=sys.OperatingSystem
      guid=3F62...B5AD
      displayName=976063429
      FQDN=fqdn/976063428
      }
   }
}

The update Entry with no Guid provided is as follows.

{
   $classType=sys.ComputerSystem
   Guid=A027...2ECB
   displayName=777-888
   signature=777-888
   $implicit {
      OSInstalled{
      $classType=sys.OperatingSystem
      guid=3F62...B5AD
      displayName=976063427
      FQDN=fqdn/976063428
      }
   }
}

{
  $implicit {
    OSInstalled{
    displayName=976063429
    FQDN=fqdn/976063429
  }
}

{
   $classType=sys.ComputerSystem
   Guid=A027...2ECB
   displayName=777-888
   signature=777-888
   $implicit {
      OSInstalled{
      $classType=sys.OperatingSystem
      guid=3F62...B5AD
      displayName=976063427
      FQDN=fqdn/976063428
      }
      OSInstalled{
      $classType=sys.OperatingSystem
      guid= 6030...E574
      displayName=976063429
      FQDN=fqdn/976063429
      }
   }
}

In addition, the TADDM Connector allows removing an explicit attribute from an existing model object by updating its value to null. To update, change the default null behavior to Return null value in the Output Map (click the More button in the Configuration Editor).

Delta mode support

In Delta mode, the TADDM Connector receives specific delta information. Based on the received information, the connector performs add, update, or delete operation on the provided Entry.

Data source schema of TADDM Connector

This section describes input schema and output schema of TADDM Connector.

Input schema

The following table lists attributes of the Input Map.

Output schema

The following table lists attributes of the Output Map.

Post-installation tasks

The TADDM Connector depends on TADDM SDK. The TADDM API JAR files are not shipped with Tivoli Directory Integrator. You need to perform the following tasks, before you start using the TADDM Connector, to avoid the unsupported modes such as Server and CallReply, and to get a list of supported class type:

1. Copy the TADDM SDK compressed archive file from the TADDM server and extract it to the system where Tivoli Directory Integrator is running. The TADDM SDK compressed file can be found at taddm-home/dist/sdk.

   The directory structure created for the TADDM 7.2 SDK is as follows:

   /sdk
    |--/adaptor - contains TADDM Discovery Library Adaptor 1.0
    |--/bin - contains useful shell scripts and batch files
    |--/dla - contains IBM® Discovery Library IdML Certification Tool
    |--/doc - contains English pdfs and other documentation files 
    |--/etc - configuration properties 
    |--/examples - samples directory 
    |--/lib - server and client runtime libraries 
    |--/log - runtime logs schema The XML Schema

2. Copy the following TADDK API JAR files to class path of Tivoli Directory Integrator.
   • taddm-sdk/lib/taddm-api-client.jar
   • taddm-sdk/lib/platform-model.jar
   For TADDM 7.1.2, the JAR file is at taddm-sdk/clientlib. Copy the files to /jars directory of Tivoli Directory Integrator, TDI_install_dir/jars/3rdparty/IBM, or the location specified by the com.ibm.di.loader.userjars property in solution.properties.

Troubleshooting TADDM Connector

This section provides information about the issues you might encounter as you use TADDM Connector, and describes how to troubleshoot them.

Throwing AccessException when using TADDM Connector

Problem

The exception is thrown when another component sets a restrictive security manager before you start the TADDM Connector for the first time. TADDM Connector relies on an all-permissive manager and unable to function properly.

Solution

Perform one of the following tasks:

• Restart the Tivoli Directory Integrator server and run the TADDM Connector first.
• Grant full permissions by default.

To grant full permissions:

1. Editing the TDI_install_dir/jvm/jre/lib/security/java.policy file.
2. Provide the following entry:

      grant {
            permission java.security.AllPermission;
      };

Throwing exception when reading data from TADDM in IdML mode

Problem

This problem is due to an inconsistency in the storage of implicit attributes in TADDM. Normally, each TADDM implicit attribute contains the name of the relationship it corresponds to. Missing of this information prevents the TADDM Connector from constructing the correct IdML model of the read data and exception is thrown. This problem is observed only for the Parent implicit attribute of class meta.UserDataMeta and process.CompositeAttributeDef.

Solution

You can switch to native mode to avoid the conversion. To switch to native mode, clear the IdML Mode check box in the Configuration Editor.

This exception is thrown when performing an iteration/lookup over all items in TADDM. The IdML mode is required for working with other CDM-aware components, for example, IdML Connector. In this scenario, you must override the Iterator Error/Lookup Error hook in the configuration of the TADDM Connector.

Configuration

This section describes the parameters of TADDM Connector. For basic configuration information, see the Basic configuration section.

Artifact Type

Use this parameter to specify the resource type, Configuration Item or Relationship, to be processed by the TADDM Connector.

Class Type

Use this parameter to specify the type of configuration item or relationship to be processed.

Note:

If this parameter is not specified when reading from TADDM, for example, in Iterator or Lookup operation mode, all configuration items or relationships are traversed.

If this parameter is not specified when writing to TADDM, an appropriate class type is supplied at run time.

To select a supported class, click the Select button in the Configuration Editor.

IdML Mode

Use this parameter to specify whether the IdML compatible data to be used for processing or not.

Depth

Use this parameter to specify the level of relationships to be traversed when reading model objects from TADDM.

Hostname

Use this parameter to specify host name of the TADDM server.

Port

Use this parameter to specify the port number to connect to the TADDM server. If this parameter is not specified, the default port number of the TADDM SDK is used.

Username

Use this parameter to specify a valid user ID to login to the TADDM server.

Password

Use this parameter to specify the password associated with user ID for the TADDM server.

TADDM SDK

Use this parameter to specify the location of TADDM SDK.

Note:

Ensure that the TADDM SDK is on the same system, where the Tivoli Directory Integrator instance, with the TADDM Connector, is running.

Click the Select... button in the Configuration Editor to locate the TADDM SDK.

MSS Guid

Use this parameter to specify the Management Software Systems (MSS) Guid from the TADDM server. MSS Guid can be used as a filter when reading or can be added to the new configuration item when writing.

Click the Select MSS button in the Configuration Editor to select an MSS Guid.

MQL Select

Use this parameter for querying TADDM using a custom MQL query to limit the amount of returned configuration items, by providing link criteria. This parameter can also be used to perform join operation between two class types.

Use SSL

Use this parameter to indicate whether an SSL connection needs to be established on the TADDM server.

Fetch Size

Use this parameter to specify the buffer size to be used while retrieving data from TADDM.

Domain Attributes

Use this parameter to specify whether the connector input to be enhanced or not with domain information such as host, and port.

Note:

The domain data is available only in enterprise TADDM infrastructures.

Extended Attributes

Use this parameter to specify whether a non-CDM data to be used for a specific configuration item and are defined only for a certain class type of items.

Explicit Relationships

Use this parameter to specify whether the explicit relationships of the read item to be checked. This option is available only for IdML mode.

MSS Information

Use this parameter to specify whether to return the information or not for the MSS associated with the read item. You can also have a stand-alone item, which is not associated with the MSS.

See also