Bugs
Locker change not synchronising to outgoing adapter entity
An update to a locker field value is not resulting in a pending outgoing change on to an adapter entity.
The adapter entity should be joined, but the Remove Joins screen shows a DataTables Error so I can't confirm that.
Locker Entity Id = c7e8a490-6cfb-4ec1-9067-42906411aed0
Adapter Entity Id = 0645e285-577e-4218-afb6-745f1ee08600
The issue is urgent since the customer's UAT is failing due to this error.
Answer
The locker field is 'Suspend' and it is used to calculate a value for 'DisableAD' in the adapter by an outgoing synchronisation task.
The change to the locker field is not generating an pending change, which should happen well before the outgoing sync change is created.
The root cause is that incoming field value changes to locker entities from synchronisation tasks do not trigger outgoing changes.
This ticket can now be closed.
Closing as root cause has been found.
The locker uses information from the incoming and outgoing mappings and their sources to determine the entities that need syncing during a Changes Sync.
In this case, the Synchronisation powershell task was being used to read a value from the adapter and inserted into a locker schema field without being mapped in the link schema mappings. In this case, the locker doesn't know that the value has been changed. It was also then being mapped back out to another adapter in the same manner.
If there's an implementation need to map the items in powershell rather than using the normal mappings (while we would encourage considering why this is necessary), a possible workaround is to map the field through a normal mapping to the locker and back out the other side of the link. That allows the link processing to determine when the value has changed, and correctly queue an outgoing change for this item.
We've added an item to our backlog to see if there's anything we can add to the product to improve this process - such as being able to better calculate changes that may not have come in through a link mapping, or to allow sync tasks access to pre and post joined value sets so operations can be run on value changes without the script needing to also map the value.
Customer support service by UserEcho
Closing as root cause has been found.
The locker uses information from the incoming and outgoing mappings and their sources to determine the entities that need syncing during a Changes Sync.
In this case, the Synchronisation powershell task was being used to read a value from the adapter and inserted into a locker schema field without being mapped in the link schema mappings. In this case, the locker doesn't know that the value has been changed. It was also then being mapped back out to another adapter in the same manner.
If there's an implementation need to map the items in powershell rather than using the normal mappings (while we would encourage considering why this is necessary), a possible workaround is to map the field through a normal mapping to the locker and back out the other side of the link. That allows the link processing to determine when the value has changed, and correctly queue an outgoing change for this item.
We've added an item to our backlog to see if there's anything we can add to the product to improve this process - such as being able to better calculate changes that may not have come in through a link mapping, or to allow sync tasks access to pre and post joined value sets so operations can be run on value changes without the script needing to also map the value.