Bugs
Unable to delete connectors and adapters within UNIFYBroker
It appears there may be an issue with my current environment.
I have a set of connectors and adapters I am trying to delete due to them no longer being in use. Their entities have been cleared for quite some time (a few months at least) and I am simply trying to delete them.
I am able to delete the connectors and adapters just fine within the interface, however upon restarting the UnifyBroker service, the service will fail to start back up. Giving the following error in the event logs:
Service cannot be started. Unify.Framework.UnifyServiceStartException: The DELETE statement conflicted with the REFERENCE constraint "FK_Entity_ObjectClass". The conflict occurred in database "Unify.IdentityBroker", table "dbo.Entity", column 'ObjectClassId'.
The statement has been terminated. ---> System.Data.SqlClient.SqlException: The DELETE statement conflicted with the REFERENCE constraint "FK_Entity_ObjectClass". The conflict occurred in database "Unify.IdentityBroker", table "dbo.Entity", column 'ObjectClassId'.
The statement has been terminated.
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Bo...
I have tried this twice, so far and both ended with the same result. The first time I suspected maybe I didn't wait long enough before clearing the entities, deleting the configuration components and then restarting. However this second time the entities were cleared months ago, and when deleting the connectors/adapters I waited several hours before restarting the UnifyBroker service. So it would appear the DB has some sort of data issue preventing the deletion.
The connectors in question are just PowerShell connectors and the adapter have no transformations.
Version 5.3.2
Answer
Morning Hayden,
In this case, it appears like there's still some entity records referencing that ObjectClass, but potentially under a different partition id? When the UNIFYBroker service attempts to start, it tries to clear out any partitions that have been removed manually, which will also cascade to the Entity and ObjectClass tables.
I can recreate the issue by manually updating an entity in the database to reference an ObjectClass unrelated to its Partition, and then remove the original partition from configuration.
To investigate further, you can get the ID of the adapter you're trying to remove and run the following query:
SELECT *
FROM [dbo].[ObjectClass]
WHERE [dbo].[ObjectClass].[PartitionId] = '<adapter_id_here>'
Use the [ObjectClassId] from this response in the following query:
SELECT *
FROM [dbo].[Entity]
WHERE [dbo].[Entity].[ObjectClassId] = <your_object_class_id>
This will give you any entities that might be referencing the same object class, but for a different partition.
It's unclear under which circumstances this might happen, but could be related to config migration or a strange state where the service has been restarted while entities are still being cleared and cascades haven't finished.
If the entities returned from the second query reference a valid adapter ID, we might have to investigate further to see how to update them to point at their correctly owned object class. If they are just 'floating' (not owned by a currently valid partition) they should be safe to delete, which will then allow the system to clean up the object class and partition correctly.
Hi Matt,
Thank you for your time the other day to get to the bottom of this one.
Just to close this one off and document the result. Confirming the end issue here was the PartitionIDs in the ObjectClass table became misaligned with the service config xml (through one of the possible circumstances you have mentioned above). There were 2 object classes that were sharing PartitionIDs with 2 other object classes, one of which was also still an active adapter.
The fix, as you mentioned was to update the object's PartitionId in the ObjectClass table to align with the service config xml. After which I restarted the service to ensure it started okay, then deleted all the disabled connectors/adapters that were scheduled for removal, waited 10 minutes to ensure UNIFBroker had finished all database cleanup queries, then restarted the service once more to ensure the service started okay.
Thank you
Customer support service by UserEcho
Hi Matt,
Thank you for your time the other day to get to the bottom of this one.
Just to close this one off and document the result. Confirming the end issue here was the PartitionIDs in the ObjectClass table became misaligned with the service config xml (through one of the possible circumstances you have mentioned above). There were 2 object classes that were sharing PartitionIDs with 2 other object classes, one of which was also still an active adapter.
The fix, as you mentioned was to update the object's PartitionId in the ObjectClass table to align with the service config xml. After which I restarted the service to ensure it started okay, then deleted all the disabled connectors/adapters that were scheduled for removal, waited 10 minutes to ensure UNIFBroker had finished all database cleanup queries, then restarted the service once more to ensure the service started okay.
Thank you