I'm trying to write an automation that uses a previously-defined variable, say {{specialClientId}}, to fetch other important data about this client from an online database. I'm having a bit of a problem with the variable scope inside the inner conditional.
In particular, I make a web request to an API endpoint that provides an output like this:
{"result": [
{"clientId": clientId1,
"clientFavAnimal": clientFavAnimal1,
etc},
{"clientId": clientId2,
"clientFavAnimal": clientFavAnimal2,
etc},
...
]
}
I want to extract the clientFavAnimal associated to my {{specialClientId}} variable.
My approach right now is to place a conditional inside a loop that iterates through the webResponse.body result, like so:
{{#webResponse.body.result}}
{{#if(equals(clientId,specialClientId))}}
{{clientFavAnimal}}
{{/}}
{{/}}
In my testing, this works perfectly if I write in the specialClientId explicitly, but this results in blank output when written as above. This makes sense to me because {{specialClientId}} is inside the loop, and so Jira thinks I'm referencing a key inside the webResponse result. How do I make the scope of the variables inside the conditional explicit so that the correct values are compared?
Ok, I've figured out some kind of a solution to this, which is to use advanced branching.
I define a new variable (say {{result}}) for {{webResponse.body.result}} which effectively raises the scope.
Then within the branch, set up an if-conditional block for {{result.clientId}} being equal to {{specialClientId}} and put all subsequent operations involving {{result.clientFavAnimal}} after the if-block within this branch.
I would still be curious to hear if this is achievable using smart value syntax only, as in my original question.
Hi @IL
This is a known limitation of automation rule iterators: once inside the scope of the iterator, it cannot access data / smart values at any higher / other level.
And so your variable specialClientId is not visible inside of the iterator {{#webResponse}} ... {{/}}
Depending upon what is needed, there are a couple of workarounds:
This second method can be challenging to get correct. The essential steps are:
Kind regards,
Bill
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The idea of treating pieces of the JSON object as a string and using matches is definitely not ideal, but thanks for giving it a shot Bill. It's too bad that the iterators can't natively handle what seems to be a pretty typical use-case of iteration. It seems like it would be easy to fix, e.g. prepending a period mark before smart values in the iteration that are meant to refer to properties of the iterated object, a la VBA.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
My understanding is the Atlassian team has attempted to address this iterator limitation in the automation engine several times without success.
You could also create a service external to the rule, passing your client ID to perform the lookup / filtering there and return the result to the rule.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.