---
title: Connector interface
description: Connectors continue to be released outside the IDM release. For the latest documentation, refer to the OpenICF documentation.
component: pingidm
version: 7.2
page_id: pingidm:connector-dev-guide:connector-implementation
canonical_url: https://docs.pingidentity.com/pingidm/7.2/connector-dev-guide/connector-implementation.html
section_ids:
  implement_a_poolable_connector_interface: Implement a poolable connector interface
---

# Connector interface

|   |                                                                                                                                                                                   |
| - | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|   | Connectors continue to be released outside the IDM release. For the latest documentation, refer to the [OpenICF documentation](https://docs.pingidentity.com/openicf/index.html). |

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 OpenICF 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

```java
@ConnectorClass(
    displayNameKey = "Sample.connector.display",
    configurationClass = SampleConfiguration.class)
public class SampleConnector implements Connector...
```

Connector Interface Implementation in C#

```csharp
[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, OpenICF 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, OpenICF 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.