Cisco Cisco Process Orchestrator 3.1 User Guide
11-5
Cisco Process Orchestrator 3.1 User Guide
Chapter 11 Working with Events and Triggers
Correlating Events
Creating a Variable Updated Trigger
Use the Variable Updated Properties trigger to specify the changed variable value to use as a trigger to
execute a process. This criteria determines the values that must be met before the process executes.
execute a process. This criteria determines the values that must be met before the process executes.
Step 1
Click the Triggers tab, then click New > Variable Updated.
Step 2
Click the General tab and enter the general information for the trigger.
Step 3
Click the Conditions tab to include special conditions for when the event log trigger will be applied.
Step 4
Click OK to complete the procedure.
Adding Trigger Logic to Process Workflows
You can check the attributes of a trigger in a process, so that if one process has multiple triggers (such
as started by user, started by parent process, and a trigger from an AMQP message), you can check which
of these events occurred and branch the execution accordingly. The properties of the event that triggered
the process are available in the process workflow using reference control.
as started by user, started by parent process, and a trigger from an AMQP message), you can check which
of these events occurred and branch the execution accordingly. The properties of the event that triggered
the process are available in the process workflow using reference control.
Correlating Events
Process Orchestrator contains a technology called Correlex that allows events that match data in the
workflow (such as a trigger) to be correlated. Process Orchestrator’s event correlation capabilities are
real time, in memory, geared towards typical IT staff, not programmers, and can be combined with active
probing and action activities to leverage correlated data.
workflow (such as a trigger) to be correlated. Process Orchestrator’s event correlation capabilities are
real time, in memory, geared towards typical IT staff, not programmers, and can be combined with active
probing and action activities to leverage correlated data.
Process Orchestrator’s correlation activities can be placed anywhere in a workflow and reference any
data from prior workflow steps. It is common for workflows to capture diagnostic data to perform
decision tree branching before they correlate other events. A workflow might:
data from prior workflow steps. It is common for workflows to capture diagnostic data to perform
decision tree branching before they correlate other events. A workflow might:
•
Probe the system to see if a service is up.
•
Test system performance.
•
Look up configuration to find a relationship that is not evident in events themselves and then use
that new information to capture events.
that new information to capture events.
Process Orchestrator's process workflows can include activities other than correlations to capture
supplemental non-event data in real time that might be gone before the end of a classic event correlation
time window.
supplemental non-event data in real time that might be gone before the end of a classic event correlation
time window.
For example, assume there are two events, A and B, and there is a need to handle things one way when
only A occurs, and another when A and B happen together. In correlation, a time window is required; if
A occurs, it will not be clear whether A and B both occur until the end of the time window. So the results
of the correlation might not be able to publish the results until sometime after A occurs. But with
complex enterprise systems, often issues can be fleeting. There is a need to capture data right when a
condition occurs or it might be gone; in other words, the tool might miss event A while looking for event
B. Too often for difficult issues, troubleshooting data is not available at the time the operator is notified
or some correlation response script occurs.
only A occurs, and another when A and B happen together. In correlation, a time window is required; if
A occurs, it will not be clear whether A and B both occur until the end of the time window. So the results
of the correlation might not be able to publish the results until sometime after A occurs. But with
complex enterprise systems, often issues can be fleeting. There is a need to capture data right when a
condition occurs or it might be gone; in other words, the tool might miss event A while looking for event
B. Too often for difficult issues, troubleshooting data is not available at the time the operator is notified
or some correlation response script occurs.