1. UNIFYBroker Forum
  2. Bugs
0
Fixed

Deletes in composite adapter broken

Adam van Vliet 13 years ago • updated by anonymous 9 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.

Matthew Clark 13 years ago

Adam,

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:

Adapters

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

Composite Adapters

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 IDB-264.

Marked as resolved.

Adam van Vliet 13 years ago

Thanks.

Matthew Clark 13 years ago

Present in v4 regression test document - 3.5.4

Customer support service by UserEcho