Customizing Tivoli Change Management


Using flexible fields

Using pre- and post-event handlers


Using flexible fields

Flexible fields are extra, unused fields defined in certain tables of the database. With flexible fields, you can:

You can add new text boxes to view or edit flexible field data in certain dialog boxes. To use flexible fields, add text boxes to the appropriate dialog boxes with the Interface Designer. The Control_ID value for the text box must match the name of the flexible field in the table, such as FLX_CHG_VCHR1. This allows values entered in the text box to be automatically saved to the database. For detailed instructions about how to create text boxes within a dialog box, see your TSD Developer’s Toolkit online help.

Note: If you want to be able to use a flexible field to inquire for or search for records, you can improve system performance by creating an index on that flexible field column.

Adding flexible fields to your database

Fexible fields are optional. If you plan to use them, you must add them to the database by executing a database script file with TSDBuild and by making code changes to rmod_wf.kb.

After you add the fexible fields to your database, consult the TSD DT documentation for instructions on adding controls to dialog boxes. Execute a database script for your database with TSDBuild. Refer to the following table to determine which script file to run.

If your DBMS is... Then run this script...
DB2/2 r_flx.db2
Informix r_flx.inf
SQL Server r_flx.mss
Oracle r_flx.ora
Sybase r_flx.syb

Applying the code changes

  1. Open rmod_wf.kb and search for beginning and ending blocks of text. The commented code is marked with hyphens that appear to the left of the code.
  2. Delete the hyphens to uncomment the code.
  3. Save the files and reparse the application.

Note: You need to uncomment the code each time you install a new version or re-install Tivoli Change Management.

Available flexible fields

The following table lists of the tables with fexible fields, the fexible field names in each table, and the data type for each field.

Table Name Flexible Field Name Data Type
CHANGE FLX_CHG_VCHR1 VARCHAR(254)
FLX_CHG_VCHR2 VARCHAR(254)
FLX_CHG_VCHR3 VARCHAR(254)
FLX_CHG_VCHR4 VARCHAR(254)
FLX_CHG_DATE1 DATE
FLX_CHG_DATE2 DATE
FLX_CHG_INT1 INTEGER
FLX_CHG_INT2 INTEGER
FLX_CHG_TIME1 TIME
FLX_CHG_TIME2 TIME
CHANGE_MODEL FLX_CHG_MOD_VCHR1 VARCHAR(254)
FLX_CHG_MOD_VCHR2 VARCHAR(254)
FLX_CHG_MOD_VCHR3 VARCHAR(254)
FLX_CHG_MOD_VCHR4 VARCHAR(254)
FLX_MOD_CHG_DATE1 DATE
FLX_MOD_CHG_DATE2 DATE
FLX_MOD_CHG_INT1 INTEGER
FLX_MOD_CHG_INT2 INTEGER
FLX_MOD_CHG_TIME1 TIME
FLX_MOD_CHG_TIME2 TIME

Using pre- and post-event handlers

The DelegateEvent statement and pre- and post-event handlers streamlines the customization process.

DelegateEvent is called before and after every event handler in the application (including those in the data utilities). Therefore, you can make functional customizations in pre- or post-event handlers within the r_events.kb file. By making changes in the event handlers or r_events.kb file, you can keep your changes in a central location and reduce the number of modifications to the original programs.

Each instance of DelegateEvent returns an integer value for the pre- or post-event. Depending on the return code value, the original code associated with the event is either skipped or executed.

The DelegateEvent statement for pre-event processing is included as the first line of every event handler. The DelegateEvent statement for post-event processing is included as the last line of every event handler.

In order to call DelegateEvent, the r_events.kb file must be included in the USES chain of the calling program file. For example, in order for the radmn_ww.kb file to call a pre- or post-event, it must have the r_events.kb file in its USES chain.

Naming conventions

For Tivoli Asset Management, pre- and post-events are stored in r_events.kb. All pre-events use the following naming convention:

pre_r_eventhandler 

All post-events use the following naming convention:

post_r_eventhandler 

For example, the pre-event for the CodesEvent event handler is named pre_r_CodesEvent, and the post-event is named post_r_CodesEvent.

Event handler parameters

The parameter that is passed to an event handler will also be accepted by the pre- and post-event handlers for the event. When you pass a parameter to an event handler, the event handler works with the parameter as needed. In r_events.kb, the event handlers are created as follows:

Event pre_r_CodesEvent (REF this_Category: R_CATEGORY_REC); 
Event post_r_CodesEvent (REF this_Category: R_CATEGORY_REC); 

The DelegateEvent statement passes the same variable that was passed to the original event handler. For example, if InventoryMainEvent is created as follows:

Event r_CodesEvent (REF this_Category: R_CATEGORY_REC); 

The call to DelegateEvent should also pass the same variable:

$Result:= DelegateEvent (pre_r_CodesEvent,this_Category) ;

Exiting an event handler

Pre- and post-events should yield return codes as follows:

graphic3.gif (3412 bytes)

graphic4.gif (3324 bytes)

graphic5.gif (3502 bytes)