Bugs
Invalid link joins after adapter entity deletion leads to unjoinable locker
When an adapter entity is deleted any persistent joins remain and block subsequent joins to remediated data.
Steps to reproduce
1. Configure a Link with outbound provisioning and persistent joins configured
2. Import an adapter entity that is intended to join a locker entity, but which is missing its join criteria field value
3. The link will provision a "duplicate" record (thereby creating an internal "Join" for the newly provisioned adapter entity)
4. To clean up the duplicate, delete the SoT for the "duplicate" adapter record and update the "intended" record to have a correct join criteria field value
5. Attempt to join the locker to the newly corrected adapter entity - it fails and re-provisions the "duplicate" record again
Customer support service by UserEcho
The behaviour is unchanged after testing.
After performing the test described above the following error appeared in the UNIFYBroker log during link sync:
Source entity '67c8ea8a-4429-4e85-b512-8cadb0c81f43' value matched to target entity '72aa7126-65f6-4d50-9674-d54ee9e0bdd4', however this target entity is already connected to another source entity. '49fd0cfc-c5a1-46a4-9432-693092a4dd47'. Cannot proceed with join.". See logs for more details.
When I looked for 49fd0cfc-c5a1-46a4-9432-693092a4dd47 in the adapter it's not there - it likely corresponds to the 'duplicate' record - which no longer exists since that record was deleted in the SoT (AD) during data clean-up tasks (as per the reproduction steps above).
After I manually removed the locker join the error goes away.
Could you please investigate further?
Hi Adrian
Did your testing include clearing the locker entities? You'll need to do this to remove the bad connections first.
Hi Beau.
Yes, I cleared and reloaded the locker entities, and I created brand new connector/adapter/external system entities for the testing.
I'm seeing that connections get correctly removed when a connector import deletes an adapter entity, or when the adapter context is cleared, but not when the adapter entities are removed following a connector entity context clear.
Can you confirm whether your test procedure involved clearing the connector, and if so, can you retry either clearing the adapter entities first, or letting the connector import perform any deletes?
Hi Beau,
My test procedure did not involve clearing the connector, as this would invalidate all joins on all links and therefore require a complete initial data load process which is a significant undertaking in a production environment. To demonstrate the problem I created brand new external system entities (and therefore new connector, adapter and locker entities), and the deletion of the 'duplicate' record was initiated by deleting the corresponding AD user object and then performing a connector import.
If it's not possible to replicate the problem that I'm seeing in your environment then I could demonstrate it in the customer's DEV environment, or even make a demo video if you'd prefer that.
Hi Adrian
A new patch has been deployed to the dev environment. It should prevent invalid connections from being created by failed connector operations, as we observed in our shared session on Monday. Please test this and let me know the results.
Can you also retest the original case to ensure there has been no regression
Hi Beau,
I've done testing of a bunch of likely data remediation activities that I'd expect the customer will encounter and they all passed with flying colours. Thanks!