Search for	Example	Results
A single word	`cat`	Topics that contain the word "cat". You will also find its grammatical variations, such as "cats".
A phrase. You can specify that the search results contain a specific phrase.	`"cat food"` (quotation marks)	Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase.

Search for	Operator	Example
Two or more words in the same topic	`AND` `and` `+` (plus symbol) `&` (ampersand)	`cat AND dog` `"cat food"+milk` `"cat food"&"dog food"`
Either word in a topic	`OR` `or` `\|` (pipe)	`cat OR dog` `cat \| dog`
Topics that do not contain a specific word or phrase	`NOT` `not` `!` (exclamation point)	`NOT cat` `! dog`
Topics that contain one string and do not contain another	`^` (caret)	`cat ^ mouse`
A combination of search types	`( )` parentheses	`cat + (dog \| mouse)` `cat \| dog + (! mouse)`

Operations Connector10.11

Administer > Policies > Scheduled Task Policies > Scheduled Task Policy User Interface > Configuring Events in Scheduled Task Policies

Configuring Events in Scheduled Task Policies

Scheduled task policies can send a notification event to OMi when a command or script starts, finishes, or fails. You can design the start, success, or failure events that you want to receive by completing the information in the Start Event, Success Event, and Failure Event tabs.

To access

In the Operations Connector user interface, click in the toolbar, then click Event > Scheduled Task. The scheduled task policy editor opens.

Alternatively, double-click an existing scheduled task policy to edit it.

Click Start Event, Success Event, or Failure Event.

Tasks

How to configure events for scheduled task policies

This task describes how configure events generated by scheduled task policies.

Select Send Start Event, Send Success Event, or Send Failure Event.
Click Event Attributes to define default event attributes, such as severity and category.

After loading the indicators from the connected OMi server, the Indicators tab shows a hierarchy of configuration item types.

To insert an indicator, drag the indicator with its state from the Indicators tab to the policy.
Click Event Correlation to set the type of duplicate event suppression and define the method used to suppress duplicate events.
Click Custom Attributes to add additional information to all events generated by this policy. For example, you might add a company name, contact information, or a city location to an event.
Click Advanced to define default advanced attributes such as legacy HPOM attributes and agent MSI (Message Stream Interface) settings.
Optional. Use the Indicators tab to add indicators to the source or target value fields. After loading the indicators from the connected OMi server, the Indicators tab shows a hierarchy of configuration item types with the associated health indicators (HIs) and event type indicators (ETIs).
Optional. In the Policy Variables tab, add policy variables to event attributes. Operations Connector replaces the variables with the appropriate values in the generated event.

Use quotation marks to surround variables, for example "<$MSG_NODE>" or "<$MSG_GEN_NODE>", at least for those variables whose values can contain space characters.

Related tasks

How to Schedule Tasks

UI Descriptions

Start, Success, and Failure Event Pages

UI Element	Description
Send Start Event	Click to send an event when the command begins to run.
Send Success Event	Click to send an event when the command completes successfully.
Send Failure Event	Click to send an event when the command fails to run or fails to complete successfully.

Event Attributes Tab

UI Element	Description
Title	Brief description of the nature of the event.
Description	Detailed description of the event.
Severity	Severity assigned to the event (Critical, Major, Minor, Warning, Normal, Unknown).
Category	Name of the logical group to which the event belongs (for example, Database, Security, or Network). The event category is similar in concept to the Operations Manager message group.
Subcategory	Name of the logical subgroup (category) to which the event belongs (for example, Oracle (database), Accounts (security), or Routers (network)).
ETI	Contains the event type indicator (ETI) resolution hint, which OMi uses to associate the event with an ETI and for event correlation. Use the format `<ETI name>:<ETI state>:<metric value>`. Specify the name of the indicator (for example, CPULoad), the indicator state (for example, High), and, optionally, the metric value (for example, 80). When OMi receives an event with an ETI resolution hint of CPULoad:High, and the ETI and state exist, the Event Type Indicator attribute is set to CPULoad:High in the event. The metric value is optional and serves informational purposes only.
Node	Name of the system where the event occurred (for example, node.example.com).
Related CI	Contains the CI that is related to the metric (for example, oraclesid01@@node.example.com or C:@@server.example.com). Use the format `<CI 1>:<CI 2>:...:<CI n>@@<hostname>`. Best practices for related CIs It is necessary to differentiate between CIs that have a Composition relationship to a node, and those that do not have such a relationship: For “hosted on” CIs `<key attribute 1>:<key attribute 2>:<key attribute n>@@<hostname>` Typically, a “hosted on” CI is a sub-type of “Running Software”. For example, a CI of type `websphereas` has a Composition relationship to a node. For virtual CIs `<key attribute 1>:<key attribute 2>:<key attribute n>` A virtual CI does not have a strong containment relationship (Composition relationship) to node. An example of a typical virtual CI type is cluster. This CI type does not have a strong containment relationship to a node. If you have problems resolving non-hosted CIs, provide the RTSM ID of the desired CI by using the format `UCMDB:<ci_uuid>`. For more information about CI resolution in OMi, see the OMi Help.
Sub Component	Information used to identify a subcomponent of a CI. This CI subcomponent is used to calculate an aggregated status within OMi's Service Health for selected CIs. If an HI is populated by events from multiple components, you can specify a component name in this field in order to ensure the correct calculation of the HI state. For example, if you have a Computer CI with two CPUs, `cpu #1` and `cpu #2`, events from both CPUs will be sent to the same `CPU Load` HI. By default, the events will override each other and create an incorrect HI state. To prevent this, you can populate Sub Component with values `"cpu #1"` and `"cpu #2"` which will cause the HI state to be calculated as an aggregated state between the two events.
Source CI	Contains the source related CI. For example, type the name and instance of the third-party system that provides events (for example, NNMi@@mgmt1.example.com or SCOM@@mgmt2.example.com). If you enter a source related CI, OMi tries to find the corresponding CI in the RTSM.
Source Event ID	ID of the event in the third-party system. This ID is required for synchronization of event changes with the source event. It also enables drilldown into the third-party system in the Event Browser in OMi. The file that the policy reads usually contains the source event ID. If you are working with sample data, you can drag the source event ID from the Sample Data tab and add it to the source event ID field.
Send with closed status (For the Open Message Interface, SNMP Interceptor, and Scheduled Task policies)	Sets the event's lifecycle status to Closed before sending it to OMi.

