The default Scope setting is Page. The Disconnect macro executes immediately after the Data Loop macro. When a Web page accesses the integration object, it must log in again.
If the Scope is set to Client, the Disconnect macro is not executed immediately after the Data Loop macro. The integration object returns the data to the Page Server, but the integration object waits for a specified time before executing the Disconnect macro. If the integration object is accessed again within that time from the same client, the integration object begins execution immediately with the Data Loop macro, avoiding logging off and logging on again.
For this to work, the Data Loop macro must return the session to the same state it was in immediately after logging in.
Scoping to client enables the same client to access the same integration object from multiple Web pages. The Web pages might use Web form parameters or session variables to control the integration object execution and perform different tasks.
For example, in each Web page, code the name of the host application to invoke, define a different screen in the integration object for each application, and collect different data.
The client accesses the same host repeatedly without logging off and on, improving performance.
Different clients use different host sessions, providing security.
Note: The online documentation reversed the definitions of Scoped to Page and Scoped to Client in one place. The definitions given here are correct.
Connection Caching provides one or more named pools of connections which are shared by multiple integration objects. Each pool is called a Host Session. Each Host Session represents one or more connections with a single network configuration, i.e. transport protocol, terminal type, LU name or host server, etc.
The first time each connection is used by an integration object, that integration object's connect macro is used to log on. Disconnect macros are never used for cached connections. If a cached connection loses its network connection to the host, the connection will be logged on again with the connect macro of the next integration object that uses the cached connection.
Important Notes:
Use |
To |
Session Name |
Select a session. Click Add to add a session. Click Remove to remove a selected session. |
Cache |
Select a number or type a new number indicating the number of connections for this session. |
Serialize access. . . |
One thread at a time accesses the cached connections. Only connections in the connection cache can connect. Queued requests wait until the connection cache is available. The wait time is set in Milliseconds to wait for a connection. If the wait time expires, the request fails. If you do not select this box and all connections in the cache are in use, new requests immediately make a new connection. |
Milliseconds to wait for a connection |
Type the number of milliseconds to allow requests to wait for a cached connection. Type -1 for an unlimited wait. |
Temporarily disable caching for this component |
Select this check box to temporarily disable caching connections for the session, such as for testing purposes. Otherwise, do not select this box. |
By default, a new unique connection is used for each connection request.
In other words, start the host application from the connect macro, and do not exit the host application from the data loop macro. (This might not be appropriate for all host applications.)
Here's a summary comparing the two techniques:
Scoping | Connection Caching | |
---|---|---|
Reuse host connection without logging off | yes | yes |
Client-specific | yes | no |
Let multiple integration objects use the same host connection | no | yes |
Scope to Client and connection caching both reduce the overhead of logging on and off. The integration object sends the data back to the page server after executing the Data Loop macro, but does not immediately execute the Disconnect macro and end the connection.
Connection Caching is applied to multiple integration objects, so logging on and off is avoided even if the page server is accessing different integration objects. This works even for integration objects in different WBLs.
Scope to client is also difficult to use with such systems, except in situations in which the user specifies the account to use.
See User ID Management for more information about this general problem.