IdB currently logs connector imports starting and ending, but there is nothing to tie the start and end operations together. a unique identifier would provide this. This would be useful when parsing the logs to get information on the operations.

Identity Broker v4.1 allows you to specify an event log to write to. Regardless of the event log chosen, it always writes to the application log.
If a custom log is chosen, it creates the event log (if it has sufficient rights), however it doesn't write to this log.

When deleting a populated connector in the latest IDB5 build the following error is received:

An exception of type 'System.Data.SqlClient.SqlException' occurred in Unify.IdentityBroker.Connector.Engine.dll but was not handled in user code

Additional information: Constraint 'FK_ChangeLog_Partition' does not belong to table 'Changes'.

The connector is still deleted successfully.

As ToLookup will load all information in one hit, a new version should be created (StreamToLookup). Transformations should be changed to use this version (mainly group transformations).

Test to ensure they correctly page.

Shane raising this on behalf of Andre from the previous weekend.

At times during a system migration, it is useful to be able to suspend automatic import schedules for connectors whilst still being able to operate the connectors manually.

Changing a connectors agent or target table/file/etc then requesting the schema fetches the old schema. After a few minutes, requesting a schema fetches the correct schema

Hey Guys,

This request has come as a result of the deletion issues experienced at APRA on the weekend.

Is it possible to implement a feature to abort a connector import / change detection run if an unexpected number of deletes are imported?

I'm thinking something along the lines of a flag to enable/disable, and a threshold value (either a number of entities, or percentage value).
Ideally this would be configurable per connector (as some may legitimately and regularly experience large changes in existing data).

This kind of issue has happened previously on other sites, and a feature like this could prevent temporary data issues within a source system from having impact on downstream systems.

SQL server "Date" type is not supported?

I have one field of type Date in SQL server.

But on import into Identity Broker, using the default field type that is configured for the schema provider (date), validation fails.

The dashboard should have a counter for the number of connectors and adapter.

The schedule for {{DeleteChangeLogsJob }} added in v5.0.0 is not configurable. Due to different requirements for each client, the duration and frequency of clearing out change logs should be configurable.