Skip to main content

Customizable processing logic

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>

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.

  • <OperatingSystemTypes> contains <OperatingSystemType> rules

  • <ServerOperatingSystems> contains <ServerOperatingSystemType> 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
<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 parameterInv3X tagTag attribute
ModelClientModel
ClientTypeClientClientType
ManufacturerClientManufacturer
OperatingSystemOperatingSystemName

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

Output parameter nameDatabase tableColumn
Modelinv.DataClientModel
ClientTypeinv.DataClientType
Manufacturerinv.DataClientManufacturer
HypervisorNameinv.DataClientHypervisorName
IsVirtualinv.DataClientIsVirtual
EXAMPLE
<?xml version="1.0" encoding="utf-8"?>
<DataProcessingTypes>
<VirtualMachineTypes>
<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>
</VirtualMachineTypes>
</DataProcessingTypes>

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 nameinv3x.xml elementAttribute
IsMobileDeviceClientIsMobileDevice
ScannerVersionClientScannerVersion
IsExternalProviderClient[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.]
OperatingSystemOperatingSystemName
ClientTypeClientClientType

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 nameDatabase tableColumn
OsTypeinv.DataOperatingSystemOsType
[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 nameOsType value
Windows0
MacOsx1
Linux2
Hpux3
Solaris4
Aix5
VmWare6
Citrix7
iOS8
Android9
ChromeOS10
WindowsPhone11
Symbian12
Blackberry13
Mainframe14
CrossPlatform15
Undefined255
EXAMPLE
<?xml version="1.0" encoding="utf-8"?>
<DataProcessingTypes>
<OperatingSystemTypes>
<OperatingSystemType Expression="{A}" OSType="Linux">
<OperatingSystem Name="A">ubuntu</OperatingSystem>
</OperatingSystemType>
</OperatingSystemTypes>
</DataProcessingTypes>

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 nameinv3x.xml elementAttribute
OperatingSystemOperatingSystemName

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

Output parameter nameDatabase tableColumn
[Implicit: 1 (true) if the inventory data matches the filter]inv.DataOperatingSystemIsServer

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

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

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 nameSIOS/inv3x.xml elementAttribute
ProductNameOracleDbTechnologyDatabaseProduct

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

Output parameter nameDatabase nameColumn
EvaluatedNameinv.DataOracleDatabaseProductName
Version
Edition
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.
IsEvaluatedNote: 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
<?xml version="1.0" encoding="utf-8"?>
<DataProcessingTypes>
<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>
<DataProcessingTypes>

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
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"