NeophyteNeophyteSo in a Jira automation rule there isn't 'code' in the traditional sense of the word. It's all visual like the application Tines.
This might help: https://imgur.com/a/oK61qK8
So what happens is there's a manual trigger, if the servicename == logicmonitor on the Incident in question then create a var: lmalertid from field 'issue.labels', print that to the audit log. Create a second var: deviceHostname from 'issue.customfield_20574', which is supplied from the ##host## token when the custom http delivery Active rule is triggered from LM.
Next we print that deviceHostname to the audit log, then send the first web request. The URL is https://xxxx.logicmonitor.com/santaba/rest/device/devices?filter=name:"{{deviceHostname}}*". The HTTP method is GET, with no body, and the following headers:
So provided LM sends the ##host## token, which defines the customfield_20574, and the rule can use that field to define {{deviceHostname}} and the URL is correctly formatted then it will throw the value of deviceHostname into the filter and send it.
I have other rules that successfully send these Jira variables in the body.. this is the first one I've tried using them in the URL.
NeophyteOh wait! I lied!
I have a rule that's sending a web request to LM that ACK's an alert that's using a var in the url.. but it's not a filter query.
https://xxxx.logicmonitor.com/santaba/rest/alert/alerts/{{LMalertID}}
Yeah, that's not a filter but a direct call to the lmalertid.
When you construct the query parameters:
filter=name:"{{deviceHostname}}*"The part after the equals sign needs to be URI encoded (after the deviceHostname variable is resolved). The colon and tilde are probably fine because they don't really change, but the quotes and start would need to be url encoded. So, you might get away with encoding it manually since don't need to change the name.
filter=name:%22{{deviceHostname}}%2A%22
