0
Fixed

Changes in adapter fields projected from a relational connector do not trigger changes

Ross Currie 9 years ago updated by anonymous 5 years ago 9

PJ: See BCE-80 for initial discovery and comments for current progress.

Affected Versions:
Fixed by Version:

Originally reported on BCE-80. Configured local instance of Identity Broker using only the problem adapter and CSV connectors in place of the underlying eMinerva connectors. Using data provided by Ross I was able to replicate the problem - changes in the base connector are picked up as expected, but not if they are mapped from another connector. Examination of the database and subsequent performance of a full import in FIM proves the connectors are importing fine and the transformations are coming up with the expected result.

This afternoon, Nick spoke to Adam and I about a similar problem in his NIM/chris21 environment with persons' managers' details not being updated. Having examined the environment and tried connecting to the same Identity Broker instance with an existing FIM installation, we've determined that the problem is likely identical to this one. This is even more serious in NIM as there is no possibility of running a full important to reconcile the data.

Implemented a fix on Thursday which worked locally, but is currently not working in Nick's environment - however, I suspect I may have applied the patch incorrectly and am currently using a number of tools (such as Fusion Log Viewer) to try and narrow down the problem.

Further testing has revealed that only part of the problem has been fixed - the eMinerva testing data works (as taking the patch our proves) but not with the more complicated chris21 data. Different relational transformations are being used, so will start by debugging there.

Patrick, I spent a bit more time of this today and think I can show you a problem that still exists in the VMs that I have for SA Water. Here is what I think is happening:

I have a CSV connector that reads in a file containing the following: ManagerEmployeeID and Subordinate EmployeeID; I am using a Relation.Group transformation to add the subordinate employeeID to the manager's person record.

The subordinates appear in the IdB Management Console but do not get presented to NIM as a change. Ithink this is quite similar tothe previous issue whic you have fixed. Here are the relevent excerpts from the IdB configuration files:

C:\Program Files\UNIFY Solutions\Services\Extensibility\ConnectorEngine.extensibility.config.xml

<!-- CSV Import -->
<connectorconfiguration configuration="readingAndWritingConnector">
<connector connector="CSV" id="

{a47567fe-9f9a-44b6-bb36-f80f5453173c}" name="CSV Import">
<entitySchema>
<field name="MgrEmployeeID" validator="string" required="True" readonly="True" />
<field name="SubEmployeeID" validator="string" required="True" readonly="True" key="True" />
</entitySchema>
<image></image>
<file>C:\Program Files\UNIFY Solutions\CSV\Sub.csv</file>
</connector>
<getAllEntities>
<timing name="Never" />
</getAllEntities>
</connectorconfiguration>

C:\Program Files\UNIFY Solutions\Services\Extensibility\AdapterEngine.extensibility.config.xml

<adapter name="Relation.Group"
InputKey="detnumber"
RelationshipConnectorId="{a47567fe-9f9a-44b6-bb36-f80f5453173c}

"
RelationKey="MgrEmployeeID"
RelationReference="MgrEmployeeID"
GroupTarget="CC-DirectReports">
<dn>
<dnComponent name="Field" key="SubEmployeeID" attributeType="UID"></dnComponent>
</dn>
</adapter>

Change the method MembershipListEntityDistinguishedNameTransformationFactory.DetermineChangeTimes to:

IEnumerable<IReportTime> changes
	= (from entity in report.ChangedEntities
	   select new ReportTime {EntityId = entity.EntityId, Timestamp = lowerLimit}).Cast<IReportTime>();

report.ReportTimes.UnionWith(changes);

return report;

This fixed the issue for me, but I have not added it to source control as there is a change missing from EntityDistinguishedNameRelationMapperValueAdapterFactoryBase.cs.

I'll have to check with Patrick about this and I'll get the change out as soon as possible.