Customizable processing logic

Customizable processing logic is introduced with Snow Inventory Server 6.5.0.

Snow Inventory Agent and other data sources—for example, Snow Integration Manager—store data in inv3x.xml files that are then packed into .inv or .snowpack files and sent to Snow Inventory Server.

The content and the structure of an inv3x.xml file can be seen by use of the Snow Inventory File Extractor tool; Details of this tool and the tool itself is available for download at Snow Globe.

Snow Inventory Server receives the data, processes it, and stores it in the Snow Inventory database.

Most of the data that is processed by Snow Inventory Server is stored as is in the Snow Inventory database. Some attribute values are evaluated during data processing according to preconfigured rules. Snow Inventory Server allows these logics to be extended and customized with Customizable processing logic.

Customizable processing logic allows existing Snow Inventory Server logics to be extended by applying additional and custom-made rules. These rules are defined in an XML file that is named DataProcessorRules.xml and saved in folder where Snow Inventory Server is installed*. This file is loaded by Snow Inventory Server when started and is then processed by Customizable processing logic.

*A custom path and file name can be used by entering the -data-rules-file [drive:][path]filename global option.

Functional design

Customizable processing logic implements rules to customize attribute values for four different data points that are found in an inventory file:

  • Evaluate the operating-system type.

  • Evaluate whether an operating system is server or not.

  • Evaluate whether a computer is a virtual machine or not, and, if it is a virtual computer, what kind of hypervisor is used.

  • Normalize name, version, and edition of an Oracle database installation.

Snow Inventory Server implements hard-coded normalization rules. When processing inventory data, Snow Inventory Server will first apply its hardcoded rules, and, if no normalization can be performed, and then use Customizable processing logic, if a valid DataProcessorRules.xml file is found.

If inventoried data does not match any rules, a default value or a null value will be entered in the Snow Inventory database.

The DataProcessor.xml file structure:

<?xml version="1.0" encoding="utf-8"?>
<DataProcessingTypes>
  <!-- RuleType: all the rules for a given data point are grouped here -->
    <!-- Rule: a rule is defined by an Expression filter and the Output Parameter(s) -->
      <!-- Named Expression Token: represents the Input Parameter, the Name attribute is referred to in the rule's Expression filter -->pattern to match<!-- /Named Expression Token -->
      <!-- Other named tokens ... -->
    <!-- /Rule -->
    <!-- Other rules ... -->
  <!-- /RuleType -->
  <!-- Other rule types... -->
</DataProcessingTypes><?xml version="1.0" encoding="utf-8"?>
<DataProcessingTypes>
  <!-- here are the rules: see examples below -->
</DataProcessingTypes>

For example, a Customizable processing logic file that contains rules to identify an Ubuntu operating system as a Linux-type, server-class, operating-system looks like this:

<?xml version="1.0" encoding="utf-8"?>
<DataProcessingTypes>
  <ServerOperatingSystems>
    <ServerOperatingSystemType Expression="{A}">
      <OperatingSystem Name="A">ubuntu</OperatingSystem>
    </ServerOperatingSystemType>
  </ServerOperatingSystems>
  <OperatingSystemTypes>
    <OperatingSystemType Expression="{A}" OSType="Linux">
      <OperatingSystem Name="A">ubuntu</OperatingSystem>
    </OperatingSystemType>
  </OperatingSystemTypes>
</DataProcessingTypes>

Rules are grouped by RuleType. There are four RuleTypes to reflect the four data points that are handled by Customizable processing logic:

  • <VirtualMachineTypes> contains <VirtualMachineType> rules.

  • <OperatingSystemName> contains <OperatingSystemType> rules

  • <ServerOperatingSystems> contains <ServerOperatingSystem> rules.

  • <OracleDatabaseTypes> contains <OracleDatabaseTypes>.

The next section details the RuleTypes, including their input and output parameters.

Expression contains a template for a Boolean expression that must be applied to Named Expression Tokens that are defined in the sub-elements of a rule. The expression is a combination of Boolean logical operators (AND, OR, and NOT) that compare results of logical evaluation of sub-elements. Parentheses can be be used to group different logic operations in an Expression. The Output Parameters that are defined in a rule will be returned if the rule is triggered.

