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.
Reflect change entities to adapter errors about duplicate entries when there are are no duplicate key values in the connector.
I've been having issues on particular PowerShell connectors/adapters in UNIFYBroker where reflecting change entities to the adapter is complaining about duplicate entries when there are are no duplicate key values in the connector.
The schema setup between the connectors and adapters is an ID key in the connector that is then used within the adapter as the DN. So it is a very simple DN template. E.g:
Name Type Key Read-only Required
AccountName String True True True
Distinguished Name Template CN=[AccountName]
The issues are generally fixed by clearing and repopulating the whole adapter, which is not a repeatable solution since it happens on a weekly basis, sometimes more often.
These errors also don't seem to happen after an obvious failures on the connector side, which is what I have previously attributed these issues to. All these connectors have deletion thresholds setup of at least 50%.
Its like broker seems to get itself tied up even though the schedules in the environment have been reduced to the point where only 1 operation is interacting within and with broker at a time.
SQL maintenance is also performed frequently and the SQL instance has plenty of resources allocated.
Version details: v5.3.2 Revision #0
Any help would be appreciated as this has been a long ongoing issue that I've seen across multiple environments.
Adapter
Adapter eb42757f-2f23-4228-928e-993942b0c050 page errored on page reflection. Duration: 00:00:21.5551444. Error: Unify.Framework.UnifyDataException: Duplicate DNs detected on adapter eb42757f-2f23-4228-928e-993942b0c050. Reflection failed. Duplicate DNs: CN=<obfuscated name>,OU=sIAMGroups,DC=IdentityBroker, CN=<obfuscated name 2>,OU=sIAMGroups,DC=IdentityBroker.
at Unify.Product.IdentityBroker.DuplicateDnDetector.DetectDuplicateDns(IDictionaryTwoPassDifferenceReport`4 report)
at Unify.Product.IdentityBroker.Adapter.ReflectChangesInner()
at Unify.Product.IdentityBroker.Adapter.ReflectChanges()
at Unify.Product.IdentityBroker.AdapterAuditingDecorator.ReflectChanges()
at Unify.Product.IdentityBroker.AdapterNotifierDecorator.ReflectChanges()
at Unify.Product.IdentityBroker.ReflectAdapterOnChangeDueJob.b__9_0(IOperationalAdapter adapter).
Error details:
Unify.Framework.UnifyDataException: Duplicate DNs detected on adapter eb42757f-2f23-4228-928e-993942b0c050. Reflection failed. Duplicate DNs: CN=<obfuscated name>,OU=sIAMGroups,DC=IdentityBroker, CN=<obfuscated name 2>,OU=sIAMGroups,DC=IdentityBroker.
at Unify.Product.IdentityBroker.DuplicateDnDetector.DetectDuplicateDns(IDictionaryTwoPassDifferenceReport`4 report)
at Unify.Product.IdentityBroker.Adapter.ReflectChangesInner()
at Unify.Product.IdentityBroker.Adapter.ReflectChanges()
at Unify.Product.IdentityBroker.AdapterAuditingDecorator.ReflectChanges()
at Unify.Product.IdentityBroker.AdapterNotifierDecorator.ReflectChanges()
at Unify.Product.IdentityBroker.ReflectAdapterOnChangeDueJob.b__9_0(IOperationalAdapter adapter)
Adapter Request to reflect change entities of the adapter.
Request to reflect change entities of the eMinerva Student: Groups (eb42757f-2f23-4228-928e-993942b0c050) adapter errored with message: Duplicate DNs detected on adapter eb42757f-2f23-4228-928e-993942b0c050. Reflection failed. Duplicate DNs: CN=<obfuscated name>,OU=sIAMGroups,DC=IdentityBroker, CN=<obfuscated name 2>,OU=sIAMGroups,DC=IdentityBroker.. Duration: 00:00:59.9516712
Error details:
Unify.Framework.UnifyDataException: Duplicate DNs detected on adapter eb42757f-2f23-4228-928e-993942b0c050. Reflection failed. Duplicate DNs: CN=<obfuscated name>,OU=sIAMGroups,DC=IdentityBroker, CN=<obfuscated name 2>,OU=sIAMGroups,DC=IdentityBroker.
at Unify.Product.IdentityBroker.DuplicateDnDetector.DetectDuplicateDns(IDictionaryTwoPassDifferenceReport`4 report)
at Unify.Product.IdentityBroker.Adapter.ReflectChangesInner()
at Unify.Product.IdentityBroker.Adapter.ReflectChanges()
at Unify.Product.IdentityBroker.AdapterAuditingDecorator.ReflectChanges()
at Unify.Product.IdentityBroker.AdapterNotifierDecorator.ReflectChanges()
at Unify.Product.IdentityBroker.ReflectAdapterOnChangeDueJob.b__9_0(IOperationalAdapter adapter)
UNIFYConnect update threshold/safety catch
A UNIFYConnect customer has requested the ability to implement a safety catch feature to stop updates if they are over a certain threshold. I know that Broker/BrokerPlus has a safety catch feature for entity deletion thresholds, but does anything currently exist for updates? Ideally this would be a check that if the number of changes on a link are over X amount it stops the sync, disables the schedules for that link, and then throws an error in the logs to be picked up via the monitoring/alerting.
The only topic I could find on this at the moment is Safety Catch Feature / UNIFYBroker Forum / UNIFY Solutions.
Attribute changes don't trigger pending sync changes on a link if they are processed in a powershell task on the link
I have noticed that if a link has a PowerShell task on an outgoing sync task that modifies and sets attributes in the target, then a change flows through to only that attribute modified in the PowerShell task, then the link doesn't pick it up as pending sync change. Only running a baseline sync on the link would trigger the PowerShelltask to change/modify that attribute.
Discussion was had with Matt Davis on the possibility of using the Register-Contribution function on a link for the attributes that are being modified through the PowerShell task to then recognise changes for those entities. However it is unsure whether the Register-Contribution function is available for links or not. As an alternative, the PowerShell script can be used on the adapter in a reverse transform, which triggers on outgoing sync changes from a link to a connector. Then the contributing attributes can be sync as direct mappings in the link.
Link Baseline sync still able to be run from Links page when link is disabled.
I have noticed that under normal operation, a baseline synchronization task on a link cannot be executed while the link is disabled. In the link UI, the option to run a baseline sync only becomes visible when the link is enabled. However I have found that on the Links page (that lists the links in the solution) selecting a disabled link and running a baseline sync through the Actions button at the top of the page still executes the baseline sync on the disabled link. Not sure if this is expected behaviour or is a bug.
Screenshot #1: Running a baseline sync task on a disabled link through the Actions button:
Screenshot #2: The baseline sync still executed even though the link is disabled:
Clarification of the Register-Contribution function
Hi,
Just seeking some clarification about how the "Register-Contribution" functions on PowerShell Schema transformations and what scenarios this applies to.
For example, if I have 2 fields Field1 and Field2 and apply the function like: "Register-Contribution Field1 Field2". Does this mean that a change to Field1 will trigger reprocessing changes of any transformations for Field2?
Also, would I be correct in assuming that this can be used to help process Time Offset Flag transformations where there may not necessarily be a change to retrigger evaluation of the flag?
Thanks,
Liam
Hey Liam,
There's a good explanation on this ticket which might help: https://unifyvoice.userecho.com/communities/6/topics/5330-time-offset-flag-not-re-evaluated-when-current-time-passes-source-field-timestamp
But essentially Field1 is a field you're creating with your powershell schema, and Field2 is an existing field which is used in calculating the result of Field1. You can call Register-Contribution multiple times on the same field, if more than one field contributes to it (see the detail at the bottom of this response)
The main use case for this is to allow automatic change detection through powershell transformations. Prior to this feature, the Broker change detection engine didn't know what the powershell script was doing - which fields were being used, and which fields were being output. Therefore, it had no way of knowing whether a change for a field should result in a change for another field.
So if you're using time offset flag transformations, where the input to your transformation is the result of a powershell script, then yes - this feature is the main use case. If you're using a time offset flag transformation with normal field mappings, then this transformation should already generate future dated changes for reprocessing even if there's no other adapter changes to trigger this.
It was something added as a patch in 5.3, and we've yet to do a documentation pass to add updated doco for it (we've got a draft ready for 6.0)
Some more technical detail on the contribution specifically which might help:
The signature of Register-Contributionis:
Register-Contribution -fieldName <string> -contributingField <string>
where fieldName is the name of the new field created with New-Field, and contributingField is the name of a pre-existing field that contributes to the new field in some way. This can be called multiple times for new fields that are contributed to from multiple pre-existing fields.
For example:
New-Field 'convertedValue' 'int'; New-Field 'joinedTS' 'timestamp'; Register-Contribution 'convertedValue' 'origValue'; Register-Contribution 'joinedTS' 'date'; Register-Contribution 'joinedTS' 'time';
Note that for most, normal usage of the PowerShell conenctor it won't be necessary to register field contributions. Time Offset Flag and Business Day Offset Flag transformations which use generated fields are the main reason why this would be needed.
Jobs Stuck Processing
Hi,
We have observed jobs such as Connector imports and Link synchronization will occassionally get stuck in a processing loop and not complete. This causes a block in operations as Broker cannot import or synchronize new data. To clear the process a restart has to be performed. Attempting to cancel the job does not have any impact.
This happens intermittently and doesn't appear to have a consistent way of reproducing the issue. I understand this makes it difficult to troubleshoot the issue, so is there other possibilities for a solution we could explore? For example, could there be a timeout introduced so that the job is killed if it runs over a period of time without closing?
Let me know your thoughts and feedback.
Thanks,
Liam
Link Synchronization not triggering
In UNIFYConnect test environment when attempting to perform a baseline synchronisation or delta changes synchronisation, the buttons seemingly do nothing when attempting to trigger on the link. The link is between a CSV connector/adapter and a locker with about ~10k entities. Nothing else is currently running, all other link schedules are disabled and no connectors are importing, nor are any change reflect options are running.
When I click a button to sync the page refreshes like it has executed but nothing else happens. Nothing appears under the "Recent Jobs" section of the link page and it logs 2 messages in the log:
23/Jan/2024 23:29:28
Information
Link Request to manually queue a baseline synchronization job on link started.
Request to manually queue a baseline synchronization job on link Managed User > AD User started.
23/Jan/2024 23:29:28
Information
Link Request to manually queue a baseline synchronization job on link completed.
Request to manually queue a baseline synchronization job on link 'Managed User > AD User' completed. Duration: 00:00:00.0310830
Is there a way I can see what is stopping the sync operation from executing? Let me know if you need more information.
Thank you
A user-interface could not be located for this agent type.
Hi Team,
We are currently doing environment updates at a site and at the same time updating their UNIFYBroker version from 5.3.1 Revision 4 to the latest version 5.3.4 but are running into issues. The customer also has the Google Apps connectors installed in there environment, but the latest version that I can see available which I have installed is 5.3.2.
The install is successful and the service starts however when validating components in the UNIFYBroker interface I noticed the following errors occurring.
On the Google Agents the following error is produced:
A user-interface could not be located for this agent type. The list of known types are:
Unify.Agent.FTP (FTP Agent)
Unify.Agent.SSH (SSH Agent)
Unify.Agent.SqlServerDatabase (SQL Server Database Agent)
Unify.Agent.OracleDb (Oracle Database Agent)
Unify.Agent.OleDb (Ole Database Agent)
Google (Google Agent)
On the Google Connectors the following error is produced:
A user-interface could not be located for this connector type. The list of known types are:
Unify.IdentityBroker.Connector.Google.Calendar (Google Calendar)
Unify.IdentityBroker.Connector.Google.DomainContact (Google Domain Shared Contact)
Unify.IdentityBroker.Connector.Google.OrgUnit (Google Org Unit)
Unify.IdentityBroker.Connector.Google.Group (Google Group)
Unify.IdentityBroker.Connector.Google.UserSettings (Google User Settings)
Unify.IdentityBroker.Connector.Google.User (Google User)
Unify.Connectors.PowerShell (PowerShell Connector)
Unify.Connectors.Direct (Database Connector)
Unify.Connectors.CSV (CSV Connector)
Unify.Connectors.Placeholder (Placeholder Connector)
I saw a similar issue mentioned on a previous ticket regarding Aurion connectors where an incorrect version was being used and I am figuring something similar could be happening here.
Thank you
Thanks Matt, that helped me find the issue.
Issues was the IIS site was pointing to the standaloneweb directory where it should be pointing to just the web directory. Repointing and doing an IIS reset got it working as expected.
Thank you
Aurion Query Attribute Order
Hi,
I've had a question from the customer regarding the queries the Aurion connector uses to pull data via the WSDL.
Does it matter if extra attributes that are not included in the schema/mapping are added to the query and does it matter what order the attributes are returned in the query?
Thanks,
Liam
Hey Liam,
No - extra fields aren't an issue. The Aurion connector uses the configured schema and mappings as the source of truth for which fields to read. So when iterating through the results of the query, each schema mapping row is attempted to be read from the results and set on the entity if it exists. So if the schema mapping doesn't exist on the query it will just skip over it, and extra ones that might be returned from the query will just be ignored if they're not in the schema.
There's also no order requirement - the query results come back in blobs of XML, and we just iterate over the results retrieving the required elements. So the connector code has no expectation of order.
Change detection engine import all items for connector Aurion Person failed with reason -25 (see UNIFACE message guide)
Hi,
I am trying to add the Employee_Number field from Aurion Person to a connector so that I can do write-back.
However, I am encountering the following error on Import All:
My mapping and schema is as follows:
Do you have more insight on what error -25 is?
Thanks,
Liam
Customer support service by UserEcho
