Managing connections

HATS defines two categories of connections; transformation connections and background connections. A transformation connection is used in creating Web-based transformations of a host connection. Transformation connections can also be used to record a macro. HATS V4 supported a single transformation connection. HATS V5 and V6 have support for background connections in addition to the single transformation connection. A background connection is used by an Integration Object or a Perform macro transaction. Background connections can be different connection instances to the same host as the transformation connection, or can be connections to entirely different backend hosts. Background connections allow you to interact with other hosts. You may gather data, enter data or exchange data between hosts via pre-recorded macros. This data can be combined with the transformation connection as well. In this way, you can automate transactions on other hosts as well as transform the default connection for your end-users.

VT hosts (VT52, VT100, VT420_7 and VT420_8) are limited to background connections. If you use the VT connection as one of the project's background connections, it can be used for recording macros and running Integration Objects. For more information, see Perform macro transaction.

Creating a connection

The new Create a Connection wizard enables you to create more connection configurations. To access this wizard, you can use the context menu in the HATS Project View, the New > Connection selection in the HATS menu, or click the Create a HATS Connection icon on the toolbar.

The wizard requires basic connection information such as host name, port, terminal type, code page and screen size.

The Host name and Port number fields are entry fields. You can change the name of the host to which your connection connects or the port number through which you connect by typing over the name and number that appear in these fields.

Host On-Demand (HOD) version 8 included Internet Protocol version 6 (IPV6) support. WebSphere Application Server version 6 also provides IPV6 support. HATS allows you to configure an IPV6 address so that you can take advantage of this functionality on the platforms where it is supported.

Note:
HATS can only support IPV6 on Linux, Solaris and AIX. There are limitations in the Windows studio environment with IPV6 addresses. Therefore, you will not be able to use the host terminal feature or test on a local test server if you use this type of address.

The session Type, Code page, and Screen size fields have drop-down lists from which you can select certain values for the fields.

Notes:

  1. The values for screen size change depending on the code page and type of host session you select.

  2. If you select a bidirectional (bidi) code page, see Enabling the user to reverse the screen direction.

You can also specify some advanced connection settings using this wizard or the connection editor. The advanced connection settings that are shown will depend on your connection type. If your connection is 5250, you will be able to configure your workstation ID. If you use a 3270E connection, then you will be able to configure the LU or pool name. There are no LU or workstation ID settings support for VT connections or 3270.

When defining a 5250 connection in HATS, you have four options for specifying the workstation ID. Choose one of the following:

None (server assigned)

Click this if you want the Telnet server to assign the workstation ID. This option can be used with pooling.

Prompt end user

Click this if you want to prompt the user for the workstation ID. If pooling is enabled, this option should not be used.

Use a specified value

Click this if you want to supply a string from which the workstation ID is created. This option can be used with pooling if a wildcard workstation ID is specified.

Workstation ID parameter for 5250 connections can use wildcard characters. The workstation ID defines the name of the workstation. The first character must be A-through-Z, $ (dollar sign), @ (commercial at sign), or # (number sign). The remaining characters can be A-through-Z, 0-through-9, $, @, #, . (period), and _ (underscore). If you do not complete this field, a workstation ID is automatically assigned by the host. The HATS Server can generate a new and non-arbitrary workstation ID for a session. Keywords and special characters in the workstation ID field can cause some or all of the following information to be substituted into the workstation ID value that is sent to the Telnet server:

  • short Session ID(*)

  • Session Type ID(%)

  • Collision Avoidance ID(=)

When specified, the Collision Avoidance ID enables the generation of a new workstation ID if the telnet server rejects the previous name (which can occur when the old name is already in use on the i5/OS(TM) server).

Wildcard combinations in the workstation ID field allows the HATS Server to automatically generate more ID variations for achieving connection acceptance from the host. This decreases the time required for session connection, as it decreases the number of times the host must reissue a request to the client for valid workstation ID.

