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.
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.
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?
Try placing your single account aggregation operation after your add entitlement operation. Hopefully, it will fetch the value after it has been updated.
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.
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.
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.
Most of the case if you use proper response mapping this issue will be resolved. if not then point 2 will resolve the issue.
@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.
@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.
@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:
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?