0
Completed
Introduce Synchronous connector operations
The current implementation of connector operations only allow for asynchronous calls; however the current implementation of Event Broker requires synchronous calls for the error event to function.
Either Identity Broker needs to support Synchronous/Like-Synchronous operations or a contract needs to be defined in EB to support an equivalent if timeouts are going to be a problem.
Customer support service by UserEcho
This issue potentially has dependencies on ECMA2.0.
ECMA2.0 requires reporting of some description. This might be achieved with the following pattern.
http://www.developerdotstar.com/mag/articles/troche_taskpattern.html
If this is how it's done, then this might expose hooks that EB can use for synchronous operations.
Example code to run import all:
Example code to run polling import:
Adam, I believe this can be resolved.
The asynchronous connector methods exposed over the RESTful API seem to provide the functionality that will be required by
EB-661.Regarding the question of the Changes Available approach, the current method is now useless and can be safely replaced with the use of the LDAP Changes Operation (once the Sorting control is added to the LDAP Engine).
A question arose about the timeliness of operations and how that may affect changes, such as if a connector is importing and the adapter context is being updated. The LDAP Changes Operation uses the modified timestamp from the Changelog. The Changelog will only be updated once the adapter context has been updated for the entity. The Changes table itself will no longer be relevant or usable in presenting externally that the adapter should run an adapter import. In the case where a connector import is running, the adapter will complete its import, and the changelog will be updated with the missing entities afterwards, meaning nothing gets lost in processing.
Marked as resolved.