Wildcard characters can be specified multiple times in the workstation ID field in any combination with other alphanumeric characters. (For example: N=A=M=E, NAME==, etc.) With each use of the wildcard, you decrease the likelihood of generating a workstation ID already claimed by another session:

  • Use of two [=] results in approximately 1 in 50 chances of duplicating an established ID.

  • Use of three [=] results in approximately 1 in 300 chances of duplicating an established ID.

  • The number of unique names generated is approximately 36N, where N is the number of equal signs [=].

For example: Given the input of NA=ME for workstation ID, the one [=] can trigger generation of 36 unique IDs that use the alphanumeric characters specified (N, A, M, E). Adding a second [=] can trigger generation of approximately 1296 unique IDs, etc.

Use an HTTP session variable

Click this if you want to specify the contents of the HTTP session variable as the workstation ID. If pooling is enabled, this option should not be used. You can also use wildcard characters in the specified string. The wildcard character is an asterisk (*). For more information, see Workstation ID.

Connection editor

The connection editor enables you to perform custom configurations to your connections and has the following tabs: Overview, Basic, Advanced, Screen Handling, Security, Pooling, Macros, User List, and Source.

Overview

The Overview tab of the connection editor summarizes most of the connection settings you specified when you created your connection. The only item you can modify on this tab is the description of your connection.

Each of the section headings on the Overview tab is a link to the other tabs of the connection editor.

Basic

Under the Basic tab are the general settings initially set up with the Create a Connection wizard. Following is a list of settings that can be modified.

  • The name of the host to which your connection connects. This is either the name or IP address of the Telnet server.

    Host On-Demand (HOD) version 8 included Internet Protocol version 6 (IPV6) support. WebSphere Application Server version 6 also provides IPV6 support. HATS allows you to configure an IPV6 address so that you can take advantage of this functionality on the platforms where it is supported.

    Note:
    HATS can only support IPV6 on Linux, Solaris and AIX. There are limitations in the Windows studio environment with IPV6 addresses. Therefore, you will not be able to use the host terminal feature or test on a local test server if you use this type of address.

  • The number of the port through which the connection connects. Typically, port 23 is used, but the administrator of the Telnet server might have modified the port number.

  • The type of host session for the connection, such as 3270, 3270E, 5250, VT hosts (VT52, VT100, VT420_7 and VT420_8).
    Note:
    HATS can only support 3270, 3270E, and 5250 connection types for the default connection. A background connection can be of any type.

  • The code page used for the connection. Select the code page for your backend host.

  • The screen size of the host connection. The screen size defines the number of rows and columns in the host screen.

  • Three check boxes to specify:

    • Only allow single connection with each user ID

    • Abandon attempt to connect after a specified number of seconds

    • Abandon attempt to disconnect after a specified number of seconds

Advanced

To specify print support as well as any other HATS connection session parameters, define these parameters in the Advanced section. The print support settings are used only if the connection is the default connection.

Select the Enable print support check box if you want print support.

For 3270E hosts, if you select the Enable print support check box, you can choose the paper size, page orientation, and the print font you want to use for printing jobs. See Defining print support for your project for more information.

If you have a 3270E host, the Advanced tab will also allow you to specify a LU or Pool Name for your connection.

For 5250 hosts, if you select the Enable print support check box, specify the URL of the iSeries(TM) Access for Web Printer Output window. The default URL is http://hostname/webaccess/iWASpool, where hostname is the name of the 5250 host. The end user of your application can set print options in the IWA Printer Output window. See Defining print support for your project for more information.

Note:
Print support in not available for 3270 connections and VT connections.

If you have a 5250 host, the Advanced tab will also allow you to specify a Workstation ID for your connection. For more information, see Workstation ID.

You can add, modify, or remove any IBM WebSphere Host On-Demand session parameters using the buttons to the right of the table of parameters. If you click Add, you can select a parameter using the drop-down list next to the Name field and then type a value into the value field. For more information, go to the Host on Demand information center at: http://publib.boulder.ibm.com/infocenter/hod9help/.

Screen Handling

The Screen Handling tab allows you to determine how a blank screen is handled at connection startup and how screen settling is handled. These settings only apply if your connection is used as the default connection.

