CTS vs CST vs CSX

This following table describe the difference between Custom Template Sensor (CTS), Custom Server Template (CST), and Custom Server Extension (CSX).

CTS vs CST vs CSX

Table 1. Difference between Custom Template Sensor (CTS), Custom Server Template (CST), and Custom Server Extension (CSX)
	Custom Template Sensor	Custom Server Template	Custom Server Extension
Definition	The custom template sensor is used to analyze and enhance the information collected by any of the existing TADDM sensors.	The custom server template is used to discover and categorize servers that are not by default, supported by TADDM.	Although details like listening port, runtime information, configuration files, application descriptors, etc., can be collected using Custom Server Templates (CST) but when additional information is needed such as product version, etc., extension scripts (CSX) are used.
Sensor Run	CustomTemplateSensor	CustomAppServerSensor	CustomAppServerSensor
Use Cases	To get extra information, which is not currently obtained from an existing TADDM sensor.	Discover and categorize servers that are not by default, supported by TADDM. Capture configuration files specified in the Custom Server template. 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.	Defining CSX on CST allows to obtain additional customized information, such as product version, etc., besides what is collected by CST. To create new objects and relationships through the use of extension through the Jython script.
Ways to create	To create a Custom Template Sensor, three configuration files are needed: template.xml, matcher.py, and sensor.py.	Creating Custom Server Templates involves defining templates on the Discovery Management Console.	There are three possible ways to create the extensions: Run commands on the target system to populate any attribute in the IBM model for the component. Run commands on the target system and store the result as a configuration file for the component. Run Jython script on the server and change or add any information about a component. An additional way is using shell and Jython script using ASDMAINS script and SCRIPT tags where TADDM copies the defined scripts to the target system, runs the scripts and returns the output files to the TADDM server which are then processed by a Jython script. However, it comes with the limitation of having to create all model objects and data to be saved explicitly. This is run in script or asynchronous discovery mode.
Limitations	Cannot be run in script-mode.	Cannot be run in script-mode.	Cannot run in script-mode except using Shell and Jython scripts using ASDMAINS script and SCRIPT tags which runs in the script or asynchronous discovery mode but comes with limitations.