Identity Broker Forum

Welcome to the community forum for Identity Broker.

Browse the knowledge base, ask questions directly to the product group, or leverage the community to get answers. Leave ideas for new features and vote for the features or bug fixes you want most.

0
Fixed

The field DateOfBirth was value 1900-01-01T00:00:00Z of type TimestampValue. Type Entity was expected..

Matthew Woolnough 11 years ago in UNIFYBroker/Learnology Life updated by anonymous 8 years ago 2
20130416,06:58:31,Adapter request to save entity to adapter space failed.,Adapter,Warning,"Adapter request to save entity 1dbf37db-5ed3-49fa-9161-ea6c9c5b1b7b to adapter space 365e6a23-2e27-485f-a6e5-52ccd3347634 failed with reason The field DateOfBirth was value 1900-01-01T00:00:00Z of type TimestampValue.  Type Entity was expected.. Duration: 00:00:00.9999360
Error details:
Unify.Framework.GroupedNameValueCollectionInvalidTypeException: The field DateOfBirth was value 1900-01-01T00:00:00Z of type TimestampValue.  Type Entity was expected. ---> System.InvalidCastException: Specified cast is not valid.
   at Unify.Framework.EntityBase`3.GetValue[TValue](TKey key)
   --- End of inner exception stack trace ---
   at Unify.Framework.EntityBase`3.GetValue[TValue](TKey key)
   at Unify.Framework.EntityToConnectorEntityBridge.GetValue[T](GroupedNameValueCollectionKey key)
   at Unify.Connectors.LifeUserConnector.SaveEntities(IEnumerable`1 entities, Action`4 preSaveAction, Action`1 responseAction, IDictionary`2 matchingEntities)
   at Unify.Connectors.LifeUserConnector.SaveEntities(IEnumerable`1 entities)
   at Unify.Framework.ConnectorToWritingConnectorBridge.SaveEntities(IEnumerable`1 entities)
   at Unify.Framework.EventNotifierWritingConnectorDecorator.SaveEntities(IEnumerable`1 entities)
   at Unify.Framework.Adapter.SaveEntities(IEnumerable`1 entities, Boolean reflect)
   at Unify.Framework.Adapter.SaveEntity(IAdapterEntity entity, Boolean reflect)
   at Unify.Framework.CompositeAdapter.SaveEntity(IAdapterEntity entity)
   at Unify.Framework.AdapterNotifierDecorator.SaveEntity(IAdapterEntity entityToSave)
   at Unify.Framework.LDIFAdapter.ExportAdapterEntity(IAdapterEntity adapterEntity, Guid adapterId)
   at Unify.Framework.LDIFAdapterServiceHostDecorator.ExportAdapterEntity(IAdapterEntity adapterEntity, Guid adapterId)
   at SyncInvokeExportAdapterEntity(Object , Object[] , Object[] )
   at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)
   at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)",Normal
0
Answered

SAP test harness cannot update infotype with subtype

Huu Tran 11 years ago in UNIFYBroker/SAP ERP Human Capital Management updated by anonymous 8 years ago 3

Monash require to write back UserID, Email and MonashPersonID as below:

  • Subtype 9008, is for FIM SAP interface on user ID and email address. Field mapping:
    Field Name Data Type length
    User ID ZZFIMINT Characters 30
    Email USRID_LONG Characters 241
  • Subtype 9009, is for Monash Person ID. Field Mapping :
    Field Name Data Type length
    Monash Person ID USRID_LONG Characters 241

When trying to test the write back permission using the SAP harness, the infotype update function does not allow to specify subtype.

0
Completed

On schema pages, allow collapsing of non-key fields

Shane Day (Chief Technology Officer) 12 years ago updated by anonymous 8 years ago 4

In order to prevent lots of scrolling on the adapter schema pages, allow collapsing of non-key fields.

-1
Completed

Alternative approach to dealing with export timeouts to IdB

Bob Bradley 8 years ago updated by anonymous 7 years ago 2

An alternative to having to change batch size/timeout settings on export, it might be worth considering adopting a similar approach that Microsoft did with the MIM (Service) MA - i.e. changing the default option to asynchronous instead of synchronous exports.

Under the current default configuration, the MIM MA gets a success returned from the MIM Service once an exported change has been successfully queued (inserted in the REQUEST - either single or batch request objects). A similar approach might be worth considering for IdB such that we can decouple long-running connector export times from the MIM export itself.

I am categorising this request under O365 because that is where I am seeing the most need for this feature right now - however this would be a generic option.

Answer
anonymous 7 years ago

Will be investigated as part of a roadmapped item on more granular and expanded set of export results - that could possibly include an export status of async/pending.