- UNIFYBroker Forum
-
Bugs
0
Fixed
Confirming delta imports following exports return no changes in some cases
For singular and composite adapters, successful exports do not seem to result in changes being generated, as confirming delta imports return empty in some cases.
An entity that is present in two adapters that share the same base connector - The changes table shows a change for the entity, but the "AdapterId" it is using is only the first adapter in the list.
There also seems to be an issue with items changed in a composite adapter - a successful export does not get added to the changes table for the entity ID.
Customer support service by UserEcho
Assigned to Matthew as discussed.
Update: For composite adapters, a change is added to the Changes register against the inner adapter ID. The delta does not import the change, but it does clear the change.
Items in an inner adapter are being reflected immediately. None of the decorators are passing a wrong reflect setting in, however. Currently investigating the reason why, as this is likely why no changes are returned by a delta (no differences between connector and adapter entities detected)
It appears that changes aren't being flagged to the changes table for single adapters. The reason that changes were present before is because the base connector was running every 45 seconds, and likely was responsible for adding changes to the changes table. As such, deltas are not pulling in items following exports.
The reason for the single adapter failing change detection was actually because the base CSV connector was used in a relational transformation elsewhere, and this was erroring:
Changes register item processing on failed.
Changes register item processing on connector CSV Test failed with reason The column GroupMulti cannot be used to form a chained transformation.. Duration: 00:00:00.0322266
Error details:
Unify.Product.IdentityBroker.ColumnBlacklistedException: The column GroupMulti cannot be used to form a chained transformation.
at Unify.Product.IdentityBroker.MultiValueSourceEntityDistinguishedNameGeneratorTransformationFactory.ApplyChangeDetectionColumnInformation(IAdapterColumnSources columnInformation)
at Unify.Framework.Visitor.VisitT(IEnumerable`1 visitCollection, Action`2 visitor)
at Unify.Product.IdentityBroker.AdapterEngine.CreateColumnSources(IAdapterEntityTransformationFactory factory, IEntitySchema baseSchema, Guid baseConnectorId, String adapterName, Guid adapterId)
at Unify.Product.IdentityBroker.AdapterEngine.<>c_DisplayClass27.<GenerateAdapter>b_23()
at Unify.Product.IdentityBroker.ChainedTransformationChangeProcessor.PublishChange(IEnumerable`1 changedEntities, DateTime changeProcessTime, ICollection`1 changeRecords)
at Unify.Product.IdentityBroker.ChainedTransformationChangeProcessor.ProcessChangeReport(IDictionaryTwoPassDifferenceReport`4 changesReport, DateTime changeProcessTime)
at Unify.Framework.Visitor.VisitT(IEnumerable`1 visitCollection, Action`2 visitor)
at Unify.Product.IdentityBroker.ChangeReportProcessor.CreateAndProcessReportT(IEnumerable`1 adapterTransformationProcessors, IEnumerable`1 sourceEnumerable, DateTime changeTime, Action`2 addAction)
at Unify.Product.IdentityBroker.ChangeReportProcessor.ProcessReport(IChangeReportProcessingRequest request)
Investigating effect of removing the "broken" transformation.
After removing the broken transformation, changes from the connector were again flowing correctly.
However, export changes to the adapter seem to also be reflected, with an entry added to the changes table.
The issue was difficult to find as it was caused by parallel execution of reflection when the entity was retrieved to be updated (ie. GetEntity defaults to reflect "true", and this was being executed after the entity was changed in most cases. This has been resolved by setting this to false. To be confirmed in the next build for composites, currently confirmed for single adapters.
Confirmed on composite adapters. Issue closed.