C OMPORTAMIENTO DEL PROCESO DE IMPLANTACIÓN DE SOFTWARE PARA LA SALUD

Overview

Process classification in Discovery tracks services, such as database servers, that play an important business role in your instance. Discovery classifies processes during the exploration phase, after the devices have been identified.

Process classification, like device classification, uses classification criteria and can launch probes, but unlike device classification, creates child configuration items (CI) with Runs on::Runs relationships. For information on how Discovery creates and maintains dependent relationships between CI, including processes, see Application Dependency Mapping.

The Classification Form

Select Discovery Definition > CI Classification > Process in the navigation pane. ServiceNow includes classifications in the base platform that discover most common processes. ServiceNow provides the following unique fields for creating new classifications or edit existing ones.

Field Input Value

Table Select the a table for this classification. For example, if this record classifies a router, select the cmdb_ci_ip_router table.

Relation type Select the CI relationship types for this classification. The relationship field is only available for Process and Scan Application classifications. The relationships that are most appropriate for Discovery are:

• Runs on::Runs: Defines the relationship of an application to the host on which it runs. This relationship is expressed from the perspective of the host and the application. For example: My database application runs on server001::server001 runs my database application.

• Depends on::Used by: Defines the relationship of an application that communicates with another application. This relationship is expressed from the perspective of each application. For example: The Tomcat application depends on the MySQL database::

The MySQL database is used by Tomcat.

• Virtualized by::Virtualizes: Defines the relationship of a virtual machine to its host. This relationship is expressed from the perspective of the virtual machine and of the host. For example: server001 is virtualized by ServerESX::Server ESX virtualizes server001.

Match criteria Select which criteria must match to classify this device - Any of the parameters or All of the parameters.

On classification script

This script runs if classification criteria are met. Use this script to perform any special tasks after a device is classified. With the October2011 Preview 1 release, it is possible to use the g_probe_parameters hashmap from within a classification script to set probe parameters for any configured, triggered probes. For example, this code sets a 'node_port' parameter to 16001 for all triggered probes.

(JS), g_probe_parameters['node_port'] = 16001; //

Classification Criteria

These criteria are formed from specific parameters and the values that they must contain to match devices that Discovery finds in the network with CIs in the CMDB. For a detailed discussion of these parameters, see Discovery Classification Parameters.

Triggers probes

These are the exploration probes that Discovery launches to gather detailed information about a CI that it has classified in the network.

A completed process classification form with an exploration probe defined is shown below. For instruction on creating probes, see Creating a Probe. The probes defined here are launched when the device is properly classified, unless Discovery is configured to stop after classification.

Classification Criteria

The classification criteria for a Discovery Classification includes a parameter, an operator, and a value. The available parameters are those returned by Discovery classify probes for each class of device found. The values configured for these parameters are the values that Discovery is looking for to establish a device's class. For available parameters for each out-of-box classification, see Discovery Classification Parameters. In this example from the out-of-box ServiceNow system, the process that is started with the command sqlservr.exe is classified as Microsoft SQL Server.

The On classification script field can be used to further customize the application record being created. There are currently some objects that are exposed for this purpose.

• current: Points to a JavaScript object with its [property:value] pair to update the application record. (It is NOT an actual GlideRecord object of the application)

• g_sensor: Points to the running process sensor class. This object contains a deviceGR object, which points to the computer CI record on which the process resides.

• g_classification: Points to the process classifier record itself.

• name: Points to the process name.

• command: Points to the process command.

• parameters: Points to the process parameters.

• g_probe_parameters: A javascript object that will allow parameter passing to the triggered probes.

By default, we create the name of the application in this format:

<name of the process classifer>@<the name of the computer CI where the process resides>

For example, for a MySQL server running on a computer called machineA, we create an application with the name, mysql@machineA. If this is not the desired name, we can customize it using exposed variables in the following script in the On classification script field:

var computerName = g_sensor.deviceGR.name;

var processClassiferName = g_classification.name;

current.name = processClassiferName + "999" + "@" + computerName;

In this example, the name of the application record becomes mysql999@machineA.

Another common technique is to use the name, command and parameter variables. For example, looking at an Eclipse process, we might have the following values in these variables:

• name => "eclipse"

• command => "/glide/eclipse/Eclipse.app/Contents/MacOS/eclipse"

• parameter => "-psn_0_1884620"

For an Eclipse application running on a computer called machineA, we create an application with the name, eclipse@machineA. If this is not the desired name, we can customize it differently (in the On classification script field). In the following example, we append the parameter value as part of the name of the application we create.

var computerName = g_sensor.deviceGR.name;

var processClassiferName = g_classification.name;

current.name = processClassiferName + parameters + "@" + computerName;

In this example, the name of the application record will become eclipse-psn_0_1884620@machineA.

Also, sometimes it's useful to pass certain values to the triggered probes in the process classification, we can achieve this by adding the name/value pair to the g_probe_parameters object.

g_probe_parameters['processCommand'] = command;

In the example above, if there is a probe triggered from the classification record, it automatically gets the parameter called "processCommand" with the value of the command variable attached to the probe.

Debugging Classifications

To log debugging information about classifications, add the glide.discovery.debug.classification property and set the value to true. The resulting log entries list the name of each classifier that runs, along with all the names and values that are available to the criteria in the classifier.

To add the property:

1. In the navigation filter, type sys_properties.list.

The list of properties appears.

2. Click New.

3. Enter glide.discovery.debug.classification in the Name field.

4. Enter a description, such as Log debugging information about Discovery Classifications.

5. Select true/false as the property Type.

6. Type in a Value of true.

7. Click Submit.