|
|
|
The tngwriter_rule.dat displays as follows:
# evt id:::dev:::user:::majorSrc:::minorSrc:::action:::template:::cmd:::log:::event_token:::user_parms
where:
The string or sed-style regular expression.
The string, sed-style regular expression, or '*' or empty.
The string, '*', or empty.
The string "uni" from uniconverter, or "tng" from tng converter.
The string or '*'.
The action options. The following options are available:
Write a new request for each event
Updates an existing request or requests (if any exists) or creates a new request if no requests are found. By default, requests are located by matching on the log_agent and affected_resource (asset) fields. The user can override the defaults by specifying a list of any call request attributes.
This is like CR_UPDATE except that a new request is never created when no matching requests are found.
Executes <cmd>, identified in the cmd description in this table.
Specifies the name of a request template to use to create a request. This parameter is not required and is ignored if the action is not CR_CREATE.
Note: The request template must be created before the rule is defined.
The command passed to the shell—ignored on all but COMMAND action.
The logging options, as shown by the following:
No logging (other than error logging).
Log incidents to the UNIX syslog (Unicenter message console).
Log incidents to application log ($NX_ROOT/log).
Log incidents to application log and syslog.
(Optional). This is a 30-character user defined tag that is used to identify a specific request associated with an event_id (tng event message) or all messages like an event_id (for example, a wildcarded event_id).
event_token is a request attribute that is stored in every request generated by the TNG interface. If no event_token is specified in the writer rule, the string "tng_generated" is used. This allows the user to update all requests that match the event_token attribute. For example, two different messages for the same asset can now update unique requests. Each CR_UPDATE writer rule specifies the unique message parts and a unique event_token. The event_token is used to find and update the matching request. By default, an activity log containing the message is added to the matching request.
In another example, the user can update the status attribute (such as, set status=CL (closed)) in an existing request by specifying the same event_token in the CR_UPDATE writer rule that was used when the request was created using a CR_CREATE writer rule.
(Optional) This contains the following three types of information:
The request values and the list of attributes are specified using a %<KEYWORD>=<value> syntax. If you use multiple keywords/value pairs, you must separate each by a semicolon (";").
Request attribute values are specified using the syntax %<ATTRIBUTE>=<value>, where ATTRIBUTE is an attribute name identified in the text_api.cfg (located in $NX_ROOT/site directory), which maps to an AHD majic request attribute.
The syntax for the list of attributes to match is specified as %SEARCH=<attribute1>[,<attribute2>.], where SEARCH is a fixed keyword and attribute1 (and so on), are ATTRIBUTE names specified in the text_api.cfg.
The following special parameter names can be used anywhere in the user_parms string:
The message text associated with this CA NSM message.
The AHD.DLL Parm field on the CA NSM Message Action dialog.
The TNG universally unique identifier.
The device (for example, hostname) that generated the CA NSM message.
The major type of source directing events to the event writer. For events from CA NSM on Windows, the value is “tng”. For events from CA NSM on UNIX, the value is “uni”.
The minor type of source directing events to the event writer.
The device (for example, hostname) that generated the CA NSM message.
The IP address of the host that generated the CA NSM message.
The user name on the host where the CA NSM message was generated.
The integer number representing the time since 1970 when the CA NSM message was generated.
The date and time of the CA NSM message. For example, Tue Jul 4 10:23:37 2000.
The severity of the CA NSM message.
The tag data associated with the CA NSM message.
As an example, using the examples outlined in Sample 2: Alternative “Cawto” formats for Generating and Updating a New Request the default Event Writer Rules file should be changed from:
*:::.*:::*:::uni:::*:::CR_CREATE:::::::::NONE
To the following:
CFNEW.*:::.*:::*:::tng:::*:::CR_UPDATE:::::::::NONE::::::&Parm;%SEARCH_EXPLICIT=STRING1 CFNEW2.*:::.*:::*:::tng:::*:::CR_UPDATE:::::::::NONE::::::&Parm;%SEARCH=Event_Token CFUPDATE.*:::.*:::*:::tng:::*:::CR_UPDATE_ONLY:::::::::NONE::::::&Parm;%SEARCH_EXPLICIT=STRING1 CFUPDATE2.*:::.*:::*:::tng:::*:::CR_UPDATE:::::::::NONE::::::&Parm;%SEARCH=EVENT_TOKEN;%STATUS=CL
Note: The %SEARCH_EXPLICIT parameter is used to ensure that when an update is performed, the search looks for a matching Request by comparing the contents of the STRING1 field before proceeding with the update. For more information about text_api.cfg and how CA SDM uses the Text API to create requests from CA NSM, see the Administration Guide.
| Copyright © 2012 CA. All rights reserved. |
|