TADDM OMP Change event module configuration

To enable sending change events, you must edit the EventConfig.xml file to define event listeners and recipients.

Event listeners

You can define a listener by providing the necessary criteria for a TADDM query. The resulting objects that are selected by the query are checked for changes after each discovery. There can be many listeners. Both a listener and a corresponding recipient block must exist for an event routing to occur.

Use the following format to specify a listener.

  <listener object="[OBJECT_TYPE]"                                     
            enabled="true|false">                                      
            sendCauses="true|false"                                    
            sendOriginGuid="true|false">                               
     <alert recipient="[RECIPIENT_SYSTEM_NAME]"/>                      
     <attribute name="[ATTRIBUTE_NAME]" operator="[OPERATOR]">         
       <value>                                                         
       [ATTRIBUTE_VALUE]                                               
       </value>                                                        
     </attribute>                                                      
     <causeFilter object="[CAUSEFILTER_OBJECT_TYPE]"     			     
                  sendOriginGuid="true|false"/>                        
                                                  					
   </listener>

where:

[OBJECT_TYPE]

is a type of model object that is represented in TADDM, for example, ComputerSystem or ITSystem. For more examples, see the TADDM Data Dictionary at http://taddmserverhost:9430/cdm/datadictionary/model-object/index.html.

enabled

is an attribute that allows for sending the events. The value must be set to true for the listener to be active.

sendCauses

is an optional attribute that defines whether the listener sends events about changes that were propagated to the model object. For example, if a change to a Windows Operating System causes a change to a ComputerSystem object, and the sendCauses attribute is set to true for a ComputerSystem listener, the listener sends an event for the change both to the ComputerSystem and to the Windows Operating System. The default value of the sendCauses attribute is false.

sendOriginGuid

is an optional attribute that is used with the sendCauses attribute. When the sendOriginGuid attribute is set to true, an object that matches the listener is considered the logical origin of changes that are propagated to the object. Events that are sent about propagated changes contain the unique identifier of the origin object. For example, if a change to a ConfigFile object causes a change to a ComputerSystem object, and both sendCauses and sendOriginGuid attributes are set to true for a ComputerSystem listener, the event about the ConfigFile change contains the unique identifier of the ComputerSystem object in addition to the unique identifier of the ConfigFile object. This function is available only for the Netcool/OMNIbus event recipients. The default value of the sendOriginGuid attribute is false.

[RECIPIENT_SYSTEM_NAME]

is an alert recipient. See Event recipients.

[ATTRIBUTE_NAME]

is the name of an attribute on [OBJECT_TYPE], which is queried.

[OPERATOR]

is the operator name of a TADDM MQL query. The following values are allowed.

Table 1. Operator names of a TADDM MQL query.
Operator	TADDM MQL equivalent
contains-with	contains
ends-with	ends-with
equals	equals
greater-or-equal	>=
greater-than	>
less-or-equal	<=
less-than	<
not-equals	not-equals
starts-with	starts-with

[ATTRIBUTE_VALUE]

is the value against which the attribute is evaluated.

<causeFilter>

is an attribute that provides a means to filter the object types of cause events that are passed when the sendCauses attribute is enabled. If you specify this attribute, only cause events of the specified object type are sent. However, propagated events are still sent, for example, the ones that are a part of the object type that is specified in the listener. If the causeFilter attribute is not specified, all cause events that are found by the listener are sent to the receiver.

For example, a change to a WindowsService causes a change to the Windows Operating System and consequently to the ComputerSystem. If you set the causeFilter attribute to WindowsService, only the ComputerSystem and the WindowsService changes are shown, the Windows Operating System change is not shown.

When you set the causeFilter attribute, you can optionally set a value for the sendOriginGuid attribute. By default, the causeFilter attribute inherits the sendOriginGuid setting of the listener that is the parent of the causeFilter attribute. When you use the sendOriginGuid attribute in a causeFilter attribute, only the listener setting for that causeFilter attribute is overridden.

