Hi,

I have a connector named "Student" with 28k users but in the Student adapter I have at the momentL 3k entities.

The maximum entities in the adapter was 13k. 

UNIFY Broker has been fully reinstalled and the database re-created to try to fix the issue.

The logs are in Diagnostic mode, there is no error.

We are in UAT env, the same configuration is working fine in DEV and TEST environments.

Seems this has happened before - but in version 5.2.1 Revision #0 the SQL connector instances do not allow you to save comments

Sometimes SQL tables and views are not able to be modified as part of an implementation, but the next best thing would often be the use of virtual tables (i.e. a select statement encapsulated by parentheses followed by a table alias.  Presently this is not possible to configure via the UI - perhaps this is only a UI limitation and not a service limitation.

The benefits of this will be in removing dependencies on DBAs, particularly during the build phase when 3rd party SQL resource availability may be an issue (e.g. 3rd party).

When using polling with the AD connector, a new record is created for objects where any attribute that is part of the key has been changed, and the old object is not removed.  This either means that the polling functionality is not useful, or else the connector cannot be usefully used with any key other than objectGUID.

If this behaviour can't be improved then it really should be mentioned in the documentation for the connector since it's quite important.

How can I view which Adapters and Lockers objects are currently joined in the UNIFYBroker/Plus UI?

At the moment it doesn't seem to be possible to perform either an incoming or outgoing baseline sync operation on a Link - only both combined, with the order and/or parallelism of execution unspecified.

It would be tremendously helpful during environment deploy and remedial BAU activities if we had the facility to perform each operation independently, rather than having to go through hoops with prescriptive data load regimes or messing around with filters or editing PowerShell Tasks.

On various connectors and adapters with ~40,000 entities I see slow performance in the Entity Search screen - typically approximately 30 seconds to refresh and display 10 records.

This performance is consistent regardless of whether a filter is set or not - same speed even when showing just one record.

After stopped the Broker service and rebuilding all SQL table indexes there was no change in performance.

The SQL server and Broker service are on the same server, which is a VM with 4 vCPUs and 16GB of memory.  SQL is using 8GB of memory and Broker ranges from 200MB to 1GB depending on what it is processing at the time.  Entity Search performance is the same regardless of whether or not the Scheduler is enabled or disabled.

While the Entity Search screen is refreshing, SQL uses around 5-10% of CPU, and Unify.Service.Connect similarly uses around 5-10% of CPU, and the system CPU is mostly idle.  Disk activity jumps from a background maximum of around 100KB/sec to a consistent 10MB/sec while the Entity Search screen is refreshing, so this would appear to be at the root of the issue.

Do you have any suggestions how the system might be tuned to improve performance?

I have a downstream Chris21 system with outgoing provisioning enabled.  After an Import All on the corresponding Connector from Chris21, a number of changes were reflected to Chris21 Adapter, for users who were not joined to Lockers.  Those changes became Pending Incoming Sync Changes, and now every time Changes Synchronization runs they are marked as Incomplete and they are "stuck" and won't go away.  Since Changes Synchronization is configured to run every 30 seconds, this is leading to extra unnecessary processing.

I suspect a Baseline Synchronization will clear the issue, but I am awaiting further instructions and have not run it yet.

Matt suggesting using $denySync as a workaround to stop the system from processing those Pending Incoming Sync Changes, however the task doesn't seem to have visibility of those change objects.  Refer https://voice.unifysolutions.net/communities/6/topics/3862-no-entities-available-in-sourceentities-targetentities-or-joinedentities-powershell-incoming for a ticket raised to address that problem.

I have two Pending Incoming Sync Changes for un-joined Adapter objects (i.e. no corresponding Locker objects), and I added the following logging to an Incoming Synchronisation Task in order to see what data is available for those objects.  In the log file it seems the task ran twice but there were *no* entities reported at all either time, for any of the $joinedEntities, $sourceEntities or $targetEntities objects.

$Logger.LogInformation("******** DET INCOMING SYNC ********")

foreach ($source  in $sourceEntities)
{
        $Logger.LogInformation("Source Entity " + $source["detnumber"].Value)
}

foreach ($target in $targetEntities)
{
        $Logger.LogInformation("Target Entity " + $target["EmployeeID"].Value)
}

foreach ($entity in $joinedEntities)
{
        $Logger.LogInformation("Joined Entity " + $entity.SourceEntity["detnumber"].Value + "/" + $entity.TargetEntity["EmployeeID"].Value)
}

$Logger.LogInformation("********* DET INCOMING SYNC done *********")

Log file output:

When looking through the logs in UNIFYBroker, I find it difficult to associate all log messages that relate to one request that has been executed.  This is particularly difficult on a busy live system where multiple operations are happening in parallel and log entries are interleaved.

It would be very beneficial to include a request identifier on every log entry, to indicate which request the log entry relates to.  That way all the log entries for one request could be extracted and viewed separately, to give a convenient and complete picture of all of the logged outcomes of that request.  It would also make it possible to generate a high level request list summary, by extracting just the first log entry for each request.  This would be incredibly useful when investigating problems and logging voice tickets.

e.g.

There is a Job ID on some types of log entries, but most don't have it, which means it isn't really suitable for this purpose.