1.1 Understanding Drivers

The Identity Manager engine processes all data changes that occur in the Identity Vault or a connected application. For events that occur in the Identity Vault, the engine processes the changes and issues commands to the application via the driver. For events that occur in the application, the engine receives the changes from the driver, processes the changes, and issues commands to the Identity Vault.

Drivers connect the Identity Manager engine to the applications. A driver has two basic responsibilities: reporting data changes (events) in the application to the Identity Manager engine and carrying out data changes (commands) submitted by the Identity Manager engine to the application. Drivers must be installed on the same server as the connected application.

Identity Manager stores drivers and library objects in a container called a driver set. Only one driver set can be active on a server at a time. However, more than one server might be associated with one driver set. Also, a driver can be associated with more than one server at a time. However, the driver should be running on only one server at a time. The driver should be in a disabled state on the other servers. Any server that is associated with a driver set must have the Identity Vault installed on it.

For detailed information about Identity Manager components involved in data synchronization between the Identity Vault and the connected system, see Section A.0, Data Synchronization Flow.

1.1.1 How a Driver Works

Figure 1-1 illustrates the data flow between Identity Manager and a driver object.

Figure 1-1 Driver Dataflow

The Identity Manager engine uses XDS, a specialized form of XML, to represent events in the Identity Vault. Identity Manager passes the XDS to the driver policy, which consists of basic policies. The Driver uses a specialized form of XDS called <driver-operation-data>. The <driver-operation-data> element encapsulates the metadata and a payload.

When an event occurs in the Identity Vault, Identity Manager creates an XDS command to represent that event. Identity Manager passes the XDS command to the driver policy. The driver policy transforms that XDS command with an output transformation policy.

This output transformation policy generates the <driver-operation-data> that includes commands, URIs, methods, and payload information for the driver’s request to the application shim. The shim then converts the <driver-operation-data> into a connected application’s specific language for example, XML, JSON, etc., to communicate with the connected application.

When the request completes, the driver processes responses and reports the status of the completed operation to the Identity Manager engine or the Identity Vault.

On the Publisher channel, the driver shim receives the response from the connected application and converts the input into the <driver-operation-data> format. Then, using the input transformation policy, the driver converts the request to an XDS event and reports back to the Identity Vault.