Using PowerShell to Check for Syntax Errors in System.ExpressionFilter Modules (OpsMgr Authoring)

With its wide range of usefulness in implementing conditional logic, expression evaluation, and error filtering, the System.ExpressionFilter module is likely to be a frequently used module in most OpsMgr Management Pack authoring scenarios.   However, the default configuration for the System.ExpressionFilter module may lead to a potential syntax error that is quite easy to miss, in my opinion.  This potential syntax error relates to the default configuration of the ValueExpression elements of the ExpressionFilter, in that the ValueExpression defaults to an XPathQuery value type.   If this default is not changed when evaluating a non-XPathQuery value, the workflow (as well as all workflows cooked down with the faulted workflow) will fail.

To illustrate an oversight resulting in this error, the following ExpressionFilter configuration would result in a workflow failure:

<SimpleExpression>
   <ValueExpression>
        <XPathQuery>ErrorCode</XPathQuery>
   </ValueExpression>
   <Operator>Equal</Operator>
   <ValueExpression>
       <XPathQuery>1</XPathQuery>
    </ValueExpression>
</SimpleExpression>

The correct implementation of this Expression Filter module would be:

<SimpleExpression>
   <ValueExpression>
        <XPathQuery>ErrorCode</XPathQuery>
   </ValueExpression>
   <Operator>Equal</Operator>
   <ValueExpression>
       <Value>1</Value>
    </ValueExpression>
</SimpleExpression>

Unfortunately, this type of error is not caught by the MPBPA, most likely due to the difficulty in differentiating between a valid XPathQuery value and string value.  To perform some basic error checking to identify these errors when authoring, I have written a simple PowerShell script that analyzes the XML of an unsealed Management Pack and reports errors and potential errors with ValueExpression configuration in ExpressionFilter modules.  

The logic of the script assumes the following:

  • Any ValueExpression configured as an XPathQuery expression and having a value that starts with a dollar sign ($) can be assumed to be a configuration error
  • Any ValueExpression configured as an XPathQuery expression and having a value that does not start with a forward slash or the strings:  Property or ErrorCode might be misconfigured

The script accepts the path to the Management Pack XML file as the single input parameter and then searches the XML for RegExExpression, SimpleExpression, and DayTimeExpression XML nodes.  These nodes are evaluated for mismatches on XPathQuery expressions and mismatches are reported to the console.

The output of the script looks like:

PS D:\Development\SCOM> ./checkexpressionfilters.ps1 -MPFIle:”d:\development\scom\xsnmp\1.1.Dev\xSNMP.AIX.xml”
Evaluating d:\development\scom\xsnmp\1.1.Dev\xSNMP.AIX.xml 

Error – Found mismatched XPathQuery value with XML:
<XPathQuery>$Target/Property[Type=”xSNMP.AIX.Processor”]/Name$</XPathQuery> 

Error – Found mismatched XPathQuery value with XML:
<XPathQuery>$Target/Property[Type=”xSNMP.AIX.Processor”]/Name$</XPathQuery> 

Errors found: 2
Warnings found: 0

The script can be downloaded here.

Read more of this post

Advertisements

Development Updates

While this blog has been a bit quiet lately, it has not been for lack of efforts.   In the next two weeks, a minor update to the xSNMP suite should be ready with a few bug-fixes and feature improvements.    This update will also include three new management packs:

  • xSNMP  for Juniper Networks
  • xSNMP for SonicWALL
  • xSNMP for APC NetBotz

We’re still finishing up testing and fine-tuning on the Oracle Unix/Linux MP as well.

These updates will be described in more detail here and available for download on manage-X.net soon.