Share all details related to your problem, including any error messages you may have received.
With a new Web Services Application I added ‘Get Object’-operation, but it looks like the account data is not stored in the Link object when refreshing the account via Manage Accounts.
I am testing the ‘Get Object’-operation by changing the data of an account directly in the Web Services application (change email, add/remove entitlements). When I hit the refresh button (Manage Accounts → Select User → press ) the ‘Get Operation’ is called and I see the updated data is in the resourceObject (added a log.error statement in the Account Customization rule to see what the API call does), but it is not updated in the Identity Link (validated via debug). Also the details button does not show the updated data.
When making a state change of the account via Enable/Disable the correct state is reflected in the data and the details window.
Also the account aggregation task works as expected (the data of all links is updated).
Is this a normal behaviour for the ‘Get Operation’-operation? If not how can I fix this issue?
no, is not normal this behaviour.
First of all, you have the same with creation? Because, get object is called every time after a creation too.
Also, this behaviour could be depends of web service or conector.
In the first case, check if the webservice support a call to a single object(I think so, otherwise it’s an incomplete web service, but it could be, I wouldn’t be surprised ).
In the other case, the getObject operation could be the same of aggregation with the id in the endpoint.
I think, in the endpoint you have like reference $plan.nativeIdentity$, try to use $getobject.nativeIdentity$
Other questions:
Have you same before/after rule in getObject and aggregation? are the same?
Does calling a single object work on postman/insomnia?
As stated, I added a log statement in the Account Customization Rule to print the resourceObject. The resourceObject contains all updated data.
This eliminates issues with:
nativeIdentity (the correct id of the account is in the URL) I tested with both $plan and $getobject
Before and after rules are almost the same. The Account Aggregation contains additional code for paging, which is not needed for Get Object
Postman/Insomnia : shows the same data as in the resourceObject (The application has it own api-explorer and I test every step manually with this api-explorer and from within IdentityIQ )
Response Mapping: without it the resourceObject would be empty
The resourceObject contains the correct Identity Attribute (from the schema).
It feels like there is a step missing after the resourceObject is passed from the connector to IdentityIQ.