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.

Unify Identity Broker- The transaction has aborted Error
Hi,
We are using Unify identity Broker version v4.1.1 Revision #1 and one of the Connector is having below error
Import All Run
Change detection engine import all items for connector Aurion Staging Staff Details Connector failed with reason The transaction has aborted.. Duration: 00:12:00.6306978
Based on my understanding, Connector is timing out if it's runs more than 10mins and I'm unable to find the set timeout threshold field limit in Identity broker. Can you please confirm where it could be set or is there option to set the version we have.
Thank you
Below is from the logs
Direct communicator Exception occured after [00:10:18.3617284] duration. System.Transactions.TransactionAbortedException: The transaction has aborted. ---> System.TimeoutException: Transaction Timeout --- End of inner exception stack trace --- at System.Transactions.TransactionStateAborted.BeginCommit(InternalTransaction tx, Boolean asyncCommit, AsyncCallback asyncCallback, Object asyncState) at System.Transactions.CommittableTransaction.Commit() at System.Transactions.TransactionScope.InternalDispose() at System.Transactions.TransactionScope.Dispose() at Unify.Framework.Data.AdoNetDataControl.ExecuteDataSetQuery(DataSet resultSet, String commandText, IEnumerable`1 parameters, String[] tableNames, CommandType commandType) at Unify.Framework.Data.AdoNetDataControl.ReturnDataSetQuery[T](String commandText, IEnumerable`1 parameters, String[] tableNames, CommandType commandType) at Unify.Product.IdentityBroker.DirectCommunicatorBase`1.GetAllEntitiesDataTable() at Unify.Product.IdentityBroker.DirectCommunicatorBase`1.GetAllEntities() |

Hi Abhishek,
The timeout for the database connector can be set on the agent that is used for that connector. In this case that appears to be the SQL server agent, which has a configuration setting for Operation Timeout.
You can find details on that configuration here: SQL Server Database Agent / UNIFYBroker knowledge / UNIFY Solutions

Understand change detection better
I have these adapter transforms set up:
Changes to the EmployeeNumbers attribute should flow through the following other attributes in this order:
- MemberADUPNs (first MVG transform)
- MemberAzureUPNs (PowerShell transform)
- MemberAzureIDs (second MVG transform)
Sometimes when EmployeeNumbers values are updated I see MemberADUPNs and MemberAzureUPNs updating correctly, but MemberAzureIDs does not update with the new value like it should.
Q1. Is this because "PowerShell transforms break change detection"? i.e. UNIFYBroker doesn't know that it needs to run the second MVG transform to update MemberAzureIDs, because it has no way to know that that MemberAzureUPNs may be updated by the PowerShell transform?
Q2. Could Beau's new "Register-Contribution" cmdlet be used in the PowerShell transform to make it so it does?

Flag to configure UNIFYBroker/Plus to delete adapter entities with incomplete joins
If an adapter has an incomplete entity on a link (i.e. no matching locker entity for the join criteria) then currently UNIFYBroker reports a warning. In many circumstances it would be appropriate to delete the adapter entity in this situation, to ensure the external data source was kept in sync with the locker. Add a configuration flag to enable this functionality.

Warnings have been improved in this process. However, it wouldn't make sense to delete adapter entities with incomplete joins, as it's valid for multiple links to point to the same adapter - even from multiple lockers. This could result in adapter objects being incorrectly removed.
An approach could be to configure a locker where entities are provisioned based on the criteria that you expect the end adapter to only have entities for, and then add a link to point to your adapter with outgoing deprovisioning enabled. This would deprovision adapter entities if they no longer meet the expected criteria, which would allow a much clearer view of why entities are being deleted and under which conditions.

