Tivoli Asset Management is designed as a management tool for asset life cycle management. In this document, the architecture of the product is addressed at the database level application programming interfaces (APIs) are provided for customization purposes.
Access to data, whether by an individual table or groups of tables that contain related data, is managed through a set of generic functions called 'DB_TRAN' (database transactions). Each table has a function call that updates a lists of records, and a fetch function that retrieves a list of records given a search clause. For example:
FUNCTION UpdateListOfContractTypes(VAL InTran: BOOLEAN, REF BeforeList: LIST OF ContractTypes, REF AfterList: LIST OF ContractTypes) : INTEGER;
SQL statements use the InTran function to identify whether a result should be considered as part of a transaction. The following are the general guidelines that apply.
Code Area | InTran |
Retrieve a counter value for a hidden primary key from within the user interface event group | FALSE |
Retrieve a counter value for a hidden primary key (general) | TRUE |
Add a record from within the user interface event group (counter retrieval as a subset of InTran = TRUE) | FALSE |
Update a list of records (individual inserts, deletes, updates in InTran equals TRUE) | FALSE |
Group of UpdateListsofRecords (for example, Migration) | TRUE |
BeforeList and AfterList represent lists of records. The two lists need to be synchronized so that the same element of each list represents a state of the record before and after the transaction.
Transaction | Before State | After State |
Insert | empty (blank) | record with data |
Update | record with old data | record with new data |
Delete | record with data | empty (blank) |
An example of a function used for information retrieval is:
FUNCTION GetHist( REF lst: LIST OF Inventory_HistoryRec, VAL iid: INTEGER): INTEGER;
The list of records contains the records that match the search criteria specified in the where clause. Table names are embedded within the function, so that only the where clause needs to be passed as a parameter. The return value indicates success or failure of the query.
The public APIs for Tivoli Asset Management are defined in a set of TSD Script program KB files that are identified with the 'i_db' prefix. One file may contain references to more than one table. Typically, these aggregate database transaction files contain methods for accessing and updating records in related tables. The following example is extracted from the i_db_hst.kb file:
KNOWLEDGEBASE i_db_hst; USES c_dtadef; evnt_rec; inv_rec; CONSTANTS TYPES VARIABLES ROUTINES FUNCTION GetSomeInvHist( VAL where : STRING, REF lst : LIST OF HistViewRec): INTEGER; FUNCTION GetHist( REF lst: LIST OF Inventory_HistoryRec, VAL iid: INTEGER): INTEGER; FUNCTION GetInvHist( REF histList: LIST OF HistViewRec, VAL is_inventory_id: INTEGER): INTEGER; FUNCTION GenerateMovedEvent( VAL table: STRING, VAL oldID: STRING, VAL newID: STRING, VAL iid: INTEGER, VAL event_id: INTEGER, REF histBeforeList: LIST OF Inventory_HistoryRec, REF histAfterList: LIST OF Inventory_HistoryRec): INTEGER; FUNCTION InsertMovedEventsForInv( VAL before: IS_InventoryRec, VAL after: IS_InventoryRec): INTEGER; FUNCTION GetInvHistRec( VAL inv_hist_id: INTEGER, REF newinvrec: Inventory_HistoryRec) :INTEGER;
You can define a variable length list of attributes for each category. Implementing this concept in a relational database requires that attributes are not used as columns within a single table, but as multiple related records that describe each attribute.
The APIs for accessing attributes are maintained in the i_db_atr.kb file.
Tivoli Asset Management allows users to maintain references to attribute default values associated with asset categories. A model can be designed based on a type of equipment with certain fixed characteristics that you want to track. These characteristics are called attributes. For example, within the asset category called Monitor, you can define a model called NEC 3FGe, with an attribute called Size and a default value of 14â. Therefore, any asset categorized as a NEC 3FGe monitor has a size value of 14â associated with it.
All models in the same category have the same attributes, but you can specify different default values based on the model. If a value can be described as a selling feature (not an option), then it should be treated as a default value.
Because you can associate an asset with an asset category, and with any model within that category, the API provides mechanisms to access and update all the related tables. The collection of APIs used to perform such updates is spread across the Tivoli Asset Management application.
Using an API requires you to be familiar with the database structure and the referential integrity (RI) in the database. The database structure requires you to perform certain record updates in sequential order to preserve the RI. For example, to insert an asset record in a new asset category, the APIs used to create the records must follow this order:
A single function within the i_asset.kb file performs the sequence of updates to all related tables.
FUNCTION UpdateListOfInventoryItems(VAL mode :STRING, VAL inTran: BOOLEAN, REF updateList: LIST OF InvUpdateRec, REF newInv_PeopleList: LIST OF Inv_PeopleRec, REF Inv_PeopleList: LIST OF Inv_PeopleRec, REF newInv_ConnectionList: LIST OF Inv_ConnectionRec, REF Inv_ConnectionList: LIST OF Inv_ConnectionRec): INTEGER
UpdateList is a list of record structures that include all the data within the update process as nested sub-lists of records. The return value indicates success or failure.
In Tivoli Asset Management, primary keys are hidden from the user. For example, when a
user adds an asset, the is_inventory_id field (a primary key) is automatically populated.
The asset tag specified by the user is actually an alternate unique key.
Primary key values are assigned automatically and are typically integers from the COUNTERS
table. For data manager or hierarchical tables, such as the ORGANIZATION_TREE table, the
primary key is a string representing an integer value from the related record in the
parent table.
The LOCATION table and the VENDOR table do not use primary keys.
Other functions that retrieve a single record based on an alternate key are part of the
API. These have been defined like the example:
PROCEDURE GetContractType( REF type_id: INTEGER, REF contract_type: STRING);
In the procedure, the type_id returned has the alternate key of the contract_type in the second parameter.
The Tivoli Asset Management data managers use a data structure called directed acyclic graphs, or DAGâ™s. DAGâ™s are part tree and part graph, with arrows that always point in one direction. There are no loops or cycles. For more information on DAGâ™s, see the following:
Algorithms in C, Robert Sedgewick, Addison-Wesley 1990, ISBN 0-2-1-51425-7, p.
479 (Topological Sorting)
Fundamental Algorithms, Donald Knuth, Addison-Wesley 1973, p. 371 (Directed
Graphs)
The following tables are constructed using DAG methodology:
Tivoli Asset Management contains a function in the i_br_gl.kb file called CheckCircularity, which detects and prevents cycles in the DAG tables.
Tivoli Asset Management uses KB files with the following syntax to implement the DAG data structure:
tree_*.kb
Tivoli Asset Management DAGâ™s allow a node to have multiple parent nodes.
In this example, node D is listed whenever paths through nodes C or E are traversed. Since node D has two parents, changes to node D are also visible when traversing through nodes C or E.
Tivoli Asset Management hierarchies allow duplicate naming of nodes.
In this example, the two D nodes are distinct, separate records with the same name (such
as âœ2nd Floorâ in the Location manager). Modifying one record does not affect the
second.