Bugs
Pending Incoming Sync Changes for unjoined Adapter entities don't clear when Changes Sync runs
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.
Answer
Hi Adrian,
You can configure links with a filter to remove undesirable entities. This is more efficient than using PowerShell so attempt to use filters first. See the Link Filter documentation for details on how to configure filters.
For more complicated filtering scenarios you can use the $denySync method, however you will need to add it to a pre-provisioning task, as well as the sync task. As I mentioned in a comment on the topic you linked to, changes which result in a provision are not processed by synchronization tasks.
Hi Beau,
I can't use a Link Filter because there's no way to identify them - they could be legitimate joins in the future if they ever appear in downstream systems.
Since I'm not provisioning to Lockers from this Link the pre- and post-provisioning tasks aren't relevant and shouldn't be run.
To re-iterate/clarify: these are records which have appeared in the downstream system and which have resulted in Pending Incoming Sync Changes on the Link. Provisioning to Lockers is disabled. They come through as "Incomplete" on every Changes Synchronization run, and consequently remain as Pending Incoming Sync Changes, which forces the scheduled Changes Synchronization re-process them every single time, even though there is no processing of the objects actually required.
Why are the changes incomplete? Presumably, one or more fields that are required are missing. Configure the link with HasValue filter conditions on these fields. If the entities get updated in the future then the filter conditions are satisfied and they well be synchronized. Otherwise they will be filtered out.
I was under the impression they are Incomplete because they haven't joined to a Locker (which is the intended behaviour). Since I am not provisioning into a Locker, there are no required fields in the target system (Lockers). How can I confirm what the reason is for them being Incomplete?
Ah I see. To be synchronized the source entity must have all fields used in join rules and whatever fields are marked as Required in the target schema (which the locker does not support). This has to be checked manually. But if you are correct and they are incomplete simply because they have no joined target entity, then this is the intended behaviour.
That said, how many incomplete sync changes are you regularly getting? Are you actually seeing performance issues during synchronization since these incomplete changes appeared? The impact of incomplete sync changes should be minimal, the only impact being that they are rechecked every sync cycle.
The "downstream" HR system (Chris21) is updated very frequently by the customer, since the solution is designed purely for new user provisioning (i.e. no post-provisioning field synchronization). I don't believe the performance issues were significant at the time when I logged this ticket, but I haven't logged into that system since then (3 weeks ago) so I don't know for sure. The Changes Synchronization schedule is set to run every 30 seconds.
Ok, then I wouldn't worry about it. If it becomes a problem in the future, open a issue and we'll deal with it then
OK Beau, will do. In the meantime, could you please change this from "Not A Bug" to "Won't Fix" or similar, to more accurately reflect the situation?
Thanks Matt. Leaving all adapter changes for un-joined objects as Pending Incoming Sync Changes in the Link just doesn't make sense to me. Are you sure that's what you intend for the software to do in that situation (which forces them to all be reprocessed every single time Changes Sychronization runs), or is it an unexplored outcome that hasn't been previously considered?
Matt confirmed that this behaviour is exactly what the software is intended to do and that it is operating correctly when it does this.
Customer support service by UserEcho
Hi Adrian,
You can configure links with a filter to remove undesirable entities. This is more efficient than using PowerShell so attempt to use filters first. See the Link Filter documentation for details on how to configure filters.
For more complicated filtering scenarios you can use the $denySync method, however you will need to add it to a pre-provisioning task, as well as the sync task. As I mentioned in a comment on the topic you linked to, changes which result in a provision are not processed by synchronization tasks.