Web Services Get Operation does not update the data in the Link

Which IIQ version are you inquiring about?

8.3

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 undefined ) 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 image 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?

– Remold

Hi @Remold,

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 :sweat_smile:).

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?

1 Like

Hi @Remold

Are you providing a response mapping in the web services operation for the Get-Object operation to the schema attributes?

1 Like

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 :slight_smile:
  • 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 :slight_smile: )
  • Response Mapping: without it the resourceObject would be empty :stuck_out_tongue_winking_eye:

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.

– Remold

1 Like

Anyone has an idea why the resourceObject is not processed?

– Remold

Hi @Remold

are you doing any customisation in Account Customization Rule apart from just printing the resourceObject in logs?

did you tried returning the resourceObject in the Account Customization Rule after printing it in the logs?

Thanks

The ResourceObjectCustomization rule does nothing more than:

if (object != null) log.error("object=" + object.toXml());
return object;

– Remold

I believe the “refresh” button just updates the enabled/locked status. Try it on another application and see if you get the same behaviour.

It would be nice if it updated the other account attributes.

@paul_hilchey Welcome to this community!

Hi @paul_hilchey,

Welcome to our community.

I see exactly that behaviour for my application. Will test with other applications as well.

Thanks,

– Remold

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