Ideas
0
Completed
Improve handling of composite adapter lookup in LDIF adapter ExportChanges
Matthew Clark 12 years ago
in UNIFYBroker/Microsoft Identity Manager
•
updated by anonymous 9 years ago •
5
See SSICT-101. An environment with a composite adapter containing three adapters - 50000 entities in the first, 38000 in the second, and 50000 in the third. The third was requiring an update to a single field and was taking 4-9 seconds per object. This was alleviated by changing the order of the adapters such that the third adapter was made the first.
This is because the LDIF reading in the LDIF adapter relies on TryGetEntityByDN to get the object class of the object. This is done because LDIF spec does not contain the objectclass field for updates. An improvement to this interface is required in order to allow exports in larger, time-sensitive environments to run in an efficient manner.
Customer support service by UserEcho
Spend a couple of hours looking at this one, logic will likely be in the composite adapter only, i.e. find all matching entities then filter by partition.
Reassigned for confirmation of completion, to be confirmed during regression.
Confirmed logic.
Issue found during regression testing.
Breadcrumbing logic not handled generically, behaviour needs to be extrapolated into set implementation for the connector context/change reports.
Unit tests need to be added to assert the correctness of this behaviour.
I have made the update, are you able to confirm the fix?