Deploying Applications . .Managing User Loads . . Setting Your Connection Method . . Related Topics . . Home

Deploying and Managing Applications

The following sections describe how to:

• deploy your applications.
• manage user loads.
• set up Direct Connect or Managed Connect application sessions.

Deploying Applications

Perform the following steps to deploy a Universal Web Connect application:

1. Set any application-specific parameters in the wcconfig.std configuration file in an application section identified by the APP and ENDAPP delimiters. An application can run even if there are no entries for the application in the configuration file. If there is no APP delimiter with a matching application name, the application is executed using the global configuration parameters.
   
2. Place the executable files in a directory on the machine on which the Web server and Universal Web Connect reside. Make sure that the MI_WEBBINDIR configuration parameter is set to this directory name. Each application can reside in its own directory, or a single directory can contain several applications.
   
3. Place the AppPages in a database repository accessible from the Web server machine with the connection specified by the MI_DATABASE, MI_USER, and MI_PASSWORD parameters. The data resides in the database repository specified by the MInam, MItab, and MIcol (and optionally, MInamObj, MItabObj, and MIcolObj) configuration parameters.
   
4. Stop and restart Universal Web Connect in the Administration Tool or the Service Manager.

Managing User Loads

The user load on the Universal Web Connect system is determined by the MI_WEBMAXSESSIONS and MI_WEBTIMEOUT parameters, set at either the global or application level, and by the number of application processes you specify in the application sections of the configuration file.

You can limit the number of simultaneous Web browser client sessions by setting the MI_WEBMAXSESSIONS configuration parameter. You can set MI_WEBMAXSESSIONS to a global value for all applications. This value determines how many session slots are reserved in shared memory. You can also set MI_WEBMAXSESSIONS to application-specific values. This value determines the maximum number of client sessions the particular application can have. If the total number of active clients exceeds the MI_WEBMAXSESSIONS limit, the ERR_MAXSESSION error is returned when a new client attempts to initiate a session.

When a client session is not active within the time period specified by MI_WEBTIMEOUT, the session times out. The session slot that was occupied by that client becomes available for a new client session request.

You can limit the number of application processes by setting a specific number of processes to be forked if you specify a number following the APP delimiter in the configuration file. The specified number of processes are started when the Universal Web Connect service starts. Use the following syntax:

APP appName #

For example, the following portion of the configuration file sets up the parameters for the myapp.exe application:

APP myapp.exe 5
MI_WEBDRIVER Y
ENDAPP

Five instances of the myapp.exe application are initialized. These processes serve all client session requests. All of the processes remain active regardless of whether the Web browser clients are making requests. When a client session times out, the session slot that was occupied by that client becomes available, but the application process continues to run, available to serve other client sessions. If more clients attempt to use the application than there are application processes available, the potential clients wait until an application process becomes available. The wait might be very short; however, if all the application processes are busy for a long time, the application is unavailable to the waiting clients. If this happens, the client receives the ERR_CONNECT_TO_APP error.

If you do not set the number of application processes, a new process is forked for the requested application every time a Web browser client session is initiated. When a client session times out, the session slot that the client occupied becomes available, and the associated application process is terminated. In this case, each Web browser client has a dedicated daemon, or application process, associated with the client, and the number of potential application processes on your machine is limited only by system resources. If the system resources become so low that a new application process cannot be forked, the client receives the ERR_STARTAPP error when the client requests a new session.

Setting Your Connection Method

Web browser clients can communicate with Universal Web Connect applications in one of two ways:

• The Web driver manages all communication. This connection method is known as Managed Connect.
• The Web driver module manages only the initial connection, and subsequent requests connect directly to the application from the Web browser. This connection method is known as Direct Connect.

Choosing Your Connection Method

Direct Connect has the following advantages:

• Portable architecture that works with more browser/server combinations
• Secure HTTP connections
• More informative messages when application times out

Managed Connect has the following advantages:

• Improved performance
• Reduced use of machine resources

Specifying the Type of Connection

Set the MI_WEBDRIVER configuration parameter in the configuration file to one of the following values: Y for Managed Connect or N for Direct Connect. You can set MI_WEBDRIVER to different values for different applications within application sections of the configuration file.

Understanding Managed Connect

