- UNIFYBroker Forum
- UNIFYBroker Service
-
Questions
Customer's HR adapter has two entities for every connector entity
My customer's adapter has two entities for every every connector entity. I am not aware of what might have caused this, other than the service outage that was resolved yesterday (unresponsive UI and no data was flowing through the system).
Could you please advise what caused there to be two adapter entities for each connector entity?
Answer
The duplicated adapter entities have different DNs, and the DN is based on entity GUID. The entity GUIDs are allocated based on connector keys, so this suggests the entity keys must have changed. The entity key is based on EmployeeNumber, but the EmployeeNumbers appear to have the same value for each pair of duplicated entities. It would be helpful to know if EmployeeNumbers values are the same at the database level (i.e. don't contain a trailing space or something wacky like that).
Due to a service outage issue yesterday, the system Changes table was cleared. This table tracks pending changes to Adapter entities.
Based on an investigation by myself and Adrian, it appears that a few days ago there were some connector imports which returned 0 entities, which would have resulted in connector entities being deleted (and subsequently re-created when the next import returned entities). This would have resulted in some 'deletion' changes appearing in the change table, but not being processed due to the change backlog. By virtue of clearing the changes table, those deletions never happened - which resulted in duplicates being added to the adapter.
To resolve this issue, Adrian is going to clear and repopulate the adapter. It's also recommended to use the connector deletion threshold to avoid this issue, although understanding that a deletion threshold being reached will result in an import being aborted and should be monitored for continual threshold triggers (as this will stop data flow).
If delete thresholds being breached is a regular problem, another way around this is to use the connector primary key as the DN field for the adapter. This would require testing, but should result in adapter entities being joined to rather than reprovisioned as their primary identifier won't change if the connector is cleared and reimported.
Closing ticket as root cause has been found - feel free to re-open if further information or investigation is required.
Customer support service by UserEcho
Due to a service outage issue yesterday, the system Changes table was cleared. This table tracks pending changes to Adapter entities.
Based on an investigation by myself and Adrian, it appears that a few days ago there were some connector imports which returned 0 entities, which would have resulted in connector entities being deleted (and subsequently re-created when the next import returned entities). This would have resulted in some 'deletion' changes appearing in the change table, but not being processed due to the change backlog. By virtue of clearing the changes table, those deletions never happened - which resulted in duplicates being added to the adapter.
To resolve this issue, Adrian is going to clear and repopulate the adapter. It's also recommended to use the connector deletion threshold to avoid this issue, although understanding that a deletion threshold being reached will result in an import being aborted and should be monitored for continual threshold triggers (as this will stop data flow).
If delete thresholds being breached is a regular problem, another way around this is to use the connector primary key as the DN field for the adapter. This would require testing, but should result in adapter entities being joined to rather than reprovisioned as their primary identifier won't change if the connector is cleared and reimported.
Closing ticket as root cause has been found - feel free to re-open if further information or investigation is required.