Connectors continue to be released outside the IDM release. For the latest documentation, refer to the ICF documentation.
The connector interface declares a connector, and manages its life cycle. You must implement the
connector interface. A typical connector lifecycle is as follows:
The connector creates a connection to the target system.
Any operations implemented in the connector are called.
The connector discards the connection and disposes of any resources it has used.
connector interface has only three methods:
init(Configuration)initializes the connector with its configuration
getConfiguration()returns the configuration that was passed to
dispose()disposes of any resources that the connector uses.
ConnectorClass, which is the implementation of the connector interface, must have the
ConnectorClass annotation (Java) or attribute (.NET) so that the ICF framework can find the connector class. The following table shows the elements within the connector class.
The configuration class for the connector.
A key in the message catalog that holds a human readable name for the connector.
The category to which the connector belongs, such as LDAP, or DB.
The resource path(s) to the message catalog. If multiple paths are provided, the message catalogs are collated. By default, if no path is specified, the
The following examples show the connector interface implementation, in Java and C#.
displayNameKey = "Sample.connector.display",
configurationClass = SampleConfiguration.class)
public class SampleConnector implements Connector...
public class SampleConnector : Connector ...
Certain connectors support the ability to be pooled. For a pooled connector, ICF maintains a pool of connector instances and reuses these instances for multiple provisioning and reconciliation operations. When an operation must be executed, an existing connector instance is taken from the connector pool. If no connector instance exists, a new instance is initialized. When the operation has been executed, the connector instance is released back into the connector pool, ready to be used for a subsequent operation.
For an unpooled connector, a new connector instance is initialized for every operation. When the operation has been executed, ICF disposes of the connector instance. Because the initialization of a connector is an expensive operation, reducing the number of connector initializations can substantially improve performance.
The following connection pooling configuration parameters can be set:
The maximum number of connector instances in the pool (both idle and active). The default value is 10 instances.
The maximum number of idle connector instances in the pool. The default value is 10 idle instances.
The maximum period to wait for a free connector instance to become available before failing. The default period is 150000 milliseconds, or 15 seconds.
The minimum period to wait before evicting an idle connector instance from the pool. The default period is 120000 milliseconds, or 2 minutes.
A connection pool cleaner thread runs every minute and closes connections whose
lastUsedtime is larger than the
The minimum number of idle connector instances in the pool. The default value is 1 instance.
PoolableConnector extends the connector interface with the
checkAlive() method. You should use a
PoolableConnector when the
init(Configuration) method is so expensive that it is worth keeping the connector instance in a pool and reusing it between operations. When an existing connector instance is pooled, the framework calls the
checkAlive() method. If this method throws an error, the framework discards it from the pool and obtains another instance, or creates a new connector instance and calls the
init() method. The
checkAlive() method is used to make sure that the instance in the pool is still operational.