– Medios de comunicación

We separate the discussion of data integration into the following areas:

򐂰 Resource data integration involves discovering and correlating resource information across various products by using the Common Data Model and IDML exchanges. See 5.2, “Resource data integration” on page 135.

򐂰 Event data integration involves event data transfer from a product to another product, including status synchronization between events that reside in separate platforms. See 5.3, “Event data integration” on page 176.

򐂰 Report integration introduces and explains the platform to provide unified reports about how Tivoli products perform. See 5.4, “Reports integration” on page 218.

򐂰 Other data integration.

In this section, we also discuss the concept of the Common Data Model:

򐂰 5.1.1, “Common Data Model” on page 130

򐂰 5.1.2, “IDML data” on page 132

5.1.1 Common Data Model

The Common Data Model is an information model that provides consistent definitions for managed resources, business systems and processes, and other data, and the relationships between those elements.

The Common Data Model is used to integrate the understanding of data and the exchange of data between management products that concern the resources and components of a client’s business. The Common Data Model is entirely composed of data definitions. These definitions are characteristics that identify resources, their meanings, and any restrictions on their lengths or values.

There are several industry data models, each one with a specific focus and specific implementation details. None of those industry models covers all client scenarios and needs; therefore, it is difficult to select just one.

The Common Data Model aims to absorb the best of each industry model and to provide a best-of-model solution. The content of the Common Data Model is obtained by merging applicable industry information, data model standards, and the data models that are used by current products into a single, converged model.

The applications that use the Common Data Model are able to share definitions

enabling the construction of higher level applications that encompass the overall management environment and share information between those systems.

The Common Data Model differs from a schema. A schema is usually associated with a database. It includes both the organization of data into a logical model and the specification of how that data is stored in specific columns of specific tables (also known as the physical model of the database).

The Common Data Model represents a logical model, which is composed of definitions, that enables the consistent identification of resource instances, information about them, and relationships between them. The data model links business and infrastructure processes with the systems that provide them, the users that invoke them, the policies that control them, the resources that processes use, and much more. The Common Data Model classifies and organizes the most commonly managed characteristics of users, resources, and business infrastructure information and processes and presents them in a way that all applications can use.

The Common Data Model has the following characteristics:

򐂰 It does not define the physical schema, and it does not define how a management system operates.

򐂰 It defines the resources and characteristics of a management environment that the management system monitors, analyzes, and controls.

򐂰 It is also in use when management applications exchange information about resource instances and their relationships to other resources.

򐂰 It standardizes the characteristics, the concepts of classes, attributes, interfaces, naming rules, and naming policies, and the data types that are in use.

򐂰 It provides consistent definitions of items, best practices for content, and guidelines for mapping resource instance data to the Common Data Model.

To foster integration among products, use the Common Data Model as the basis of your data modeling and interactive design. Because the Common Data Model is an information model, products are able to maintain their existing database schemas and also utilize the Common Data Model. When integrating with other products (such as when loading information into the IBM Tivoli Change and Configuration Management Database (CCMDB)), you need to use Common Data Model definitions and terminology. Using Common Data Model definitions and terminology fosters a consistent, one-time integration function that is reusable across multiple solutions.

We use the Common Data Model as an information model for data integration.

When managed resources and business components are modeled using

Common Data Model specifications, Tivoli management products can understand and more easily exchange data across the enterprise.

This capability allows multiple IBM Tivoli management products that run in a single enterprise to work together. Although each of these products still maintains its own separate data that is related to the set of resources that it manages, the data maintenance and administration efforts for these multiple formats can be minimized.

The Common Data Model provides a language specification to describe

infrastructure resources, their attributes, and relationships. It is based on Unified Modelling Language (UML) and includes influences from various management products, client solutions, and industry standards, including:

򐂰 Distributed Management Task Force (DMTF)

򐂰 Common Information Model (CIM)

򐂰 Business Process Execution Language (BPEL)

򐂰 IT Infrastructure Library (ITIL) specification

򐂰 Lightweight Directory Access Protocol (LDAP) directory schema

򐂰 TeleManagement Forum (TMf)

򐂰 Storage Networking Industry Association (SNIA)

The Common Data Model is used to define the external representation of Configuration Item (CI) information, as well as representations of infrastructure throughout the enterprise. It is used to exchange data across multiple

