0
Fixed

Handling of ModifyAnchor when the Identity Broker ID is being provisioned

Matthew Clark 7 years ago • updated by anonymous 3 years ago 6

The following error was thrown when attempting to provision a new user to the SharePoint Org Profile connector (which is not a ModifyAnchor connector, see IDBSP-44):

System.ServiceModel.FaultException`1System.ServiceModel.ExceptionDetail: Object reference not set to an instance of an object. (Fault Detail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is:
System.NullReferenceException: Object reference not set to an instance of an object.
at Unify.Notification.TaskNotifier`1.Dispose()
at Unify.Framework.EventNotifierModifyAnchorConnectorDecorator.ModifyAnchor(MultiKeyValue oldKey, MultiKeyValue newKey)
at Unify.Framework.Adapter.<>c_DisplayClass34.<CheckAnchorChangeOnSave>b_2f(KeyValuePair`2 keyValue)
at Unify.Framework.Visitor.<>c_DisplayClass1`1.<Visit>b_0(T item, Int32 index)
at Unify.Framework.Visitor.VisitT(IEnumerable`1 visitCollection, Action`2 visitor)
at Unify.Framework.Visitor.VisitT(IEnumerable`1 visitCollection, Action`1 visitor)
at Unify.Framework.Adapter.CheckAnchorChangeOnSave(IEntitySchema connectorSchema, IEnumerable`1 entitiesToSave, IEntityPartitionUpdatableContext connectorContext, IEnumerable`1 entityIds)
at Unify.Framework.Adapter.SaveEntities(IEnumerable`1 entities, Boolean reflect)
at Unify.Framework.A...).

This was resolved by removing the creation of the Identity Broker ID from the provisioning logic, however, there may be solutions where this is a design requirement where no other uniqueness can be guaranteed at provision time. Regarding the above, the entity was being added, so no modify behaviour should be taking place. This behaviour either needs to be corrected, or a better error message put in its place (if there is a legitimate reason a modify operation is being attempted and failing with a null reference).

Affected Versions:
Fixed by Version:

Please determine the best course of action.

Thanks.

Adam, we should try this:

  • against a passthrough adapter to a non-modify anchor connector
  • against a composite adapter with a modify anchor and non-modify anchor base connector.

Matthew, why is the ModifyAnchor call even being made in this case?

As well as not having the ModifyAnchor call being made, if it for some reason get to this point, can the error message be changed in CheckAnchorChangeOnSave?

Thanks.

Regarding the above, the entity was being added, so no modify behaviour should be taking place. This behaviour either needs to be corrected, or a better error message put in its place (if there is a legitimate reason a modify operation is being attempted and failing with a null reference).

Modify Anchor is no longer accessible on adds, and as an additional safeguard no handling will be performed if the old key is null. Issue resolved.