A Named Expression Token represents the Input Parameter of a rule and the value of the Name attribute is referred to in the expression. The logic always matches a value string from an attribute in an inv3x.xml file against the value that is enclosed in its tag. The evaluation compares the value of the Input Parameter that is retrieved from the inv3x.xml file with the string that is enclosed in the parameter. By default, the evaluation contains the "ContainsIgnoreCase" logic. This behavior can be changed by specifying a different logic as value for the Logic attribute of the Named Expression Token. The values for the Logic attribute are:

  • ContainsIgnoreCase: This checks if an enclosed substring contains the incoming-parameter value. The check is not case sensitive.

  • ContainsWithCase: This is identical to ContainsIgnoreCase except that it is case sensitive.

  • StartsWithIgnoreCase: This checks an enclosed substring at the end of a parameter. The check is not case sensitive.

  • EndsWithIgnoreCase: This is identical to StartsWithIgnoreCase except that it is case sensitive.

  • EndsWithCase: This is identical to EndsWithIgnoreCase except that it is case sensitive.

  • EqualsIgnoreCase: This checks if an enclosed substring is the same as the parameter value.

  • EqualsWithCase: This is identical to EqualsIgnoreCase except that it is case sensitive.

Example 36.
<Manufacturer Name="B" Logic="StartsWithIgnoreCase">Google</Manufacturer>


Rule types

VirtualMachineType

This type of rule detects whether an inventory file represents a virtual machine or not and an eventual hypervisor name. The rule also normalizes attributes such as Manufacturer and Model.

The following table shows possible input parameters and corresponding attributes and elements in the inx3x.xml file.

Input parameter

Inv3X tag

Tag attribute

Model

Client

Model

ClientType

Client

ClientType

Manufacturer

Client

Manufacturer

OperatingSystem

OperatingSystem

Name

The following table shows possible output values and corresponding affected table and columns in the Snow Inventory database.

Output parameter name

Database table

Column

Model

inv.DataClient

Model

ClientType

inv.DataClient

Type

Manufacturer

inv.DataClient

Manufacturer

HypervisorName

inv.DataClient

HypervisorName

IsVirtual

inv.DataClient

IsVirtual

Example 37.
<VirtualMachineType Expression="({A} OR {C}) AND NOT {B}" HypervisorName="VMware Virtual Platform" IsVirtual="true">
    <Model Name="A">vmware</Model>
    <OperatingSystem Name="B">esx</OperatingSystem>
    <Manufacturer Name="C">vmware</Manufacturer>
</VirtualMachineType>


OperatingSystemType

This type of rule detects the operating-system family (e.g. Linux, Windows, and Android). This is done while creating ClientContext.

The following table shows input parameters and corresponding elements and attributes in inv3x.xml.

Input parameter name

inv3x.xml element

Attribute

IsMobileDevice

Client

IsMobileDevice

ScannerVersion

Client

ScannerVersion

IsExternalProvider

Client

[Note: this value is not read from inv3x.xml, but is generated and based on the contents of the file; If the ClientType attribute of the Client element is equal to 'SIEDP', it is true.]

OperatingSystem

OperatingSystem

Name

ClientType

Client

ClientType

IsExternalProvider and IsMobileDevice are not used as Boolean values instead of being compared with string patterns.

The following table shows possible output values and the corresponding affected table and columns in the Snow Inventory database.

Output parameter name

Database table

Column

OsType

inv.DataOperatingSystem

OsType

[Note: see below.]

The output value of these rules is a string with the OsType name and the name stored in the database is numeric.

The following table shows the correspondence between OsType names and numeric values. The same correspondence is reported in the inv.OperatingSystemType table in the Snow Inventory database.

OsType name

OsType value

Windows

0

MacOsx

1

Linux

2

Hpux

3

Solaris

4

Aix

5

VmWare

6

Citrix

7

iOS

8

Android

9

ChromeOS

10

WindowsPhone

11

Symbian

12

Blackberry

13

Mainframe

14

CrossPlatform

15

Undefined

255

Example 38.
<OperatingSystemType Expression="{A}" OSType="Linux">
  <OperatingSystem Name="A">ubuntu</OperatingSystem>
</OperatingSystemType>


