Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

https://support.atlassian.com/opsgenie/docs/dynamic-fields-in-opsgenie-integrations/

Jira Service Management parses your data to construct rich and informative alerts. You can use dynamic fields to customize alert properties and alert conditions.

Draggable Fields

Draggable fields bring significant data for creating and managing well-informed alerts. Jira Service Management Integrations Framework provides different dynamic fields for every integration, specific to the integrated tool. You can use dynamic fields in Filters of your integration actions as well as Alert Fields. In Filter, fields are available to choose in the condition drop lists. In Alert Fields, you can drag a dynamic field into any input you find appropriate.

Jira Service Management interprets the expressions within the double-curly braces as dynamic fields. Dynamic data populates at every notification that's sent to Jira Service Management.

For example, let's say someone created an issue in JIRA; and enters "This is the summary" as summary. Using Jira Service Management’s JIRA integration, "[Jira] {{summary}}" for Message in a Create Alert Action will yield an alert with the message "[Jira] This is the summary". It will then notify the users. All we needed to do was drag {{summary}} to Message. When the issue was created, Jira Service Management got automatically notified. It creates an alert with the issue's summary in the message.

You can mix static text with dynamic fields. In the example above, the "[Jira] " in "[Jira] {{summary}}" is static and it'll be at the beginning of every created alert's message. "{{summary}}" can be different for each alert.

Using Raw Parameters from Webhook URL, Payload and Headers

You can also insert url parameters or http payload parameters from webhooks directly into your alerts. Let's clarify with an example:

Suppose you're using Jira Service Management's Jira integration. Jira sends a variable named timestamp to Jira Service Management in the webhook payload. But timestamp isn't available as a draggable field in the Integrations page. If you still need to use timestamp in your alerts, you can:

  • Go to Advanced Settings of your integration

  • Wherever you need, add {{_payload.timestamp}} to the input fields.

  • Save the integration.

Nested payload variables are accessible as well. In the Jira example, we could also use _payload.issue.fields.environment to access the following value that is in the http body of the webhook:

Text

{
    "issue" : {
        "fields" : {
            "environment" : "env_val"
        }
    }
}

Url query parameters of a webhook are also accessible via {{_url.param}} where param is the parameter key. You can add custom parameters to the webhook url and inject it into your alerts. To clarify this with an example:

Suppose you're using Jira Service Management’s Stackdriver integration. You're monitoring many projects and want to use a single integration for all your alerts. But you still want to have a way to distinguish which alert belongs to which domain. A way to do this is to use a custom parameter for each of your projects.

You can add your custom parameter to the webhook url of the Stackdriver integration. E.g.: ¶m1=val1, and insert {{_url.param1}} in the integration config to access it.

Note that accessing request url, payload and headers parameters is not available for actions via Alert API

Headers of a webhook request are also available via {{_headers.param}} where param is the name of the header. You can use all the headers of a request in your alert fields.

For email-based integrations, you can use headers of an email via {{_headers.PARAM1}} notation. For example, for an email-based integration, you can use {{_headers.IMPORTANCE}} in the alert fields. Note that you should use UPPER CASE letters for the keys.

To control your alert fields further, you can use string processing methods on dynamic fields. For example, your Jira Service Management JIRA Integration has an 'Add Note' action, and Note is configured as "note: {{comment_body.substringAfter("is")}}".

Now when someone in JIRA comments on an issue with "This is the comment", a note is added to the issue's Jira Service Management alert, with the text "note: the comment".

Listed below are the complete list of methods you can use in dynamic fields:

substring(int from), substring(int from, int to): yields the string between specified indices. from is included to is excluded

{{ from_name.substring(5,20) }}

substringAfter(String from): yields the string between specified indices. from is included to is excluded

{{ subject.substringAfter("Host") }}

substringBefore(String to): yields the string before the specified parameter

{{ from_address.substringBefore("@") }}

substringBetween(String from, String to): yields the string between from and to parameters

{{ subject.substringBetween("URL:","(") }}

extract(regular expression): yields part of the string that matches the parenthesized section of the regular expression.

{{ message.extract(/Host: (\S+)/) }}

toDate(String format) converts millisecond-based timestamp into date format, following Java formatting . The default format is "yyyy-MM-dd HH:mm:ss ZZZ".

{{create_timestamp.toDate()}}

get(int index) yields the element at the given index of an array.
{{myArray.get(0)}}

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.

Criteria for checks

  • Replacing OG with JSM
  • Basic grammar & spell check
  • US English
  • Positive language
  • Removing passive voice (wherever necessary)
  • Simplifying sentences
  • Change V&T
  • Replacing old links and images with new ones
  • Structure of these pages: Do these need to be separate topics? Can it be added /merged with another topic? Does the headline need to revised? Are all the topics + content helpful for our reader?
  • Conceptual validation: Do these journeys, concepts, terms make sense for JSM? Do we need a developer to verify parts of this content?
  • No labels