Federation and TPAE

Introduction

This document describes how the Tivoli Process Automation Engine (TPAE) can be configured to use a federated data source.

Assumptions:

This document assumes that DB2 Enterprise Edition Server is being used as a backend database for the TPAE.

Configuration:

Run the following command to enable the federation in a DB2 instance:

DB2 update dbm cfg using FEDERATED YES

Scenario

Assume there is a DB2 database containing information about Computer System, to be federated with the Authorized CI space in the Change and Configuration Management Database (CCMDB). Here is the DB2 table definition:

COMPUTER_OWNER table

Column Name	Column Type	Length
COMPUTER_OWNER_ID	INTEGER
COMPUTER_NAME	VARCHAR	50
OWNER	VARCHAR	50

with the following contents:

COMPUTER_OWNERID	COMPUTER_NAME	OWNER
16	bush.my.com	Dan Quayle
18	bushw.my.com	Dick Chenney
14	carter.my.com	Walter Mondale
17	clinton.my.com	Al Gore
5	coolidge.my.com	Charles Dawes
9	eisenhower.my.com	Richard Nixon
13	ford.my.com	Nelson Rockfeller
7	froosevelt.my.com	John Garner
4	harding.my.com	Calvin Colidge
6	hoover.my.com	Charles Curtis
11	johnson.my.com	Hubert Humphrey
10	kennedy.my.com	Lyndon Johnson
12	nixon.my.com	Spiro Agnew
19	obama.my.com	Joe Biden
15	reagan.my.com	George Bush
2	taft.my.com	James Sherman
1	troosevelt.my.com	Charles Fairbanks
8	truman.my.com	Alben Barkley
3	wilson.my.com	Thomas Marshall

Configuring TPAE

Creating New Database Object

Although the COMPUTER_OWNER table will be federated from an external database, in order to use this table in TPAE, it needs to be defined using the Database Configuration application (under System Configuration -> Platform Configuration).

• In the Database Configuration application, click New Object:

• Type COMPUTER_OWNER in the Object field, and Computer Owner in the Description:
  

• In the Attributes tab, add the attributes COMPUTER_NAME and OWNER and delete the attribute DESCRIPTION:

• Save the new Database Object.

Applying the Database Change

• Make a backup of the TPAE database
  
• Go back to the List tab
• In the Select Action pull down menu, choose Manage Admin Mode
• Click Turn Admin Mode ON

• Click the Refresh Status button until the Admin Mode is set to ON:

• Close the Turn Admin Mode ON dialog
• In the Select Action pull down menu, click Apply Configuration Changes
• Select the Do you have a current backup? checkbox
• Click the Start Configuring the Database button:

• Click the Refresh Status button until the End ConfigDB message is displayed:

• Close the Structural Database Configuration dialog.
  

Creating the Relationship

• Select the CI Object:

• Click the Relationships tab
• Add the new Relationship, specifying the following information:
  
• Relationship: COMPUTER_OWNER
• Child Object: COMPUTER_OWNER
• Where Clause: computer_name = :cinum
  

• Save the new Relationship
• Go back to the List tab
  

Modifying TPAE GUI to show the federated information

In this step, we'll add the Computer Owner to the TPAE GUI.

• Go to Application Designed (under System Configuration -> Platform Configuration).
• Select the CI application:

• Click the Configuration Item tab
• Select the Organization attribute:

• Right-click the CI Location attribute and click Copy
• Click the section containing the CI Location attribute:

• Right click the section and select Paste. A copy of the Organization attribute is put in the section.
• Right-click the new Organization field and select Properties
• In the Attribute field, type COMPUTER_OWNER.OWNER
• Define a value in the Label field:

• Save your work in the Application Designer
  

Configuring Database Nickname

So far, the database still contains a table (created through the Database Configuration application). We'll redefine it as a nickname to the table in another database.

Registering the Federated Database in the TPAE Database Server

If the federated database is in another database instance, the database needs to be registered in the TPAE database server.

• Run the following command to register the node:
  
  db2 catalog tcpip node federate remote <remote_db_server> server <remote_db_port>
  
• Run the following command to register the instance:
  
  db2 catalog db <remote_db> at node federate
  

Creating the Database Nickname

• In the DB2 Control Center, expand the options under MAXDB71 and select Tables
• The application shows all tables. Right-click the table COMPUTER_OWNER and select Drop
  
  
  
  
• In the left side, under MAXDB71, right-click Nicknames and select Create..
• In the Introduction screen, click Next
• In the Specify the data source and the wrapper, select DB2.
• Click the Create... button in the Wrappers area.
• Click OK in the Create Wrapper dialog.
• Click Next.
• In the Specify the server definition for the data source, click the Create... button
• In the Create Server Definitions dialog, click the Discover.. button
• Select the federated database and define the Type and Version:
  
• Click Properties...
• In the Server Definition Properties dialog, type the User ID and Password:
  
  
• Click OK to close the Server Definition Properties
  
• Click OK to close the Create Server Definitions
• In the Create Nicknames dialog, click Next twice
• In the Define Nicknames windows, click Discover...
• In the Discover dialog, filter by Schema name
• Select the table and click Properties...
• In the Nickname schema, select MAXIMO and click OK
  
• Click Finish to close the Create Nicknames dialog.
  

Create User Mappings

• Expand the Federated Database Objects
• Expand DRDA
• Expand Server Definitions
• Expand the Server name
• Select User Mappings
  

• Click Create New User Mapping
• In the Create User Mapping dialog, select the MAXIMO user:
  
  
• On the Settings tab, specify the remote user and password and click OK:
  

Viewing the Federated Data

After the nickname has being configured, the federated data can be seen in the Authorized CI application:

Using the deltaEngine.js to determine changes in TDI

Introduction

This document describes how to use the JavaScript code deltaEngine.js to determine changes in the data source.



This document extends the tutorial Creating IDML Books using Tivoli Directory Integrator (DLA Tutorial), describing how to create a Discovery Library Adapter. Certainly, the deltaEngine can be used in any Assembly Line, and the use in the DLA process is just an example.

Configuration of deltaEngine.js

The component deltaEngine.js can be obtained from Lotus Quickr Place. Copy this file to your TDI solution directory. Then follow these steps to configure it:

• 
  Right-click Scripts and click New Script
  
  

• 
  In the Input Text, give the Script a name and click OK:
  
  

• 
  Click the Config... tab, select the Implicitly Included checkbox and the add the deltaEngine.js file:
  

• 
  Click the Properties and add a new Property file:
  

• 
  In the Connector Configuration tab, specify a name to the Property file:
  
  
  
  
  
  


• 
  In the Property Stores list, move the Derby-Properties to the top of the list:
  
  
  
  
  
  


• 
  In the Editor tab, define the properties below, adjusting the com.ibm.di.store.database property according to your TDI solution directory:
  


• 
  
  
  

Configuration of the System Store

Before we can use the TDI System Store, we need to start it. Follow these steps to start it:

• 
  Click Store -> Network Server Settings:
  

• 
  Click Start:
  

Using the deltaEngine Script

This section describes the procedure to use the deltaEngine in an Assembly Line:

• 
  In a suitable spot in your Assemby Line, add a Script
  
  

• 
  In the Input Text dialog, give it a name and click OK:
  
  
  
  
  
  


• 
  Type the following script in the CalculateDelta:
  

deltaEntry = deltaEngine.computeDelta (work, "machine");

task.logmsg ("deltaEntry: " + deltaEntry.getOperation ());

• 
  Run your Assembly Line. The first time you run the Assembly Line, it shows the deltaEntry operation as add, indicating the records should be added. The subsequent runs show the operation as generic, indicating there was no change to the entry:

11:54:20 11:54:20 @@Old snapshot: [machine:troosevelt.my.com] 11:54:20 @@Commiting snapshot changes... 11:54:20 @@finished 11:54:20 deltaEntry: generic 11:54:20

• Assuming we want to skip the entries that have no change, add the following code to CalculateDelta script:
  
  
  deltaEntry = deltaEngine.computeDelta (work, "machine");
  
  task.logmsg ("deltaEntry: " + deltaEntry.getOperation ());
  
  if (!deltaEntry.getOperation().equals ("add")) { task.logmsg ("Skipping entry: " + work.getString ("machine")); system.skipEntry (); }
  
• Now, the Assemby Line will skip the records that are not new to the data source.

Conclusion

This tutorial showed how to use the deltaEngine.js to determine changes in the data source. With a few steps, it's possible to leverage the internal TDI System Store to store a snapshot of the data source and skip records that have been processed.

CA Spectrum Discovery Library Adapter

In the old days, a Discovery Library Adapter was described as a Java component that exports the data from a certain product as an XML file that complies to the IDML XML schema format.

Well, since then a DLA has been described as a process to export data into this XML schema, without mentioning Java component, as the use of data integration tools, like Tivoli Directory Integrator, proved more effective to create an IDML file.

My goal is expand the mechanism to create DLA, and I always dreamed to create a DLA in perl. Well, here is the perfect opportunity:

The CA Spectrum DLA

This DLA is very simple and can be run in any machine

#!/usr/bin/perl
print "Go, talk to your CA representative and demand a change to CA's license agreement\n"

Done!!

Here is the deal: according the CA license agreement, CA owns the data it collects with its product, so other products can't retrieve it. So, it's illegal to write a DLA for CA. How stupid that it!!

Imagine if IBM Information Management group crafts the following statement: "The data stored in an IBM DB2 relational database belongs to IBM and can't be extract for the purpose of moving to another database."

Imagine if EMC puts a similar statement, saying: "The data stored in an EMC storage device belongs to EMC and can't be used to move data outside an EMC device."

The world would be unmanageable! As a customer, if I buy a certain product, I would expect that I can use the data collected in any way I want. Now with CA...

The solution: get rid of these CA. Your life will be better without them.