ServerOperatingSystemType

This type of rule detects whether an operating-system is considered to be of server-class or not.

The following table shows the input parameters and corresponding elements and attributes in the inv3x.xml file.

Input parameter name

inv3x.xml element

Attribute

OperatingSystem

OperatingSystem

Name

The following table shows output values and the corresponding affected table and columns in the Snow Inventory database.

Output parameter name

Database table

Column

[Implicit: 1 (true) if the inventory data matches the filter]

inv.DataOperatingSystem

IsServer

The output parameter is implicitly defined and is therefore not mentioned in the DataProcessorRules.xml file.

Example 39.
<ServerOperatingSystemType Expression="{A}">
  <OperatingSystem Name="A">ubuntu</OperatingSystem>
</ServerOperatingSystemType>


OracleDatabaseType

This rule type is used to normalize the name, version and edition of Oracle database products.

The following table shows input parameters and corresponding elements and attributes in the Snow Inventory Oracle Scanner (SIOS) inv3x.xml file.

Input parameter name

SIOS/inv3x.xml element

Attribute

ProductName

OracleDbTechnology

DatabaseProduct

The following table shows output values and the corresponding affected table and columns in the Snow Inventory database.

Output parameter name

Database name

Column

EvaluatedName

inv.DataOracleDatabase

ProductName

Version

[Note: These output-parameter values are not stored as is in the database. Instead, they contribute to the normalized product name which is defined as "Oracle Database {Version} {Edition}", which is then stored in the ProductName column of the inv.DataOracleDatabase table.]

Edition

IsEvaluated

[Note: This output parameter is only used to validate whether the input parameter is valid or not; In the latter case, the execution of the rule set is stopped.]

Example 40.
<OracleDatabaseTypes>
    <OracleDatabaseType Expression="NOT ({A} OR {B} OR {C} OR {D})" IsEvaluated="false">
        <ProductName Name="A">database</ProductName>
        <ProductName Name="B">oracle8</ProductName>
        <ProductName Name="C">oracle8i</ProductName>
        <ProductName Name="D">oracle9i</ProductName>
    </OracleDatabaseType>
    <OracleDatabaseType Expression="{A} AND {B}" EvaluatedName="Trusted Oracle Database 8 Enterprise Edition">
        <ProductName Name="A">trusted</ProductName>
        <ProductName Name="B">8</ProductName>
    </OracleDatabaseType>
    <OracleDatabaseType Expression="{A} AND {B}" Version="18c" Edition="Enterprise Edition">
        <ProductName Name="A">18c</ProductName>
        <ProductName Name="B">enterprise</ProductName>
    </OracleDatabaseType>
</OracleDatabaseTypes>

The first rule is required to determine whether the product name contains a valid string or not. If the product name to be normalized is not valid, the function will return the null value.

If the second rule triggers, it will return the product-name string from the EvaluatedName output parameter.

The third rule is used to determine the version and edition of an Oracle product. If the rule is executed, the normalized product name will be entered into the Snow Inventory database as "Oracle Database {Version} {Edition}," where version and edition are corresponding output parameters.



Logging

Customizable processing logic does not generate logs by default. To facilitate troubleshooting of rules, enable log generation for Customizable processing logic in the Inventory Server snowserver.config file.

[...]
<Logging>
  <Tags>
      [...]
      <Tag>data-rules-engine</Tag>
      [...]
  </Tags>
  [...]
</Logging>
[...]

When data-rules-engine is enabled, logs are generated.

Example 41.
2020-06-02T14:26:33+02:00;data-rules-engine;OperatingSystemType;;;DPRE returned "Windows" as OS type when "OperatingSystem: Microsoft Windows Server 2016 Datacenter, Model: , Manufacturer: , ClientType: Snow Agent - Windows, HypervisorName: , ScannerVersion: , IsMobileDevice: False, IsExternalProvider: False"
2020-06-02T14:27:24+02:00;data-rules-engine;VirtualMachineType;;;DPRE evaluation results "OperatingSystem: Microsoft Windows Server 2016 Datacenter, Model: Google Compute Engine, Manufacturer: Google, ClientType: Snow Agent - Windows, HypervisorName: Google Compute Engine, IsVirtual: True" for client id  "1"