Decouple adapter import from entity transformations
Adam van Vliet 12 years ago • updated by anonymous 7 years ago • 17
The adapter transformation process should be decoupled from the adapter import.
Allow the adapter to be configured to allow for both modes - default to decoupled mode.
The benefits would be:
- The appearance of faster imports into the identity management solution.
- Searches on the adapter space would not have to wait for transformations.
- Transformations could be performed as needed.
- Add methods to adapter to perform transform only.
- Create a job that can be added to the adapter configuration that runs the transformation after:
- The base connector has performed an import.
- A specified connector has performed an import.
- A change is due in the changes register.
- As per a schedule - regular timings.
Customer support service by UserEcho
Adapter methods done.
Next - the tasks and timings.
Reopen if further work required.
Matthew, please confirm.
Current configuration of Identity Broker does not allow reflection to happen. All adapters currently default to the AdapterImportSettings.ReflectOnRelationalConnectorPoll behaviour, with reflection only happening if:
A few changes need to be made:
Raising priority as this is now blocking the checking of
The job on ReflectAdapterOnChangeDueJob runs every 2 minutes and will reflect any adapter changes, but only if the ReflectOnChangeDue flag is present. Hence none of the relevant flags are being set on the adapter on creation.
Possible UI is a set of multiple checkboxes under an "Advanced" screen on the main adapter information page, to add the flags to the final value.
Each reflection setting has been added to the UI, see attached screenshot. This option has introduced a major race condition, however, where it would now be possible for data to be missed due to the fact that the changes register may have been updated before the adapter context, and a delta import would pull the entity and clear the change before the context is updated. See
The race condition for deltas could be addressed here by extending the Changes Available check to account for the reflection job, and not just whether or not items are in the changes table. Full imports are also affected by this condition as they may be run before the adapter context has been updated - similar behaviour exists for v3 if imports are run before change detection processing completes, resulting in the "current state" of the adapter context being retrieved (minus the changes that are still pending on the job).
For CTP, the option to reflect may be set to the CoupledProcess option, and additional addressing of this issue addressed in Beta.
The UI should provide feedback on the reflection process occurring.
The reflection settings have been set to default to CoupledProcess and are hidden on the UI for CTP.
Adam, I believe this is as complete as it can be for CTP. Assigning to you for appropriate action.
Remaining work moved to Beta
Various reflection settings will need to be covered by the regression test document as they become available.
Moved to v4.1 with
Lowering priority as currently out of scope
Work done in