JDBC batch update exception during aggregation: Unique constraint violation

[#1]

During an aggregation, the following error may appear:

Exception during aggregation of APPLICATION: sailpoint.tools.GeneralException: an object name with 'TKIRK51' already exists.

The error was generated when the aggregation attempted to create an Identity named 'KIRK51'. It would do that when the associated correlation rule does not find the Identity the source account should be linked to. When it created it, it found that the Identity already existed.

What follows is a very simplified version of how that could happen:

Suppose you have an Identity with the following attributes:
Name: kirk51
Firstname: Trey
Lastname: Kirk
EmpID: (blank)

And then suppose you have a correlation rule that correlates the 'Employee ID' attribute from the account to the Identity attribute 'EmpID'.

Finally, suppose you have the following application account come in during aggregation:
Name: kirk51
Firstname: Trey
Lastname: Kirk
Employee ID: 51

As you can see, the correlation rule would not find a match due to the account's 'Employee ID' attribute being 51 and the intended target Identity attribute 'EmpID' (as EmpID is null). The result is that it would then want to create a new Identity and presumably call it "kirk51". It's at that point an error about kirk51 already existing.

This situation most often occurs when an Identity is created from a non-authoritative source resulting in most if not all extended identity attributes being null. This can be rectified by doing any of the following:

• Modify the existing Identity and manually insert a value that will allow it to be correlated (in this example, manually setting 'EmpID' to 51).
• Use Creation Rules to define how Identities are created and ensures they are created with values that can always correlate or ensures that the resulting Identity name is guarantied to be unique.
• Update the correlation rule to perform secondary correlation.
• Remove the existing Identity and allow the underlying link to be recreated upon subsequent aggregations (For production environments, seek other alternatives before deleting data).