From PRODUCT-7:

In order to aid diagnosis of failing processes, I think it would be a good idea for there to be a configurable option to provide detailed diagnosis information at every interface boundary within Identity Broker.

By that, I mean every Identity Broker process that has interfaces should be able to have a decorator inserted to provide details information about the methods and data provided at each step of a process. This would prevent the kinds of Product Support issues where: "I can't really tell what's going on so I suspect something is wrong with Identity Broker".

This could be achieved by implementing the interfaces of major boundaries, and logging debug information. IDB-84 (filter on log verbosity) will have to be looked at to avoid flooding the logs.

From DEEWR-55, there were difficulties using multiple fields as relationships. These difficulties will be documented in IDB-352.

It could be of benefit to be able to generate a hash of any number of fields and have this included in the schema for the connector. Could be of benefit to allow this to be used as the key of the connector, and to be used for relationships.

Obviously the UI will have to be updated to accomodate, as would the config files and adapter/factory pairs. The schema provider may have to be updated to allow for these hashes to be suggested, depending on how the configuration is done.

The hash must always calculate the same for the same input, differently should the same values be swapped between two of the fields, and be resilient to clashes.

From PRODUCT-14, the current clear database script is out of date and there isn't currently a script for v4.0.

Please change TruncatePartitionsCommandText to a .sql file and rename and move to the database directory.

Please add to the installer such that it is included like the other script.

Thanks.

For investigation, please try and reproduce the error from IDB-116 and IDB-400.

As discussed, try to get the delete individual partition and the delete script to be called. Run a SQL trace to ensure that the correct calls are being made.

Mitchell Dowd (Coffey) has mentioned the desire to limit memory usage. The high memory occurs during FIM import and is likely a result of way transformations can greatly increase the factor of data requested from the database.

Please determine what our options are.

When there is a mismatch between the number of fields in the schema, and the number of fields with a matching info type configuration, the following exception is thrown:

Mismatch in field count between entity schema and info type definitions in connector {0}

This should also specify the complete list of fields on both sides of the comparison.

When attempting to export users to MOSS, the AccountName attribute was assigned from an incorrect field, rather than a string containing the DN as assigned by the provisioning logic. A more useful error message could be returned in this case, stating that the DN is of the incorrect type.

For reference, here was the error message provided:

The extensible extension returned an unsupported error in MIIS.
The stack trace is:

"System.ArgumentException: dnComponentString
at Unify.Framework.DistinguishedNameComponent.CreateDNComponent(String dnComponentString)
at Unify.Framework.ReferenceValueToDistinguishedNameValueAdapter.Transform(ReferenceValue sourceValue)
at Unify.Framework.ChainValueAdapter`3.Transform(TBaseValue baseValue)
at ... "

As per attached email:

Adam
When investigating why my adapter join wasn’t pulling through any data I noticed the following:

Note how the startDate format varies from the endDate. Checking the schema both columns are configured as “timestamp”:

Is it possible that the value “9999-12-31T23:59:59Z” exceeds the bounds for this datatype in IdB?

The following is the raw data for the record in question (via the same PowerShell script that loads the connector, but running in debug mode) where both fields are represented as valid datetime values:

seqNumber : 1
userId : 10000167
startDate : 10/01/2014 00:00:00
endDate : 12/31/9999 23:59:59
businessUnit : U
company : AU01
countryOfCompany : AUS
lastModifiedOn : 10/07/2014 09:24:36
lastModifiedDateTime : 10/06/2014 22:24:36
userNav.userId : 10000167
positionNav.code : 50000355
positionNav.effectiveStartDate : 10/01/2014 00:00:00
employeeTypeNav.id : 12088
employeeClassNav.id : 1875
emplStatusNav.id : 1581

Thanks
Bob

Note: initial assessment only and possible workaround suggested if there turns out to be an issue here

It is possible to throw the below exception (same one as seen in IDB-1036) in the following scenarios:

• Committing an empty DN template search box and hitting Save
• Clicking on the little cross that appears when you mouse over a short template

The error is

System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: Value cannot be null.
Parameter name: value (Fault Detail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is: System.ArgumentNullException: Value cannot be null.
Parameter name: value at System.Xml.Linq.XAttribute..ctor(XName name, Object value)
at Unify.Product.IdentityBroker.TemplateDistinguishedName.ToXml(String template)
at Unify.Product.IdentityBroker.IdentityServiceCollector.UpdateAdapter(BasicStandardAdapterRemotingConfiguration adapterConfiguration)
at SyncInvokeUpdateAdapter(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.ProcessMessage31(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)).

In \Source\Web\Unify.Framework.Web.Schedules\Unify.Framework.Web.Schedules.csproj, the PrecompiledViews reference hint path is to a directory on your machine.

Could you please fix this up?

Thanks.