When the connect application event processes the obtain default connection action, HATS will attempt to connect to the legacy host to get a connection. If this connection attempt is not completed successfully, the application will end with an error page. If the connection attempt does complete successfully, the legacy host screen is allowed to settle according to the screen timers specified on this page. These timers are also used to settle the host screen at the completion of a custom screen recognition event, the blank screen application event (if configured), and the unmatched screen event. For a detailed description of screen-settling algorithms and settings, refer to Appendix A. HATS screen-settling reference.

If blank screen is received at connection startup allows you to choose what to do if the legacy host screen remains blank after successfully connecting to the host, and allowing the host time to settle the screen as explained above. Your options are:

Wait until connect timeout before termination with an error

This option causes HATS to terminate the application with an error page if the legacy host screen remains blank after successfully connecting to the host.

Show blank screen

This option causes HATS to proceed with screen recognition processing even if the legacy host screen remains blank after successfully connecting to the host.

To ensure that a blank screen is not shown to your end users, you may specify a screen recognition event in the Event Priority list for processing a blank screen, or you may add actions to the Blank screen Application Event to handle a blank screen. By default, the Unmatched screen application event will present the end user with the blank legacy host screen. For more information on screen recognition events, refer to Screen customization priority. For more information on application events, refer to Application Events.

Send the host key

This option will send a host function key to the legacy host if the connection remains blank after successfully connecting to the host. This key will be sent once, the screen will be allowed to settle, and then HATS will proceed with screen recognition processing. You can choose which key to send from the drop-down list. This option is useful if your legacy host always draws a blank initial screen, and end users must submit a particular function key (SysReq, for example) before the host will present a new screen.

Screen timers allow you to configure the length of time to wait for the legacy host to complete sending its screens to the HATS runtime. To understand when these timers are used, refer to Appendix A. HATS screen-settling reference. You can specify the following:

Minimum time to wait for initial host screen:

The default is 2000 milliseconds. This is the minimum amount of time that the application waits for the arrival of initial screen updates after the host connection becomes ready. Increase this amount if the host is slow to send the first screen, even if the connection has been in the ready state for some time.

Maximum time to wait for the screen to settle:

The default is 1200 milliseconds. This is the maximum amount that the application waits for the arrival of screen updates after the initial screen update. Increase this value if the host is slow to send the contents and you receive frequent partial screens.

Maximum time to wait for screen to settle (session using asynchronous update):

The initial default value is 400 milliseconds. You should increase this amount if the host is slow to send the screen and you receive frequent partial screens. This value can also be lower than the Maximum time to wait for the screen to settle if the browser specific settings are set to Refresh for Asynchronous Update in the Other tab of your Project Settings.

Security

The Security tab contains information on Secure Socket Layer (SSL) and Web Express Logon (WEL). Select the SSL enabled check box to enable SSL. If SSL is enabled, you can import the required certificate file by clicking Import. You can select the Use Web Express Logon check box and then click Configure. For more information on security settings, see Security and Web Express Logon.

Pooling

A pool is a group of host connections that are maintained in an initialized state, ready to be used without having to create and initialize them. This reduces the response time when starting and running an application.

You can enable pooling by clicking the Pooling tab and selecting the Enable pooling check box. If pooling is enabled, after the connection is released and determined to be in an acceptable state as defined by the checkin screen definition, it is kept in a list of active connections. When a new request for a connection is received, one of these idle pooled connections is used. If connection pooling is disabled, after a connection has been released, it will be disconnected. If there are no idle pooled connections, a new one may be created based on other pool settings such as maximum connections.

Because there is no guarantee that an end user navigating screens on the transformation connection will navigate back to the checkin screen, it is recommended that you do not use pooling on the HATS transformation connection. Pooling is efficient and effective for background connections used by Integration Objects or used in perform macro transaction actions, since these automated navigations can be programmed to navigate back to the checkin screen.

