IDN - Json Path Filter returns Array instead of Single value

Identity Security Cloud (ISC) ISC Discussion and Questions
, , ,
1

Hi everyone,

Encountering an issue when aggregating accounts and using filters in the json path. I saw there is a similar issue which was fixed when using workflows Changes to Workflows? Displaying arrays instead of a single value for JSONPath filtered results . I am basing the filters on Filtering Events | SailPoint Developer Community which if I understand correctly is the same json path libraries that are used in workflows as well,so at least it seems like a similar problem to me. An example of a filter:

$.items[*].workRelationships.items[?(@.PrimaryFlag == true)].StartDate

This produces the following in the list Account json
“StartDate”: [
“2023-03-01”
],
And this is how is represented via a postman call:
“workRelationships”: {
“items”: [
{
“WorkerNumber”: null,
“PrimaryFlag”: true,
“StartDate”: “2023-03-01”
}

I didn’t include the whole response but I think it is self explanatory. As long as we map the Account attributes to Identity attributes it should work fine as a criteria for Role membership but if I ever need to use Account Attributes as criteria I cannot use the “Equals” option since the value is in an array. I would have to use “Contains” which works but doesn’t seem ideal.

In order to fix it do I have to make a rule to remove the brackets or I should wait for a fix, assuming it is a similar problem to the provided link.

Thanks for your time

2

Welcome to the Developer Community Spyros!

The JSONpath implementation used by workflows is actually different from the one used by event triggers and other areas of IDN. They share many similarities, but the workflow implementation changed the behavior of arrays in JSONpath to remove the brackets for arrays with a single item. This was done to support inline variables in workflows.

I wouldn’t expect this change to be reflected in the rest of IDN since it technically alters the JSONpath standard. I recommend proceeding with the workaround you mentioned.

If you do manage to get it working via a rule, I would love if you could share that code in this topic for others to see how you solved this.

3

Hi again,

Best solution we were able to come up with is using the Json library to parse the data.

try {
  if (processedResponseObject != null) {
    for (Map accountEntry : processedResponseObject) 
    {
        Map jsonResponse = (Map) JsonUtil.parse(rawResponseObject);
        // Parse the JSON string
      JSONObject rootObject = new JSONObject(jsonResponse);
      // Retrieve the "workersArray" from the response
      JSONArray workersArray = rootObject.getJSONArray("items");
         for (int i = 0; i < workersArray.length(); i++) {
             JSONObject workerObject = workersArray.getJSONObject(i);
              // Retrieve the "workRelationships" JSON object from the worker
          JSONArray workRelationshipsArray =
workerObject.getJSONObject("workRelationships").getJSONArray("items");
          }
      }
}

Etc

I think you get the point. I can’t share all of it because it is very specific to the client. It is about an Oracle Fusion HCM target system where the OOB connector doesnt fit the use case due to data issues.

Long story short we had to parse the data using the json library and isolate the attributes. It highly depends on the source system response and data quality of course.

4

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.