Integrating the eG Manager with a TT System via a TT Mail Interface

To achieve this, follow the steps below:

  1. Login to the eG administrative interface.

  2. Select the Manager option from the Settings tile.

  3. Figure 1 will then appear. From the MANAGER SETTINGS tree in the left panel of Figure 1, select the ITSM/Collaboration Integration node. The third-party ITSM/Collaboration tools that eG Enterprise can integrate with will be listed in the right panel.

    Figure 1 : Viewing the ITSM/Collaboration tool options

  4. Now, click on the Mail option in the right panel (see Figure 1). A Mail section will now appear in the right panel (see Figure 2).

    Figure 2 : Configuring the TT mail settings

  5. To enable TT integration using a mail interface, slide the Enable mail alerts slider in the Figure 2 to the left.

  6. Next, specify the Subject of the email alerts that the eG manager will send to the TT system. To ensure that the mail subject reflects the problem component name, problem component type, the problem priority, etc., variables can be used in the Subject definition, in the following format: $alarmid#$user#$cname#$ctype#$layer#$prior#$pdesc. The variable $alarmid in the Subject ensures that the subject of the TT mail contains the alarm id. Similarly, the $user, $cname, $ctype variables represent the user with whom the alarm is associated, the name of the problem component, and the problem component type, respectively. Likewise, the $layer, $prior, and $pdesc variables denote the problem layer, the alarm priority, and the alarm description, respectively. The ‘#’ is the separator, but it can be changed. You can rearrange the order of the variables, and even omit a few variables if need be; but, the variable names and the ‘$’ symbol preceding the name should not be changed. A sample subject has been provided below:

    192.168.10.12_14678945321#john#printer:NULL#Host_system#NETWORK#Critical#Network connection down

    This mail subject has been described below:

    • 192.168.10.12_14678945321 is the alarm id that eG’s trouble ticketing engine automatically generates every time a new alarm is processed by it; typically, this will be of the format: <ManagerIP>_<a long value>
    • john is the user with whom the problem component is associated
    • printer:NULL is the hostname of the problem component
    • Host_system is the component type
    • network is the layer name
    • Critical is the alarm priority
    • Network connection down is the alarm description

    Note:

    Note that a mail Subject specification characterized by variables discussed above will work only if the SeparateMails flag in the [ttmail] section of the eg_services.ini file (in the <EG_INSTALL_DIR>\manager\config directory) is switched on. By default, this flag is set to No, indicating that a single TT mail will comprise of details pertaining to all the alarms that were raised by the eG Enterprise during that point in time. In such a case, the variables in the Subject cannot be substituted by the corresponding problem information; in this case therefore, by default, eGTTMail will appear as the subject of the TT mail. However, if every problem event in the environment should generate a separate TT mail, then set the SeparateMails flag to Yes. In such a case, the variables in the Subject will be substituted by the corresponding details from the problem information.

  7. Next, against the Mail ID field, provide a comma-separated list of email IDs to which the email alerts are to be delivered.

  8. Then, specify the Mail output format. This represents the format in which alarm content needs to be emailed. The default format is as follows:

    <eG_Alarm>\n<Priority>$prior</Priority>\n<AlarmId>$alarmid</AlarmId>\n<User>$user</User>\n<ComponentName>$cname</ComponentName>\n<ComponentType>$ctype</ComponentType>\n<Layer>$layer</Layer>\n<Problem>$pdesc</Problem>\n<Service(s)>$Service</Service(s)>\n<DD>$DD</DD>\n</eG_Alarm>

    As stated earlier, a single TT mail can comprise of details pertaining to numerous alarms. Every such alarm definition within a TT mail will typically begin with the tag <eG_Alarm> and end with the tag </eG_Alarm>. This essentially indicates that the details contained within these tags pertain to a single alarm. These tags can be changed if so required. For example, you can specify <Alarm_info> and </Alarm_Info> instead of <eG_Alarm> and </eG_Alarm>. The variables $prior, $alarmid, $user, $cname, $ctype, $layer, $pdesc, $service , and $dd, during run-time, will display the alarm priority, alarm id, the user associated with the problem component, the problem component’s name, the problem component type, the problem layer, the problem description, the service affected by the problem, and the detailed diagnosis of the problem (if any), respectively. In a TT mail, the value of each of the defined variables will be enclosed within the opening and closing tags defined in the Mail output format. For example, take the case of the specification <Priority>$prior</Priority>. In the TT mail for a critical alarm, this specification will appear as <Priority> critical </Priority>. These tags serve as qualifiers for the enclosed values. In other words, they indicate what value is displayed within. These tags can also be modified, if need be. However, the dollared variable names cannot be changed. ‘/n’ acts as a separator for the values. A sample TT mail output has been provided below:

    <eG_Alarm>
    <Priority>Normal</Priority>
    <AlarmId>2</AlarmId>
    <User>john</User>
    <ComponentName>king:7001</ComponentName>
    <ComponentType>WebLogic_server</ComponentType>
    <Layer>WL_SERVICE</Layer>
    <Problem>Many invocations{DD}</Problem>
    </eG_Alarm>

  9. If the problem component is associated with multiple users, then the $user variable, if used in the Mail output format, will display a comma-separated user list. Typically, these users will be the ones responsible for resolving the issues with the corresponding component. However, some users will be authorized by the eG Enterprise system to oversee the performance of all the components in the environment (for eg., the default users of the eG Enterprise system – admin and supermonitor). In most cases, the responsibilities of such users will be more ‘supervisory’ in nature, and not administrative – i.e. might not involve troubleshooting and problem redressal. Therefore, by default, the eG Enterprise system will hide the ID of this user from the user list displayed in the TT mail output. To ensure that the user list displays such a user ID too, slide the Include user details in mail slider to the right. By default, this flag is turned off .
  10. Typically, every new alert generated by the eG Enterprise system will be associated with a unique alarm ID. By default, when every new alarm is processed by eG’s trouble ticketing engine, a different alarm ID is generated by the engine, which will be of the format: <ManagerIP>:<a long value>. Instead of this TT engine-generated alarm ID, if you want the original, manager-generated alarm ID to be associated with the alarm and be part of the TT mail output, slide the Use unique ID slider to the right. By default, this flag is turned off.

  11. If need be, you can make sure that the TT mails indicate the alarm priority using numbers instead of priority names such as critical, major, minor, or normal. For this purpose, you will have to slide the Priority as numeric slider in Figure 2 to the right. By default, this flag is turned off, indicating that the priority of an alarm is indicated using the priority name by default. If this flag is turned on instead, then the default priority name-number mappings defined in the [Ttmail] section of the eg_services.ini file (in the <EG_INSTALL_DIR>\manager\config folder) will automatically apply.

    According to these mappings, if the Priority as numeric flag turned on, then, in every TT mail sent subsequently, critical priority will be represented by number 1, major priority by number 2, and minor priority by number 3. If required, you can even change the numbers that should represent the alarm priorities. For instance, your priority name-number mapping can be as follows:

    Critical=10
    Major=11
    Minor=12

  12. Also, by toggling the Apply priority for all TT mails flag, you can indicate whether the Alarm preference setting (see Figure 2) applies only to each new alarm ID that is raised by the eG manager or to modified alarms as well. As already stated, if an existing alarm has been modified, the eG manager retains the earlier assigned alarm ID for this alarm. The following are considered alarm modifications:

    • A change in the alarm priority: This could be a switch to a higher or lower priority.
    • A change in the alarm description: For example, originally, a usage-related alarm may have been raised on disk ‘D’ of a server. Later, disk ‘C’ of the same server might have experienced a space crunch, causing another alarm to be raised. In this case, the description of the original alarm will change to indicate that both disks C and D are experiencing a problem, but the alarm ID will not change. Changes in alarm description may also happen if additional tests being run for the same layer indicate a problem. A change may involve either an addition to the description (as in the example above) or a removal of one or more descriptors (e.g., the space usage of disk ‘C’ in the example / above returning to a normal condition).
    • A change in the list of impacted services

    If the Apply priority for all TT mails slider is moved to the right, then the eG manager will send an email alert into the TT system even if one of the above modifications occur on an existing alarm, as long as the priority of the modified alarm belongs to the list of priorities configured against Alarm preference in the Settings page (see Figure 1). On the other hand, if the Apply priority for all TT mails slider is moved to the left, then the eG manager will send email alerts only for every new alarm ID. In this case, the manager will ignore all subsequent changes to the priority of the alarm.

  13. Finally, click the Update button.

