Creating rules

Rules evaluate incoming events generated by monitor adapters and trigger processes according to the results.

Every rule on a grid evaluates all XML input from the events from the monitor adapters on the grid. Each rule can trigger only one process, but a single event might cause multiple rules to evaluate to true, causing multiple processes to run.

When a process is triggered by a rule, the entire adapter's event XML is passed to the process to an input parameter. The input parameter must be created in the Start activity of the process and named inputevent context item. BMC Atrium Orchestrator encapsulates each event with the parent XML "inputevent," therefore all of the monitor adapter's events are captured in the inputevent context name. You can use a transform editor to parse the input event and store extracted content in context items.

For more information about Start activity properties, see Start activity.

To create a rule

1. In the BMC Atrium Orchestrator Development Studio Project Navigator, expand the module that will use the rule.
2. Double-click rules.

3. In the Rules Designer tab, click Add in the toolbar.

4. In the empty rule, enter the name for the rule in the Rule field.

5. Click the Search button on the far right and browse to select the process that you want to run if the rule evaluates to true.

   A process is listed in the process browser only if the Expose Process in Rules property was selected for that process in the Process Properties dialog box or in the New Process dialog box.

6. In the Match selection list, choose how you want the rule to be applied using one of the following options:

   The source for the condition comparison is the adapter event generated by the monitor adapter. The adapter event is an XML document that you can transform to extract a portion from for comparison.

   • All indicates that if every condition evaluates to true, the process is executed.

   • Any indicates that if any condition evaluates to true, the process is executed.

7. To launch the transform editor, click the Transform button.

   The Transform Editor wizard is displayed. For information about using the transform editor, see Using a transform editor.

   The Token pane is not present in the transform editor launched from the rules designer because tokens cannot be used in XPath expressions executed against adapter events.

8. Create the XPath expression to extract the content that you want to use for the rule condition.

9. Click Save and Exit to save the expression and return to the rules designer.

10. Select the comparator that you want to use from the drop-down menu.

    The comparator is a relational operator that compares the value derived from the Source field to the contents of the Value field and evaluates the expression to true or false.

11. Select the value type from the selection list to the right of the Value field, as described in the following table:

    Value type	Description
    String	A character string If you select String, enclose the value in single quotation marks.
    Numeric	A number
    Date	A date Use the Calendar button below the Value field to populate the field. All dates are stored in epoch time format. When comparing a date from an event generated by an IMAP or POP monitor adapter, use the value contained in the <sent-epoch-milliseconds> element.
    Input Event	A value from the incoming monitor adapter event Use this value type to compare one part of the adapter event to another. If you select this type, the Transform button is displayed below the Value field to allow access to the transform editor.

12. In the Value field, enter the value that you want to compare to the source value.

    For values with a Value Type of Input Event the Value field is not available. The value is the entire adapter event, or the segment of the adapter event as defined with an XPath expression in the transform editor. Repeat steps 6 through 8 to extract the portion that you want to compare to the source value.

13. (optional) Click the Add button to add additional conditions.

14. Click Apply to save the rule; click OK to clear the confirmation message.

The new rule is displayed in the Rules List.

Example

The following examples demonstrate the Match setting of All or Any and how they control when the process runs based on the two specified rules (conditions).

• Example A specifies that all conditions must be satisfied (meaning both conditions must be met) for the process to run.
• Example B specifies that any condition can be satisfied (meaning one of the two conditions must be met) for the process to run.

The following XML samples show three possible scenarios to which the two conditions can be applied:

When Match is set to All (as in example A):

• Scenario 1: Both conditions are satisfied (all conditions are met). The process runs.
• Scenario 2: One condition is satisfied. The process does not run.
• Scenario 3: No conditions are satisfied. The process does not run.

When Match is set to Any (as in example B):

• Scenario 1: Both conditions are satisfied (all conditions are met). The process runs.
• Scenario 2: One condition is satisfied.  The process runs.
• Scenario 3: No conditions are satisfied. The process does not run.