Score XML Reference

Some functionality of Experience Optimization is linked with Finder (classic).

Nexthink Finder is a Windows-only desktop application whose functionality is now available within the Nexthink web interface. Nexthink can now be used directly from a browser and most functions no longer require an additional desktop application.

Scores are defined in XML documents. This article details the format of XML files that define a score.

Just as with any other XML file, a score definition must begin with the XML header. Use utf-8 encoding:

<?xml version="1.0" encoding="utf-8"?>

The XML header is followed by the root element. The name of the root element for XML documents that define a score definition is ScoreDef:

<ScoreDef UID="[<unique identifier>]" Name="[<name of the score>]"
  Object="[device|user]" InObjectView="[true|false]"
  Status="[enabled|disabled]" SyntaxVersion="1"
  DataModelVersion="12">
    <Platforms ...
    <ScopeQuery ...
    <ComputationSchedule ...
    <Thresholds ...
    <CompositeScore|LeafScore ...
</ScoreDef>

Along with the ScoreDef element, find the following attributes:

UIDA

The universally unique identifier for the score is a 128-bit integer number expressed in hexadecimal format with separators. There are tools available to generate them with low collision probability. Example: f54972e7-0f9c-46ce-8931-bbe31b06f7b4

Name

The name of the score as shown in Finder

Object

The type of object to which the score applies. It can either be user or device.

InObjectView

Whether or not the score should appear inside the User or Device view in Finder. Note that the User and Device views can display a maximum of five scores each. Possible values are true or false.

Status

Whether the score should be calculated or not. Possible values are enabled or disabled.

SyntaxVersion

The version of the schema for the XML file. Currently fixed to 1.

DataModelVersion

The version of the Nexthink Data Model on which the score relies for its queries. Currently fixed to 12.

After the attributes, the following elements can be found inside ScoreDef:

Platforms

The platforms to which the score applies. Enumerate each supported platform within a Platform element. Possible values for platforms are windows, mac_os, or mobile. Example: 

<Platforms><Platform>windows</Platform></Platforms>

ScopeQuery

Define the scope of the query to retrieve users or devices by filtering the objects. Write a where clause in NXQL inside the Filtering element. For example, to filter out servers from a score on devices: 

<ScopeQuery><Filtering>(where device (ne device_type (enum server)))</Filtering></ScopeQuery>

ComputationSchedule

The moment to compute all the leaf scores that have a computation input. It can be either a specific hour of the day that computes the score every day at that hour, or a period of time that computes the score more often. It applies only to those leaf scores whose input is a computation and not a field, as field-based scores are updated every minute. The main score is updated whenever a leaf score changes, be it a computation input or a field input. To specify an hour of the day, insert the element At with a value between 0 and 23. To specify a period, insert the element Every with values 15min, 1h or 6h. Example:

 <ComputationSchedule><At>2</At></ComputationSchedule>

Thresholds

Optional: The limit values of the score that determine its status. Define up to three thresholds that the score has to exceed to be in a particular status. Finder displays the score with a particular color depending on its status: red, yellow or green. Specify the thresholds from green to red or from red to green (yellow is optional), always keeping the values in ascending order. Each Threshold element contains the Color attribute, as well as a Keyword element that defines the limit value of the threshold in its From attribute and the name of the corresponding status in the Label attribute. For a score to define no thresholds, declare exactly one threshold with the color none.

Example: 

<Threshold color="green"><Keyword From="9" Label="good"/></Threshold>

Once the general elements of the score definition are laid out, add a single composite or leaf score element to the definition. This last element describes how to compute the score from the values stored in the Nexthink database. If you add a LeafScore element to your ScoreDef, the score will depend on one computation or on the value of one field only. On the other hand, if you add a CompositeScore element to the ScoreDef, a combination of several scores is used to compute the main score.

In fact, a composite score is itself composed of other composite or leaf scores, forming a tree of up to five levels. Ultimately, all the nodes at the lowest level of the tree must be leaf scores.

Composite and leaf scores

CompositeScore and LeafScore are the elements in the score definition that are used to compute individual scores.

The following attributes are common to the CompositeScore and LeafScore elements:

UID

A universally unique identifier for the score (similar to that of the ScoreDef element)

Name

The name of the score

Description

A textual description of the score

Visibility

Optional: Whether the score should be visible in Finder, nowhere or only in quantity metrics in Portal. Possible values are visible, hidden and visible only in quantity metrics. By default, a score is visible everywhere.

Weight

Optional: A floating point number with up to two decimal places that acts as a multiplier of the computed score when its immediate composite parent score performs a weighted average operation. See how a composite score is computed below.

In addition to the common attributes, both the CompositeScore and the LeafScore elements optionally include a Document element. The Document element contains the documentation of the score that is displayed in the corresponding score tab of either the device view or the user view, depending on the object to which the score applies. In addition to the detailed description of the score, the documentation of a score may also contain:

