Specifying Connection Overrides

Connection overrides can be set dynamically or by the user. Specifying connection overrides allows the user to build a generic application and customize some settings based on the user running the application. However, for example, the LUName being used for a 3270E connection or the workstationID for a 5250 connection can be set dynamically at runtime.

To specify connection overrides on Integration Objects, the user needs to modify the code accessing the Integration Object to call the Integration Object instance methods setHPubConnectionOverrides(Properties overrides) or setHPubConnectionOverrides(String overrides) before calling the doHPTransaction() or processRequest() methods. The method sets the connection overrides for the Integration Object. When the Integration Object doHPTransaction() or processRequest() methods are called, if there are connection overrides associated with the Integration Object, a new pool for the Integration Object is created based on the Integration Object's connection pool and connection overrides in input.

The following is an example of JSP code using the IO.setHPubConnectionOverrides() method: 
<% / Set the connection overrides    
java.util.Properties overrides = new java.util.Properties();   
overrides.setProperty("LUName", "LU00001");   
// Apply overrides to the IO    
SignOn.setHPubConnectionOverrides(overrides);   
SignOn.doHPTransaction(request,response);       
// Get new IO pool name to be used in following logic   
String newPoolName = SignOn.getHPubStartPoolName();      

%>

To specify connection overrides on existing Integration Objects, without recompiling the Integration Object, the new com.ibm.HostPublisher.IntegrationObject.HPubPoolFactory class can be used. Its static create() method can be used before calling the doHPTransaction() or processRequest() methods. The method generates a new pool object by cloning the pool object in input, and applying the connection overrides to the Host On-Demand properties associated with it. The new pool name is returned and must be set in the Integration Object using the setHPubStartPoolName() method. The create() method returns null, if the pool name in input is invalid.

If the third parameter of the create method is null, then the pool name must be qualified with the ZIETrans application name. For example, the pool name should be my_ZIETrans_project/main.

The two static methods that you can use are: 
static String create(String poolName,
                     Properties overrides,
                     javax.servlet.http.HttpServletRequest httpServletRequest)
static String create(String poolName,
                     String overrides,
                     javax.servlet.http.HttpServletRequest httpServletRequest)

The methods create a new pool definition based on the named pool definition and the supplied connection overrides.

The new pool name must be set on the Integration Object using the instance method setHPubStartPoolName() before calling the doHPTransaction() or processRequest() methods of the Integration Object establishing the host connection.

The create() methods returns null if a connection definition for the supplied pool name does not exist in the project.

If the third parameter of the create method is null, then the pool name must be qualified with the ZIETrans application name. For example, the pool name should be "my_ZIETrans_project/main".

The connection overrides must be in the format "key1=value1, key2=value2" if the second method signature is used. The first method uses a standard Java™ Properties object to specify the overrides.

The following is an example of JSP code using the com.ibm.HostPublisher.IntegrationObject.HPubPoolFactory,create() method: 

<% / Set the connection overrides    
java.util.Properties overrides = new java.util.Properties();   
overrides.setProperty("LUName", "LU00001");   
// Create a new Pool based on a the default pool and the connection overrides    
String poolName = SignOn.getHPubStartPoolName();   
String newPoolName = 
com.ibm.HostPublisher.IntegrationObject.HPubPoolFactory.create    
                               (poolName, overrides, request);   
// If a valid poolName is returned, make the IO use the new pool   
if (newPoolName != null) {      
  SignOn.setHPubStartPoolName(newPoolName);      
  SignOn.doHPTransaction(request,response);   
}  
else {     
  // Error condition  
}  

%>
For chained Integration Objects to work correctly:
  • If you use the setHPubConnectionOverrides() method, the connection overrides must be set on the first Integration Object in the chain.
  • If you are using the HPubPoolFactory.create() method, the newly created pool name must be set on the first Integration Object in the chain.

With either example, the Integration Object uses a new Pool object created by cloning the original Integration Object's pool and applying the connection overrides. All the settings that apply to the original Integration Object's pool also apply to the new pool, including pooling. Connection overrides can be different for each user accessing an Integration Object. ZIETrans runtime creates a pool object for each user. These pools, created dynamically when connection overrides are specified, are destroyed when the last active connection is terminated, providing that pooling is not enabled. Connection override parameters specified on the Connection Parameter Overrides page on the Other tab in the project settings editor do not apply to Integration Objects.

Pools dynamically created when connection overrides are specified are automatically destroyed when the last active connection is terminated, providing that pooling is not enabled.

Parent topic: Programming with Integration Objects