the build.xml

here's my next favorite hack. the build.xml that is used to create the automation package (tcdriver) for TIO / TPM can provide quite a bit of goodness. with one of my customers, i modified the contents of the tcdriverdevelopment.jar file so that each and every automation package that is created has a super-duper action packed build.xml.

1. take the current tcdriverdevelopment.jar file and extract it using jar -xf to a directory of your choice
2. navigate to com/ibm/tivoli/orchestrator/tcdriverdevelopment/resources
3. modify build.xml
a. you could also modify xml-template.xml so that it fits company standards (or in the case here, adding cvs tags so that non-developers that write workflows don't forget)
b. tc-driver-template.xml which is converted to TC-INF/tc-driver.xml when the automation package project is created
4. when finished making changes, simply rebuild the jar file with: jar -cf and copy it back into your apde / plugins directory (from where you originally retrieved it).
5. restart APDE and create a new automation project

What have i added to the build.xml you ask?

Incremental build number for every build that updates the tc-driver.xml direct and uses a build.properties file to store the information.

Add custom properties to the tc-driver.xml for use when automation package is imported into TIO.

Output directory of automation package after packaging was modified to automation project home instead of APDE home.

Just little things to make the lives of developers easier (and my life too!)

-sd

tc-driver.xml and device driver properties

Where to start. How about a description. What is "tc-driver.xml"?

The tc-driver.xml file is a manifest file for an automation package. It contains the name and the version number of the automation package and the version number of the automation package template, and describes all of the device driver dependencies on other automation packages.

Read more about it at: Setting up the manifest file

In addition to any helpful information you find at the link above, you can also have the manifest file set dcm properties when it is imported. You may or may not know that you can have variables associated against device drivers. I find that these variables can be better stored here rather then as global variables (that is, if the variable is not needed globally). When you update a tcdriver it will remove all of the variables loaded against the device drivers that it is updating. Most companies implement this product to facilitate some sort of automation ... so, unless you want to manually re-add the variable(s) every time, you can try the following within the <device-model></device-model> stanza:

<dcm-property component="DEPLOYMENT ENGINE" name="your variable name" value="the value" />

Now, each and every time your automation package is updated, the variable with name "your variable name" will be available by DCMQuery.

somewhere new

I've been working with TIO/TPM (IBM Tivoli Intelligent Orchestrator & IBM Tivoli Provisioning Manager) for the better part of forever. Some time ago, I had a forum under autonomics.ca where I had posted lots of great information related to TIO 3.1.

By "great information", I mean, information that I found useful. I have no idea if anyone else ever did. The only comments and posts that I received were from spambots telling me how to make my penis bigger.

So here I am on blogger. A place for me to post my rants and tips and hope that google can help filter out penis spam.

-sd