Event Correlation Tab

UI Element	Description
Event Key	An identifier used to identify duplicates and for Close Events with Key.
Close Events with Key	If events with the event key that you type here exist in the OMi event database when this event is received, these events are automatically closed. You can use pattern matching and variables to match multiple event keys. For example, consider the following pattern: `<$MSG_SEV>:<$MSG_NODE_NAME>` This pattern is evaluated by first replacing the variables with the values that they resolve to, for example: `critical:cabbage.example.com` This pattern is then compared using pattern matching rule against the event keys for all events in the OMi event database. Any key that you provide in the policy is treated as a simplified OM pattern in OMi. Therefore a plain string is treated as a substring and not as a complete match. The key in our example will match: critical:cabbage.example.com:TEST critical:cabbage.example.com:TEST1 critical:cabbage.example.com:TEST2A and so on. To ensure that that the key matches only exact values, enclose the attribute value in an OM Pattern Expression, starting with ^ (start of line) and ending with $ (end of line), for example: ^critical:cabbage.example.com:TEST$ An Operations Manager i Event Management Foundation License is required to enable the Close Events with Key feature in OMi
Suppress Deduplication on Server	Stops automatic discarding of new events that are duplicates of existing events.

UI Element

Description

Event Key An identifier used to identify duplicates and for Close Events with Key.

Close Events with Key

If events with the event key that you type here exist in the OMi event database when this event is received, these events are automatically closed. You can use pattern matching and variables to match multiple event keys. For example, consider the following pattern:

<$MSG_SEV>:<$MSG_NODE_NAME>

This pattern is evaluated by first replacing the variables with the values that they resolve to, for example:

critical:cabbage.example.com

This pattern is then compared using pattern matching rule against the event keys for all events in the OMi event database. Any key that you provide in the policy is treated as a simplified OM pattern in OMi. Therefore a plain string is treated as a substring and not as a complete match. The key in our example will match:

critical:cabbage.example.com:TEST
critical:cabbage.example.com:TEST1
critical:cabbage.example.com:TEST2A

and so on.

To ensure that that the key matches only exact values, enclose the attribute value in an OM Pattern Expression, starting with ^ (start of line) and ending with $ (end of line), for example:

^critical:cabbage.example.com:TEST$

An Operations Manager i Event Management Foundation License is required  to enable the Close Events with Key feature in OMi

Suppress Deduplication on Server Stops automatic discarding of new events that are duplicates of existing events.

Custom Attributes Tab

UI Element	Description
	Create New Custom Attribute: Creates a new custom attribute.
	Delete Custom Attribute: Deletes an existing custom attribute.
Name	The name of the custom attribute. The name is case-insensitive. Custom attributes are additional attributes that contain any information that is meaningful to you. For example, you might add a company name, contact information, or a city location to an event. You can have more than one custom attribute attached to a single event. The following custom attribute names cannot be used because they are reserved for internal use: `Description` `EtiHint` `HP_OPR_SAAS_CUSTOMER_ID` `NoDuplicateSuppression` `RelatedCiHint` `SourceCiHint` `SourcedFromExternalId` `SourcedFromExternalUrl` `SubCategory` `SubCiHint`
Value	Value of the custom attribute.

