Bugs
0
Planned
Field mapping priority not respected when Baseline sync is run on a Link
Adrian Corston 3 years ago
in UNIFYBroker/Plus
•
updated by Matthew Davis (Technical Product Manager) 2 years ago •
12
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.
Customer support service by UserEcho
Hi Adrian
Not seem the same behaviour, personally. Can you provide your extensibility configuration, and the version of Broker and Plus this is occurring in.
Do you know if this also happens with changes synchronization , or only with baselines?
Hi Beau, I do not know if this happens with changes synchronisation as well.
Hi Adrian,
Do you happen to have an update on this?
Hi Matt, not yet. It's a blocker on the Adaptalift UAT so will be circling back very soon. The Tower demo took priority, now pre-sales work has taken priority.
Hi Adrian,
Config looks OK. Can you provide an example of the adapter values for this field? I have been able to replicate this issue with both sync types but only when the higher priority value is null and the lower priority is not. Is this the case for here?
The adapter DateCommenced fields and the locker DateCommenced field are all of type String. The adapter values are set by PowerShell transforms. Both links have set priority. The value for the higher priority link (Aurion Pending Employee) is "2022-01-07". The value for the lower priority link (Aurion Employee) is "2018-09-17". So it is NOT the case that one value is NULL and the other isn't.
When I run Changes Sync the problem doesn't occur - but that's simply because there are no pending sync changes to process so nothing happens.
I set up a simple test case with configuration equivalent to the problem I'm seeing (two links, both set priority, different string values) but I could not replicate the problem, so it looks like there is some non-obvious aspect of the Adaptalift TEST UNIFYConnect configuration or data that is necessary to replicate the issue. Perhaps David could provide you a copy of the UNIFYBroker database?
Thanks Beau.
This is a bit tricky now. Because the customer (Adaptalift) needed to go ahead with UAT I discussed with Shane and he approved me changing the configuration to emulate the field mapping priority mechanism for the affected fields (over 20 of them) in a PowerShell task instead. However this has made the configuration rather inelegant so I am eager to revert back if we're confident the patch will work. The customer is currently working on the last stages of UAT in that environment and wants to finish it this week, so I'll need to talk to them and find out if they can pause while we work on it.
Fair enough. It should be enough to clear the locker and re-baseline everything, as the bad state causing the issue should only come about from adding fields with existing entities. If that works for you, I'll save the database change for a future release.
Amazing work to find the root cause, by the way. You are great at your job! :)