• Links to external HTTP resources (e.g. knowledge base, external documentation, etc).

• Links to remote actions that can be manually triggered in order to take appropriate action on devices that display a poor score.

See how to document scores for the complete reference of the Document element.

Computing a composite score

A composite score results from the combination of its direct child scores by means of an operation. Each composite score declares an Operation element that specifies how to combine its child scores. After the operation, find the list of child scores that contribute to the composite score:

<CompositeScore UID="[<unique identifier>]" Name="[<name of the score>]"
  Description="[<score description>]" Visibility="[visible|hidden]"
  Weight="[<float>]">
    <Operation>[Average|Min|Max|Sum|WeightedAverage|Multiply]</Operation>
    <!-- List of child scores -->
    <LeafScore ...
    <CompositeScore ...
    <LeafScore ...
    ...
    <!-- Optional documentation for the score seen in device or user views -->
    <Document ... 
</CompositeScore>

The list of possible values for the Operation element can be found below:

Average

Compute the arithmetic mean of the direct child scores.

Min

Get the minimum direct child score.

Max

Get the maximum direct child score.

Sum

Compute the addition of the direct child scores.

WeightedAverage

Compute the arithmetic mean of the direct child scores after multiplying each child score by the quantity specified in its Weight attribute.

Multiply

Compute the multiplication of the direct child scores.

The list of child scores is limited by the maximum number of scores that you can simultaneously enable. Remember, however, that this limit includes the nested scores and the maximum nesting of scores is 5 levels.

Computing a leaf score

A leaf score is a result of applying a normalization procedure to an input value from the Nexthink database. The input is either the value of a field that belongs to the user or the device objects or the result of a computation on devices or users expressed in the NXQL language.

Thus, a LeafScore is composed of an Input element and a Normalization element:

<LeafScore UID="[<unique identifier>]" Name="[<name of the score>]"
  Description="[<score description>]" Visibility="[visible|hidden]"
  Weight="[float]">
    <Input ...
    <Normalization ...
    <!-- Optional documentation for the score seen in device or user views -->
    <Document ... 
</LeafScore>

In turn, the Input element encloses either a Field or a Computation element.

For an input of the field type, specify the name of the field to retrieve in the Name attribute of the Field element. Type in the name of the field as stated in the NXQL data model. For example, to retrieve the WMI status of a device, write: 

<Input><Field Name="wmi_status" /></Input>

An input of the computation type is slightly more complex to define. First give a name, a description and a unique identifier to the computation as attributes of the Computation element. Then write an NXQL query to extract information from the Nexthink database inside a child Query element. As attributes of the Query element, set the Output to be the aggregate or field in the query that should be passed as input to the leaf score. Set the DefaultOutputValue to the value returned when the previously specified output is undefined. The structure of a computation input is as follows:

