Workflows Improvements: Correct string length and support for objects and arrays in inline variables

[angelo_mekenkamp]

@colin_mckibben

A string like “hello” would result in a value of 7 when using the .length() function. This has been fixed in the latest release, and the length function will now return the correct length, which is 5 in the “hello” example.

This is great, thank you @colin_mckibben !

@colin_mckibben

With the latest release, inline variables now supports JSON serialization of objects and arrays with the use of the .JSON() function.

Trying to get this to work, as I think this might be the solution to a functionality gap workflows has, where we first want to filter an array using JSONpath and then filter by index, as mentioned here:

@angelo_mekenkamp

Suppose my workflow performs an action (for example to get all accounts of a specific identity) and then gets a JSON response which is an array. Is it then possible in ISC workflows to apply a filter on the results with a JSONpath expression, store the result in a variable, and then apply a second JSONpath expression on that variable, to get the first record? I tried with the define variable operator, but did not succeed. Maybe because it expects to return a string instead of a structured JSON object?

As test, I have created a workflow, with external trigger, where the only action is to send an email. The email should send the name of the first item whose cost is 10 in the subject. As input to this, I use the example JSON file mentioned here:

ISC JSON path evaluator from SailPoint does not behave the same as ISC workflows

Hi all, SailPoint has written a Json path evaluator that should be as similar as possible to the implementation used by SailPoint in each area of the UI (only workflow and event trigger implementations are supported for now). This is great and can be useful, but I noticed during testing that it is actually not matching in behavior. Using this evaluator to convince yourself that your workflow implementation will work correctly is therefore not a working strategy. Since the defau…

So I tried the subject like this:
TEST {{$.trigger.items[?(@.cost == 10)].JSON()[0].name}}
The idea would be to:

1. Have the original JSON visible in $.trigger
2. Use the JSONpath .items[?(@.cost == 10)] to filter on items whose cost is 10.
3. Add .JSON() to your JSONpath to force it to serialize to JSON as you mentioned.
4. Use the JSONpath [0].name to get the name of the first item.

I expected this result:
TEST apple
However, the results show this:
TEST [map["color":"red" "cost":%!q(float64=10) "name":....., where all items of cost 10 are visible here. Shouldn’t the .JSON() command force this to serialize to JSON?