I have multiple Aurion Employee records for each Aurion Person. I joined on the Person Number and then selected Priority and the Date_Commenced field (which is a Date data type in the connector schema). Based on the comment in the UI saying the highest value is picked I expected the record with the latest Date_Commenced to be joined, however it picked the older record. Is this how it's supposed to work? It seems wrong to me.

I have switched to using a status field and telling it to prioritise 'ACTIVE' - however I've been told that status is manually managed in Aurion so had thought the Date_Commenced filed would be a safer option.

I have configured an IdB 5.0.4 DB connector for a SQL table. It is complaining about a column with a "-" in the name:

"Invalid column name 'NUWorkflow'. Invalid column name 'GUID'."

In fact the column name is 'NUWorkflow-GUID' which has been successfully identified by the schema retrieval.

IdB 5.0.4 RTM. In my Adapters I have both Rename transformations and Join transformations. There is a long list of attribute renames in each. I see the list in the UI but when I try to edit the list I am only shown the first one. I have had to go through the XML to make my changes.

I set a Description value on two new Aurion connectors (IdB 5.0.4) during creation but the Comment still says "A comment has not been provided". I have edited the connectors again to set the Description but still have nothing in Comment.

As well as it not being saved it would be good if the same terminology could be used in setting and viewing - either Description or Comment.

I have created a new Aurion connector with IdB 5. I have configured the Agent and successfully retrieved the schema using the "Query fields" provider.

However in the Connector I see the message "Aurion connectors require Query Mappings to be configured. Please reconfigure this connector to update the Query Mappings."

What does this mean? The documentation on creating the Aurion connector has nothing about this, when I go back into the settings there is nothing called "Query Mapping", and I couldn't find anything on jira or voice about "Query Mapping" either.

As per the header, is it possible to set the XML_FILE_PATH value when making calling the QUERY_TO_XML API via SOAP to MIM_WAMI.xml (don’t specify a path?

Hi Gents,

Found an interesting one i believe. We have been seeing the following behavior in the PROD environment out at QDET.

1. A delta import from IDB fails with due to the configured operation timeout being exceeded.

2. After the failure, no subsequent delta imports are triggered via EVB (using the IDB changes plugin as a trigger).

3. Manually triggering a delta import (with an extended timeout setting), clears the issue once the import completes. Further imports are triggered ok via EVB. (Running a Full Import also works here)

I believe the following is occurring:

1. Delta fails due to timeout in FIM.

a. The following is in the windows event log:

The extensible extension returned an unsupported error.

The stack trace is:

"Unify.Product.IdentityBroker.LdapOperationException: Operation timed out.

at Unify.Product.IdentityBroker.LdapConnection.SendRequest(ILdapRequest request)

at Unify.Product.IdentityBroker.LdapConnectionProxy.<SearchRequestPaged>d__6.MoveNext()

at System.Linq.Enumerable.<SelectManyIterator>d__14`2.MoveNext()

at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()

at System.Linq.Enumerable.<SelectManyIterator>d__14`2.MoveNext()

at Unify.Product.IdentityBroker.ExtensionMethods.Take[TSource](IEnumerator`1 source, Int32 count, IList`1& items)

at Unify.Product.IdentityBroker.ExtensionMethods.<Page>d__0`1.MoveNext()

at Unify.Product.IdentityBroker.ImportProxy.Import(GetImportEntriesRunStep importRunStep)

Forefront Identity Manager 4.1.3627.0"

b. IDB log shows the LDAP connection, followed by a connection aborted error after the timeout.

2. For some reason, the delta operation is not actually terminated within IDB. Thus when EVB tries to check for changes, the operation returns false as it thinks an import is in progress.

This is evidenced by the following. On manually running a delta import from FIM, IDB showed on the adapter that the operation had a duration of 15 hours:

I was able to trace this time back to the exact time when the first delta import operation had timed out:

So essentially it seems that because IDB thinks it's still going, it stops the IDB changes plugin from initiating subsequent operations.

We have a workaround for now - obviously increase timeouts, and run manual operations when needed.

Currently in IDB the Import and Export statistics for the last connector run are lost when the Identity Broker windows service is restarted. After a restart it makes it difficult to tell when the last run was and how long etc it took to run.

It would be a nice to have if this data was stored persistently somewhere so it was visible on the Connector page after a restart.

With EB and IdB:

Login details validation failed with the following error: "The server cannot handle directory requests." Please check your login information. There doesn't appear to be any issues with AD.

I haven't worked with the Aurion Schedule connector before. The old Design doc I'm reading (for IdB 3) states that the Schedules will disappear from ILM once they have been completed in Aurion. I can't see any filtering on date in the Adapter so would I be right in assuming the Schedules Connector only imports Schedules that haven't yet been completed?

And if so does the IdB 5 Aurion Schedules connector work the same way? I looked at https://unifysolutions.jira.com/wiki/display/IDBAUR50/Aurion+Schedule+Connector but it doesn't say.