Incident Management Integration Service

ZenPacks.zenoss.IncidentManagement

Subscription

This integration is a subscription-based Professional Services engagement. Our Integration Services are offered as subscriptions in order to provide initial setup and ongoing compatibility and maintenance. All standard packages are renewable every 12 months from the date of purchase. Contact Zenoss to request more information regarding this or any other ZenPacks.

About

This ZenPack provides functionality to talk via web APIs to different workflow products (eg Remedy, Service Now). Many customers will be able to utilize this ZenPack simply by customizing the Notification configuration, though some customers may need a new ZenPack that inherits from a ZenPacks.zenoss.IncidentManagement class and is customized further.

Two general types of notification are provided by this ZenPack.

Notification Action

This type of notification provides a one way notification flow. A Zenoss event triggers the action to send a notification to an external system. The event will be updated with information about this action (date/time, name of notification/trigger, success indicator or error message) unless disabled (see notes below on sending multiple occurrences and disabling event updates)

The following event notification actions have been added (integration-specific docs available below):
- Slack: post messages to a Slack channel for new Incidents
- dpaste.com: an example that writes event information to a popular site.
- Debug: creates random incident numbers and links for demonstration purposes.
- HTTP: forward events to an HTTP based API
Incident Integrate

This type of notification provides a bi-directional incident integration. A Zenoss event triggers the integration to create an incident in an external system (the word incident will be used in this documentation to refer to external system's objects such as incidents, tickets, events or similar). The event will be updated with information about the created incident (date/time of notification, incident identifier/url, trigger/notification name) or error message, unless disabled (see notes below on sending multiple occurrences and disabling event updates). The created incident will be tracked and updates to the incident or event can trigger updates to the related object in the other system, including closing or acknowledging the event or incident and updating notes.

The following event notification actions have been added (integration-specific docs available below):
- Service Now: the ServiceNow workflow system.
- Jira: Atlassian Jira Issue and project tracking system
- Remedy ITSM: the BMC Remedy IT Service Management workflow system.
- Remedy Force
- CA Service Desk
- CA Service Manager
- OTRS
- HP Service Manager

An additional button has been added to the Zenoss event console that allows the user to manually trigger the notification based on a selected event (or multiple selected events)

When attempting to create a new incident via trigger (not via the UI), the ZenPack will first try to find an existing incident that is open and associated with an event of the same dedupid as the new event. If found, the ZenPack will associate the new event with the existing incident.

A daemon zenincidentpoll will periodically connect to the remote system to determine the status of incidents and perform actions (ie close an event in Zenoss associated with an incident that is now closed in the remote system).

These new fields are now available to be used in the Event Console:

Incident: the incident identifier from the remote system. This is clickable in the GUI and will take you to the remote system.
Incident URL: the URL used to construct the clickable link.
Notification GUID: an internal identifier to distinguish between multiple notification end-points.
Incident Creation Time: notes the time when the Incident was associated to the event. If an Event is associated to an existing Incident, then this time reflects the association time, not the time the existing Incident is created.
Incident Trigger Name: the name of the trigger that matched the event.
Incident NotificationName: the name of the notification that was triggered for the event.
Incident Management Error: short message if an error occurred while running the notification.
Incident Management Error Detail: detailed message if an error occurred while running the notification.

It is suggested that only the Incident field be added to Event Consoles.

Prerequisites

Prerequisite	Restriction
Product	Zenoss 6.0.0 or higher
Required ZenPacks	ZenPacks.zenoss.PS.QFramework >= 1.4.0
Other dependencies	None

Usage

See the Zenoss Service Dynamics Administration Guide for more information about triggers and notifications. Any issues detected during the run of the notification will result in an event sent to the event console as well as a message in the zennotifyworker.log file.

Zopeurl

The zopeurl setting is used when generating event links in notifications to set the external hostname that will be presented. This is configured in the following config files on these services:

NOTE: The config file that is read for the zopeurl setting varies per the list below. In general, automatic Incident creation from Triggers will use the zennotify.conf file on the zenNotifyWorker Service. For Incidents manually created from the Event Console, the corresponding Zope services will use the zenactiond.conf file.

Automatic Incident Generation

Service	File
zenNotifyWorker	zennotify.conf

Manual Incident Generation

Service	File
Zope	zenactiond.conf
zenapi	zenactiond.conf
zendebug	zenactiond.conf

A template zenactiond.conf file will be added to these services during ZenPack installation, and set to the appropriate host automatically if previously configured.

Configuration

The following common checkboxes are available:

Title	Default	Description
Enabled	True	Should the notification be used if triggered
Send Clear	False	Should we process the clear when a previously processed Event clears.
Send only on Initial Occurrence	True	Should ALWAYS be checked, otherwise may result in duplicate creates. Unchecking this will disable the updating of events with incident info.

The following common checkboxes are available on the Content tab of the Edit Notification window:

Title	Default	Description
Should event details and log be updated with success/fail info and incident number/url?	True	By default, events are updated when they are processed, indicating what trigger/notification processed them and including relevant information based on the success or failure of the notification. By setting this to False, no updates to the events will be made.
Hide this notification from the event	False	If selected, hide this Notification from the Create Incident dropdown in the Event Console.
Acknowledge event on incident creation?	False	After creating an Incident, whether to acknowledge the Event in Zenoss
One incident per event?	True	When true, creating an incident in the event console results in one incident created for each selected event. When false, one incident is created for and associated with all selected events (applies only to manual Incident creation in the Event Console).

The following checkboxes are available on the Content tab of the Edit Notification window for Incident Integrate type notifications only:

Title	Default	Description
Acknowledge event on incident assignment	False	Whether to acknowledge the event in Zenoss when the incident has been assigned
Close event on incident resolution	False	Close the event if the incident is closed/resolved.
Close incident when the event is closed	True	Update the incident to a closed state when the event is closed.
Re-open incident when the event re-occurs	False	Re-open the previously associated incident if a new event comes in that matches the deduplication id of an event that was associated to an incident.
Re-open incident when the event is re-opened	True	Re-open the previously associated incident if the event is manually re-opened in Zenoss.
Assign incident again when the event is acknowledged	True	Update the incident when the event is assigned in Zenoss.
Check to see if the incident is already closed before Assigning incidents to events	True	Polls the incident state before attempting to associate new events.
Add notes added to the event to the incident	True	Update the incident with Notes manually added to the event.

Date Format Processing

There are two fields in the Content tab of all notifications provided by the Incident Management ZenPack that deal with presentation of date/time fields in data sent by the notification.

Title	Default	Description
Date Time Format	`%Y/%m/%d %H:%M:%S.%f`	Format that date/time strings should use when being sent in notification data as strings.
Date Time Format Time Zone	`UTC`	Timezone that date fields should be coerced to when being sent in notification data as strings.

Associating to Existing Incidents

There are several controls that affect how and whether events get associated to existing incidents.

If "Check to see if the Incident is already closed before assigning incidents to events" is not checked, new events that come in with a deduplication signature matching an existing event that has not yet aged out of the system will always be associated to the incident that the matching event was associated to.

If the integration supports adding notes to an incident, this will cause a note to be added to the incident saying "New event for existing incident", along with the event id of the new event. If that box is checked, then this association will only happen if the existing incident is still open.

However, if the "Re-open incident when the event re-occurs" is also checked, then instead of simply associating to the existing incident, that incident will, if the integration supports it, be re-opened, regardless of whether the "Check to see if incident is already closed..." is checked.

If the integration does not support re-opening, then a new incident will be opened, and a warning message will be logged.

Field Mapping

Each integration builds a default dictionary of data used to create the Incidents (as applicable to the individual integrations). The contents of the fieldMapping configuration provides overrides to this data, overriding default fields or adding in new fields. This allows customizing the values sent to the ticketing system without modifying code.

Each entry should be of the form fieldname, value with each entry on a separate line. Example:

Device, ${dev/title}
comments, Created by Zenoss IncidentManagement

In addition to literals you can use TALES expressions for the value; TALES processing for IncMan integrations supports Python expressions and receives the following contexts:

evt The Event
dev The Device associated with the event
component TheComponent associated with the event
dmd Provides access to dmd for advanced options
urls Provides access to several URLs related to the event or device
- eventUrl
- ackUrl
- closeUrl
- deviceUrl
- eventsUrl (all events for the device)
- reopenUrl
- baseUrl
defaultFields Integration specific default fields can be accessed via this context (see individual integration documentation for available fields, if applicable)
mappingUtils Provide access to Integration specific methods used to map or build field values. These are typically used to build the default fields, available in the defaultFields context.
removeField A special flag that can be set to delete a field from the field map sent to the external integration. Typically used to delete a field from the defaults.
jsonstring Passes data through json.dumps() to output a JSON compatible string

The Zenoss Administration Guide contains more information on the attributes available for Device and Event contexts.

`mappingUtils` Methods

These are the default methods available on the mappingUtils context. See individual integrations for any custom methods added.

getDescription(event)

Builds a detailed description of the event details
getSevString(event)

Get the Zenoss Severity String (e.g., 'Clear', 'Error') corresponding to an event.

Examples

Note that there may be many ways to accomplish the same thing, and this is far from a comprehensive list:

Set a static value:

comments, Created by Zenoss IncidentManagement

Set the field 'Device' to the associated Device title:

Device, ${python: (dev.titleOrId())}
- or -
Device, ${dev/titleOrId}

Set the Comments with the Device URL:
```
comments,Device: ${urls/deviceUrl}
```

Enforce a maximum Severity based on device Priority (must be a single line):

severity,${python: '3' if hasattr(dev, 'getPriority') and int(dev.getPriority()) <= 800 and int(defaultFields.get('severity')) > 3 else defaultFields.get('severity')}

Using the mappingUtils method the create a new Description field:
```
NewDescription,${python: mappingUtils.getDescription(evt)}
```
Remove the Description field from the Incident:
```
description,${removeField}
```

Format a JSON data field (especially for use in the HTTP notification):

{
    "eventClass":${python: jsonstring(evt.eventClass)},
    "eventClassKey": ${python: jsonstring(evt.eventClassKey)}
}

Create an Incident Manually

This assumes that notifications have already been created.

Navigate to the event console.
Select an event.
Click on the Create Incident button at the top-right hand side and select the appropriate notification.

NOTE: In order for a manually created Incident to be updated when the event clears or is acknowledged. The notification choosen must have the following settings

Send Clear in the Notification tab is checked
There is an "Enabled" Trigger in that notification (also Notification tab)

Allow the `ZenOperator` Role to Create Incidents Manually

The ZenOperator ZenPack creates a new role to manage events. To enable this new role to also be able to create an incident, follow these actions for every notification to be displayed:

Navigate to the event console.
Click on the Triggers menu.
On the left-hand side, click on the Notifications button.
Double-click on the notification to edit it.
Click on the Subscribers tab of the dialog box.
From the pull-down menu, select the user or group to permit manual incident creation, and then click the Add button.
Add all users and groups that require the permissions.
Click on the Submit button to save the settings.

Now users should be able to refresh the event console to see the create incident actions.

Associate Events with an Existing Incident

Navigate to the event console.
Select an event.
Click on the Create Incident button at the top-right hand side
Right-click the appropriate notification (as opposed to a left-click).
An Assign New Incident Number dialog comes up. Type in the new incident number.
Click on the Okay button.

NOTE: When associating events to an existing Incident, the Incident Creation Time will reflect when the event was associated, not the creation time of the existing Incident.

Notification Suppression

Suppression of incident creation can be enabled to avoid potential floods.

zNotificationSuppressionThresholdNum: The maximum number of notifications to create.
zNotificationSuppressionThresholdSecs: The timeframe within which suppresion will be triggered by reaching the maximum.
zNotificationSuppressionDedupFormat: The format for deduping events (default is device|component|severity).

Setting either zNotificationSuppressionThresholdNum or zNotificationSuppressionThresholdSecs to -1 will disable suppression.

ZenPack Installation / Removal

Install or remove this ZenPack following the instructions in the Zenoss Resource Manager Admin Guide matching your Zenoss RM version.

Upgrading to IncidentManagement 3

IncidentManagement 3 introduces several major changes that may cause issues when upgrading existing integrations. While out of the box features should migrate without needing further configuration, any customizations may require manual intervention to update.

It is recommended to test using a development system if possible, or plan a maintenance window for troubleshooting should the need arise. Recreating the Notifications may be necessary, so details of the existing Notifications should be available, including any authentication credentials that may need to be re-entered.

QFramework ZenPack

IncidentManagement now uses zenNotify provided by the QFramework ZenPack. This is a replacement for zenactiond. This ZenPack must be installed and zenactiond disabled before upgrading.

Customization ZenPacks

If you use a customization ZenPack to extend IncidentManagement features, it may require updates to be compatible with this new version. Contact Zenoss to review before proceeding.

ServiceNow Integration

The ServiceNow integration has been split into three Notification types: Certified, ImportSet, and Legacy (see the ServiceNow specific documentation for more details). Existing notifications will automatically be migrated to one of these new Notifications.

The 'incident_state' field is now mapped within the Certified app configuration. Users who had customized this should verify their configuration.

The ServiceNow application (used for the Certified integration) must be updated to version 2.0.15.

Slack Integration

The TALES processing for the messages has been updated to use the full context available elsewhere in IncidentManagement (e.g., field mappings). Existing use of '${evt/url}' will automatically be migrated to '${urls/eventUrl}'.

Daemons

IncidentManagement actions may take place in these daemons:

zenactiond Runs any automatic actions, such as:
- Creating Incidents from Triggers
- Updating Incidents when an Event clears
Zope Runs most user-initiated actions, such as:
- Manually Creating Events from the Event Console
- Assigning eventsRe-opening Events
zenincidentpoll Periodically checks the Incident status and updates the Event appropriately (if enabled in configuration).

Isolating Incident Management Traffic to a Specific Zope

For debugging purposes, it is sometimes useful to force the traffic to a particular Zope in order to make use of a pdb debugger session, or to more carefully observe the behavior of the system in isolation.

Reduce Zope to a Single Instance

This is covered in the ZPL docs at https://zenpacklib.zenoss.com/en/latest/development-environment-5.html
Attach to the zope service:
```
serviced service attach zope
```
change to user zenoss:
```
su - zenoss
```
Identify the runzope process currently running and get its pid (ps -ef or equivalent)
Kill the currently-running process and start a new zope in the foreground in one line
```
kill SIGTERM <zope-pid>; zopectl fg
```
Note: that last line is important to do all at once, otherwise zope will be restarted in the background*

Configuring zenincidentpoll

By default, zenincidentpoll checks existing Events every 60 seconds. This can be modified similar to other services via Control Center:

open the zenincidentpoll service in Control Center
select 'Edit' for zenincidentpoll.conf
update the 'cycletime' property
restart the service once saved

Type	Name
Notification	zenNotify / zenNotifyWorker
GUI	Zope / zenapi / zendebug
Event integration	zenincidentpoll

Integrations

ServiceNow

This integration offers three types of integration that interact differently with the ServiceNow API.

Service Now Certified This is the preferred integration for most uses. This works with a certified ServiceNow app installed on the ServiceNow instance. This integration type utilizes an ImportSet table for all writes which allows business rules and workflows to operate on both the creation and update of incidents. Since all updates are written to an import set, all inserts and updates are logged and available for debugging. This uses the REST API for connecting to ServiceNow.
Service Now Import Set A generic ImportSet integration for user-customized ImportSet tables and rules. Like the Certified integration all writes are to an ImportSet Table, but can be fully customized by the ServiceNow Administrator. This uses the REST API for connecting to ServiceNow.
Service Now Legacy This integration writes directly to an Incident table in ServiceNow. Records are created and updated in-place, minimizing the audit trail and debugging more available from the ImportSet methods. This integration type is provided for backward compatibility, but is not recommended for most users. JSON and REST API support are included, but REST is recommended.

Zenoss Configuration

The following documentation assumes the use of the ServiceNow Certified Notification type. More information is available in this video tutorial. While from an older version, most of this information is still relevant. Please note that the notification type has changed to Service Now Certified and automatically uses the REST API.

Create a ServiceNow Notification

This assumes that the appropriate triggers have already been set up.

Navigate to the Events > Triggers page.
Click on the Notifications menu item.
Click on the plus sign (’+’) to add a new notification.
From the dialog box, specify the name of the notification and select the appropriate ServiceNow action (e.g.,ServiceNow Certified).
Enable the notification and add a trigger to be associated with this action.
Click on the Contents tab.
Fill in the appropriate settings. Mandatory settings are: – URL (eg. https://demo08.service-now.com) – Username – Password
Click on the Submit button.

Configuration

The following configuration items are added by the ServiceNow integration:

Title	Default	Description
URL	`https://account.service-now.com`	URL for your ServiceNow instance
OAuth Client Id		Client ID to enable OAuth authentication (Import Set and Certified integrations only).
OAuth Client Secret		Client Secret to enable OAuth authentication (Import Set and Certified integrations only).
Company		The value for the Company field on the incident
Company Group		If populated, the system will look at the group membership for the device associated with the event, and if the listed group is found, it will use the group just below the listed group to populate the Company field.
Close Notes	Closed By Zenoss	Text to populate the close notes when resolving an incident
Incident State Field	incident_state	The field to use for checking incident state
Incident Closed Value	6	The value to set the state to on the incident when an event is closed in the UI
Incident Cleared Value	7	The value to set the state to on the incident when an event is cleared automatically
Incident Closed Values	6, 7	The values for incident state that represent an incident that is considered closed when polled by zenincidentpoll or associating a new event to an existing open incident.
Incident Final States (can not be reopened)	7	The values for incident state that represent an incident that can not be re-opened.
Table	incident	The table to use when checking the status of an incident

Default Fields

For the certified integration, the following fields are included in the import set.

Import set	Incident	Information
priority	priority	See mapping below
short_description	short_description	See below
description	description	See below
incident_state	incident_state	1 for new incidents, user defined when closing/resolving
company	company	Configured as part of notification
evid		Zenoss event id (GUID)
eventstate		Zenoss event state (typically will be ’1’ on insert)
eventclass		Zenoss event class
eventgroup		Zenoss event group
eventkey		Zenoss event key
eventclasskey		Zenoss event class key
agent		Zenoss agent (generally, daemon that generated the event)
facility		Zenoss facility (generally only populated for syslog events)
monitor		Zenoss monitor field (collector)
count		Zenoss event count
created		String of the event creation time
firsttime		Unix timestamp when event was first seen
lasttime		Unix timestamp when event was last seen
statechange		Unix timestamp when event last changed state
severity		Zenoss event severity (numeric)
severitystring		Zenoss event severity (string - "CRITICAL", etc.)
message		Full Zenoss event message text
summary		Short Zenoss event summary text
clearid		ID of event that cleared this one (generally blank)
dedupid		Deduplication fingerprint of this event
flappinginterval		Used in Zenoss by the event flapping detection algorithm
flappingseverity		Used in Zenoss by the event flapping detection algorithm
flappingthreshold		Used in Zenoss by the event flapping detection algorithm
ntevid		Windows event id (if applicable)
ownerid		User who acknowledged event (Before this action), if any
eventurl		URL for Zenoss event
device		Zenoss device for the event
component		Zenoss component of the device, if any
ipaddress		IP address of Zenoss device
prodstate		Zenoss device production state for the event
deviceclass		Zenoss device class
devicegroups		List of groups for the Zenoss device
devicepriority		Priority value for Zenoss device
location	location	Name of location for device in event, if any
systems		Zenoss systems this device belongs to
deviceurl		URL for Zenoss device
custom_1		Custom field for user-defined mappings
custom_2		Custom field for user-defined mappings
custom_3		Custom field for user-defined mappings
custom_4		Custom field for user-defined mappings
custom_5		Custom field for user-defined mappings
custom_6		Custom field for user-defined mappings
custom_7		Custom field for user-defined mappings
custom_8		Custom field for user-defined mappings
custom_9		Custom field for user-defined mappings
custom_10		Custom field for user-defined mappings
incident_state	state	Field to use when updating the state of the incident

Priority Mapping

Event Severity	Incident Priority
0 - Clear	5
1 - Debug	4
2 - Info	4
3 - Warn	3
4 - Error	2
5 - Critical	1

This can be overridden with a python-based field mapping. For example, to map only criticals to P1, and everything else to P3:

priority,${python:dict([('5','1'),('4','3'),('3','3'),('2','3'),('1','3')]).get(str(evt.severity))}

Short Description

The short description looks like:

[location severity Zenoss] device: eventsummary

For example:

[Chicago Critical Zenoss] server.example.com: Device is down!

This can also be overridden with a field mapping. For example, to remove the location:

short_description,[${evt/severity}] ${evt/device}: ${evt/summary}

Description

The description looks like:

    Timestamp: created
    Device: device
    IP address: ipaddress
    Component: component
    Severity: severitystring (severity)
    Event class: eventclass
    Device class: deviceclass
    Device/Element priority: deviceprioritystring (devicepriority)
    Summary: summary
    Message:
    message

    Groups:
    devicegroups

    Event details: eventurl
    Device details: deviceurl

This can also be overridden by a field mapping. For example, to only show the event message:

description,${evt/message}

Custom Fields

In Zenoss, the custom fields (custom_1 through custom_10) are configured in the fieldMapping as previously described. In ServiceNow, an administrator will need to use the Zenoss Incident Management Properties page to map those custom fields to fields in the incident table.

Open the Incident Management Properties page for editing
Find the custom field you are editing and enter the field name this will be mapped to
Save the Properties page.

ServiceNow Configuration

User Roles

If using the Certified Integration, the Zenoss IncidentManagement App installs a user role which you can assign to the service user, x_zeno2_incman.ServiceUserRole.

For both the Certified Integration and the ImportSet integration, the user will also need the import_transformer role (already included in the x_zeno2_incman.ServiceUserRole).

OAuth Authentication

OAuth can be enabled by setting the OAuth Client ID and OAuth Client Secret fields for Import Set and Certified integrations. If either field is blank, OAuth is disbaled.

Installing the Certified App

To use the integration path that has been certified by ServiceNow as conforming to their best practices (recommended for all customers), the ServiceNow administrator will need to install the Zenoss IncidentManagement Integration app from the ServiceNow store. Simply search for the app in the store, and click the ’Contact Seller’ or ’Request App’ button. This will send the request to Zenoss, who must approve the request before it can be downloaded. Once you have received that approval, install the app as you would any ServiceNow app. There are documents in the app store that give more details about exactly what is provided by the certified app.

Tips

In the ServiceNow UI, right-click on an item to find out the underlying field name. The name will be at the bottom of the menu.
In the ServiceNow UI, when looking at a record (for example, an incident record), click the hamburger menu, and choose ’Show XML’ - this will show you the actual field names of all of the fields.
In the ServiceNow UI, the magnifying glass next to a field indicates that it refers to something else. You will need to find out which field is used as the base for this field.

Controlling Incident Re-use

Some clients may want to limit the total number of incidents by re-using an existing incident within a certain time frame. For example by default once a Zenoss event closes we will set the Incident closed as well if the ’Close incident when the event is closed’ checkbox is selected.

However it is possible to configure an incident to be re-used by having the SN admin add a few options, and re-configuring the Incident Closed Value and Incident Cleared Value. Here’s an example scenario.

Create a new state in ServiceNow called Pending Closed with an integer value of 10 for example.
Update the settings for Incident Closed Value and Incident Cleared Value to both use this new state of 10.
Add business logic on your ServiceNow endpoint to move Pending Closed state incidents to Resolved after 120 minutes of inactivity.
ServiceNow must also have the workflow of a ticket moving from this new Pending Closed back to the New (or whatever their original incident state is).

Troubleshooting

A ServiceNow administrator can check the System Import Set Log and System Import Set Rows to see the results of attempts to create and update incidents. The Import Set Rows, in particular, will show all fields sent by Zenoss, so you can see if your field mappings are sending what you expect.
401 Unauthorized - These errors are often the result of invalid login credentials or missing roles from the login user.
No incident number generated errors - This usually indicates an issue on the ServiceNow side, where the request for generating the Incident is accepted but further logic or permissions block the creation or response. Investigate the ServiceNow logs for details on what failed. More details are available on the ServiceNow wiki

CAServiceDesk

Create a CAServiceDesk Notification

This assumes that the appropriate triggers have already been set up.

Navigate to the Events -> Triggers page.
Click on the Notifications menu item.
Click on the plus sign (’+’) to add a new notification.
From the dialog box, specify the name of the notification and select the CAServiceDesk action.
Enable the notification and add a trigger to be associated with this action.
Click on the Contents tab.
Fill in the appropriate settings. Mandatory settings are:
- URL - (for example, https://account.servicedesk.ca.com)
- Customer
- Group
- Category
- Username
- Password
Fill in optional fields:
- Description Override - The text given here will override the default description
- Field Mappings - Each line in this text box represents a field/value pair separated by a comma. Possible values include:
  - description_additional - Adds the value as a line after the description
  - summary_additional - Adds the value to the end of the summary
  - priority_override - Override the priority of all tickets generated by this notification
  - any additional field supported by CAServiceDesk
Click on the Submit button.

Troubleshooting

Log into the ServiceDesk web service using the account that Zenoss will use and enter a ticket. Do not proceed until this works, and note the required fields to enter a ticket.

CAServiceManager

Create a CAServiceManager Notification

This assumes that the appropriate triggers have already been set up.

Navigate to Events -> Triggers page.
Click on the Notifications menu item.
Click on the plus sign (’+’) to add a new notification.
From the dialog box, specify the name of the notification and select the CAServiceManager action.
Enable the notification and add a trigger to be associated with this action.
Click on the Contents tab.
Fill in the appropriate settings (see below).
Click on the Submit button.

Settings

CA Service Manager Connection Settings

Title	Description
Required Settings
WebService URL	example, `https://sm1s.saas.ca.com`
Username
Password
Optional Proxy and Connection Settings
Proxy Url	Connect to CA Service Manager via a Proxy
Proxy Username
Proxy Password
Retries	Connection Retry Attempts
Timeout	Connection Timeout (in Seconds)

Incident Settings

Title	Default	Description
Ticket Description		(TALES Expression)
Description Long		(TALES Expression)
Person 1 Alt Email		Defines the value of the "person1_alt_email" field when creating new Incidents.
Assigned Group Name
Resolve Action ID		Service Manager Action to invoke when an event reaches a Cleared status in Zenoss. This is an automatic state, not an event manually closed by a User within Zenoss.
Close Action ID		Service Manager Action to invoke when an event is manually Closed by a user.
Re-open Action ID		Service Manager Action to invoke to re-open a previous Incident when an event recurs.
ServiceManager Incident Prefix	"300-"	The prefix automatically prepended to Service Manager Incident IDs.
Incident URL		Used to generate the URL for the Event Console link to an incident. This string is ran through a Python String.format(), with the sole argument being the Incident number (such as 275237, without the Incident Prefix). Thus, this string should have a single '{}' which is replaced with the Incident Number.
Event Severity Mapping		Maps the Zenoss Severity value to Service Manager Urgency.
* sev_5	High
* sev_4	Medium
* sev_3	Low
* sev_2	Low
* sev_1	Low
One incident per event?	True	When true, creating an incident in the event console results in one incident created for each event. When false, one incident is created for and associated with all selected events.
Acknowledge event on incident creation?	False	After creating an incident, acknowledge the event in Zenoss?
Close incident when the event is closed?	True	Update an existing incident (via Close / Re-open Actions above) when an Event is closed in Zenoss?
Re-open incident when the event is re-opened?	True	Re-open an incident (via the Re-open Action above) an event is re-opened in Zenoss.
Assign incident again when the event is acknowledged?	True
Check to see if the incident is already closed before assigning incidents to events?	True
Add notes added to the event to the incident?	True	Add Notes on the Zenoss Event as Worklog Entires on the Incident.

Troubleshooting

Log into the Service Manager web service using the account that Zenoss will use and enter a ticket. Do not proceed until this works, and note the required fields to enter a ticket.

OTRS

Create an OTRS Notification

This assumes that the appropriate triggers have already been set up.

Navigate to Events -> Triggers page.
Click on the Notifications menu item.
Click on the plus sign (’+’) to add a new notification.
From the dialog box, specify the name of the notification and select the OTRS action.
Enable the notification and add a trigger to be associated with this action.
Click Send Clear to enable a Zenoss clearing event to close an incident
Click on the Contents tab.
Fill in the appropriate settings. Mandatory settings are:
- OTRS Server URL (for example, http://otrs.company.com/otrs)
- Username
- Password
- Ticket Type
- Queue
- Customer User
Ensure that the Event Severity (1 through 5) match the OTRS serverities configured
Adjust the fieldMapping:
- e.g. to specify a Service, put Service,your_service_name in the fieldMapping
Click on the Submit button.

Dpaste

Demo integration which ’pastes’ an incident on dpaste.com. This creates a new paste with the description of the Incident, which is viewable by clicking on the Incident link in the Event Console. Only create is supported, other actions will be ignored.

HTTP

The HTTP Notification allows for maximum flexibility when needing to forward events to an HTTP based API.

HTTP Settings

URL - The HTTP request url
Method - The HTTP request method
Username - Basic Authentication will be used when the Username field is defined.
Password - If basic authentication is used, the value in the Password field will be used.
Headers - Define one or more HTTP Headers. It expects each line to contain exactly one header. The line should be composed of a header name and header value separated by a colon ":" and then a single space.
Data - Value placed in the HTTP request body.
Success Text - Value set on the event’s incident number field upon success. No value will be set if sending all event occurrences or if event updating is disabled.

Unsupported

Event/Incident assignment functionality
Event/Incident closing functionality

JIRA

This directory contains the framework for Jira integration.

Configuration

Every implementation of Jira tends to be quite different from other implementations, and thus some customization will be required for all Jira integrations.

Authentication

Some version of Jira have deprecated the use of username/password for API Basic Auth. In this case, the password is replaced by an API Token, generated from https://id.atlassian.com/manage/api-tokens

Fields

There are typically 4 fields common amongst all Jira projects:

project
issuetype
summary
description

Unfortunately they are not required to be present, and will cause failure in createIncident if they are not present.

Other fields may be required for creation of an Issue, and this can generally only be determined by querying the running Jira system. In this directory, you’ll find a stand-alone python script called "parse_createmeta.py" which will parse the output of such a query and show the required and available fields for all issueTypes in all Jira projects.

The query should be run as an authenticated Jira user that has access to create issues in all projects that Rm will be required to create issues in. It is simplest to do this via a web browser as per the instructions below:

Log on to your Jira instance as a user who has privileges to create new issues for the projects in which we will be creating issues.
Assuming your Jira URL looks like https://company.jira.com/jira/... in the address bar of your browser, replace everything after /jira/ with the following:
```
/rest/api/2/issue/createmeta?expand=projects.issuetypes.fields
```

An example of the final url would be:

https://company.jira.com/jira/rest/api/2/issue/createmeta?expand=projects.issuetypes.fields`

This will be a large textual output in your browser window that you can just cut an paste verbatim into this support ticket.

Save the resulting json output in a file, and then run the "parse_createmeta.py" script against it

./parse_createmeta.py createmeta.json

You can also restrict the output of the script using command-line arguments. See parse_createmeta.py -h for more details.

The "fieldmappings" field can be used to fill in other required or custom fields. The following is an example of a fieldmapping entry and the corresponding field descriptions from the above script which can help to guide configuration. When Jira expects an object (array or structure) rather than a string, you’ll need to prepend the value with the keyword object:.

Example fieldmapping field

customfield_10836, object:${python: repr([dev.getLocationName().strip('/')])}
customfield_11301, object:[{'value': 'Internal System'}]
customfield_10811, object:{'value': 'Alarm'}
customfield_12904, Zenoss

Example parse_createmeta.py output

./parse_createmeta.py --project TestIssue --issuetype Incident ~/createmeta.example
Project: TestIssue
Issue: Incident
            id: customfield_12904 name:Alarm Source type: string required: False
            id: customfield_10811 name:Method of Notification type: string required: True
            id: description name:Description type: string required: True
            id: customfield_10836 name:Data Center type: array of string required: False
            id: summary name:Summary type: string required: True
            id: project name:Project type: project required: True
            id: customfield_11301 name:Affected Service(s). type: array of string required: True

In the above example, here is an explanation of the field types:

the field customfield_10811 expects a string, but in this example an json representation of an object whose value is a string is set as the field value. This representation is often used to represent a string value from a pre-determined set of strings.
the field customfield_12904 expects a value of type string, so a bare string "Zenoss" is set as the field value
the field customfield_11301 expects an array of strings, and thus a json representation of a list containing a single object whose value is a string is set as the field value. This representation is often used to represent a set of string vlaues from a pre-determined list.
the field customfield_10836 also expects an array of strings, but in this case we are using a python tales expression to generate the value of the field.

Remedy ITSM

Create a Remedy ITSM Notification

This assumes that the appropriate triggers have already been set up.

Navigate to Events -> Triggers page.
Click on the Notifications menu item.
Click on the plus sign (’+’) to add a new notification.
From the dialog box, specify the name of the notification and select the Remedy action.
Enable the notification and add a trigger to be associated with this action.
Click on the Contents tab.
Fill in the appropriate settings. Mandatory settings are
- Remedy Server URL (for example, https://remedyitsm.example.com)
- Username
- Password
Click on the Submit button.

Troubleshooting

Log into the Remedy web service using the account that Zenoss will use and enter a ticket. Do not proceed until this works, and note the required fields to enter a ticket.

Remedy ARS

Create a Remedy ARS Incident

This assumes that the appropriate triggers have already been set up.

Navigate to Events -> Triggers page.
Click on the Notifications menu item.
Click on the plus sign (’+’) to add a new notification.
From the dialog box, specify the name of the notification and select the Remedy ARS action.
Enable the notification and add a trigger to be associated with this action.
Click on the Contents tab.
Fill in the appropriate settings. See table below for explanations of the parameters.
Click on the Submit button.

Configuration

The following configuration items are added by the Remedy ARS integration:

Title	Default	Description
Remedy Server URL	`https://host.example.com`	URL for the Remedy ARS web service endpoints
Remedy Server Name	`arsServer`	Name of the remedy server
Remedy UI Server URL	`https://smartit.example.com`	URL for the Remedy ARS UI
Username		Username for the Remedy ARS web service
Password		Password for the Remedy ARS web service
Proxy URL		Proxy credentials (if needed)
Proxy username		Proxy credentials (if needed)
Proxy password		Proxy credentials (if needed)
Company		Company to use for Remedy ARS Incident ticket (optional)
Assigned Support Organization		Organization to use for Remedy ARS Incident ticket (optional)
Assigned Group		Group to use for Remedy ARS Incident ticket (optional)
Ticket reporter	`First Name`
Ticket reporter	`Last Name`
Opened status	`New`	Status to use when opening or re-opening incidents
Incident resolution status	`Resolved`	Status to use when resolving tickets
Closed statuses	`Closed`	If an incident has one of these status values, the system will consider it closed
Impact Field Mapping	5: 1-Extensive/Widespread	Mapping of event severity to ticket
	4: 2-Significant/Large
	3: 3-Moderate/Limited
	2: 4-Minor/Localized
	1: 4-Minor/Localized
Urgency Field Mapping Mapping	5: 1-Critical	Mapping of event severity to ticket urgency
	4: 2-High
	3: 3-Medium4-Low
	2: 4-Low
	1: 4-Low
	0: 4-Low
Status Reason	Monitoring Incident	Status Reason for Closing Incidents
Resolution Text	`Automatically cleared by monitoring system`	Resolution Text for Closing Incidents
Annotation Summary Limit	`128`	Field length for work notes short description

Default Fields

The following fields are populated in the incident by default. The field mappings can be used to modify this list.

Incident	Information
Assigned Group	From notification configuration
Assigned Support Company	From notification configuration
Assigned Support Organization	From notification configuration
First_Name	From notification configuration
Last_Name	From notification configuration
Impact	See mapping below
Reported Source	’Systems Management’
Service_Type	’Infrastructure Event’
z2TF_Summary	Event summary
Short Description	Event Summary
Status	From notification configuration
Description	See note below
z2TF_Notes	See note below
Urgency	See mapping below

Description

The default description is just the device in the event, a ’:’, and the event message. The equivalent TALES expression is:

Description,${evt/device}: ${evt/message}

z2TF_Notes

This field is constructed from the device, the event class, and Zenoss event severity. The equivalent TALES expression is:

z2TF_Notes,Zenoss-Monitored Resource: ${evt/device}\nEvent Class: ${evt/eventClass}\nSeverity: ${python: mappingUtils.getSevString}

Impact Mapping

Event Severity	Incident Priority
1 - Debug	4-Minor/Localized
2 - Info	4-Minor/Localized
3 - Warn	3-Moderate/Limited
4 - Error	2-Significant/Large
5 - Critical	1-Extensive/Widespread

This can be overridden with a python-based field mapping. For example, to map only criticals to the highest impact, and everything else to moderate impact:

priority,${python:dict([('5','1-Extensive/Widespread'),('4','3-Moderate/Limited'),('3','3-Moderate/Limited'),('2','3-Moderate/Limited'),('1','3-Moderate/Limited')]).get(str(evt.severity))}

Urgency Mapping

Event Severity	Incident Priority
1 - Debug	3-Medium
2 - Info	3-Medium
3 - Warn	3-Medium
4 - Error	2-High
5 - Critical	1-Critical

This can be overridden with a python-based field mapping. For example, to map only criticals to ciritcal urgency, and everything else to medium urgency:

priority,${python:dict([('5','1-Critical'),('4','3-Medium'),('3','3-Medium'),('2','3-Medium'),('1','3-Medium')]).get(str(evt.severity))}

Slack

Settings

Title	Description
Organization	The Organization name of the Slack account, from the URL https://.slack.com
API Token	The Slack API Token
Channel	The Slack Channel (e.g., #zenoss) to post messages.
Message	A TALES enabled message to post for new events.
Clear Message	A TALES enabled message to post when an event clears.

EasyVista

Create an EasyVista Notification

This assumes that the appropriate triggers have already been set up.

Navigate to Events -> Triggers page.
Click on the Notifications menu item.
Click on the plus sign (’+’) to add a new notification.
From the dialog box, specify the name of the notification and select the EasyVista action.
Enable the notification and add a trigger to be associated with this action.
Click Send Clear to enable a Zenoss clearing event to close an incident
Click on the Contents tab.
Fill in the appropriate settings. Mandatory settings are
- EasyVista Server Hostname (e.g., server.easyvista.com)
- EasyVista Account (e.g., mycompany)
- Username
- Password
Adjust the fieldMapping:
Click on the Submit button.

RemedyForce REST API via SalesForce

This integration allows use RemedyForce integration that interacts using SalesForce REST API. As result BMC ServiceDesk Incident will be created

Configuration

The following configuration items are added by the RemedyForce(SalesForce) integration:

Title	Default	Description
URL	`https://MyDomainName.my.salesforce.com`	URL for your SalesForce instance
OAuth Client Id		Client ID to enable OAuth authentication
OAuth Client Secret		Client Secret to enable OAuth authentication
Template name	Zenoss Incident Ticket	Template name for your incidents, should be created and configured on RemedyForce(SalesForce) instance. Use of this option is preferred
Category name	Category name for your incidents if not provided by template.
OPENED	Opened name	The name of state to create/reopen incident
CLOSED	Closed name	The name of state to close incident
Impact Field Mapping		Severity to Impact mapping if not provided by template
Urgency Field Mapping		Severity to Urgency mapping if not provided by template

Notes

Depending on configuration, values provided by template may not be overridden by notification-configured fields/fieldmappings on incident creation. It is highly recommended that a template be configured in RemedyForce(SalesForce) to assign default staff and client which will IncidentManagement to autoclose incidents on close events

Priority Mapping

Event Severity
0 - Clear
1 - Debug
2 - Info
3 - Warn
4 - Error
5 - Critical

The above is the list of zenoss event severities. To provide a mapping for impact/urgency you could use, for example:

5, Low: No current observable negative impact to customers

Mapping entries are comma-separated key-value pairs. Zenoss severity is the key and the full text of the desired impact/urgency is the value. Provide as many lines as you need to cover severities. Events of severities that are not mapped will have no impact/urgency sent on incident creation.

Troubleshooting

In case of multiple ticket creations, you can increase the default timeout setting to give SalesForce more time to process each request. 10 seconds should be enough to make the request and not make a queue of unprocessed events.

Also you could reduce retry parameter to 0 to ensure only a single attempt is made. This will result in missed incidents when timeouts occur.

Autotask

This integration allows use Autotask API v1.0. As result Autotask Tickets will be created

Configuration

The following configuration items are added by the Autotask integration. Arguments not set will be sent as empty strings on ticket creation.

Title	Default	Description
URL	`https://ww2.autotask.net`	URL for your Autotask zone
Secret		API User secret(password)
ApiIntegrationCode	API User ApiIntegrationCode
Customer (ID or Name)	Zenoss Incident Ticket	Customer for whom ticket created. Accepted full name or ID. Optional
Queue ID	8	Queue ID for whom ticket assigned. Could be optional, depending on Autotask settings
Issue type ID	28	Ticket Issue type ID. Optional, could be omitted
Sub Issue ID		Ticket Sub Issue ID. Optional, could be omitted
Source ID	11	Ticket Source ID. Optional, could be omitted
Ticket type ID	5	Ticket type ID. Optional, could be omitted
Allocation ID		The billingCodeID field must reference a Work Type allocation code. Could be optional, depending on Autotask settings
Opened statuses	1,22	Opened statuses, coma-separated IDs if several values. If present, first ID will be used for created incident, last one - for reopened.
Closed statuses	5	Closed statuses, coma-separated IDs if several values. If present, first ID will be used for closed incident.
Priority Field Mapping		Severity to Priority mapping to override default (check section below)
DueDate Delta time		Severity to DueDate Delta time mapping to override default (check section below)
Mapping	override default (check section below)
Custom Message Limit	7800	Message characters limit if custom message used
Custom Title Limit	250	Title characters limit if custom title used

Priority Mapping

Event Severity	Incident Priority
0 - Clear	3
1 - Debug	3
2 - Info	3
3 - Warn	2
4 - Error	1
5 - Critical	4

This can be overridden with mapping entries, which are comma-separated, key-value pairs. Zenoss severity is the key and the ID of the desired priority is the value. Provide as many lines as you need to cover severities. Events of severities that are not mapped will have priority from fallback mapping (see above).

Example mapping:

5, 5
4, 4
3, 3

Meaning severity 5 correspond to priority 5, 4 to 4, 3 to 3. Non-listed in example above severities 2, 1 and 0 will take priorities 3, according to fallback mapping

DueDate Delta time Mapping

Event Severity	Delta time
0 - Clear	4w
1 - Debug	4w
2 - Info	4w
3 - Warn	1w 3d
4 - Error	5d
5 - Critical	12h

This is DueDate Delta time Mapping used for DueDateTime incident field. On incident creation Delta time will be added to event creation time. Mapping entries are comma-separated key-value pairs. Zenoss severity is the key and the TimeDelta string of the desired TimeDelta is the value. Provide as many lines as you need to cover severities. Events of severities that are not mapped will have TimeDelta from default mapping.

Supported TimeDelta values:

12W or 12w - weeks count
34D or 34d - days count
2H or 2h - hours count
135m or 135M - minutes count

Could be used ONLY in order w -> d -> h -> m, spaces between values could be omitted, any value could be omitted, but at least one should be present

Example

4, 1w 3d 15m
5, 5h3m
3, 1w 15m

Mapping Utils Integration provides additional mapping utils getCustomDescription and getCustomTitle which could be used in fieldmapping. Characters limits controlled by Custom Message Limit and Custom Title Limit.

getCustomTitle restructure event summary to display "KB" groups at beginning. Example usage form (valid for both methods):

description,${mappingUtils/getCustomDescription}
title,${python: mappingUtils.getCustomTitle()}

Change Log

3.8.2

Fixes
- SVC-3868 Fix embedded special charaters in the FieldMapping that are encode to decode, e.g. new lines.

3.8.1

Features:
- SVC-3635 Update for HTML & TAL syntax
- SVC-3813 fix for updated redis client

3.7.1

Bug Fixes
- SVC-3652 Fix traceback when copying details from old events to new

3.7.0

Features
- SVC-1603 Add ability to test IncMan field mappings in the UI
- SVC-3525 Implement new authentication for Remedy
Bug Fixes
- SVC-3505 When reassociating, copy all detail fields from old event
- SVC-3512 IncMan updatedExistingEvents possible nameError
- SVC-3611 IncMan embeds full list of possible timezones in each notification info, causing data to be very large

3.6.1

Bug Fixes
- SVC-3341: Autotask getIncidentStatus fix, priority fieldMapping fix
- SVC-3111: ServiceNow safe statuses extraction, validation
- SVC-3398: RemedyForce REST API via SalesForce getIncidentStatus fix

3.6.0

Features
- SVC-3398: RemedyForce REST API via SalesForce integration
Bug Fixes
- SVC-3341: Autotask zone regex

3.5.0

Features
- SVC-3431: Autotask integration
- SVC-3420: postCreateIncidentHook and postGetIncidentStatusHook implementation
- SVC-3463: mappingUtils methods using partials and standard arguments as default
Bug Fixes
- SVC-2820: docs update: Each event can only be managed by a single notification
- SVC-2730: docs update: notification MUST be subscribed to trigger

3.4.0

Features
- SVC-3385: Make TALES processing errors WARNINGS rather than ERRORS in logs, and add details
- SVC-3403: Send events when logging non-fatal errors processing events
Bug Fixes
- SVC-3426: zep.json fields trigger and notification use incorrect type
- SVC-3427: Aged events should be considered when closing events and need to reopen aged events before closing
- SVC-3393: List PS.Util as a prerequisite

3.3.2 Hotfix

Bug Fixes
- SVC-3423: Use event.evid in log message, not event.id

3.3.1 Hotfix

Bug Fixes
- SVC-3383: Ensure zenincidentpoll checks the status of all incidents
- SVC-3381: ensure trigger info is available for clears as well
- SVC-3382: do not refresh clear from zep if not updating events with notificastion info
- SVC-3382: remove extra zep refresh when not updating events

3.3.0

Bug Fixes
- SVC-2643: batch requests for zenincidentpoll for ServiceNow
- SVC-2643: Chunk requests in case we have too many incidents
- SVC-2837: add default values for Headers and Data fields in HTTP Notification, which includes setting user-agent
- SVC-3032: Changed closeCode field to configurable instead of hard code value
- SVC-3032: Added 'timeout' field to request, implemented handlers for different errors
- SVC-3032: made 'timeout' field provided by default visible
- SVC-3032: HTTP Notification Timeout made configurable
- SVC-3034: Remove cz0 prepend within fieldmapping context for smarViewUrl
- SVC-3320: check impactEvents exist before processing
- SVC-3319: dont update event if send_initial_occurence is false
- SVC-3323: update main documentation
- SVC-3323: formatting fixes to SNow docs
- SVC-2661: Change impact related event info from score to confidence rating to match data visible in UI
Features
- SVC-2660: Added additional fields for Impact events in order to be more user-readable.
- SVC-2660: Added getImpactDetails method in order to get correct Impact event details for each event.
- SVC-2660: added caching in order to prevent multiple calls of DB
- SVC-3121: Add detail fields for trigger and notification name, and populate when creating incident
- SVC-3122: triggerName and notificationName fieldmap for UI generated Incidents
- SVC-3122: add notification and trigger name to fieldmap using notification attributes
- SVC-3122: Unit test for Tal Context
- SVC-3122: use notification and trigger object in getTalcontext
- SVC-3122: add signal attributes for jira context test
- SVC-3319: Make updating events optional for IntegratorAction
- SVC-3323: update to use QFramework retry counter abstraction
- SVC-3323: rework HTTP notification and retry mechanisms; update docs
- SVC-3323: cleanup separation between Notification Action and Incident Integrate

3.2.4

Bug Fixes
- Moved retry flow for HTTP notification actions to QFramework

3.2.3

Bug Fixes
- Fixes HTTP notification won't send non-initial occurrences

3.2.2

Bug Fixes
- Fixes tracebacks due to missing OAuth settings on non-supported integrations (problem introduced in 3.2.0)

3.2.1

Bug Fixes
- Fixes an extra argument to a method call when processing HTTP Notifications, leading to tracebacks (problem introduced in 3.2.0)

3.2.0

Features
- ServiceNow log response details if hitting the REST API RateLimit
- Enable OAuth authentication for ServiceNow Import Set and Certified integrations.
- Added 'jsonstring' context for use in fieldMapping configurations

3.1.1

Bug Fixes
- Allow ServiceNow Certified Notifications stateField to be customized.

3.1.0

Features
- Added new contexts available in the fieldMapping configuration (defaultFields, mappingUtils,removeField)
Bug Fixes
- Prevent an event loop when processing errors if "Send only on initial occurrence" not selected(SVC-2666)
- Don't add multiple zenactiond.conf config files (SVC-2664 / SVC-2602)

3.0.4

SVC-2662: ignore suppression rules for events that have no device

3.0.3

Add redis endpoint to zenincidentpoll service

3.0.2

Fix "403 Forbidden" error when assigning an Incident when manually creating a ServiceNow incidentwhen REST API is used.

3.0.1

Fix AddZenactiondConfToZope migration to support zopeurl configs with spaces (for when templating isused).

3.0.0

Switch to using zenNotify (from QFramework) for processing instead of zenactiond
Add Incident Creation Time field to events.
Add SmartView Urls for supported systems (urls/smartViewUrl)
Fix invalid Device URLs generated for descriptions.
Attempt to automatically set zopeurl during installation
ZenNotify (QFramework) will create events for failed notifications.
ServiceNow: Split action types into Legacy, ImportSet, and Certified
ServiceNow: Remove Deprecated JSONv1 support
ServiceNow: Add REST API connection
ServiceNow: Support ImportSet API
ServiceNow: Remove invalid [code] links for URLs in descriptions
ServiceNow: The SN IncidentManagement Application updated to version 2.0.11.
Slack: add Re-open support
Slack: TALES Processing for messages now supports the same options as the rest of IncMan
Slack: Fix NotImplementedError encountered during closing events
Slack: Fix 'double close' messages during close/clear events.
Slack: Fix not creating new incidents due to incorrect deduplication rules.

2.9.4

Bug Fixes
- Deleting a Notification leads to tracebacks during polling if open events existed
Features
- 'Re-open incident when the event re-occurs?' configuration added to control re-open functionality.
- ServiceNow 'Incident Final States' configuration added (default '7')
- Extensive documentation updates.

2.9.3

Bug Fix
- When more than one Notification is configured, Incident polling may have used the incorrect settings.

2.9.2

Bug Fix
- Slack Integration now raises exception with details from invalid AP responses.
- Fix 'BadRequest' Exception when creating Incidents manually from the Event Console.

2.9.1

Bug Fix
- Fixes an exception from formattedDatetime after some upgrades to 2.9.0

Incident Management Integration Service

Subscription

About

Prerequisites

Usage

Zopeurl

Configuration

Date Format Processing

Associating to Existing Incidents

Field Mapping

mappingUtils Methods

Examples

Create an Incident Manually

Allow the ZenOperator Role to Create Incidents Manually

Associate Events with an Existing Incident

Notification Suppression

ZenPack Installation / Removal

Upgrading to IncidentManagement 3

QFramework ZenPack

Customization ZenPacks

ServiceNow Integration

Slack Integration

Daemons

Isolating Incident Management Traffic to a Specific Zope

Configuring zenincidentpoll

Related Daemons

Integrations

ServiceNow

Zenoss Configuration

Create a ServiceNow Notification

Configuration

Default Fields

Priority Mapping

Short Description

Description

Custom Fields

ServiceNow Configuration

User Roles

OAuth Authentication

Installing the Certified App

Tips

Controlling Incident Re-use

Troubleshooting

CAServiceDesk

Create a CAServiceDesk Notification

Troubleshooting

CAServiceManager

Create a CAServiceManager Notification

Settings

CA Service Manager Connection Settings

Incident Settings

Troubleshooting

OTRS

Create an OTRS Notification

Dpaste

HTTP

HTTP Settings

Unsupported

JIRA

Configuration

Authentication

Fields

Remedy ITSM

Create a Remedy ITSM Notification

Troubleshooting

Remedy ARS

Create a Remedy ARS Incident

Configuration

Default Fields

Description

z2TF_Notes

Impact Mapping

Urgency Mapping

Slack

Settings

EasyVista

Create an EasyVista Notification

RemedyForce REST API via SalesForce

Configuration

Notes

`mappingUtils` Methods

Allow the `ZenOperator` Role to Create Incidents Manually