Hi all,
In workflows, this is acceptable:
And this is not:
However, according to the documentation, We get this:
And according to this JSON Slice GitHub repository README, we see that negative indices are supported:
Please fix this, such that we do not get this incorrect invalid JSONPath message.
Kind regards,
Angelo
The Variable Selector generates a JSONPath expression using the JSON Slice implementation of JSONPath.
Hi @angelo_mekenkamp, I think the answer will be that it works as designed. (jk, there will probably be no answer)
The âvariable selectorâ itself uses a JSON Slice implementation, not necessarily the comparison action in the workflow.
Regarding the actual JSONPath:
When you select the trigger for your workflow, the Filter field is displayed. Enter a JSONPath expression using the Jayway implementation. Note that this is not the same implementation used to select values in actions and operators.
and also see Workflows: Getting Started and Advanced - #2 by colin_mckibben .
Workflows uses a language called JSONpath to aid the in the selection of data that can be used as input into actions and operators. JSONpath has a few implementations, with the most common one being Goessner. SailPoint, however, uses an implementation that is closer to Jayway, which offers a more robust set of filters and operators. This is an important distinction to remember when building and testing your JSONpath because many online JSONpath validators only support Goessner, which means you could be testing against the wrong implementation. I highly recommend you check out our trigger filter reference material in the developer portal to learn more about the operators that are available, along with a suitable online JSONpath validator.
I am unsure why SailPoint doesnât provide such a validator themselves, as it seems the implementation is âcloserâ to Jayway (but not exactly that). The same may be true for Goessner.
The documentation also mentions that SailPoint sometimes uses Goessner, so I guess they mix and match for enhanced flexibility and increased speed.
However, you can still select variables using JSONPath for use in future steps by adding the trigger field to your JSONPath expression using the Goessner implementation.
Thank you for the clear information @adamian! Some of which I hadnât seen before.
Based on your information it indeed looks like they use different implementations at different parts of workflows.
This bit was added on my request. I was trying before to get SailPoint to document which implementation they use for JSONPath, such that I know how I should write the code as it felt a bit too much as reverse engineering: doing trial and error to see what works and what doesnât. The documentation team did create the internal ticket SAASDOCS-7447 and updated the documentation as a consequence, mentioning the JSON Slice GitHub repository.
I disagree with your ânot necessarilyâ part. The comparison action in the workflow does rely on input. And the documentation mentions that for this input, you use the variable selector, which is therefore using the JSON Slice according to SailPoints documentation, where they also attach the specific repository.
The issue here is not with the specific implementation of JSONPath, but rather on the specific implementation of the validator, as the validator is wrongly saying that the code is wrong.
Also, for other developers that are reading this. I think it is good to also be aware of this bug in Identity Security Cloud related to JSONPath where a filter will not return an array if the filter returns only one object, making it more difficult to loop over it. Suddenly you donât loop with just one iteration, but you loop over the properties of that single object instead.
Got an update from SailPoint Support:
I appreciate it that the engineering team have created these internal ticket IDs (after 17 days).
I donât appreciate SailPoint Support claiming that this is a summary of their investigation.
This was my investigation and exactly what I shared with them from the beginning, as you can see in this forum post.
Kind regards,
Angelo
Hey @angelo_mekenkamp @adamian,
While I canât necessarily speed up the UI implementation fix, we have recently made a json path evaluator that uses the implementation we use in each area of the UI.
You can switch between the two implementations with the dropdown on the right of the path. Workflows is the default.
Great stuff @tyler_mairose!
With SailPoint Documentation currently pointing to implementations outside of SailPoint, we saw mismatches. Here we might be able to notice the true effect of it.
However, I made some tests on your evaluator (using workflows implementation), but unfortunately also notice mismatches between your evaluator and the actual behavior of ISC workflows.
Is this evaluator actually applying the exact same code as the one that is getting used by ISC workflows, or is ISC workflows using some additional steps that you are not using in your evaluator?
In addition I would suggest to have the default input also have values that are arrays with 0,2 and 3 elements, instead of just 1 which you see right now. Also boolean values and integer values would be nice. Of course we can change the input ourselves, but I think it adds value to have these types in the default input as well, to speed up the testing.
Kind regards,
Angelo
The online evaluator uses a javascript library that should match the behavior exactly, we wanted to keep it javascript so that speed of the evaluation response was kept. If you detail the mis-matches we can get them in our javascript library.
We do have a new cli command sail jsonpath eval -f path-to-file.json -p "$.jsonPath" that uses the exact workflow golang library, that you can try out.