IDM 7.2.2

Connector interface

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.

The connector interface has only three methods:

  • init(Configuration) initializes the connector with its configuration

  • getConfiguration() returns the configuration that was passed to init(Configuration)

  • dispose() disposes of any resources that the connector uses.

The 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.

Element Description

configurationClass

The configuration class for the connector.

displayNameKey

A key in the message catalog that holds a human readable name for the connector.

categoryKey

The category to which the connector belongs, such as LDAP, or DB.

messageCatalogPaths

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 connector-package.Messages.properties is used.

The following examples show the connector interface implementation, in Java and C#.

  • Java

  • C#

Connector Interface Implementation in Java
@ConnectorClass(
    displayNameKey = "Sample.connector.display",
    configurationClass = SampleConfiguration.class)
public class SampleConnector implements Connector...
Connector Interface Implementation in C#
[ConnectorClass(
    "connector_displayName",
    typeof (SampleConfiguration)
    ]
public class SampleConnector : Connector ...

Implement a poolable connector interface

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:

maxObjects

The maximum number of connector instances in the pool (both idle and active). The default value is 10 instances.

maxIdle

The maximum number of idle connector instances in the pool. The default value is 10 idle instances.

maxWait

The maximum period to wait for a free connector instance to become available before failing. The default period is 150000 milliseconds, or 15 seconds.

minEvictableIdleTimeMillis

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 lastUsed time is larger than the minEvictableIdleTimeMillis.

minIdle

The minimum number of idle connector instances in the pool. The default value is 1 instance.

A 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.