        |  |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
Telnet Connect User's Guide
CHAPTER 6
This section discusses certain features available in the Telnet Connect designed to maximize performance of deployed services.
The overall performance of any service that uses back-end connectivity is usually dependent on the time it takes to establish a connection and begin interacting with the host. Obtaining the connection is "expensive" in terms of wait time. One strategy for dealing with this is connection pooling, a scheme whereby an intermediary process (whether the app server itself, or some memory-resident background process not associated with the server) maintains a set number of preestablished, pre-authenticated connections, and oversees the "sharing out" of these connections among client apps or end users.
Connection pooling overcomes the latency involved in opening a connection and authenticating to a host. But in terminal-based applications, a considerable amount of time can be spent "drilling down" through menu selections and navigating setup screens in order to get to the first bonafide application screen of the session. So even when connections are reused through pooling, session-prolog overhead can be a serious obstacle to performance.
Composer addresses these issues by providing connection pooling, managed by a special kind of component (called a logon component) that can maintain an open connection at a particular "drill-down" point in a terminal session, so that clients can begin transactions immediately at the proper point in the session.
Logon Components are useful in several types of situations:
When you have a need for multiple tiers of pooling based on multiple security challenges within your system. (For example, users may need one set of logon credentials to get into the network, another to get into the mainframe, and another to get into database.) Serial log-in requirements may dictate the use of multiple logon components.
When your service needs stateful "session-based" connections.
When you need the performance advantages available through connection pooling.
If performance under load is not a high-priority issue and your connectivity needs are relatively uncomplicated, you may not need to use Logon Components at all. But there is no way to know if performance is adequate merely by testing services at design time, on a desktop machine.
Components and services built with the Telnet Component Editor may appear to execute quickly at design time (in Animation Mode, for example). But in real-world conditions—which is to say under load, with dozens or even hundreds of requests per second arriving at the server—session overhead can be a significant factor in overall transaction time. The only way to know whether you need to use the special performance enhancement features described in this chapter is to do load testing on a server, under test conditions that mimic real-world "worst case" conditions.
When you install the Connect for Telnet, two types of Connection Resources are added to the Connection creation wizard:
The Telnet Connection is a true terminal connection and (when used by a Telnet component) can establish a session with a host system. This is the connection-type we have been using throughout this Guide.
The Telnet connection resource is designed to make an individual connection to the host on an as-needed basis. The connection is made just-in-time and discarded as soon as the client is done. It is not reused in any way.
The Logon Connection, on the other hand, is different. It defines a pool of User IDs and passwords, each of which can make its own connection. The Logon Connection also serves as an indirection layer to allow clients to connect to the host at exactly the point in the host program (exactly the screen) where the client needs to start. This entry-point-location behavior is made possible by the Logon Component. (A Logon Connection always uses a Logon Component to get to the actual connection.) The architecture is shown in the graphic below.
A Connection Resource is always required in order to get to the host. (This is true for any Composer service that uses Telnet components.) For simplicity, this diagram shows the Connection Resource going directly to the host; in the real world, there may be intervening delegation layers for security purposes.
The Logon Component contains Actions (an action model) designed to find a particular screen of interest in the host program. This drill-down location is the effective entry point of the transaction for any upstream process that uses this Logon Component. You can think of the Logon Component as a go-between between the physical connection (represented by the Connection Resource) and the logic layer (represented by the Telnet Component itself.
In order for a Telnet Component (at the top of the diagram) to use a Logon Component, it needs to enlist the aid of a Logon Connection resource. The Logon Connection is the bridge between the Telnet Component and the Logon Component.
The kinds and responsibilities of the various objects discussed above are summarized in the following table.
The Logon Connection differs from the ordinary "host-direct" connection resource in that it manages pooling (the sharing of connection instances and Logon Component instances at runtime).
In the context of a Composer service, pooling not only allows reuse of (open) connections at runtime, it also increases the effective bandwidth of a deployed service. Consider the simple case where you've designed a Telnet component that uses a regular connection resource. In creating the connection resource, you will have specified a UserID and password for the resource to use so that at runtime, the component can log in to the host. When an actual running instance of your component is using that connection, no other instance of the component can log in to the host using that same set of credentials. The bandwidth of your service is limited to one connected instance at a time.
With a Logon Connection, on the other hand, numerous host connections can be maintained in a "live" state so that multiple instances of your component can access the host (each on its own connection) without waiting. Throughput is dramatically increased.
The diagram below shows one possible runtime case where three component instances (two instance of Telnet Terminal Component A and one instance of Telnet Terminal Component B) are executing on the server. Instance 1 of Component A is using UserID `E' to obtain a connection. This component has its own dedicated instances of Logon Component M and Connection S.
Terminal Component B has just finished executing and is relinquishing its connection (established through credentials defined by UID `F'). Note that because connection pooling is in effect, Component B's downstream resources (its Logon Component instance, M2, and its Connection instance, S2) are not simply discarded; they remain live. As a result, Terminal Component A2 is able to obtain (reuse) the M2/S2 resource instances that were previously held byTerminal Component B.
In this diagram, Logon Connection D is associated with four connections based on four UIDs (user IDs or credentials: A-thru-F). One is in use; another (UID `F') is alive but not being used; and two are inactive but available (i.e., valid UIDs have been assigned, so these two connections can be made live at any time).
It's possible for several different Telnet components to draw from the same connection pool. It's also possible for different components to draw from different pools. This means different Logon Connections.
An important factor in deciding how many Logon Connection resources (in effect, how many pools) your service needs is the number of different start screens (or entry point screens) needed by the various components in your project. Suppose Terminal Component A needs to begin its work at a particular starting screen in a host application, but you've also designed another component—Terminal Component B—that needs to start on a different screen. Components A and B will need separate Logon Connections, and the separate Logon Connections will point to separate Logon Components. (In any given connection pool, Composer objects are shared in such a way that every user of the pool must start at the same screen.)
The combination of a Logon Connection, a Logon Component, and its Connection Resource form the basis of a connection pool. Starting from the host layer and working up the chain:
The Connection Resource defines the most basic parameters necessary for establishing a connection with the host. When connection pooling is in effect, runtime instances of this object are kept alive and reused.
The Logon Component defines the set of steps (actions) necessary to get to a particular entry point in the host program. (At runtime, an instance of this component will actually carry out those steps in order to arrive at, and maintain ready-to-use, a particular screen location in the host program.) When connection pooling is in effect, instances of this object are kept alive and reused.
The Logon Connection is a special type of resource that contains all the information needed to define a connection pool. This resource is designed to encapsulate pool-management info and does not establish host connections directly; instead, it delegates those responsibilities to the Logon Connection (which delegates them, in turn, to the appropriate Connection Resource).
To create the various pieces required for pooling, you'll go through the following basic steps (each of which will be discussed in greater detail in the sections to follow):
First, you'll create a basic Telnet connection resource, as demonstrated in Chapter 2 of this Guide.
Next, you'll create a Logon Component that uses the connection resource defined in Step 1. As part of this process, you'll create an action model designed to navigate to a certain point in the host program.
You will create a Logon Connection resource, which is a specialized type of connection resource that relies on a Logon Component (from Step 2) to make the basic connection (through the resource defined in Step 1).
Finally, you'll create a Telnet Terminal Component and associate it with the Logon Connection resource of Step 3.
These steps are described in detail starting with the discussion in "Creating a Connection Pool" further below. Before going to that section, however, you should become familiar with the design principles behind the Logon Component (and also the Logon Connection). We'll start with the Logon Component, since it's impossible to create a Logon Connection without using a Logon Component.
The Logon Component is a special type of component: It has an Action Model, yet can be used as a connection resource as well. The Action Model of this type of component is designed to manage a connection that will be used by multiple Telnet Terminal Components. In most respects, the Logon Component is the same as a Telnet Terminal component. The differences are:
In a Logon Component, the Action Model is organized around connection-management tasks. Those tasks are implemented via special actions: the Logon Action, Keep Alive Action, and Logoff Action.
A Logon Component is not invoked directly by another component or service. Its invocation is under the control of a Logon Connection.
NOTE: A Logon Component must and can only be used in conjunction with a Logon Connection.
Instead of calling the Logon Component directly, using (for example) a Component Action, you will associate the Logon Component with a special connection resource called a Logon Connection. When your Telnet Terminal Component executes, it executes via the Logon Connection, which in turn executes the Logon Component.
The Logon Component provides several screen-management capabilities that are important factors in overall performance. These capabilities are implemented in terms of Logon, Keep Alive, and Logoff actions:
Logon Actions—These actions navigate through the host environment and park at a desired launch screen in the host system. The connection is activated using UserIDs from the pool. The Telnet Terminal components that subsequently reuse the connection have the performance benefit of already being at the launch screen and won't incur the overhead of navigating to the launch screen as if they had come in under their own new session.
Keep Alive Actions—These actions do two important tasks. First, they prevent the host from dropping a connection if it is not used within a standard timeout period defined by the host. Second, these actions must insure that the connection is always positioned at the "launch screen in the host, even after performing the Keep Alive actions needed to prevent the connection from dropping (the first important task).
Logoff Actions—These actions exit the host environment in a manner you prescribe for all the connections made by User IDs from the pool, when a connection is being terminated.
These actions and their meanings will be discussed in greater detail below. For now, it's enough to know that these three action groupings are created for you automatically when you first create a Logon Component. Note the (empty) Logon, Keep Alive, and Logoff action blocks in the action model shown below:
Actions you place in the LOGON group are primarily concerned with signing into the host security screen and then navigating through the host menu system to a launch screen where each Telnet component's Action Model will start. It is important that any Telnet component using a Logon component be able to start execution at the same common screen. Otherwise, the performance gains of avoiding navigation overhead won't be realized and more importantly, the odd Telnet component won't work.
You can create actions under the Logon Actions block the same way as you would in an ordinary Telnet Terminal Component—namely by using the Record feature to create (in real time) whatever actions are necessary in order to enter sign-on info such as User ID and Password (as well as your initial menu choices to arrive at the launch screen).
NOTE: Remember to use the User IDs and Passwords from the Logon Connection Pool. (See the discussion in "Creating a Logon Connection using a Pool Connection" on page -82.) To do this, you need to map the two special system variables called USERID and PASSWORD to the appropriate fields on the screen. By specifying these two variables, you make it possible for exteNd Composer to automatically locate and use values from the next active and free Pool slot.
The launch screen is a common point of execution for all the Telnet Terminal Components that use the User ID pool provided by a Logon Connection. The Logon actions in a Logon Component (which are executed only once when a new connection is established) let the calling component—your Telnet Terminal Component—begin execution at a given screen in the host program.
The Logon Actions must be structured properly and therefore always begin and end with a Check Screen Action as shown in the screen below.
The final Check Screen action in the Logon block guarantees that control is not turned over to the Telnet Component before the screen of interest has arrived in the connection. Without this, the Telnet Component could start at an invalid screen, throw an exception, and possibly corrupt a transaction.
NOTE: You may notice when animating a Logon Component that the ending Check Screen is skipped. This is normal design-time behavior. In a production environment , the actions in a Logon Component always execute in an interleaved manner with a Telnet Terminal Component. Animating a Logon Component from start to finish actually creates an abnormal sequence of events that would result in two Check Screens being processed in succession, which is not allowed.
The performance benefit comes into play as a result not only of connection reuse but launch-screen reuse. For example, if a User ID pool of three entries is fully used and (ultimately) reused by the execution of a component fifteen times, the overhead of navigating to a menu item that executes the transaction of interest will occur only three times. Likewise, there will only be three logons to the host because the Logon actions at the top of a Logon Component are executed only once—when a new connection is activated (not when it is reused). This is key to obtaining maximum performance in a high-transaction-volume production settings.
NOTE: When possible, use the Try/On Error action to trap potential logon errors that may be recoverable. Otherwise, the UserID trying to establish the failed logon will be discarded from the pool, decreasing the potential pool size. The pool size will remain smaller until you manually reset the discarded connections using the exteNd Composer Enterprise Server Console for Telnet. See Managing Pools Sections in this Chapter for more details.
The Keep Alive block is where you will place actions that "ping the host" in whatever way necessary to keep the connection alive so that it can be reused.
Keep Alive actions usually involve sending a key like <ENTER>, to the host at some specified interval. However, if after sending the key the screen changes to some screen that is different than the launch screen, you must be sure to return the Logon Component to the launch screen in the Keep Alive section. Failure to do so will leave the next component at an incorrect screen, causing it to fail.
In Telnet connections, you may type a letter and then use backspace to erase it. See the following screen. This will create and send a buffer action to the Host. This action allows interaction to be maintained with the Host and keeps the terminal connected.
The Pool Info dialog of a Logon Connection setup dialog (see discussion in "Creating a Logon Connection using a Pool Connection" on page -82) is where you control how often the Keep Alive actions will execute. If you specify in your Logon Connection pool that you would like to keep a free connection active for 60 minutes, but the host will normally drop a connection after two minutes of activity, you can specify keyboard actions to let the host know the connection is still active such as sending an <ENTER>key.
Keep Alive actions may be executed multiple times, at intervals defined by the Keep Alive parameter defined on the Pool Info dialog of the Logon Connection.
NOTE: The execution of the Keep Alive actions does not cause the Inactivity Lifetime clock to reset in the Logon Connection. Only a Telnet Component's execution will reset the Inactivity Lifetime.
The last action inside a Keep Alive block should be an empty but "enabled" navigation action. If a user disables this last action, animation will not work properly due to two consecutive empty navigation actions occurring. For example, if an action in Logon and the first action in Keep Alive are disabled, an error occurs.
Check Screens must occur at the beginning and end of the Keep Alive section.
Not only does the Keep Alive section prevent the connection from closing, but it must make sure that the launch screen is present when the execution is completed. The beginning Check Screen checks to make sure that during the time the connection was available but not in use, that an unexpected screen didn't arrive from the host. And again, the ending Check Screen prevents releasing the connection to the next Telnet Component prematurely after executing the Keep Alive actions. See the following screen.
Logoff actions essentially navigate the User ID properly out of the host system after a timeout.
Logoff actions execute only once for a given connection and only when a connection times out (i.e. the Inactivity Lifetime expires) or screen expression criteria is not met, or the connection is closed via the Telnet Server console.
In a "best practices" sense, it's vitally important to make Logoff Actions bulletproof. If an exception occurs during execution of the Logoff actions, exteNd Composer will break its connection with the host, freeing the UserID in the pool. But the UserID may still be active on the host. Until the host kills the UserID (from inactivity), a subsequent attempt by the pool to log on with that UserID may fail, unless you've coded your logon to handle the situation. Logon failures cause the UserID to be discarded from the pool, reducing the potential pool size and performance overall. As with Logon and Keep Alive actions, the way to guarantee you are on the proper screen at the end of the logoff is to end with a Check Screen.
Each time a User ID is activated from the Logon Connection Pool, an instance of the corresponding Logon Component is created and associated with that User ID. Then the Logon actions are executed until the desired launch screen is reached. At this point the Telnet Terminal component execution begins. When it is finished another Telnet Terminal component using the same Logon Connection may begin executing, starting at the same launch screen.
If no other component requests the connection, then the connection-instance in question enters an active but free state (an "idle state") defined by the Inactivity Lifetime and Keep Alive settings on the Pool Info dialog of the Logon Connection. If the Keep Alive period (e.g., 2 minutes) is shorter than the Inactivity Lifetime (e.g., 120 minutes), then at appropriate (2-minute) intervals, the Keep Alive actions will be executed, preventing a host timeout and dropped connection; and the Keep Alive Period begins anew.
A Logon Component's execution lifetime is dependent on the activity of the Logon Connection that uses it. As long as one entry in the Logon Connection pool is active, then one instance of the Logon Component will be in memory in a live state. A Logon Component instance will go out of scope (cease executing) when the last remaining pool entry expires due to inactivity. The only other way to stop execution of a Logon Component is through the Telnet Console on the Server.
The Logon Connection is not a true connection object like a Telnet Connection Resource, but a pointer to a Logon Component (which in turn connects to a host either through a conventional Connection Resource or yet more intervening Logon Connection/Logon Component pairs). The Logon Connection encapsulates information needed to describe a pool of connections. That includes User IDs and passwords, plus pool settings involving the time interval between retries on discarded connections, etc. Another function of the Logon Connection is that it ensures the use of different instances of the same Logon Component for all the User IDs for which connections are made.
The dialogs you'll use in setting up a pool of User IDs for a Logon Connection are shown in the following set of illustrations. Arrows denote the buttons that lead to continuation dialogs.
Every Logon Connection is associated with a given Logon Component. In addition, the Logon Connection provides the following User ID pool functionality:
It allows the specification of multiple User IDs in advance ensuring that clients are able to secure a connection when one is needed
It allows the reuse of a User ID/connection once it is established to eliminate repeated user authentications and disconnects
It allows a single User ID to use multiple connections if this is supported by the host system
It keeps a connection active to prevent host timeouts during inactive periods
It lets you specify when to remove a connection from the active pool
It sets a timeout period to use for a fully active pool to provide a free connection
It lets you specify error handling dependent on the state of the Logon Component used by the Logon Connection
In order for multiple instances of a Telnet component or different Telnet components to use the same Logon Connection, the following conditions must be met:
All the Telnet components must use the same Connection Resource (thereby sharing the Telnet Host, Port and Terminal type).
All the Telnet components must have a common launch screen in the host system from which they can begin execution (see "The Telnet Logon Component" above for more detail).
If your host system security supports multiple logins from a single user ID, you may have circumstances where you wish to pool the single User ID. This can be accomplished by performing the following steps:
Specify a User ID/Password in the Connection Resource used by the Logon Component
On the Pool Info dialog of the Logon Connection, specify a Pool Size greater than one
Do NOT check the Override the UID/PWD setting in the Pool Info dialog of the Logon Connection.
These steps will cause each pool slot to use the User ID and Password contained in the Connection object and not use and user IDs from the pool.
When creating a Telnet Terminal component, you normally create the Connection object it needs first. Similarly, when creating the objects comprising a Connection Pool, you must create certain objects first, starting (in essence) at the host and working your way backwards to the Telnet Terminal Component that will access the host.
A typical sequence of steps for creating a Connection Pool is outlined in the diagram below:
This step is simple. Create a new Connection Resource as described in "To create a Telnet Connection Resource:" on page -14 of this Guide. Even though you will be using User IDs and Passwords defined in the Logon Connection later, you should still define one in the Connection as well. This will be needed when you define the Logon Component in the next step. Alternatively, you can simply use an existing Connection Resource.
To create a Telnet Logon Component:
From the Composer File menu, select New> xObject, then open the Component tab and choose Telnet Logon.
Select a Connection from the drop down list. (This will be the basic connection, not the logon connection.)
Click Finish and the Logon Component Editor appears.
NOTE: Recording actions follows a series of steps. The cursor must be positioned over LOGON; then turn Record on, and when you are done, turn Record off. Position the cursor to Keep Alive, turn Record on, and when you are done, turn Record off. Position the cursor to LOGOFF, turn Record on, then when you are done, turn Record off.
Record Logon Actions for logging into the host and navigating to the launch screen using the same Recording techniques described in Chapter 4 of this Guide.
Edit the Logon Map actions that enter a User ID and Password to instead use the special USERID and PASSWORD variables described in the section titled "Telnet Specific Expression Builder Extensions" in Chapter 4 of this Guide.
Create the needed SEND Buffer actions in the Keep Alive section of the Action Model (a quick way is to copy an existing SEND key action, Paste it, and then modify the key code sent). 
To create a Telnet Logon Connection:
From the Composer File menu, select New> xObject, then open the Resource tab and select Connection, or you can click on the icon. The Header Info panel of the New xObject Wizard appears.
For the Connection Type select "Telnet Logon Connection" from the drop down list.
In the Logon Via control, select the Logon Component you just created.
Click on the Pool Info button and the Pool Info dialog appears.
Enter a Pool Size number. This represents the total number of connections you wish to make available in this pool. For each connection, you will be expected to supply a UserID/Password combination later.
Enter a Keep Alive time period. This number represents (in minutes) how often you wish to execute the Keep Alive actions in the associated Logon Component whenever the connection is active but free (i.e. not being used by a Telnet component). The number you enter here should be less than the Timeout period defined on the host for an inactive connection.
Enter an Inactivity Lifetime. This number represents (in minutes) how long you wish to keep an active free connection available before closing out the connection and returning it to the inactive portion of the connection pool. Remember, that once the connection is returned to its inactive state in the pool, it will incur the overhead of logging in and navigating host screens when it is re-activated.
Enter an Entry Wait time in seconds. This time represents how long a Telnet component will wait for a free connection when all the pool entries are active and in use. If this time period is reached, an Exception will be thrown to the Application Server.
Checking Override UID/PWD means you wish to specify User ID/Password combinations for use in the connection pool. When checked, this activates the Set USERID/PASSWORD button. Click on the button to display the Set USERIDs and PASSWORDS dialog.
On the Toolbar there are three icons: Add which adds an empty row, Delete, which deletes a highlighted row and Paste which allows you to copy/paste information from a spreadsheet into the table. For more on this, see the following Note.
NOTE: Alternate and faster ways to enter data are to copy data from a spread sheet and paste it into the table. Make sure your selection contains at least two columns, UserID and Password. The first and second column must contain data, all other columns will be disregarded. The first number column you see in the screen is automatically generated. Open the spreadsheet, copy the two columns and as many rows as needed. Open the table and immediately press the Paste button. You can also copy data from tables in a Microsoft Word® document using the same technique.
Enter as many USERID/PASSWORD combinations until you reach the size of the pool you specified and click OK. Pool size will be adjusted depending upon how many rows you entered.
Click OK to dismiss the "Set User IDs and Passwords" dialog and return to the Pool Info dialog.
Optionally check the Use Sequential Connections control if you want Composer to establish connections in the same order that User IDs were listed in the "Set User IDs and Passwords" dialog. Connections will be made in numerical sequence.
Optionally check the Reuse connection only if expression is true control. This control allows you to enter an ECMAScript expression that evaluates to true or false based on some test of the launch screen. The purpose of the expression is to check to make sure the launch screen is the proper one each time a new Telnet Component is about to reuse an active free connection. Under circumstances unrelated to your Composer service, it's possible that the launch screen will be replaced by the host with a different screen. For instance, if there is a system ABEND on the host, the launch screen in the Logon Component may be replaced by a System Message screen.
The following a is a sample Custom Script used to see if a particular screen is present. If it is not, the script writes a message to the console stating that the screen is bad and the logon connection is being released. This function is called from the "Reuse connect only if expression is true" control on the Pool Info dialog.
To prevent Telnet Components from beginning execution on a connection that may have been left on an invalid screen by a previous Telnet component, the Logon Connection Resource allows the connection itself to check for the presence of the launch screen. This is accomplished by using the option titled "Reuse connection only if expression is true" on the Pool Info dialog of the Logon Connection. The screen test you specify here is executed each time a Telnet Component completes execution. If the test fails, exteNd Composer will immediately disconnect from the host, possibly leaving a dangling UserID on the host. As noted before, the host will eventually kill the user, but the UserID may be discarded from the pool if it is accessed again before being killed, thereby reducing the pool size and consequently overall performance.
Another reason to use the "Reuse connection only if true" option is that you can perform very detailed tests against the screen to make sure it is your launch screen. While Map Screen actions do perform a screen check, they only look at the number of fields in the terminal data stream. In most cases, this is sufficient. However, it is possible two different screens can have the same number of fields in which case the expression based test that examines the content of the screen will produce more rigorous results. A best practices approach mandates that you use this feature all the time.
In some Composer applications, users have a need to place various control, auditing, and/or meta-data in an XML document. This document may or may not be in addition to the actual elements/documents being processed (i.e. created from an information source). If this document structure and data is dynamically created by multiple Map actions (i.e. over 100) performance of the component and therefore the entire service may suffer. To boost performance, create the portion of the document structure without the dynamic content ahead of time, then load it into the Service at runtime via an XML Interchange action and retain the Map actions for dynamic content. This can boost performance as much as 30% in some cases.
Sometimes, you may want the extra level of control over session parameters that a Logon Connection affords, without necessarily wanting to use pooling. In this case, you can follow the procedure outlined below.
To create a Telnet Session Connection:
From the Composer File menu, select New> xObject, then open the Resource tab and select Connection, or you can click on the icon.
For the Connection Type select "Telnet Logon Connection" from the drop down list.
In the Connect Via control, select the Logon Component you just created.
Click the Session Connections radio button and then on Session Info.
The Keep Alive (minutes) number represents (in minutes) how often you wish to execute the Keep Alive actions in the associated Logon Component whenever the connection is active but free (i.e. not being used by a Telnet Terminal component). The number you enter here should be less than the Timeout period defined on the host for an inactive connection.
The Inactivity Lifetime (minutes) number represents (in minutes) how long you wish to keep an active free connection available before closing out the connection and returning it to the inactive portion of the connection pool. Remember, that once the connection is returned to its inactive state in the pool, it will incur the overhead of logging in and navigating host screens when it is re-activated.
Click in the checkmark box if you want to Reuse connection only if expression is true. If you choose to do so, the expression field automatically displays and you can click on the expression icon to display the if the expression is true dialog.
At this point, you are ready to create a Telnet Component that can use the Connection Pool. For the most part, you will build the component as you would a normal Telnet component, the only difference being the Connection you specify on the New xObject Wizard. (You'll specify a Logon Connection instead of a regular Telnet Connection.)
From the Composer File menu, select New > xObject, then open the Component tab and select Telnet. The Header Info panel of the New xObject Wizard appears.
Select the necessary Input and Output Templates for your component.
Select the Logon Connection you created and click on Next. The Component editor appears.
Build the component as described in "To create a new Telnet Component:" on page -17 of this Guide.
Once the launch screen is obtained by the logon Component's logon actions, it is handed to the Telnet Terminal Component that uses the connection. Then the Telnet Terminal component (when finished executing) leaves the screen handler back at the launch screen. If the Telnet Component finishes without being on the launch screen,(i.e. it releases the connection back to the pool with an invalid screen) then it is possible that all subsequent Telnet Components that use the connection may throw exceptions rendering the connection useless. It also will degrade overall performance and possibly cause data integrity problems within the component processing.
Once again, to ensure that the launch screen is present, the last action to execute in a Telnet Component must be a Check Screen that checks for the launch screen. This can be tricky if your component has many decision paths that may independently end component execution. You must be sure that each path ends with a Check Screen action.
Connections pools can be managed through the Telnet Console Screen.
If you are using the Novell exteNd Application Server, log on to your Server via your web browser using http://localhost/SilverMaster50 (or whatever is appropriate for the version in use). In this example, Novell exteNd App Server 5.0 is used.
NOTE: If you are not using the exteNd app server, enter a URL of this form:
Click on the exteNd Composer link and a list of installed Connects displays to the left of the main console page:
Click on the Telnet link in the left (nav) frame and the Telnet Console General Properties Screen will come into view.
Click on Console. A browser popup window (the Telnet Connection Pool Management Screen) should appear.
To initialize a Logon Connection Pool, enter its deployment context, the word "connection", and the actual connection name in the text field near the bottom of the screen. (See illustration above.) Then click the Initialize Pool button.
NOTE: Refer to the appropriate Composer Enterprise Server guide for more information.
Optionally click the Refresh Console button to update the view.
The Connection Pool Management Screen displays the current state of the connection(s) with the Telnet Connect. The screen contains a table listing the Pool Name, Description of the connection, the maximum number of connections in the pool, the number of connections in use, the number of connections available, the number of connections discarded. It also contains several buttons allowing you to perform various actions related to connection pooling, which are outlined in the table below.
The performance benefits of connection pooling are based on the ability of more than one user to access a resource, or set of resources, at once. The way a connection is established begins with the logon component picking the User ID and Password from the table. If the connection fails, then it is discarded for this User ID and Password and tries another until a connection is established. The failure of one connection doesn't necessarily prevent a successful connection from being established.
The Connect for Telnet addresses the "one bad apple" problem by discarding any connection that can't be established (for whatever reason: bad user ID, timed-out password, etc.) and reusing the others. When a connection is determined to be unusable, the Connect for Telnet will write a message to the system log that says: "Logon connection in pool <Pool name> was discarded for User ID <User ID>."
Screen synchronization has special ramifications for users of pools. If a situation arises in which a user leaves a connection without the screen returning to its original state, the next user will begin a session with the screen in an unexpected state and an error will occur. To prevent this, we have a screen expression which the user can specify in the connection pool. It is important that the last action in a Telnet Component be a correct Send Key action that will result in the session ending with the correct logon screen active.
NOTE: The last action should be an empty Check Screen action so that the Telnet Terminal component waits until the launch screen arrives before giving up the connection. (This should happen automatically, when you create the Send Key action, but nevertheless, the last action should be the Check Screen.)
If you want to check, at runtime, for the presence of a bad screen at the end of a user session, include a Function action at the end of your component's action model that executes a function similar to the one shown below:
function checkValidReleaseScreen(ScreenDoc)
{
var screenText = ScreenDoc.XPath("SCREEN").item(0).text
if((screenText.indexOf( "MENU") != -1 || screenText.indexOf("APLS") != -1) &&
(screenText.indexOf("COMMAND UNRECOGNIZED") == -1 || screenText.indexOf("UNSUPPORTED FUNCTION") == -1))
{
return true;
}
else // Write error messages to
// System.out and System.err:
{
java.lang.System.out.println("Warning - Releasing logon connection at bad screen");
java.lang.System.err.println("Warning - Releasing logon connection at bad screen");
return false;
}
}
This function checks the screen text and returns false if the final screen is not correct. The check returns true if the screen contains "MENU" or "APLS" and does not contain "COMMAND UNRECOGNIZED" nor "UNSUPPORTED FUNCTION."
Copyright © 2004 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...