Add ability to recreate deleted future-dated adapter changes (Time Offset Flag etc)
In ticket https://voice.unifysolutions.net/en/communities/6/topics/4238-time-offset-flag-didnt-re-evaluate-when-date-threshold-was-passed?redirect_to_reply=21889# Beau mentions that:
Add functionality to recreate deleted future-dated adapter changes to the UNIFYBroker UI (and API).
This should also be called automatically after a Clear Adapter Changes operation completes, because it is unlikely that there are any conceivable scenario where future-dated changes should not be restored, and without them UNIFYBroker does not operate sensibly (i.e. expected transforms silently fail to trigger when the configuration suggests they should).
Also, update the Clear Adapter Changes documentation in Voice to indicate that after running Clear Adapter Changes some transforms will no longer work correctly until Clear Precalculated Entities is run or all relevant date fields on all adapter entities are updated.

This has been implemented and is available in the release of UNIFYConnect V6, which will be made available shortly.

Time Offset Flag didn't re-evaluate when date threshold was passed
I have the following Time Offset Flag adapter transformation configured:
For the problematical entity the EndTimestampUTC field is "4/22/2021 12:00:00 PM" (i.e. midnight at the start of April 23rd in my customer's timezone - NZ), so the corresponding UTC timestamp for the threshold comparison should be "5/7/2021 12:00:00 PM" (i.e. midnight at the start of May 8th in NZ timezone). EndTimestampUTC was changed to that value on May 7 (i.e. before UTC 5/7/2021 12:00:00 PM) but even though today is now May 10th the PostEndPlus14 field hasn't been re-evaluated to "Yes" as I would have expected (i.e. transition from the ">" case to the "<" case).
To allow a better chance to debug I have not run a Generate Changes on the adapter yet.

How soon will temporal transformations (e.g. Time Offset) be re-evaluated after the current date and time changes?
How soon will temporal transformations (e.g. Time Offset) be re-evaluated after the current date and time changes?

Baseline Sync calling connector entity update for all entities even when there are no value changes
When a Baseline Sync runs on a link the connector's update export functionality is called to update every entity, even when there are no field value changes. This places an unnecessary load on UNIFYBroker and performs null updates against the external system for no discernible reason, and since UNIFYBroker/Plus is unable to sync any other links while this takes place can result in unnecessary processing delays while the connector is busy effectively doing nothing.

This has been implemented and is available in the release of UNIFYConnect V6, which will be made available shortly.
Internal value comparison happens on assignment of a value to an entity schema field, so while the workaround provided by Shane above would still help, the engine performs the same check on assignment as well.

Return a more helpful error when an adapter accessed via ODATA is not enabled
When an non-enabled adapter is queried via ODATA the endpoint returns a 404 error. A different error with some descriptive text would make it easier to work out what has gone wrong.

This has been implemented and is available in the release of UNIFYConnect V6, which will be made available shortly.

Duplicated join target for NULL field value where there is no target with that field value
I am seeing: Baseline synchronization failed with the message "Source entity 'b5d56da5-a8af-4088-b98c-4b78a693b093' shares a join target with another source entity: 'fa457ecd-b5a7-4708-886b-747ca82da40a'. Cannot proceed with join.". See logs for more details.
Both source entity have a join field value of NULL, and there are no target entities with a join field value of NULL.
I tried deleting entities and reloading them, but the error remains. The mapping of field values through to other locker entities is not happening, and I would like to know if the join failure is the cause of this.

Hi Adrian
As the error message says, both of those source entities have the same join target, which may or may not exist until provisioning occurs. If the schema fields you're using can contain nulls and you want the sync to progress I'd recommend adding a Has Value filter on the join fields.

PowerShell connector operation timeout
Add a feature to allow a timeout to be specified for a PowerShell connector operation (Import All, etc). When the timeout expires, forcibly kill the PowerShell operation and log an error.
This came up because a connector hung for ten days in a UNIFYConnect environment until I noticed. All of the other connectors in the same connector exclusion group were blocked from running as well. I suggest a default timeout of one hour for most operations and 10 minutes for Import Changes.

This has been implemented and is available in the release of UNIFYConnect V6, which will be made available shortly.
Customer support service by UserEcho