How to filter Automation Policy Messages using XML?
search cancel

How to filter Automation Policy Messages using XML?


Article ID: 184989


Updated On:


IT Management Suite


Some of the SMP automation policies run when a specific system message is received. Applying the filter to the system messages lets you trigger the automation policy only if it receives a message that matches to the rule(s) that you specify. 


To apply a filter to Automation Policy Message using XML:

  1. In the Symantec Management Console, on the Manage menu, click Automation Policies.
  2. On the Automation Policies page, on the System Messages tab, in the right pane, under Trigger type, select the NS Message that you want to filter.
    To see all NS Messages, check Show all messages.
  3. To view all message fields, click the View all message fields (glasses) icon next to the NS Messages drop-down list.
    You can use these fields for filtering the messages.
  4. To specify the filtering rules, check Apply message filter, and then click the Edit message filter (pencil) icon to create the filter.
  5. In the Edit message filter dialog box, on the Sample Message tab, you can see the XML schema of the selected NS Message as an example.
    Note that the ImportRuleGuid is manually edited to a real value.

  6. On the Filter XML tab, you can enter the XML of the filter.
  7. On the Evaluation Output tab, you can see the variables that the filter saves and the print/log messages that the filter creates.
  8. In the Edit message filter dialog box, click OK.
  9. Click Save changes.

Examples of filtering XML

The examples below provide you with the most useful filtering XML examples. The examples are based on the Active Directory Import Completed NS Message.

1. Filtering by NS Message field

The Automation Policy is only triggered when particular Active Directory Import rule is executed. Creating the XML requires knowing the GUID of the rule. You find the GUID of the rule in SMP Logs when you run the rule.

Option #1 (detailed)

    <if:equal v='38187410-d399-4152-abd6-a35d3e4f407b'>

Option # 2 (short)

<check:equal ctx='RuleGuid' v='38187410-d399-4152-abd6-a35d3e4f407b'/>

2. Filtering by NS Item property, which is referenced by some NS Message field

Sometimes, the messages are coming from the items that should be checked for some internals first, and then executed if applicable. In the following sample case, RuleGuid property of the NS Message is an Item (AD Import Rule) with property Server.

Option #1 (detailed)

            <if:equal v=''>

Option #2 (short)

<check:equal ctx='RuleGuid:Item.Server' v=''/>

3. Propagating XML Filter Variables to Data Source

It is possible to save evaluated data from filter XML as a Report or SQL Query. To achieve this, you have to know the exact names that the selected Data Source can use as parameters.

For example, if you define the Raw SQL Query data source with custom parameter as follows:

The filter to save the parameter for data source would be the following:

<save:vRuleGuid ctx='RuleGuid'>

If you choose the Action to be the task that sends the results as HTML after Active Directory Import, the e-mail will look as follows:

4. Using logical blocks OR, AND, DO

Filter XML evaluation must return Boolean value. However, internally the following three evaluation results are used:

  • NULL – the node evaluation is not affecting the current execution block (e.g. actions like “save”)
  • TRUE – node evaluation succeeded
  • FALSE – node evaluation failed

4.1 Using AND

    <check:equal ctx='RuleGuid' v='38187410-d399-4152-abd6-a35d3e4f407b'/>
    <check:equal ctx='ErrorCode' v='0'/>

This filter will succeed if all evaluations are TRUE.

4.2 Using OR

    <check:equal ctx='RuleGuid' v='38187410-d399-4152-abd6-a35d3e4f407b'/>
    <not><check:equal ctx='ErrorCode' v='0'/></not>

This filter will succeed if RuleGuid matches the value or ErrorCode is not equal to ‘0’ (failed rule).

4.3 Using DO

Note that DO does not combine the result, but ensures that all the steps are executed. The result is NULL and will not affect the logic above this section. If this is the only section in the filter, the filter will fail because the result is NULL, not TRUE.

    <log:verbose v='AD Rule executed, message: $(Xml)' cat='Automation Policy Hooks'/>
    <log:info v='AD Rule executed: $(RuleGuid:Item)' cat='Automation Policy Hooks'/>

This filter will log 2 messages in SMP Log and then stop Automation Policy to proceed:

5. Forcing return values

In some cases, it is necessary to define the end result of the evaluation:

  • Of current node
  • Of current nodes block
  • Of the whole flow

5.1 Using Return

The Return operator can be used as the last node in block to mark the node execution as TRUE, even if the node type is NULL.

<save:vClass ctx='RuleGuid:Item:Xml:XPath(/item/import/classes/class/@name):First.Value'>

This sample will return TRUE. If this is the only section in filter, the filter will pass and the policy continues to run.

5.2 Using Break

The Break will exit from the current node block and return TRUE.

    <log:verbose v='AD Rule executed, message: $(Xml)' cat='Automation Policy Test'/>
    <log:info v='AD Rule executed: $(RuleGuid:Item)' cat='Automation Policy Test'/>

This sample reports the verbose log, but no info. Even if the DO block should evaluate everything, it will pass.

5.3 Using Exit

The Exit will end the whole filter evaluation and set the overall result.

    <ifnot:equal ctx='ErrorCode' v='0'>
        <log:error v='AD Rule failed, error code: $(.), message: $($ErrorMessage)'/>
    <log:info v='AD Rule executed: $(RuleGuid:Item)'/>

If the message contains non-zero ErrorCode value, the error message is shown in log and fail filter XML. Otherwise, informational message will be logged and filter will succeed.