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.
Joins to non-existant adapter objects created when outgoing baseline syncs fail to provision in the connector
I have a customer where connector entity create fails (due to external issue on the customer side) for a number of entities during link sync, and for each one I end up with a Join showing on the Locker but no corresponding adapter entity.
For example, for a baseline sync I see: Update entities 1690 to connector AD User reported 1690 entities saved, 3 failed
After this I look at locker joins: Showing 1 to 10 of 1,693 entries
But adapter joins says: Showing 1 to 10 of 1,690 entries
This causes problems on the next baseline sync, because even though the locker is already joined (to a non-existant adapter entity) another attempt to create the adapter/connect is still made but then this error appears:
Unify.Product.Plus.JoinExecutorTargetEntityAlreadyJoinedException: Source entity '2ac4395a-2cb7-4f6e-9d80-e6a6a38994b7' value matched to target entity 'f70abdcf-4097-4d41-84a6-b0703308f16f', however this target entity is already connected to another source entity. 'fb9d3fea-9b4a-4708-a0e1-e730551ef030'. Cannot proceed with join.
I thought we worked through this and already had a patch for this issue, but I cannot work out which ticket it was in.
Could you please investigate and see what the situation around this is?
Field mapping priority not respected when Baseline sync is run on a Link
My customer has two adapters contributing data to the same locker field via two links. I have set a priority sequence for the field, but when I run a Baseline sync on the link with the lower priority mapping the field in the locker is updated with the (wrong) value from that lower priority source. Running a Baseline Sync on the link with the higher priority mapping set the locker field back to the (right) value from the higher priority source. The most recent Baseline sync to run always wins, regardless of the priority setting.
Allow manual Import and Sync operations while all scheduled operations are suspended
When the scheduler is disabled it's not possible to run Import or Sync operations. During solution development, initial data load and remediation activities it is often necessary to perform manual import and sync operations in specific orders while all scheduled other activity is suspended. To achieve this right now all connector and link schedules must be individually disabled, which can be time consuming for non-simple solutions, and comes with an increased risk of schedules being left disabled inadvertently.
Provide some way to suspended scheduled operations, while allowing manual operations to continue to work.
I suggest adding a "Manual Operations Only" flag (or similar) to the dashboard.
Outgoing pre-provisioning task is called for some joined users
In my customer's TEST environment they are seeing AD sAMAccountName being updated for existing users where the join criteria are met. The only place where the sAMAccountName is set is in the outgoing pre-provisioning task, which should not be called for existing joined entities.
I have also seen a second confirmation that the task is being called for pre-existing users: the "AD Account Creation" notifications being repeatedly sent for a large number of entities every time a Baseline Sync is performed. The only place where that notification is sent is in that same outgoing pre-provisioning task.
Invalid link joins after adapter entity deletion leads to unjoinable locker
When an adapter entity is deleted any persistent joins remain and block subsequent joins to remediated data.
Steps to reproduce
1. Configure a Link with outbound provisioning and persistent joins configured
2. Import an adapter entity that is intended to join a locker entity, but which is missing its join criteria field value
3. The link will provision a "duplicate" record (thereby creating an internal "Join" for the newly provisioned adapter entity)
4. To clean up the duplicate, delete the SoT for the "duplicate" adapter record and update the "intended" record to have a correct join criteria field value
5. Attempt to join the locker to the newly corrected adapter entity - it fails and re-provisions the "duplicate" record again
Inexplicable 'Source entity shared a join target with another source entity'
I am seeing this familiar error:
(Baseline synchronization failed with the message "Source entity '93fe60b9-05ba-4b92-b167-80738bdad66a' shares a join target with another source entity: '695411ab-e878-4ae2-9e39-f04267ac6767'. Cannot proceed with join.". See logs for more details.)
I can't see why this is the case - the join criteria is on source field 'EmployeeNumber' and those two source entities have different values:
93fe60b9-05ba-4b92-b167-80738bdad66a EmployeeNumber=145627
695411ab-e878-4ae2-9e39-f04267ac6767 EmployeeNumber=145158
Could you please look at the joins in the database and tell me what's going on internally to see if that sheds light on how this has happened?
The environment has been running for months now, untouched from an administrative perspective.
Because I can see 66 pending incoming updates on that link that aren't being processed it seems like this failure is either (a) blocking all subsequent mappings for that link, or (b) happening for 66 different joins. The customer reported that their upstream changes are not flowing through to AD.
Not enough detail to properly investigate/replicate this issue. Happy to be reopened if the issue resurfaces
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.
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.
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.
Connection-aware join not persisting for outgoing link when join criteria field value changes - new adapter entity is created and old one is left behind
When a locker's Cloud Group Name field is updated this configuration causes the creation of a new adapter/connector entity. The old adapter/connector entity is retained. After the
The functionality is needed to allow solutions to have changes to entity key/join fields flow through to downstream systems.
Customer support service by UserEcho