Forum Discussion

Jeroen_Gouma's avatar
2 years ago
Solved

Variable json content in http integration

Hi all,

we implemented custom http integration to create tickets in Jira Servicedesk. This works fine.

However, new requirement is to put a variable (##jira.assetid##) in the content to link the ticket to the correct asset.

This works fine when the assetid is set. But when there is no asset id available the integration fails. Is there a way to make this output more dynami? I mean, if the value is set, write the value. If not, just write a default.

Our json message (bit redacted):

{

  "fields": {

        "summary": "##ALERTID## ##LEVEL## - ##HOST## ##DATASOURCE## ##DATAPOINT## ",

        "issuetype": {

            "id": "xxxxx"

        },

        "project": {

            "key": "xxx"

        },

        "description": {

            "type": "doc",

            "version": 1,

            "content": [

                {

                "type": "paragraph",

                "content": [

                    {

                    "text": "##MESSAGE##   ##ALERTDETAILURL##",

                    "type": "text"

                    }

                ]

                }

            ]

        },

            "customfield_10500": [##jira.organizationid##],

        "customfield_10681": [

          {

          "workspaceId": "230f10d2-b759-405f-8d38-157edbe9e818",

          "id": "230f10d2-b759-405f-8d38-157edbe9e818:##jira.assetid##"

          }

      ]

    }

  }

  • When you say that integration fails, do you mean that LM doesn’t sent the REST request at all? Or that Jira is rejecting the json you are passing? I thought that LM will just fill in unset tokens with nothing, aka send over  "customfield_10500": [] . If you are looking to have some sort of default value when it’s not set, I would suggest setting a jira.organizationid property on the root folder/group as a default and let sub groups override it.

    I don’t use Jira so I might not understand the situation fully. I’m assuming jira.organizationid is assigned to groups/resources and not pulled from somewhere else.

3 Replies

  • When you say that integration fails, do you mean that LM doesn’t sent the REST request at all? Or that Jira is rejecting the json you are passing? I thought that LM will just fill in unset tokens with nothing, aka send over  "customfield_10500": [] . If you are looking to have some sort of default value when it’s not set, I would suggest setting a jira.organizationid property on the root folder/group as a default and let sub groups override it.

    I don’t use Jira so I might not understand the situation fully. I’m assuming jira.organizationid is assigned to groups/resources and not pulled from somewhere else.

  • Completely agree and we need this too. Currently every integration we have has to be configured at least twice in LM, once for regular alerts and once for collector down notifications. These two notifications do not have a common set of alert tokens, so the payloads have to be drastically different. Having the ability to use a templating engine like Jinja2 would allow for conditional branching and also other options. 

  • If you are looking to have some sort of default value when it’s not set, I would suggest setting a jira.organizationid property on the root folder/group as a default and let sub groups override it.

    I didn’t even think of that. Shame on me and good catch @Mike Moniz. It has been our experience as well that when the token is blank, it causes the target system to reject the json payload because it’s incomplete. 

    Still, there should be a better templating engine for the JSON and also the messages. The fact that ##LIMITEDMESSAGE## for DSs does not return the first 10 words of the message, but instead is equivalent to ##VALUE## is another reason that a more fully fledged templating engine is needed. Context: ##LIMITEDMESSAGE## is an event source token, where it does show the first 10 words of the message (##MESSAGE##), but when used with a DS, it includes the int/float value of the datapoint. Jinja2 would allow this with {{ ##MESSAGE##[:10] }}. 

    Jinja2 would also allow conditionals for us, fixing a big problem. Some of our customers use us to resolve their incidents and some get the incidents themselves and fix it themselves. Each device in LM has a tag that indicates which is the case. It would be nice to be able to use that tag to customize the message so that incidents that we resolve have just the data we need, but incidents that go to customers have a different message that is more user friendly.