<Input>
  <Computation Name="[<name>]" Description="[<desc>]" UID="[<identifier>]">
  <Query Output="[<name_of_aggregate>|<name_of_field>]"
    DefaultOutputValue="[<value>]">
    <!-- NXQL query -->
    (select (id ...) (from [user|device] ...
    </Query>
  </Computation>
 </Input>

Note that the embedded NXQL query must select the id of the objects retrieved (users or devices) as well as the field declared as output, if any. If an aggregate is declared as output instead, include the calculation of the aggregate in the query within a compute clause. For example, to compute the ratio of successful HTTP requests of a device over the previous week to use as an input to a leaf score, write the following Query element:

 <Query Output="successful_http_requests_ratio" DefaultOutputValue="NULL">
   (select (id) (from device
     (with web_request
       (compute successful_http_requests_ratio)
       (between now-7d now))))
 </Query>

Note the use of the keyword NULL as the default output value in the previous query. Whenever it does not make sense to return a value for the score if the underlying field or aggregate is undefined, write NULL as the default output value. In the previous example query, the ratio of HTTP requests is undefined if the device made no HTTP requests. Rather than force an artificial value for the score, it is preferable to return no value.

A leaf score with no value that is part of a composite score is discarded for the computation of the composite score. If a composite score or the main score cannot be computed because of a lack of underlying values, they have no value as a result. Finder displays a dash sign (-) for scores with an undefined value.

In the event that the input to a leaf score actually gets a proper value, transform it to give it business significance by means of a normalization function. The purpose of scores is, indeed, to make sense out of the detailed measurements in the Nexthink database. Normalize quantities, ratios, enumerations or even strings to a numerical range (usually the range from 0 to 10), to make it easier for you to understand the status of a user or device with respect to the measured input.

The Normalization element defines how to map the input values to the desired range. Depending on the type of input, apply a different normalization function:

To normalize numerical input values by means of a step function, define a list of Ranges with input values in ascending order (attributed scores do not need to follow any particular order), as in the following example:

<Normalization>
  <Ranges>
    <Range>
      <From Value="0" Score="0" />
    </Range>
    <Range>
      <From Value="0.6" Score="5" />
    </Range>
    <Range>
       <From Value="0.8" Score="10" />
    </Range>
  </Ranges>
</Normalization>

The example defines a step function for what looks like a ratio input that returns:

• A score of 0 for an input value between 0% and 60% (not included)

• A score of 5 for an input value between 60% and 80% (not included)

• A score of 10 for an input value equal to or greater than 80%

As mentioned previously, scores do not necessarily grow with the input value. For instance, consider this alternative normalization where the score drops to zero for input values higher than 80%:

<Normalization>
  <Ranges>
    <Range>
      <From Value="0" Score="5" />
    </Range>
    <Range>
      <From Value="0.6" Score="10" />
    </Range>
    <Range>
       <From Value="0.8" Score="0" />
    </Range>
  </Ranges>
</Normalization>

The resulting step function returns:

• A score of 5 for an input value between 0% and 60% (not included)

• A score of 10 for an input value between 60% and 80% (not included)

• A score of 0 for an input value equal to or greater than 80%

To normalize numerical input values by means of a piecewise linear function, define a list of Ranges similar to those found in the step function, but this time with an additional To element that delimits a linear interval and specifies the final value of the score within the interval:

<Normalization>
  <Ranges>
    <Range>
      <From Value="0" Score="0" />
      <To Value="0.6" Score="2" />
    </Range>
    <Range>
      <From Value="0.6" Score="2" />
      <To Value="0.8" Score="9" />
    </Range>
    <Range>
      <From Value="0.8" Score="9" />
      <To Value="1.0" Score="10" />
    </Range>
    <Range>
      <From Value="1.0" Score="10" />
    </Range>
  </Ranges>
</Normalization>

The example defines a piecewise linear function that maps our ratio input to a score that evolves linearly within each interval:

• For an input value between 0% and 60%, the score ranges from 0 to 2.

• For an input value between 60% and 90%, the score ranges from 2 to 9.

• For an input value between 90% and 100%, the score ranges from 9 to 10.

• For an input value equal to or greater than 100%, the score is 10.

As shown in the figure, linear interpolation is performed within each interval. For instance, an input value of 30% would receive a score of 1.

Note that the Value and Score attributes of a To element must be equal to those of the From element defined in the next range for the piecewise linear function to be continuous. The last range does not define a To element to avoid imposing a limit to the input value (in the event that our hypothetical ratio input could be higher than 100%).

For inputs of an enumerated type, the normalization function must directly map each possible input to a score, as in the following example:

<Normalization>
  <Enums>
    <Enum Value="ok" Score="10" />
    <Enum Value="failure" Score="0" />
  </Enums>
</Normalization>

Similarly, for inputs of the string type, the normalization function must map the possible inputs to a score. An input matches the value specified when it contains the string. You can use the wildcards:

• *, as a placeholder for 0 or more characters.

• ?, as a placeholder for a single character.

For example, this is a possible normalization function for an input that returns the Windows License Key of a device:

<Normalization>
  <Strings>
    <String Value="Windows is not activated" Score="0" />
    <String Value="?????-?????-?????-?????-?????" Score="10" />
  </Strings>
</Normalization>

In the case of Enums and Strings, be aware that the values are case-sensitive. Therefore, ensure that your definitions match the expected values as, for instance:

• Value="Ok" is not the same as Value="ok".

Additionally, providing several values with the same score for Enums and Strings is not allowed because only the first value in the list will be considered.

When displaying a leaf score in the device or user views, Finder shows the payload of the score which is the input value that resulted in a particular score. To improve the readability of scores in both the device and user views, when the input to a score has an obscure meaning, tag each normalization rule with a label that substitutes the raw input as the payload of the score. Use the Label attribute within the Range, Enum, or String elements. For example:

<Normalization>
  <Enums>
    <Enum Label="Service working" Value="ok" Score="10" />
    <Enum Label="Service not available" Value="failure" Score="0" />
  </Enums>
</Normalization>

Score XML validation

The structure and datatypes of XML files that describe scores are defined in an XML Schema Definition (XSD) file that Nexthink provides. To get the schema file (score.xsd):

1. Log in to Finder as a user with the right to manage scores.

2. Select Scores in the left-side panel of the main window.

3. Right-click anywhere in the Scores space to bring up a context menu.

4. Choose Export > Score schema to file... from the menu.

5. Select the location of where to store the file in the dialog box and press Save.

To write your own scores, take the existing scores that you can find in the Library as an example and validate the XML files that you create against this score.xsd schema file.

RELATED TASKS

• Computing scores

• Creating a score

• Documenting scores