Enhancement: Fixed, Workflows JSONpath Issue, Array Brackets Always Present When Using Filters

Announcements Product News
, ,
1

This issue is now fixed. The root cause was a shim we have in our code to add convenience for our customers. The JSON specifications do not flatten (provide the string data) in single element arrays. What this means is that if you want to filter on a single item array, you would have to extrapolate the data and transform. Our developers added a convenience item for customers to avoid this extra work which was affected by the enhancement added to support jayway capabilities in actions and operators.

The added benefit here now means you can use jayway operators in actions and operators in addition to triggers. Prior to this enhancement, actions and operators only supported the Goessner JSONpath when selecting variables. We now support jayway for Actions, Operators, and triggers.

For more information, please review this page: Filtering Events | SailPoint Developer Community

Recently, an enhancement to the JSONpath implementation that Workflows uses has been released. This enhancement adds support for additional operators, like regex pattern matching. This enhancement was supposed to keep backwards compatibility with JSONpath expressions implemented in existing workflows. However, it has come to our attention that the use of a filter in a JSONpath expression now always results in an array, even if there is only one item in the array.

Before: A filter like $.trigger.changes[?(@.attribute == 'manager')].newValue.name would produce this result: John Doe

After: A filter like $.trigger.changes[?(@.attribute == 'manager')].newValue.name will now produce this result: [John Doe]

We have received reports that this subtle change has broken workflows using filter expressions within a Compare Strings operator, and use of this filter in email bodies is resulting in the array brackets being displayed in the resulting email.

We are working hard to fix this ASAP!

We sincerely apologize to anyone who has been affected by this change, and we appreciate your support and patience while we resolve this issue. We will make updates to this post as the solution progresses.

3 Likes
2

Thank goodness. I was going nuts trying to figure out why my new workflow wasn’t working.

3

Did this get pushed to the prod tenants without going through sandbox first?

4

I was using this type of filter JSON expression as a variable in a templating context for an email action, which worked perfeclty for two weeks until yesterday where that workflow doesn’t work at all anymore (both SB and Production). Could this have anything to do with that?

Template:
“oldCostCenter.$”:“$.trigger.changes[?(@.attribute == ‘costCenter’)]@.oldValue”
+
“oldManager.$”:“$.trigger.changes[?(@.attribute == ‘manager’)]@.oldValue.name”

5

Sebastian Wegmann,

Yes, the same issue above affected the email Body variables as well. The fix checked in last night should fix both issues.

1 Like
6

Update 02/08/2023:

This issue is now fixed. The root cause was a shim we have in our code to add convenience for our customers. The JSON specifications do not flatten (provide the string data) in single element arrays. What this means is that if you want to filter on a single item array, you would have to extrapolate the data and transform. Our developers added a convenience item for customers to avoid this extra work which was affected by the enhancement added to support jayway capabilities in actions and operators.

The added benefit here now means you can use jayway operators in actions and operators in addition to triggers. Prior to this enhancement, actions and operators only supported the Goessner JSONpath when selecting variables. We now support jayway for Actions, Operators, and triggers.

For more information, please review this page: Filtering Events | SailPoint Developer Community

7

The issue still seems to persist on our workflows using oldValue variables in email templates. How can I fix this?

8

@Swegmann can you share how you configured your email step along with the actual result that it produces. This will better help us understand what you are observing.

9

Of course, it all should be in this support ticket:

https://support.sailpoint.com/csm?id=csm_ticket&table=sn_customerservice_case&sys_id=7d714132dbfc29d038e5ddf5f4961960&view=csp

10

Has a new update been pushed recently? My workflow just broke again. :weary:

11

Hey Ben,

So we can properly investigate, can you share exactly what has changed for you?

12

When using the Manage Accounts node in conjunction with the Get List of Identities Search, it fails on arrays and single values returned in the search

This is jsonPath I am using to get the data from Get List Of Identities.

$.getListOfIdentities.identities[*].accounts[?(@.source.id == “2c9180867c5b60ac017c70c751a37076”)].id

It worked a few weeks ago when I first started developing this. Now it doesn’t seem work for either.

I keep getting values that are double wrapped in arrays when I look at the failure json.

Manage Accounts",“result”:{“failedAccounts”:[“[05878e8a7f824206abcb51d5058ad6d0]”,“[b5188cbe69b943b59dcf9c719968928d]”],“successfulAccounts”:null},“stepName”:“manageAccounts”,“task”:“sp:manage-account”}

My json path expression seems to be valid according to the evaluator.

Again, this all did work a few weeks ago.

Here is a picture of the workflow in question. It’s pretty straightforward. If an active Identity with an account from a particular source is in a disabled state, enable the account.

image
image790×600 20.2 KB

13

Still experiencing this issue with Manage Accounts. Any idea if this is being looked at?

1 Like
14

I am going to redesign the workflow to loop through the results from the search with the loop operator.

15

Hi @BenNelson ,

Thank you for bringing this to our attention. This has been identified as a bug, and engineering is working on it.

2 Likes
16

Hi @colin_mckibben any update on this. Actually we also face the same issue where the json in “ComapreStrings” is returning an array value and it is going always to false path. It would be really helpful if you could provide an update on the fix.

Thanks,

17

Hi @colin_mckibben Is there any update on the fix.? We are facing this issue where the JSONpath is returning an array, we are not able to move forward on the testing of requirement that we have. It would be really helpful if you could provide an update on the fix.

Thanks,

18

The ticket is still in the backlog. I have asked engineering for an ETA.