A number of projects involving Aurion stall for a number of reasons, mostly to do with Aurion's API.

A topic on INTIDBAUR:Aurion project risk mitigation strategies has been commenced and will hopefully be completed in the next couple of days.

However, the only successful treatment will be to eventually get enough pressure on Aurion to fix the issue at their end. Some of our workarounds will only work for small datasets, or internally hosted solutions, and some of these end up being difficult to maintain. At present, however, the impact is critical.

As all Aurion teams will now be instructed to perform some treatment by insisting the client informs Aurion of any issue, and this being enforced through the new project management office, a version of the connector that permits composition of one of the following options is required to ensure current projects are not blocked:

• A way of using the filter mechanism on the QUERY_TO_XML function to perform the same query with different filter parameters, resulting in the retrieval of all relevant data by requests that can be performed within the time-out period.
• A away of using multiple queries with the same data schema to retrieve all relevant data by requests that can be performed within the time-out period.

At no time is this to be considered a permanent resolution to the Aurion query performance issue.

The following is logged on service startup if the base connector cannot be found.

Please move the extended logging engine into the logging engine and logging engine base.

Please create a generic validation Action that is passed down to the log writer factories, that calls back into the engine. Add a validation routine that confirms the CSV writer doesn't conflict with others.

Additionally, the Identity Broker service (haven't tested console) is halting operation on attempt to browse to the Connector and Adapter page (the Home page is fine, haven't tested others). The following error is being thrown:

Logging configuration attached.

Thanks.

The IDB chris21 connector has the ability to send a filter to chris21 when querying for users.

I attempted to write a filter as described by the chris21 BRE SDK documentation but are unable to get my query to work.

The filter has the following syntax: field:operation:value:[join]

I tested the query on the test web page for chris BRE: https://localhost/Scalable/post21.htm

The following example filter works fine:

:cbr="poslst",maxlines=1,sendfields="S",filter01="posstart:<=:=T:"

But if I modify it to filter on detnumber, it doesn’t work anymore:

:cbr="detlst",maxlines=1,sendfields="S",filter01="detnumber:=:=100001"

The error I receive is:

error01="BRE353:detnumber: No connector provided for filter.",status="fail"

Any ideas how to fix my filter on detnumber?

Is there a transformation that performs a relation lookup that is capable of returning multiple values?

Currently for a client we have two tables, one has a user ID, the other a userID and an organisation name. A single User ID may be associated with multiple organisation names.

The design calls for a single adapter that has a multi value attribute on a person object listing all the organisation names to which that person belongs. The person object is the only object being flowed into the metaverse for this design.

I've had a look at two exisiting transformations:
Relation.Group (https://unifysolutions.jira.com/wiki/display/IDB306/Group+membership+relational+transformation) - This one returns multiple results, but regardless of whether Relation.Group or Relation.Group.Dn is used, the result appears to be a list of references. As noted already, we only flow the person into FIM and thus we want the actual organisation name, not a reference/DN value.

Relational (https://unifysolutions.jira.com/wiki/display/IDB306/Relational+transformation) - This can flow the actual value, but it will only flow a single value and as far as I can see, does not support output to a multivalue field.

I want to check whether there's an alternative I've some how overlooked. The connectors (one for each sql table) is a straight up unify SQL connector based around the EmpopweHR design. There is the option to redevelop this if needed to handle the work rather than an adapter, but an adapter is preferable.

When attempting to create the correct value during an export, a multivalue DN generator field throws a cast exception:

Source value in this case is a single entry: CN=Administrator,DC=UNIFY2010DEMO. The object attempting a cast is a MultiValue<StringValue> as parsed by the LDIF handling.

Adding two entities with different DNs but the same key is currently being reported as successful by the LDAP engine but is silently failing change detection, meaning that neither entity is actually committed to the connector, and no alert is displayed to the user.

If entities with duplicate keys accumulate in the change report, it might be possible to detect this and report failure on the LDAP response, avoid corruption of the connector space by committing only the entities already reported as successful, and displaying an alert to the user. This might also be an opportunity to implement user-cancellable warnings.

If the duplicate keys occur between a newly added entity and an existing entity and the DNs are different, this should be handled by rejecting the add request.

Disabled Adapters should return false on Changes available, with correct alerts on disabling Relational/Base connectors (and corresponding clearing alerts on enabling the adapter).

This is to prevent the FIM or potentially/alternatively EB logs from being flooded with resultant messages about the target adapters being disabled.

This would put the requirement on the user to be aware of the state of IDB with regards to Adapter enablement - the justification for this being that only explicit/manual changes to IdentityBroker components can disable adapters, which means that the user who should care about the adapter being disabled has already been a part of the domain of IdentityBroker in the first place.

I've created a single Powershell Connector and Adapter as per the attached documents. If I attempt to create a new MA in FIM 2010 R2, I get the following error after entering my credentials and attempting to proceed from the connectivity portion of the FIM MA config:

Unable to retrieve schema. Error: An anchor attribute defined by the extension must not be of type Reference or Boolean. A multivalued attribute defined by the extension must not be of type Boolean.

In the event log I see:

Log Name: Application
Source: FIMSynchronizationService
Event ID: 6801
Level: Error


The extensible extension returned an unsupported error.
 The stack trace is:
 
 "System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
   at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
   at Unify.Product.IdentityBroker.SchemaEntryToAttributeTypeAdapter.Transform(String schemaEntry)
   at System.Linq.Enumerable.WhereSelectListIterator`2.MoveNext()
   at System.Linq.Enumerable.ToDictionary[TSource,TKey,TElement](IEnumerable`1 source, Func`2 keySelector, Func`2 elementSelector, IEqualityComparer`1 comparer)
   at System.Linq.Enumerable.ToDictionary[TSource,TKey,TElement](IEnumerable`1 source, Func`2 keySelector, Func`2 elementSelector)
   at Unify.Product.IdentityBroker.LdapConnectionProxy.get_Schema()
   at Unify.Product.IdentityBroker.UnifyLdapConnectorTypeProxy.GetSchema(KeyedCollection`2 configParameters)
Forefront Identity Manager 4.1.3627.0"

My DN is defined as UID=UFYGuid

That UFYGuid is not one of the Boolean attributes (it is type GUID).

If I change the schema of the connector so that the two Boolean attributes are of type string, then I can proceed to create the MA without any other changes.

The following test:

        [Test]
        public void FirstOrDefaultWithNoDataTest()
        {
            using (var entityContext = CreateAndPrepareContext(PartitionId))
            {
               var firstItem = entityContext.Entities.FirstOrDefault(item => item.GetValueOrDefault<StringValue>(CreateEntityKey("NotThere")) == "Hello");

               Assert.IsNull(firstItem);
            }
        }

fails with the following exception:

System.InvalidOperationException : Sequence contains no elements

This fault should be corrected, and the above unit test included in the KnownEntityRepositoryTestFixtureBase test fixture.