applications, such as IBM Tivoli Application Dependency Discovery Manager, IBM Tivoli Change and Configuration Management Database, IBM Tivoli Network Manager for IP, IBM Tivoli Business Service Manager, and other applications that support the Common Data Model. For more information about the Common Data Model, refer to IBM Tivoli Common Data Model: Guide to Best Practices, REDP-4389.

5.1.2 IDML data

The Identity Markup Language (IDML) is an Extensible Markup Language (XML) dialect that is used to describe resource instances and their relationships according to the Common Data Model. Processes that produce these IDML files are called Discovery Library Adapters (DLA). DLAs are an easy-to-develop, lightweight solution that allows for rapid integration between management products, customer data, and other third-party data sources. These IDML files are created by DLAs on a periodic frequency (set by the client) and then sent to a common location (set by the client) for multiple management products to

consume the same set of IDML files.

As a discovery technology, IBM Tivoli Application Dependency Discovery Manager is a powerful tool for discovering information about hardware and software assets, including relationships and dependencies. Additional information about these assets from files, databases, and other sources is needed. This information is reformatted and written as Identity Markup Language (IDML) files that IBM Tivoli Application Dependency Discovery Manager can import.

IBM Tivoli Application Dependency Discovery Manager provides a generic IDML reader that can load several books into the database at a time. This loader is also referred to as the BulkLoader. Figure 5-1 shows the process of importing the IDML books into IBM Tivoli Application Dependency Discovery Manager.

Figure 5-1 Importing IDML books inside IBM Tivoli Application Dependency Discovery Manager

As a result of execution, Discovery Library Adapters generate Identity Markup Language (IDML) files that contain the resource attributes and relationships that are known by a particular data source. These IDML files, otherwise known as DLA books, should be placed into a directory called the Discovery Library File Store (DLFS). These IDML-based files can be imported from the Discovery Library File Store into the discovered CI data space of the IBM Tivoli Change and Configuration Management Database. The bulk loader is run as a program that honors the reconciliation logic while batch importing the data. The bulk loader allows the data to arrive from separate data sources at various times to reconcile

TADDM Server

together into a single representation, in order to guarantee the uniqueness of the Configuration Item resource data.

Some DLAs are written by IBM to extract information from management applications, while other DLAs are written by third-party providers. You can obtain a recent list of DLAs at this Web site:

https://www.ibm.com/developerworks/wikis/display/tivoliaddm/Discovery+L ibrary+Adapters

Most of the DLA tools are recorded in the Tivoli Open Process Automation Library (OPAL) Web site:

http://www.ibm.com/software/tivoli/opal

The bulk load program is an efficient way to load large numbers of managed elements and relationship definitions into the IBM Tivoli Application Dependency Discovery Manager database. The bulk loader must be run by the user that starts and stops the IBM Tivoli Application Dependency Discovery Manager server. A sample command to run the bulk loader is shown in Example 5-1.

Example 5-1 Running bulk loader su - cmdbadmin

export ${COLLATION_HOME}=/opt/IBM/cmdb/dist cd $COLLATION_HOME/bin

./loadidml.sh -f <dlfs> -h <hostname> -u <userid> -p <passwd>

The execution result of the bulk loader resides in these files:

򐂰 $COLLATION_HOME/dist/bulk/results/xxxxx.results

򐂰 $COLLATION_HOME/dist/log/bulkload.log

For additional details about the contents of the results file, you can turn on statistics data from the $COLLATION_HOME/dist/etc/collation.properties file:

com.ibm.cdb.bulk.stats.enabled=true

The settings of the bulk loader are stored in the bulkload.properties file. You must ensure that the working directory and the results directory that are mentioned in the bulkload.properties file are valid.

For more information about IDML and its API, see this Web site:

Note: The working directory and the results directory must preexist, or the bulk loader does not run. It does not automatically create these directories.

http://publib.boulder.ibm.com/infocenter/tivihelp/v10r1/topic/com.ibm.t addm.doc_7.1.2/DLADevGuide/c_cmdbsdk_dla_introducing.html

Several of the Common Data Model APIs can be invoked using the api.sh script.

For example, you can query information in IBM Tivoli Application Dependency Discovery Manager by running the command:

./api.sh -u <taddm_admin> -p <password> find "select * from

com.collation.platform.model.topology.process.ManagementSoftwareSystem where guid=='<GUID>'"

More information about the api.sh command can be found at this Web site:

http://publib.boulder.ibm.com/infocenter/tivihelp/v10r1/topic/com.ibm.t addm.doc_7.1.2/SDKDevGuide/r_cmdbsdk_cliapi_commandsyntax.html