Note:

You can even configure the specific tests for which TT mails are to be sent using the TestsList parameter in the [ttmail] section. By default, this parameter is set to All, indicating that the eG manager, by default, sends out TT mails for alarms related to all tests. To restrict TT mail transmission to specific tests, provide a comma-separated list of tests against TestsList. While providing test names here, make sure you provide the <internaltestnames> and not the display names. For instance, say, you want TT mails to be sent only when the eG manager raises alarms for the Processes test and the System Details test. To achieve this, your TestsList specification should be as follows:

TestsList=ProcessTest,SystemTest

In the specification above, the internal name for Processes test is ProcessTest, and the same for SystemDetails test is SystemTest. To determine the internal name of a test, do the following:

  • Open the eg_lang*.ini file (from the <EG_INSTALL_DIR>\manager\config directory), where * is the language code that represents the language preference that you have set using the user profile page. In this file, the component types, measure names, test names, layer names, measure descriptions, and a wide range of other display information are expressed in a particular language, and are mapped to their eG equivalents. 
  • Now, search the eg_lang*.ini file for the test name of interest to you. For example, to know the internal name of the SystemDetails test, search the language file for the text, SystemDetails.

  • Since the eG equivalent of the SystemDetails test is SystemTest, you will find a specification to that effect in the [TEST_NAME_MAPPING] section of that file. For our example, the specification would be as follows:

    SystemTest=SystemDetails