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.
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.
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.
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.
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.
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.
The evaluator does not work correctly either. I have a workflow for trigger âAccess Request Decisionâ where I use operator ânoneofâ to filter out decisions other than approved. I have used this workflow for tens of working tests, however when I put the filter in the evaluator, it says operator ânoneofâ is not supported.
What is going to be the fix?
Fix the evaluator so that it works 1 to 1 with the existing implementations, or document all the differences, or retire it?
Hi Lukas. The workflows implementation does not support noneof. What you are describing is an event trigger filter, which does support noneof. By default, the jsonpath evaluator is set to validate workflows json path. YOu have to choose event trigger from the dropdown if you are attempting to validate an event trigger jsonpath.
You are correct. Our initial approach to this was naive in thinking that we could take an existing open source jsonpath library and modify it to match the two implementations SailPoint uses. This has proven to be a bigger challenge than we anticipated. We are evaluating an option to provide APIs that will use the exact same libraries as our two implementations. The downside is that it will be a little slower since it will be API calls instead of javascript in the browser, but the upside is that it will be 100% accurate. Expect this to happen in late January.
Thanks @colin_mckibben, I think this is really the only way to go. I assume it canât be that slow, and it will definitely be faster than testing the Paths in a real workflow within ISC.
And another suggestion, as I donât want to open another thread: create a tool hosted by SailPoint for the tool mentioned on Connector Executed Rules | SailPoint Developer Community , so that users donât have to upload their code to third party services.
script - Ruleâs code the connector runs. This must be an escaped string. For help with formatting, use an escaping tool like Free Formatter.
We have updated our JSONpath evaluator to use the same libraries as our backend services. This means the validator is now 100% the same as our event triggers and workflows.