https://support.atlassian.com/opsgenie/docs/what-are-the-integration-types-and-actions/
Jira Service Management's Integrations Framework allows Jira Service Management’s alerting capability to work in conjunction with the most popular monitoring tools. Through email and API, Jira Service Management can communicate with these tools and process its alerts according to the data they send. With integrations, you can extend your everyday monitoring services with a powerful alert and notification system. Jira Service Management integrates with the services Rackspace, New Relic, Circonus, and more.
Jira Service Management gives you a robust framework so that you can integrate it with all your operations management tools. Through email and APIs, Jira Service Management can communicate with your tools.
View the full list of Jira Service Management integrations.
The owner of your Jira Service Management account has to verify emails of users within your organization so that they can use API integrations.
Integration Types
Jira Service Management Integrations Framework can operate different types of integrations.
API based Integrations:
You can forward events from many monitoring tools to Jira Service Management for alerting purposes. Jira Service Management is able to catch and process notification webhooks and create well-informed alerts based on the notification data. With this ability you can let Jira Service Management process any HTTP request as well as using many API-based integrations configured specifically for monitoring tools. For example, if you're a Scout customer, you can use Jira Service Management's Scout Integration to let Jira Service Management automatically create and close alerts according to events on Scout.
The owner of your Jira Service Management account has to verify emails of users within your organization so that they can use API integrations.
Bidirectional Integrations
Jira Service Management's bidirectional integrations allow data to be sent and processed both ways between Jira Service Management and the other applications. A good example is our ServiceNow integration. Using the integration, ServiceNow sends incident events to Jira Service Management, with detailed information and Jira Service Management forwards alerts as incidents to ServiceNow.
Outgoing Integrations
Jira Service Management Integrations Framework has callback capability that can notify chat applications about Jira Service Management events. A good outgoing integration example is our Webhook capabilities which pushes information via a URL endpoint. It's important to note that this information is not customizable
Email based Integrations
You can use Jira Service Management email integrations to process your incoming emails for alert management. Jira Service Management Email Integration accepts any kind of email and is fully customizable; allowing you to control a robust alerting mechanism tailored to your inbox. Jira Service Management has also specific email based integrations for several monitoring tools, e.g., Pingdom, Uptime Robot, Zenoss etc. For example, if you're a Pingdom customer, you can add Jira Service Management's Pingdom Integration and readily turn Pingdom events into Jira Service Management alerts.
Integration Advanced Settings
Integration advanced settings consist of many different alert scenarios. These scenarios are called "Actions"; and they specify how and when alerts can be created, closed, acknowledged. etc. There are default actions provided by Jira Service Management for every integration; but you can customize them and add as many actions of your own as you like. You can, for example, have three ‘Create Alert’ actions; which means the webhook data that comes to Jira Service Management will be evaluated against these three scenarios in order; and if one of them has a match a new alert will be created.
Action Processing
There is a specific order to which type of actions will be evaluated first. For example, by design ‘Ignore’ actions are evaluated first and ‘Add Note’ actions are evaluated last. This means the incoming data will be evaluated against ‘Ignore’ actions; and if one of them has a match then ‘Add Note’ actions and also any other action will not be evaluated at all; and only that Ignore action will be processed.
The order in which action types stand for evaluation is:
Ignore
Create Alert
Close Alert
Acknowledge Alert
Add Note
You can have up to 255 actions for each integration.
If you’re using the new integration framework, you can have up to 250 incoming automation rules and up to 50 outgoing automation rules.
The actions of the same type also are evaluated in order; and you can change it. For example, let's say you have three Create Alert actions in the order of CreateAlert1, CreateAlert2, CreateAlert3. You can just drag CreateAlert3 and move it up to change the order to CreateAlert3, CreateAlert1, CreateAlert2. Now upon save, CreateAlert3 will be evaluated before the other Create Alert actions against incoming data; and if its Filter has a match, CreateAlert1 and CreateAlert2 will not be evaluated. Remember that for one incoming request only one integration action can be executed.
Note that any change you make in action order will only be effective after you click "Save All Changes".
The available actions are explained in detail below.
Ignore Action
An Ignore action means that the webhook data, if it matches the action's filter, will be ignored completely; and will not be evaluated by any other action. Ignore actions are the first actions to be processed when a webhook data comes to Jira Service Management.
From the Integration Advanced Settings page, under Actions on the right, click the plus sign next to 'Ignore'. This will open a new ignore action. You'll see that an Ignore action has one tab, Filter. If a webhook data matches the condition set of this filter, the ignore action will be processed, thus, the data will be ignored. For more information on Filter, see Action Filters.
To save this action and any customization you made, remember to click 'Save Integration'.
Create Alert
A Create Alert action will create a new Jira Service Management alert if the condition set of its filter matches the data. You can not only specify the conditions to when an alert will be created, but you can also fully customize what kinds of information it will have and where, its formatting etc.
To see this in detail, click the plus sign next to ‘Create Alert' under 'Actions’. This will open up an empty Create Alert action. A Create Alert action has three tabs: Filter and two Alert Fields tabs.
Filter
If the data that's sent to Jira Service Management matches the condition set of this filter, this Create Alert action will be processed to create an Jira Service Management alert. For more information on Filter, see Action Filters.
Alert Fields
Alert fields are the data that’s present in a Jira Service Management alert. The fields that you can configure are explained below. You can write text, and also drag and use the dynamic fields from the right. For more information on draggable fields, see Dynamic Fields.
Message: Alert text up to 130 characters.
Alias: The alias is the unique identifier for "open" alerts. There can only be one "open" alert with the same alias in Jira Service Management.
Recipients: The names of the users, groups, escalations and schedules that should be used to determine who should be notified. Note that for a Create Alert action, Message and Recipients fields are mandatory.
Entity: The name of the entity that the alert is related to. For example, the name of the application, server etc.
Source: The source of the alert.
Tags: Labels to the alert for easier identification and categorization of alerts. Use commas in between for multiple tags.
Actions: List of actions a recipient can execute to respond to an alert. Use commas in between for multiple actions.
Description: Detailed description of the alert; anything that may not have fit in the Message field can be entered here.
Extra Properties: Additional alert properties. Enter the name of the property in the first field and the value in the second.
User: Owner of the note that will be added to the alert.
Note: Note to be added to the alert.
Close Alert
A Close Alert action will close an existing Jira Service Management alert based on its alias; if the data matches the condition set of the action's Filter. For more information on Filter, see Action Filters
Alert Fields
Alias is mandatory in the alert fields of a Close Alert action. When a Close Alert action is processed, Jira Service Management looks for an "open" alert to close, whose alias is equal to the Alias specified in the Close Alert action.
User: Owner of the note that will be added to the alert.
Note: Note to be added to the alert.
Acknowledge Alert
An Acknowledge Alert action will acknowledge (or ack) an existing alert based on its alias; if the data matches the condition set of the action's Filter. For more information on Filter, see Action Filters
Alert Fields
Alias is mandatory in the alert fields of an Acknowledge Alert action. When an Acknowledge Alert action is processed, Jira Service Management looks for an "open" alert to ack, with alias equal to the Alias specified in the Acknowledge Alert action.
User: Owner of the note that will be added to the alert.
Note: Note to be added to the alert.
Add Note
Add Note action is used to add a comment to an existing alert according to the data Jira Service Management API receives. When an Add Note action is processed, Jira Service Management looks for an alert to add note to, with alias equal to the Alias specified in the Add Note action.
User: Owner of the note that will be added to the alert.
Note: Note to be added to the alert.
Share your feedback
We would love to receive feedback about this documentation, the product experience, functionality, or anything you’ve got to share.
(Simpler: Do you have any feedback about this documentation, your product experience, or any functionality? We'd love to hear from you.)
You can either add comments to this page or add a card on the Trello board.
0 Comments