As discussed with Curtis:
Recently at DET (and at TAFE) we have experienced some issues with IDB where one or more entities in the Adapter get out of sync with the entity state on the associated MA in FIM. This results in a few error conditions:
Delta imports of entities in this state usually present with a staging-error on the MA.
Exporting changes to entities in this state usually results in an error similar to this:
Internal Server Error #9: Unify.Product.IdentityBroker.LDAPModifyException: Cannot add the value 43-61-72-6D-65-6C to the existing, non-multivalue field SAFE-MiddleName. at Unify.Product.IdentityBroker.LDAPModifyRequestToEntityConverter.HandleAttributeValueAdd(IModifyRequestOperation op, IAdapterEntity entity, IEntitySchema schema) at Unify.Product.IdentityBroker.LDAPModifyRequestToEntityConverter.Transform(IRfcModifyRequest sourceValue, IAdapterEntity origEntity) at Unify.Product.IdentityBroker.ModifyRequestHandler.InnerApplyTransformation(IHandleRequestCoreRequest request, LDAPModifyRequestToEntityConverter converter)
The advice to-date on how to resolve this issue is "run a full import/full sync" or alternatively "clear the entity from IDB and re-import". While both of these actions usually work, they aren't always a valid/practical option in an operational environment. (Here at DET, running a Full Import/Sync on SAFE consumes most of the day, and block all other operations while it's running.)
I was discussing this issue with Curtis, and he suggested that a change to the FIM Adapter might be possible to address this. Essentially adding in some logic to identify and flag records that have failed with either a staging error on import, or specific IDB related export errors (Likely text file store in the MA data directory).
Then on the next delta import, any existing records that are flagged could be requested and supplied as a full object, in order to re-sync it's state with FIM.
Does this sound feasible?
Customer support service by UserEcho