This topic describes programming concepts and requirements needed to customize IBM Director console tasks using the snap in interface.
Many of the tasks provided by IBM Director are designed to be very flexible and display a wide variety of information. Unfortunately, the information might not always be displayed or accessed in a way that is best suited for the task. For example, the CIM Browser task uses a table to display attribute information for CIM instances. But it might make more sense to the user to see the data as a tree or chart for a particular CIM class. The snap in interface allows you to write customized extensions to the user interface that snap or plug directly into the existing GUI. These snap in extensions are installed on the IBM Director server system and will be used automatically by all of the IBM Director consoles connected to the server.
Every snap in is identified by a type string and a subtype string.
The type string is used to specify where a snap in is designed to
work. For example, the string "TonysConsoleTask"
could
be used to indicate that the snap in will be used by a console task
extension written by Tony. The subtype string is used to indicate
when the snap in should be used. For example, the string
"ImageDisplay"
could be used to indicate that the snap
in would be used whenever the console task needed to display an image.
To work correctly, a snap in must also be sure that it implements the
expected interface for the console task that defined the snap in point.
The classes used for snap in development and integration are:
snap in points are defined by console tasks that would like to allow customization of the user interface. A snap in point is an agreement between the console task and the customization. It is composed of a type string, a guideline for possible subtype strings, and an interface to be implemented by the snap in. When a snap in point has been defined, the console task uses the TWGRemoteSnapInManager.loadSnapInForSubType() method to search for and load a snap in.
The CIM Browser console task provides two snap in points for customization.
The first snap in point allows you to customize how a list of instances is displayed for a particular CIM class. The snap in type is SNAPIN_TYPE_TWG_CIM_INSTANCE_BROWSER. The subtype is the name of the particular CIM class that the snap in will display. A snap in developed for this point must implement TWGCIMInstanceBrowserInterface.
The second snap in point allows you to customize how the properties of an instance are displayed for a particular CIM class. The snap in type is SNAPIN_TYPE_TWG_CIM_PROPERTY_BROWSER. The subtype is the name of the particular CIM class that the snap in will display. A snap in developed for this point must implement TWGCIMPropertiesBrowserInterface.
The DMI Browser console task provides one snap in point for customization.
This snap in point allows you to customize the way instances of a particular DMI group are displayed. The snap in type is SNAPIN_TYPE_TWG_DMI_GROUP_BROWSER. The subtype is the name of the DMI group that the snap in will display. A snap in developed for this point must implement TWGDMIGroupBrowserInterface.
The SNMP Browser console task provides one snap in point for customization. The snap in type is SNAPIN_TYPE_TWG_SNMP_INFO_BROWSER . A snap in developed for this point must implement the TWGSNMPInfoBrowserInterface2.
Creating a snap in customization is very similar to creating a user defined console task. A snap in must be implemented in 100% Java and the normal IBM Director user interface classes are available for use (including the help system). Since snap ins are installed only on the IBM Director server system, though, any non-Java resources used by the snap in must be loaded using TWGRemoteSnapInManager.
If you are providing help with your snap in customization, you will also need to modify your HTML so that any icons or links are resolved correctly by the system. This modification is done by using the MTP prefix for any URL addresses within the file. The MTP prefix indicates to IBM Director that if the address is not found on the console system, it should try to load the address from the server system classpath. For example, you might have to put an image on your help page by using HTML similar to the following:
<img src="mtp://myimage.gif">
New snap ins are added to IBM Director by extensions. A complete description of extensions can be found in Understanding IBM Director Extensions. Here is a brief overview of how extensions work. When the server engine is initializing, it searches for files matching the wildcard x:\Program Files\IBM\Director\classes\extensions\*.TWGExt, where x is the drive letter on which the IBM Director server is installed. These are text files that define extensions. The only required line specifies the fully qualified name of a subclass of the extension class.
Example: twg.extension.classname=com.BobCo.snapins.BobsSnapInsExtension
The extension class is a subclass of the TWGExtension abstract base class. It is loaded and instantiated during the server's initialization. The abstract methods that must be implemented by your subclass are called during various stages of initialization.
Typically, new snap ins are added in the InitClassInstances() method of the extension class by using the TWGSnapInManager.RegisterSnapIn() method. The snap in provides the type string and subtype string for the snap in along with the name of the Java class that implements the snap in. A single extension class can register multiple snap ins and the same Java class can be registered for more than one type and subtype. Unlike tasks, snap in registration is not persistent.