This section provides more information about how Managed Connect works. The type of connection you use does not affect how you write your Universal Web Connect applications.

When you use Managed Connect, the Web driver manages all communications between the client and the application, in the following sequence of events:

1. The user starts the session by entering a URL for a Universal Web Connect application. For example, the following URL invokes the myapp application using the wcdrvr Web driver:

   NT:   http://myhost:myport/ifmx-bin/wcdrvr.exe/myapp.exe

   UNIX: http://myhost:myport/ifmx-bin/wcdrvr/myapp

   (It is possible to hide the full URL from the end user. For example, you might provide an opening screen with a Start button that invokes this URL.)

2. The Web server starts the Web driver process. The Web driver attaches to shared memory and assigns the Web browser client a global session ID, which is used to track the Web browser session with the application.
3. The Web driver checks shared memory to find the location (specified by the MI_WEBBINDIR configuration parameter) of the myapp application and retrieves the values of variables and any other configuration information about the application. Then the Web driver forks the application, allocates a TCP port to it, and waits.
4. When the application starts, it attaches to the assigned TCP port: the Web driver and application are able to communicate with each other.
5. The application performs its tasks. Typically, it opens a connection to the database, generates the first AppPage, and returns the expanded AppPage to the Web driver. The Web driver returns the expanded AppPage, along with the session ID, to the Web browser.
6. The Web driver terminates. The application stays resident in shared memory, listening on the TCP port.
7. Subsequent calls to the application begin by starting the Web driver again. Instead of the application name, the session ID and any variables are encoded in the URL. The following is a sample URL for a subsequent AppPage request when you are using Managed Connect:

   NT:

   http://myhost:myport/ifmx-bin/wcdrvr.exe/SESSION_ID=1/SESSION_AR=0?MIval=menu&lastName=Smith

   UNIX:

   http://myhost:myport/ifmx-bin/wcdrvr/SESSION_ID=1/SESSION_AR=0?MIval=menu&lastName=Smith

   This URL is constructed for you automatically when you use the WEB_HOME variable in your URLs. The WEB_HOME variable is automatically expanded to replace the portion of the URL up to the query string (preceding the ? ):

   NT:

   http://myhost:myport/ifmx-bin/wcdrvr.exe/SESSION_ID=1/SESSION_AR=0?

   UNIX:

   http://myhost:myport/ifmx-bin/wcdrvr/SESSION_ID=1/SESSION_AR=0?

   The rest of the URL consists of variable names and values being passed from the AppPage to the application (in this example, MIval and lastName).

8. The application uses the session ID to find its area in shared memory; then it generates the next AppPage and returns it through the Web driver.
9. Steps 7 and 8 are repeated for each subsequent AppPage until the application times out or exits normally.

Understanding Direct Connect

This section provides more information about how Direct Connect works. Note that the type of connection you use does not affect how you write your Universal Web Connect applications.

When you use Direct Connect, communication between the Web browser client and the application is initiated by the Web driver. However, subsequent communications are made directly from Web browser to the application, bypassing the Web driver. The wcConOpen( ) function, called from your application, can handle HTTP requests and enables your application to supersede the role of the Web driver and Web server.

The first six steps, the retrieval of the initial AppPage, are the same in a Direct Connect session and a Managed Connect session. The retrieval of subsequent AppPages is handled differently, however. When you use Direct Connect, the following sequence of events occurs:

1. In subsequent calls to the application, the application's TCP port number is encoded in the URL instead of the Web driver name. The following is a sample URL for a subsequent AppPage request when you are using Direct Connect:

   http://myhost:8000/SESSION_ID=1/SESSION_AR=0?MIval=menu&lastName=Smith

   This URL is constructed for you automatically when you use the WEB_HOME variable in your URLs. In Direct Connect, WEB_HOME automatically expands to the portion of the URL up to the query string (preceding the ? ):

    http://myhost:8000/SESSION_ID=1/SESSION_AR=0?

   The rest of the URL consists of variable names and values being passed from the AppPage to the application (in this example, MIval and lastName).

2. The application uses the session ID to find its area in shared memory; then it generates the next AppPage and returns it directly to the Web browser.
3. Steps 7 and 8 are repeated for each subsequent AppPage until the application times out or exits normally.

Related Topics

Configuring Applications