Advanced Tab

UI Element	Description
Event Drilldown
Event Drilldown URL	URL of the event in thethird-party system. This is the complete path of the URL, and includes the FQDN (fully qualified domain name) of the computer that hosts the third-party system, the communication port, and the root URL path (for example, `http://nnmi.example.com:8004/nnm/launch?cmd=showForm&objtype =Incident&objuuid=$OPC_CUSTOM[nnm.incident.uuid]&menus=true`). Event drilldown information enables OMi users to launch the user interface of the third-party system in the context of an event. To drill down to a specific event in the third-party system, add the source event ID to the URL. This event attribute can also be set by OMi based on an Operations Connector integration server configuration. If a policy and an integration server configuration both set this attribute, the information in the policy takes precedence.
OM Attributes
Application	Application that caused the event to occur. Unlike the Related CI attribute, which is a direct relationship to a CI in the RTSM, the application attribute is a simple string-type attribute (for example, Oracle and OS).
Object	Device such as a computer, printer, or modem. Unlike the Related CI attribute, which is a direct relationship to a CI in the RTSM, the object attribute is a simple string-type attribute (for example, `C:`, and `/dev/spool`).
Type	String used to organize different types of events within an event category or subcategory (for example, users or applications, accounts and security). The attribute is automatically set to `BSMC_Message`. You can delete the value but it will be inserted when you save the policy.
HPOM Service ID	ID of the service associated with the event. A service ID is a unique identifier for a service and can be used in OMi to identify the node and CI associated with the event.
Agent MSI	The message stream interface (MSI) allows external applications to interact with the internal event flow of Operations Agent. The external application can be a read-write application, for example, an event processing program that can read events, modify attributes, and generate new events for retransmission to the server. The application could also read events, or send its own events.
Divert events	If Agent MSI is enabled, diverts an event to the MSI instead of to the server when an event is requested by an external application.
Copy events	If Agent MSI is enabled, sends the event to the server, and a copy of the event to the MSI.

Indicators Tab

UI Element	Description
	Refresh. Loads the configured indicators from the connected OMi server. Loading indicators from the OMi server may take a few seconds. The Operations Connector server must be configured as an Operations Connector integration server in OMi for the indicators to load successfully.
<Search …>	Entered search string is used to search the indicators and highlight only the indicators containing the specified string. To search for indicators with specific text strings in the name, type the string in the <Search …> field and click the button. The first matching indicator is selected in the list of rules. Click the and buttons to move to the previous and next matching indicator.
<Indicators>	Hierarchy of configuration item types with associated health indicators (HIs), which are applicable for the event integration only, and event type indicators (ETIs). To insert an indicator with a state in a policy, drag and drop the indicator from the Indicators tab to the relevant field in the policy.

UI Element

Description

Refresh. Loads the configured indicators from the connected OMi server.

Loading indicators from the OMi server may take a few seconds.
The Operations Connector server must be configured as an Operations Connector integration server in OMi for the indicators to load successfully.

Entered search string is used to search the indicators and highlight only the indicators containing the specified string.

To search for indicators with specific text strings in the name, type the string in the <Search …> field and click the button. The first matching indicator is selected in the list of rules. Click the and buttons to move to the previous and next matching indicator.

Hierarchy of configuration item types with associated health indicators (HIs), which are applicable for the event integration only, and event type indicators (ETIs). To insert an indicator with a state in a policy, drag and drop the indicator from the Indicators tab to the relevant field in the policy.

Policy Variables Tab

Policy Variables Tab for Database and REST Web Service Listener Policies (Events only)

Variable	Description
`<$MSG_APPL>`	Returns the name of the application associated with the input event that caused the message. Sample output: `/usr/bin/su(1) Switch User`
`<$MSG_GEN_NODE>`	Returns the IP address of the node that sends the event. Sample output: `192.168.1.123`.
`<$MSG_GEN_NODE_NAME>`	Returns the host name of the node that sends the event. Sample output: `node123.example.com`.
`<$MSG_GRP>`	Returns the default category of the event. Sample output: `Security`
`<$MSG_ID>`	Returns the unique identity number of the event, as generated by the Operations Agent. Note that identity numbers are not generated for suppressed messages. Sample output: `6e998f80-a06b-71d0-012e-0f887a7c0000`
`<$MSG_NODE>`	Returns the IP address of the node on which the original event took place. Sample output: `192.168.1.123`
`<$MSG_NODE_NAME>`	Returns the name of the node on which the original event took place. This is the hostname that the agent resolves for the node. This variable is not fixed, however, and can be changed by a policy on a per-event basis.
`<$MSG_SERVICE>`	Returns the service name associated with the event.
`<$MSG_OBJECT>`	Delivers the name of the object associated with the event.
`<$MSG_SEV>`	Returns the default value for the severity of the event. Sample output: `Normal`
`<$MSG_TEXT>`	Returns the full text of the event. Sample output: `SU 03/19 16:13 + ttyp7 bill-root`
`<$MSG_TIME_CREATED>`	Returns the time the message was created on the managed node in seconds elapsed since midnight (00:00:00), January 1, 1970, coordinated universal time. Sample output: `950008585`
`<$MSG_TYPE>`	Delivers the name set for message type.

