Integrating with Ivanti Service Manager
Ivanti Service Manager, powered by HEAT, is a cloud-optimized ITSM solution, which automates workflows, eliminates manual processes, and improves business security and efficiency. Using the Service Manager, you can perform IT help desk / support ticketing or more advanced ITIL service management processes.
eG Enterprise integrates with Service Manager, so that eG alerts are automatically routed to Ivanti, resulting in the automatic creation/updation of trouble tickets.
To integrate eG Enterprise with the Ivanti Service Manager, do the following:
- Login to the eG administrative interface.
-
Select the Manager option from the Settings tile.
-
Figure 5 will then appear. From the manager settings tree in the left panel of Figure 5, 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.
-
Now, click on the Ivantioption in the right panel (see Figure 5). An Ivanti section will now appear in the right panel (see Figure 6).
Figure 6 : Configuring integration with Ivanti Service Manager
- To enable integration with Ivanti Service Manager, first slide the Ivanti slider in Figure 6 to the right.
-
Then, specify the following in Figure 6:
- WSDL URL: Specify the Web Services Description Language (WSDL) URL via which the eG manager should connect to Service Manager's web services interface.
- User and Password: Specify the credentials of a user with access to Service Manager's web services interface.
- Role: Service Manager uses roles to define responsibilities for the users as they work within the application. A role consists of device- or function-specific application access to various workspaces, business objects, and fields. The eG manager needs to be assigned a role that has permissions to create/update trouble tickets in Service Manager. Assign such a Role to the eG manager.
- TenantID: A Tenant is an Ivanti Service Manager system for a particular customer or application. Since the eG manager will be integrating with a particular customer's or application's Service Manager system, the corresponding tenant ID has to be specified here.
- Customer: Specify the name of the person who is reporting the incident. To enable help desk to quickly figure out that it was the eG manager that reported the incident, you may want to use a special customer name for all eG alerts - eg., eG Monitor.
- Team: Mention the team that will troubleshoot the incident. If there is a dedicated team for attending to all eG alerts, then specify the name of that team here.
- Owner: Specify the login ID of the Service Desk Analyst who is assigned to work on the incident. All trouble tickets auto-generated from eG alerts will be assigned to this analyst only.
- Service: Mention the service that has been affected by the incident.
- Category: Categorizing incidents allows the Service Manager to appropriately assign the incidents to specialists by matching categories with skills. For example, an incident with a category of desktop hardware could be assigned to the desktop hardware group. This means that you can group all eG alerts into a specialized category, so they can be collectively assigned to an expert in troubleshooting eG alerts. If such a special category exists, then specify its name against Category.
-
Source: Specify how the incident was submitted. Typically, this can be configured with values such as email, phone, etc. For eG alerts, the source is set by default, and it is AutoTicket.
-
Incident title: Specify the format in which the title of the trouble ticket is to be displayed in Service Manager. The default format is as follows:
$prior - $ctype / $cname - $pdesc
The ‘dollared’ ($) text in the format above is a key, the value of which varies at run time, depending upon the information contained in the eG alarms. For example, in the default format above, $prior is a key that represents the alarms priority, and changes according to the priority of the actual alarm that is sent by the eG manager to Service Manager. You are advised against changing any of the key names.
The other keys that are part of the default format are discussed in the table below:
$cname
Will display the name of the problem component
$ctype
Will display the component type to which the problem component belongs
$pdesc
Will display a brief problem description
-
Problem description: Against Problem description, specify the format in which the problem description should appear in the trouble ticket that is auto-created for eG alerts, in the Service Manager. The default format is as follows:
Priority: $prior Component Type: $ctype Component: $cname Layer: $layer Problem Time: $starttime Problem Description: $pdesc
The text preceding the ‘:’ (colon) in the format above indicates what information follows. The ‘dollared’ ($) text that follows the ‘:’ (colon) is a key, the value of which varies at run time, depending upon the eG alarms. For example, in the default format above, Priority is a label that indicates that the information that follows the ‘:’ is the priority of the alarm. The key $prior that succeeds the ‘:’ represents the alarm priority, and changes according to the priority of the actual alarm that is sent by the eG manager to the Service Manager. While you can change the labels, you are advised against changing any of the key names.
The other keys that are part of the default format are discussed in the table below:
$cname
Will display the name of the problem component
$ctype
Will display the component type to which the problem component belongs
$layer
Will display the layer affected by the problem
$starttime
Will display the problem start time
$pdesc
Will display a brief problem description
- Finally, click the Update button in Figure 6 to save the changes.
