We’ve encountered an interesting issue on one of our custom Web Services connector sources.
The connector will send the create account action to the source and it receives the 200 OK response (and the account in the source IS created successfully). Account is successfully correlated on the identity cube and details for the account show up correctly in the GUI.
After this, a full aggregation on the source starts and does not complete successfully, with an error.
When the full aggregation fails, the previously successfully created account correlated to the identity is deleted from the source (and hence from the identity).
IdentityNow starts sending new Create Account actions to the source, which fail because the account already exists in the source.
Some additional information:
The source in question initially responds to IdentityNow with a 429 retry-after 120 to allow the integration to obtain and prepare the data for the aggregation of the source (Boomi Integration), and will respond with the aggregation data on one of the successive retries.
Manually terminating an aggregation in progress either before or after account processing starts does not produce the same behaviour.
Has anyone else seen this behaviour? It is as though IdentityNow is considering that initial Create Account action to be a tentative success and waits for confirmation from the next full aggregation. I wouldn’t expect that a failed full aggregation should be considered grounds for invalidation of the tentative success however. The behaviour matches what would happen if the aggregation succeeded but the user list received is that of the previous full aggregation.
I believe account aggregation failure shouldn’t remove the accounts from identities. One thing you can test, set the delete threshold to 0% and run the same. If after failed account aggregation, the connector attempts to delete account - you will see in the aggregation logs, otherwise it will be known that this is not causing the issue.
Also, did you configure get-object operation on your web service source, I believe once you create an account, the connector runs get-object to fetch all attributes of the newly created account, check this one?
Good thinking on the get-object action, we do have it configured. Checking our Boomi integration API logs, I can see for one of the users that was affected that the Create-Account was sent and responded to (200 OK), the Get-Object was sent and returned the object successfully (200 OK with appropriate body) meaning that the account had received an aggregation prior to the full-aggregation failure. This implies that the fault is with the failed aggregation itself - something about the way it is failing is behaving as though aggregation has been successful but without the recently created accounts.
I’ll give your failed aggregation method a go and try a few others as well (like bogus HTTP endpoint address and continuous 429 messages) to see if I can replicate the failure behaviour.