You also have the option of setting your Connection Timeouts and Connection Limits.

  • For Connection Timeouts, select: Terminate connection after a maximum idle time and/or Terminate connection after a maximum busy time check box(es) and enter the time in seconds.
    Note:

    • Terminate connection after a maximum busy time can also be used outside of pooling

    • Maximum busy time should be set to the same value for all connections within a HATS application.

  • For Connection Limits, enter the Minimum number of idle connections to retain in the pool and/or the Maximum number of connections in the pool that can be active in the text box(es).

    You can also decide what should be done After the maximum number of connections has been reached. You can either Create a new (non-pooled) connection by checking the radio button or Wait for an available pooled connection and set the limit to the time to wait by selecting the Limit the time to wait for a pooled connection to a maximum number of seconds check box and entering the time in seconds in the text box. Leave the check box unchecked to wait indefinitely for a connection.

Macros

The Macros tab shows information about the Connect macro, the Disconnect macro, and the checkin screen. Both macros are optional. This information is on a separate tab from the pooling information because these macros can still be applied even if pooling is disabled.

Select the connect and disconnect macros from the Connect macro and Disconnect macro drop-down lists.

A Connect macro is run automatically when the connection is initially created. The only prompts allowed in a connect macro are those that can be satisfied by a user list. If pooling is enabled, the connect macro will be run when the HATS server initializes, otherwise the connect macro will be run when a user makes the first request to the HATS application (usually in the Connect event).

Note:
If you need to have an automatic sign-on macro run using the end user's credentials, you can add a play macro action to the connect event instead of using a connect macro here. Macros run using the play macro action can satisfy prompts interactively or with global variables initialized during the start event, for example.

A Disconnect macro is run automatically when the connection is destroyed. No prompts are allowed in a disconnect macro. If pooling is enabled, the disconnect macro will be run when the HATS server is shut down, otherwise the disconnect macro will be run when the HATS application releases the connection back to the system (usually in the Disconnect event).

A Checkin screen describes the screen a connection must be on to be placed into the pool. It is only enabled if pooling is enabled. Typically, the checkin screen is the same as the exit screen of the connect macro, and this also matches the entry screen of the disconnect macro.

The checkin screen section will be available only if you have enabled pooling on the Pooling tab. If you have enabled pooling, the checkin screen section has three options:

  • Use first exit screen of Connect macro. This is the recommended option.

  • Use a specific screen of Connect macro where you have the option of selecting a screen macro from the drop-down list.

  • Use different screen recognition criteria based on a previously captured screen allows you to use different screen recognition criteria for the checkin screen based on a previously captured screen which you select from the drop-down list.

You can also specify recognition criteria for the checkin screen. For instructions on how to define screen recognition criteria, see Screen Recognition Criteria.

Note:
A poorly-defined checkin screen will render your pool useless. Adding definitive recognition criteria is highly recommended.

For more information on macros, see Macros and Host Terminal. If you use a connect macro, you can set up a user list to specify the list of users who can use the connection.

User list

The user list is a list of users and passwords that can be used by a macro. User profiles from the user list can only be used in the connect macro. During the creation of a macro the user ID and password in the user list can be pulled from the list and placed into the user ID and password fields in the session. This allows a predefined list of user IDs and passwords to be used so that the user does not have to know or type in a user ID and password on the screen.

The User List tab displays a table of user profiles with the capability to add, edit, or remove any one of them.

If you click Add , you will be prompted to provide the user ID, a description, and password. All of these fields are required and any of these fields can be modified by clicking Edit. You can also delete the entry by selecting it and clicking Remove.

Clustering and user lists

When you create multiple instances of WebSphere application servers running HATS applications and sharing the same application files, you can use user lists on multiple-logon hosts without any special considerations. However, there are special considerations for the use of user lists with single-logon hosts:

  • In vertical clustering, where application-related files are not physically copied to each application server but are merely represented in memory, you cannot use user lists. This restriction exists because every application server running HATS would need a user list for its exclusive use; but in fact there is only one user list.

  • In horizontal clustering, where multiple copies of an application are running in separate application servers, modify the user list in each copy of the application so that no two copies have a user ID in common.

Source

You can configure all connection editor settings manually by going to the Source tab and using the built-in editor. See Source for more information.