Creation of a new Connector:

Connection String - window very small by default. Can we have it so its possible to fit a typical connection string in without wrap-around?

Event Broker allows for an Adapter ID Override, but this couldn't be done in IDB4 without taking the ID from the URL or from the Extensibility; would it be worthwhile including a label with the adapter id?

PJ Edit: Update logging to display adapter/connector name as well as id, and ensure standard adapter display shows GUID.

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.

It would be handy if relational transformations started out with all columns in their column mappings, or a shortcut to do so. You don't always want to pull all columns from a relational connector, but in the cases you do it would be quite useful.

When deleting attributes from the connector schema, the whole screen refreshes rather than just removing single line.

User needs to scroll back down to bottom of page to make further changes.

Another improvement would be to have the edit text boxes and drop downs only appear on mouseover, as this would clean up the UI a bit.

Would like to have SQL Table hints support, specifically for NOLOCK, but other options might also be useful.

If you disable a connector, the job keeps running & there appears to be no way to stop it running except for restarting the IdB service.

Viewing IdB logs shows you oldest items in logs at top.
Typically user looks at logs to view recent information. User needs to navigate to bottom and click last to show most relevant objects.
This is opposite to default view on Windows Event Viewer.
I think I already wrote an enhancement for changing and sorting by relevant column, as can be done in previous versions of IdB.

Consider the potential for updating relational data through a single core adapter. Need to consider:

• Adds vs. Updates
• If adds, default values
• User expectations
• What it means if Join criteria aren't met (adds or exception)
• Supported transformations
• 1:1 vs. 1:many

Currently the extensibility options for log writers involves a new product life-cycle.

It could be of benefit to create a PowerShell log writer.

It would be good if it kept around the PowerShell context and the script (if possible) for a certain amount of time or activity, in a similar way to the transformation on IDB-839.