Get position of specific value block in {{webResponse}}

[Svante Gustafsson Björkegren]

Hey community,

I am trying to get one specific element in an array returned in a {{webResponse}} in Automation. I have found the method .get() which requires the number of the position of the element and it works fine. 

The position is different by the runs which means that I need this to be dynamic. My first try was to use a smart value as the position, like:

{{webResponse.body.data.get({{myPosition}})}}

but the get-function does not support smart values like this.

My example is this: I have the following webResponse returned in my automation:

{
  "data":
   [
      {
        "id": "A",
        "name": "foo"
      },
      {
        "id": "B",
        "name": "bar"
      },
      {
        "id": "C",
        "name": "baz"
      }
   ]
}

In my automation I now want to get the name attribute for the element having id == "B", i.e. "bar"

Is there a way to get that specific element from the webResponse using any filtering or parsing so that I can use the element in later actions such as:

{{webResponse.body.data."id==B".name}} => "bar"

Looking forward to hear back from you!

Cheers,

// Svante

[Bill Sheboy]

Hi @Svante Gustafsson Björkegren 

Short answer: the inline, list function get() requires a number, and it cannot take a Created Variable directly.  There are several workarounds, assuming your myPosition is a Created Variable.

Force the correct number typing for the get() function.  There are two versions of the get() function: one for inline, list iteration and one for lookup tables.  The list version suffers a known limitation where many functions cannot use a Created Variable as a number parameter, even when converted using asNumber.  The problem seems to be the value type stays "text" in the function call, even though it is converted to a number.  (Aside: the newer get() function for lookup tables does not have this limitation.)

As I described in this article, there is a workaround to force the type as a number by ensuring the first thing the get() "sees" is a number.  This may be done by adding another, empty created variable, such as with:

• action: Create Variable
  • name: varNull
  • smart value: {{null}}
• action: Create Variable
  • name: myPosition
  • smart value: whatever you are doing to set this value
• Something that needs the record from the webresponse

{{webResponse.body.data.get(varNull.length().plus(myPosition.asNumber))}}

How that works is:

1. Creating the varNull variable with an unknown smart value, {{null}}, creates an empty string
2. We get the length of the empty string, which is 0, and so the first type entering the get() function is a number (specifically, an integer)
3. We add to that your variable, and this time the asNumber function works because math functions such as plus() can correctly handle the conversion of text to number

I recommend trying this approach before the other two.

Branch and test with a condition (as @Tomislav Tobijas suggested with the link to that article).  This approach may not help if the parallel processing / asynchronous behavior of branches does not fit with your rule structure.

Dynamic list searching using a regular expression.  This approach is likely not needed with the number get() you are trying, and is more relevant for complex searches of list data with text.  Please see this article I wrote to learn more about this technique.

Kind regards,
Bill

[Svante Gustafsson Björkegren]

Hey Bill,

I added a followup on your response but I made it an answer instead of a reply to you answer. Sorry for the confusion

Cheers,

// Svante

[Tomislav Tobijas]

Hey @Svante Gustafsson Björkegren ,

You might want to check this resource: JSON Queries in Jira Automation 

Based on the article above, maybe something like this would work:

1. Use an "Advanced branching" action on {{webResponse.body.data}}

2. Inside the branch, add a condition: If {{item.id}} equals "B".

3. In the "Then" branch, use {{item.name}} (which will be "bar" in your example).

I believe we constructed something like this a while back, but I've lost track of that automation to check it out 😅

Bonus, here's another feature request that might be relevant to the use case: AUTO-1682: Add support for find() and filter() functions in automation smart values 

Cheers,
Tobi

[Svante Gustafsson Björkegren]

Hey Bill,

Thnx for your very comprehensive answer! Awesome stuff! 

I will use this method but meanwhile I have run into another issue with my automation that I want to hear your opinion about, if that is ok?

My use is:

I have got all my users API Access tokens out and added them as Assets using the API Access REST API and Automation. That was quite straight forward. Any item in the webResponse that is missing in Assets will create a new object.

My next step is to edit any token data in Assets when changed in Cloud happens. (It is actually only the LastActive-, and status-attributes that can change) My approach for this part is to get the same data from the REST endpoint, stored in the smart value {{webResponse.body.data}}. Then I am doing a For AQL action, fetching all existing token-objects in Assets.

For each object in the FOR-loop I am getting the attribute: tokenId (object) and compare this with the id (webResponse) of each token returned in the webResponse. When I find the match I have the index of that token in the webResponse.

My smart-value for the index is:

{{#debug}}{{#webResponse.body.data}} 

 {{#if(equals(id,foundId))}}{{index}}{{/}} 

{{/}}{{/}}

where id is the attribute in the webResponse and foundId is fetched from the current object in the loop, as:

{{#debug}}{{object.tokenId}}{{/}}

This does not work unfortunately! If I replace the smart value, foundId with a hard-coded id-string, then it works fine and I get the correct index in the webResponse.

I suspect that there is some limitation in the branch-handling here. Isn't it possible to use a "branch-local" smart value in the equals-function within a branch like this, perhaps? I have also tried replacing the smart value foundId with the more direct smart value object.tokenId without any luck.

Do you have any clues why I can't seem to get a match giving me the index using a smart value when it works with a hard-coded value?

Looking forward to hear back from you!

Cheers,

// Svante

[Bill Sheboy]

First, no problem asking additional related questions to your topic! 

When you have a new question, I recommend completing the current one (e.g., accepting answers that helped) and then using the "Ask a question" button at the top of the page to ask the new one.

For what you asked, there is indeed a long-standing, known limitation for the long-format of iterators: only data from the iterator scope, and lower, is visible / accessible.  The Atlassian automation team knows about this, and has tried several times to fix it...without success yet.  This means your created variable cannot be "seen" inside the long-format iterator.

In my earlier post, I noted the technique of dynamic list searches with a regular expression.  The essential steps for your case would be:

• build a regular expression with your foundId, based on the structure of the response list elements
• flatten the response into text, with delimiters, including the {{index}} in each "record"
• split that flattened data back into a list, and use inline iteration with the match() function and the regular expression to get your record(s)
• use text functions to extract the needed data from the result

Please read that article I wrote to fully understand this approach before using it; although complicated, it is quite reliable.