Transaction Routing › Directory Services User Exit

Directory Services User Exit

The Client Manager Directory Services user exit is a dynamic-link library (DLL) that contains routines (or functions) to implement transaction routing.

• The Directory Services user exit was created to allow code external to the Client Manager to determine the name of the server targeted by a cooperative flow request.
• Directory Services provides accessibility to a user-defined process for determining the destination server of a cooperative flow request. The range of complexity for this user-defined process can vary depending on application needs.
• Using Directory Services helps to exploit the capabilities of the multi-connect feature of the Client Manager by identifying the desired target without user intervention.

Note: Code for a sample Directory Services user exit is provided with the Client Manager installation, in iefdir.c. The iefdir.c source code is located in the
\samples\ClientManager subdirectory of the directory where the Client Manager is installed. This code contains the description and sample usage of the Client Manager Directory Services API. Because the roles of these functions represent only a baseline behavior, the source code for the Directory Services user exit may require tailoring for the implementation of your specific transaction routing scheme. Exercise caution when modifying the user exit code. One or more of the supplied example subroutines may subject string data to modification due to the need to trim leading and trailing spaces. You must be careful when supplying strings constants to ensure they are stored within modifiable rather than read only memory.

The following examples and the Transaction Routing Flow illustration represent possible scenarios for when Directory Services should be considered:

• Multiple client applications on a workstation that require transactions to be executed on different servers. For example, for Client App1, Tran2 runs on Server1 and for Client App2, Tran3 runs on Server2.
• Single client applications on a workstation that require transactions to be executed on different servers. For example, for Client App1, Tran2 runs on Server1 and Tran3 on Server2.
• Server application deployed on multiple servers, which means the transactions are the same on those servers. For example, for Client App3, Tran4 is installed on Server2 and Server3. This scenario requires the use of NEXTLOCATION to identify the target server destination because the same transaction resides on multiple servers.

If Directory Services is not enabled or if the Directory Services user exit returns a NULL value, transactions are routed to the Default Server—if one has been specified. Otherwise, an error is returned to the DPC application.

The following diagram illustrates Transaction Routing Flow: