Extending custom server and computer system templates

Your infrastructure might contain software applications and server types, such as custom Java™ servers, that are not automatically categorized by TADDM. Using the Discovery Management Console, you can create custom server templates to discover and categorize these servers.

You might also want to define a custom server template for a server type that is already discovered, if you want to customize certain aspects of the way it is discovered. For example, you might want to change the display icon, or capture specific configuration files.

Defining a custom server means that you are creating a template that sets up the "membership rules" for the custom server.

During a discovery, TADDM then automatically categorizes any unknown server as a custom server of this type if the runtime information matches the criteria that you defined in the template. Any configuration files used by the custom server are also automatically captured if specified in the templates.

Creating a custom server template for an application also enables TADDM to subsequently display it as part of the topology. You can view details about the application, including the listening port, runtime information, and any config files or application descriptors that were collected.

In some cases this might not be sufficient. For example, you might also need to access the product version. By default, TADDM is unable to collect version information for arbitrary custom server applications.

You can use TADDM to extend custom server templates to collect additional information, as required, using the following approaches:

• Run commands on the target system to populate any attribute in the Common Data Model for the component

  You can use this approach to set the productVersion attribute, for example. For more information, see the section on executing commands to populate the Common Data Model.

• Run commands on the target system and store the result as a config file for the component

  One common use of this approach is to extract information from the Windows Registry. For more information about running commands to create a custom configuration file, see Running commands to create a custom configuration file.

• Run a Jython script on the TADDM server.
  You can change any information about a component. The difference between this and the first approach is where the code runs. This is more flexible than the CMD approach. The Jython based custom server extensions run on the TADDM server. These extensions can create new components and set ExtendedAttributes. They can also set attributes below the first level of the discovery target.

  • For example, a CMD based extension can set ComputerSystem.serialNumber or any other primitive attribute of ComputerSystem. A Jython based extension can set attributes on the L2Interfaces associated with the ComputerSystem.

You can also configure Shell and Jython scripts together to extend a custom server template (CST). In this case, TADDM copies the user-defined Shell scripts (configured through ASDMAINSCRIPT/ASDSCRIPT tags) to the target system, run the scripts, and returns the output files to the TADDM server, and then they are parsed by a Jython script (configured via SCRIPT tag). The model objects created and return by this script file will get stored. The limitation, in this case, is that there will be no basic discovery result object (comprising of basic details like listening port, runtime information, etc.) generated or stored because of custom server templates, but which were present in other types of extensions. All data needs to be explicitly created by the Jython script to get saved. For more details, refer to Using scripts to extend custom server extensions to run in script and asynchronous mode.