If you want to update objects like WindowsService or ConfigFile, whose changes are propagated to a higher-level object like ComputerSystem, capture such objects by using a combination of the sendCauses and causeFilter attributes, rather than a separate listener.

[CAUSEFILTER_OBJECT_TYPE]

is the class name of the object as defined in the CDM. You can use the full name, for example, com.collation.platform.model.topology.sys.windows.WindowsService, or the short name, for example, WindowsService.

Examples of event listeners

In the following example, a change that is detected in any ComputerSystem whose FQDN contains the "mycompany" string is sent to the recipient "enterprise-eventhost-itm".

    <listener object="ComputerSystem" enabled="true">                  
      <alert recipient="enterprise-eventhost-itm"/>                    
      <attribute name="fqdn" operator="contains-with">                 
        <value>                                                        
         mycompany                                                     
        </value>                                                       
      </attribute>                                                     
    </listener>

In the following example, changes to all objects of a specified type are detected.

      <attribute name="guid" operator="not-equals">                    
        <value>                                                        
         0                                                             
        </value>                                                       
      </attribute>

In the following example, a change that is detected in any object of the ComputerSystem type is sent to the recipient "enterprise-eventhost-omnibus".

    <listener object="ComputerSystem" enabled="true">                  
      <alert recipient="enterprise-eventhost-omnibus"/>                
      <attribute name="guid" operator="not-equals">                    
        <value>                                                        
         0                                                             
        </value>                                                       
      </attribute>                                                     
    </listener>

In the following example, only changes that are caused by a change in a ConfigFile on a Linux Computer System are sent.

    <listener object="ITSystem" enabled="true" sendCauses="true">
      <alert recipient="enterprise-eventhost-itm"/>
      <attribute name="name" operator="ends-with">
      <value>
        ShoppingCart
      </value>
      </attribute>
      <causeFilter object="ConfigFile" />
      <causeFilter object="LinuxUnitaryComputerSystem" />
    </listener>

Event recipients

An event recipient is an instance of IBM Tivoli Monitoring or OMNIBus, which can receive events from the change event module. When changes are located by the change listeners, notification is sent to the corresponding recipients. You can define multiple recipients of a different or the same type simultaneously. Both a listener and a corresponding recipient block must exist for an event routing to occur.

Use the following format to specify a recipient.

   <recipient name="[RECIPIENT_NAME]" type="[RECIPIENT_TYPE]">         
     <address>[RECIPIENT_FQDN]</address>                               
     <port>[EVENT_ROUTING_PORT]</port>                                 
     <config>[PATH_TO_EIF_CONFIGURATION]</config>                 
   </recipient>

where:

[RECIPIENT_NAME]

is the name of the system referred to in the listener.

[RECIPIENT_TYPE]

is the type of software that is used for receiving events. The following types are supported:

itm - IBM Tivoli Monitoring 6 with Universal Agent POST Data provider.
omnibus - Netcool/OMNIbus with EIF adapter.

[RECIPIENT_FQDN]

(IBM Tivoli Monitoring only) is the fully qualified domain name of the host where the Universal Agent is located.

[EVENT_ROUTING_PORT]

(IBM Tivoli Monitoring only) is the port, which the Universal Agent POST Data Provider specified in KUMENV as KUMP_POST_DP_PORT.

[PATH_TO_EIF_CONFIGURATION]

(OMNIBUS only) is the path to the EIF configuration, which is read from the properties file. Use the full path to the file.

Examples of event recipients

The following example defines a Netcool/OMNIbus event recipient.

  <recipient name="enterprise-eventhost-omnibus" type="omnibus">
    <config>/opt/IBM/taddm/dist/etc/omnibus.eif.properties</config>
  </recipient>

The following example defines an IBM Tivoli Monitoring event recipient.

  <recipient name="enterprise-eventhost-itm" type="itm">
    <address>itm-ua.mycompany.com</address>
    <port>7575</port>
  </recipient>