Don't let the documentation lead you astray - extended attributes in TADDM should be your LAST CHOICE for customization!
I realize that's a bold statement (especially since there's so much information about creating extended attributes in the documentation), but I'll explain why it's a valid statement:
1. You can't run any reports based on values stored in extended attributes! None. You can say, for example "give me all ComputerSystems where myCustomAttribute contains the string 'foo'". Just can't do it. The only call to get extended attribute values requires the GUID (or GUIDs) of the object(s) you're interested in. This is enough reason to stay away from extended attributes.
2. Extended attributes don't get imported into the CCMDB unless you do a LOT of customization to the TADDM integration adapter.
If you have custom data that you need to store in TADDM, what you need to do is become familiar with the CDM (Common Data Model) and the APIs available in TADDM. They are documented in three different archives that you have to extract (these all exist on your TADDM server):
CDMWebsite.zip - contains information about the CDM, including entity relationship diagrams.
model-javadoc.tar.gz - contains javadoc information for interacting with model objects.
oalapi-javadoc.tar.gz - contains javadoc information for accessing TADDM, from which you may just output XML, or you might obtain references to model objects, whose methods are defined in the above file.
If you're reading these files on your own workstation, make sure to grab a fresh copy from the TADDM server after each fixpack, as Tivoli does update this documentation.
By reading and understanding the documentation above, you can determine the appropriate object types to use to effectively store all of your data.
2 comments:
I think you're being a little bit unilateral :)
Sure you can't generate regular reports with the extended attributes, but I don't like them much any way.
You can use the Tivoli Directory Integration to import/export data from TADDM relatively easily with this OPAL solution:
http://www-01.ibm.com/software/brandcatalog/portal/opal/details?catalog.label=1TW10CC10
And then you can generate reports for Extended Attributes without much trouble.
Thanks for the comment, Robert!
You can absolutely use that solution, or you can use the API directly to get the extended attributes into XML, from which you can then create reports. Absolutely. But IMO, most of the time, if you search hard enough, you can find existing model objects with existing attributes that can be effectively used to store your additional data.
Also, while I think TDI is pretty cool, it's another (kinda big) tool/interface that a customer has to deal with. Storing all of the customer's data inside pre-defined classes and attributes allows the customer to stay inside the TADDM interface to run reports (even though you and I both know that facility isn't very great) via custom queries.
So that's why the unilateral title of my post :) With *your* amount of experience, you know the exact issues you're dealing with, so anything is fair game. But there appear to be more and more new TADDM customers out there who don't realize those challenges.
Post a Comment