Handling String Array() Values in OpsMgr WinRM Enumeration Data Sources

I was recently asked a question on this topic, and I thought it was worth sharing.  

In this post, I described discovering Oracle processes with enumerations of instances of the SCX_UnixProcess class that are filtered on the values of the “Parameters” property.   The question I was asked involved a problem with a similar discovery process that was not evaluating the full Parameters value if more than oe value is returned.   An example of an enumeration for such an SCX_UnixProcess instance would be:

SCX_UnixProcess
    CSCreationClassName = SCX_ComputerSystem
    CSName = tl-lx02.testlab.corp
    Caption = Unix process information
    CreationClassName = SCX_UnixProcess
    CreationDate = 2010-05-09T09:17:37.614884Z
    Description = A snapshot of a current process
    […]
    ModulePath = /usr/bin/Xorg
    Name = Xorg
    OSCreationClassName = SCX_OperatingSystem
    OSName = Red Hat Distribution
    OperationalStatus = null
    OtherEnabledState = null
    OtherExecutionDescription = null
   Parameters = /usr/bin/Xorg, :0, -br, -audit, 0, -auth, /var/gdm/:0.Xauth
    ParentProcessID = 4040
    Priority = 75
    ProcessGroupID = 4048
    ProcessNiceValue = 20
    ProcessSessionID = 4048
    ProcessTTY = null
    […]

In this example, if an ExpressionFilter module were configured to evaluate the XPATH query:  //*[local-name()=”Parameters”], the evaluated value  would resolve to:  /usr/bin/Xorg.  Just the first value in the string array  would be evaluated.  

However, with this array of strings, the other values can be accessed with an ordinal appended to the XPATH queries:
 //*[local-name()=”Parameters”][1]
//*[local-name()=”Parameters”][2]
//*[local-name()=”Parameters”][3]
etc.

So, the ExpressionFilter module could easily be configured with a top-level  ‘OR’ operator, and a sequence of RegExExpressions to evaluate the first 2, 3, 4, 5 etc values in the Parameters value list