Account attribute not updating after Add Entitlement

Im using a the web services connecter with a Before Operation Rule that fires for create/update http operations.

Running into an issue where after an access request, an account attribute (“version”) is not getting updated after the entitlement is added.

Looking at the ccg logs, the “Modify” operation is being invoked and the role is successfully provisioned on the target. The response mappings are getting parsed correctly:
"Resource objects parsed: [{id=2067020921, version=f382eb72b37144013e*********}]"

But the updated “version” “f382eb72b37144013e*****” is not reflecting on the account.

Looking at this doc - there’s no info. on whether account attributes are updated after the response is mapped.

Appreciate any help!

Hi @mario_rod
Can you verify that post running a single account aggregation/full aggregation the updated values are coming in the account attribute?

Also if you can verify once that the response includes the version attribute once a update call is made. Because eventually it is looking at the response received after running that api call, and it parses the value out of there.

1 Like

Hi @neeraj99
Yes, when I run a single acct. aggregation the value gets updated (ie. the “version” gets pulled correctly).

Yes, the response includes the version attrib and that’s what I see in the ccg logs when it get’s parsed. I mentioned that in my previous post: "Resource objects parsed: [{id=2067020921, version=f382eb72b37144013e*********}]"

"version=f382eb72b37144013e*".** That’s in the JSON response and it gets parsed but what I don’t see in the ccg logs is any debug msg that shows that its trying to update the account.

Should it be performing a “Get Object” operation after provisioning the entitlement at the target? The next msg is about paging - which I don’t matters in this case?

Hi @mario_rod

Try placing your single account aggregation operation after your add entitlement operation. Hopefully, it will fetch the value after it has been updated.

1 Like

@mario_rod try to use the below after rule from mapping the response if you are not able to map the response with the ootb options

tyimport connector.common.JsonUtil; 
import java.util.HashMap; 
import java.util.Map.Entry; 
import java.util.Map; 
import java.util.List; 
import java.util.ArrayList; 
import javax.net.ssl.HttpsURLConnection; 
import java.io.BufferedReader; 
import java.io.PrintStream; 
import java.io.StringWriter; 
import java.text.SimpleDateFormat; 
import sailpoint.tools.GeneralException; 
import com.google.gson.Gson; 
import org.json.*; 
import sailpoint.integration.*; 
 
 
List list = new ArrayList(); 
Map response = new Gson().fromJson(rawResponseObject, Map.class); 
 
List Finallist = new ArrayList(); 
log.info(\"Get raw response\"+response); 
 
list = response.get(\"Resources\"); 
log.info(\"get List\"+list); 
 
    for(int d = 0; d < list.size(); d++ ){ 
      Map responseMap = (Map) list.get(d); 
 
 
        Map newmap = new HashMap(); 
        newmap.put(\"id\", responseMap.get(\"id\")); 
        newmap.put(\"displayName\",responseMap.get(\"displayName\")); 
       Finallist.add(newmap); 
  } 
 
Map updatedMapInfo = new HashMap(); 
updatedMapInfo.put(\"data\", Finallist); 
log.info(\"Get Final List\"+Finallist);
 
return updatedMapInfo;

1 Like

@mario_rod There are multiple ways we can use:-

  1. If this attribute something not schema attribute for example some application does have id created in their side then it must be handle in response mapping properly.
  2. If all the attribute you are sending from schema then you can add one more operation and there use get object so it will call first main operation and then second one.
  3. if operation response is coming like account created or modified nothing while do patch , pull or post operation then you need to have get object.
  4. Most of the case if you use proper response mapping this issue will be resolved. if not then point 2 will resolve the issue.
1 Like

@Gopi2000 you mean like this? Does the order of the operations in the UI affect the behavior (if so, where is that documented)?

@schattopadhy Thanks for the resp.
I’m curious though: Why would an “after op rule” need to be written? I can see that the response is being parsed, so what’s the purpose of that?

@neeraj99 Yes, the values are getting returned from single acct agg and full agg.
Still don’t see why the acct. attrib is not getting updated from the the parsed JSON response

@Gopi2000 Still doesn’t work
The response is getting parsed successfully with the updated “version” from the JSON resp. All I see in the ccg logs is that the paging logic for the endpoint tries to get executed. That’s it.

1 Like

@mkumariaas The attrib from the resp is getting mapped correctly and it is in the schema. I also have “Get Object” and it works fine with single acct aggregation.

@mario_rod please send me application UI and Response for Modify operation you are getting

@mkumariaas
Can you please clarify what you mean by “application UI”?

For the response - here’s the mapping/ui and ccg log showing that “version” was parsed from the response JSON with the value 1a7cf…
The only other logs after that are for paging and then logs showing that the prov plan was committed


@mario_rod response mapping u r giving root path in application then you are reading version that version name must be same schema attribute.
Also when you cretate or modify the record in target u must be getting response that repsonse want to check you can check in postman also. So that we can see if vesion is coming from response or not as you have mentioned the logs which says aggreation , as those are inside list

@mkumariaas the path is correct - which is what we’re seeing in the logs that’s it’s able to parse the version. The schema file has “version” as an attribute (and it works fine with single account agg)
Here’s the resp info:

Here’s what postman returns for “add entitlement” operation:

Hey @mario_rod,

For your Root Path, since in the response from the API the userPartials object is an array, can you try using this: $.userPartials[*]

Thank you,

  • Zach

Hi @zachm117
I will try that and report shortly - but just as an FYI - that response is getting parsed correctly per the ccg logs screenshot below (see response to @mkumariaas earlier).

No Luck - after changing the root path the response is still parsed showing the correct version attribute but still same issue - “version” is not getting up updated on the account.

Wondering…could this be related to attribute sync and the fact that “version” is not an identity attribute and is not mapped in the identity profile?