Deletes in composite adapter broken
Adam van Vliet 11 years ago • updated by anonymous 8 years ago • 3
The check to confirm that a delete has succeeded has regressed Identity Broker.
In a composite adapter, entity ids don't have to belong to the adapter being visited, and as such the error will occur for every delete performed.
If the adapter containing the deleted entity is first in the configuration, the delete will succeed, but report back a failure when an exception in thrown in another adapter.
If the adapter containing the deleted entity is not the first in the configuration, the delete will fail and report back the failure.
Customer support service by UserEcho
Adapters and composite adapters both delete successfully. The following are examples of errors thrown when delete attempts are made on entities not in the repository:
Attempt to delete entities from adapter Microsoft SharePoint Adapter (1c278344-7ada-4f6c-ab78-78261f955df1) failed - Requested entities not all present in the connector repository. Ids: 1c278344-7ada-4f6c-ab78-78261f955df0
Attempt to delete from composite adapter failed. Not all requested entities were present in the entity repository. The following number of entities were deleted from each composed adapter:
Microsoft SharePoint Adapter (1c278344-7ada-4f6c-ab78-78261f955df1) - 0 deletes
Microsoft List Adapter (81d386df-df83-49ae-b337-3634b004842d) - 0 deletes
CSV Adapter (0335b677-899f-4a3b-9dea-f0b4093d311b) - 0 deletes
Requested entities: d5251d7d-05cc-4d35-916e-e99e06b9ffd2
I have tested these locally against single and composite Chris21 and SharePoint adapters. See
Marked as resolved.
Present in v4 regression test document - 3.5.4