Identity Broker 4.0

Hi Craig,

Thank you for submitting these suggestions. Responses for each are below.

COMMON TRANSFORMATIONS
Over time I have seen quite a bit of work needing to be done in SQL to prepare or cleanse data prior to Broker (or straight ILM) being involved. This may just be simple views or complex changes. Currently views need to be developed still with Broker when things could perhaps be solved with a few common simple transformations such as:

Trimming leading and / or trailing spaces
Case changes (toupper, tolower)

Based on the mission statement and business value of Identity Broker that has been set by the company, this is not something we're looking at doing right now. Although we completely understand the difficulties you face, the role of Identity Broker is to present information to an identity management system exactly as it resides in the connected system. The role of transformations is to model the data in a particular way as required by the solution, not to manipulate or modify the data in any way. We believe the correct course of action for a situation such as this is to encourage solution builders to actually fix any malformed data in the connected system, either with the identity management solution itself and the exporting of data back through Identity Broker, or manual intervention by the owners of the connected system.

Ability to specify a query (akin to a SQL view definition) when retrieving data from a SQL repository)

Are you talking about retrieving information from Identity Broker in to FIM, or from a SQL repository in to Identity Broker? The latter already has some support by way of our "Direct SQL connector" and is used extensively at QDET - see the COP connector and some of its options like "filters" and "orders".

Ability to archive / age data out of the store so the connector space is reduced (e.g. if a record is inactive for more than 90 days don't present through to the adapter interface)

How would you want to to configure this - based on a date field in the adapter? Would you configure this in the adapter itself or on the request in FIM?

Ability search for individual records rather than having to return all adaper or connector space records

Completely agree. See IDB-128 based on Eddie's earlier suggestions.

More visibility of teh transformations (I think this has already been referenced but thought I would support it)

We will be providing a new user interface that will make these easier to configure. Are you also talking about documentation that is clearer and gives examples of what each transformation does?

Better scheduling. We need to be able to schedule daily and time based delta and full loads. i.e. akin to what is being delivered with the newer Event Broker.

A number of new schedule options were added to EB 3 and have already been put in to IdB 4. EB300:Schedules talks about some of them - are there any others you would be interested in seeing?

Timing: Please at least let us work in seconds (and minutes and hours) rather than "ticks"

Identity Broker v3 already includes support for a number of other schedules, including hours, minutes and seconds. See IDB306:Timing for full details.

Better visibility around what is happenning and what is in the data repository

What are you interested in seeing - what the transformations are doing? To monitor when different operations (imports, exports, change detection, etc) are taking place?

This unclosed issue has no priority. Please specify a priority.

Most suggestions are available in v4.0/v4.1 or will be in v5.0.