Policy Variables Tab for XML File and Structured Log File Policies (Events only)

Variable	Description
`<$MSG_APPL>`	Returns the name of the application associated with the input event that caused the message. Sample output: `/usr/bin/su(1) Switch User`
`<$MSG_GEN_NODE>`	Returns the IP address of the node that sends the event. Sample output: `192.168.1.123`.
`<$MSG_GEN_NODE_NAME>`	Returns the host name of the node that sends the event. Sample output: `node123.example.com`.
`<$MSG_GRP>`	Returns the default category of the event. Sample output: `Security`
`<$MSG_ID>`	Returns the unique identity number of the event, as generated by the agent. Note that identity numbers are not generated for suppressed messages. Sample output: `6e998f80-a06b-71d0-012e-0f887a7c0000`
`<$MSG_NODE>`	Returns the IP address of the node on which the original event took place. Sample output: `192.168.1.123`
`<$MSG_NODE_NAME>`	Returns the name of the node on which the original event took place. This is the hostname that the agent resolves for the node. This variable is not fixed, however, and can be changed by a policy on a per-event basis.
`<$MSG_SERVICE>`	Returns the service name associated with the event.
`<$MSG_OBJECT>`	Delivers the name of the object associated with the event.
`<$MSG_SEV>`	Returns the default value for the severity of the event. Sample output: `Normal`
`<$MSG_TEXT>`	Returns the full text of the event. Sample output: `SU 03/19 16:13 + ttyp7 bill-root`
`<$MSG_TIME_CREATED>`	Returns the time the message was created on the managed node in seconds elapsed since midnight (00:00:00), January 1, 1970, coordinated universal time. Sample output: `950008585`
`<$MSG_TYPE>`	Delivers the name set for message type.

Policy Variables Tab for Open Message Interface, Scheduled Task, and SNMP Interceptor Policies (Events only)

Variable	Description
`<$MSG_APPL>`	Returns the name of the application associated with the input event that caused the message. Sample output: `/usr/bin/su(1) Switch User`
`<$MSG_GEN_NODE>`	Returns the IP address of the node that sends the event. Sample output: `192.168.1.123`.
`<$MSG_GEN_NODE_NAME>`	Returns the host name of the node that sends the event. Sample output: `node123.example.com`.
`<$MSG_GRP>`	Returns the default category of the event. Sample output: `Security`
`<$MSG_ID>`	Returns the unique identity number of the event, as generated by the Operations Agent. Note that identity numbers are not generated for suppressed messages. Sample output: `6e998f80-a06b-71d0-012e-0f887a7c0000`
`<$MSG_NODE>`	Returns the IP address of the node on which the original event took place. Sample output: `192.168.1.123`
`<$MSG_NODE_NAME>`	Returns the name of the node on which the original event took place. This is the hostname that the agent resolves for the node. This variable is not fixed, however, and can be changed by a policy on a per-event basis.
`<$MSG_SERVICE>`	Returns the service name associated with the event.
`<$MSG_OBJECT>` (Open Message Interface and Scheduled Task Only)	Delivers the name of the object associated with the event.
`<$MSG_SEV>`	Returns the default value for the severity of the event. Sample output: `Normal`
`<$MSG_TEXT>`	Returns the full text of the event. Sample output: `SU 03/19 16:13 + ttyp7 bill-root`
`<$MSG_TIME_CREATED>`	Returns the time the message was created on the managed node in seconds elapsed since midnight (00:00:00), January 1, 1970, coordinated universal time. Sample output: `950008585`
`<$MSG_TYPE>`	Delivers the name set for message type.
`<$NAME>` (Scheduled Task Only)	Returns the name of the policy that sent the event. Sample output: `cpu_util`
`<$PROG>` (Scheduled Task Only)	Returns the name of the program executed by the scheduled task policy Sample output: `check_for_upgrade.bat`
`<$USER>` (Scheduled Task Only)	Returns the name of the user under which the scheduled task was executed. Sample output: `administrator`

Policy Variables Tab for All Policy Types (Metrics only)

Variable	Description
`<$MSG_GEN_NODE>`	Returns the IP address of the node that sends the event. Sample output: `192.168.1.123`.
`<$MSG_GEN_NODE_NAME>`	Returns the host name of the node that sends the event. Sample output: `node123.example.com`.

Send Help Center feedback