# Application Framework

Configuration Overview Programming

## 1.1 WebSpeed 4GL Changes

### 1.1.1 State-Aware Support Moved

The code to manage persistently running, state-aware web objects has been moved out of the main dispatch web-disp.p procedure and into stateaware.p, running as a persistent SUPER-PROCEDURE. This has the affect of removing it from the web request execution path, resulting in faster request execution time. State-aware mode support is still optionally available for applications that require it.

### 1.1.2 Miscellaneous Utilities Moved

Several design time utilities built into WebSpeed are available for Agent monitoring, but represent a security hole. These needs to be reimplemented external to web/objects/web-disp.p, rather than hard-coded as they are currently. Support for debug, ping, and reset in the URL QUERY_STRING have been moved to external files debug.p, ping.p, and reset.p, respectively.

## 1.2 FreeFrameWork Utilities

FreeFrameWork utilities are implemented such that they can be activated or deactivated on a WebSpeed broker-by-broker basis. Availability is controlled through broker environment variables.

### 1.2.1 Modularity and extensibility

web/objects/web-util.p has had a large rewrite to modularity with the use of super procedures. State-aware support has been moved into a super procedure “stateaware.p” which is only added to web-utilities-hdl if the agent starts in state-aware mode. Extra functionality like run-logging, developer-propath and database reconnection has been added to their respective super procedures that will only be initialized if the functionality is configured.

### 1.2.2 Reset, Ping and other utilities

This security setting determines whether to allow a web request to run reset.p. Setting NO requires stopping and restarting the broker when changes are made to web/objects/web-util.p, tagmap.dat, web/support utilities or any other persistently running procedure. This kind of features is moved out of web/objects/web-disp.p to respective programs.

### 1.2.3 RunLogging

The RunLogging feature generates a log entry at the start and end of each web request. As an example of this feature’s usefulness, consider an Agent that has hung and is in a BUSY state. The run logs can be checked for the PID of the Agent which started, but did not finish executing, a web request. The log messages is categorized and each category of messages can be enables/disabled as requested. For efficiency, the logs will only be written at the end of each web-request, but can optionally be configured to write immediately so that it will be written to a log even when the agent crashes.

### 1.2.4 Compile-On-The-Fly

Prior to executing an HTML file, if Progress rcode is not found for it, the HTML source will be compiled into a temporary directory at run time and run from there. The compile can be configured to delete the r-code after run so that it will compile each time it’s being requested, or it can be configured to compile only when the r-code is older than the source code. Optionally you can specify key for XCODE compile. This is for development only.

### 1.2.5 Batch Interval

This feature determines how often the Agent will break out of the WAIT-FOR statement during periods of inactivity and run the proactive database connection check (see 2.2.9 Check Database Connections) and any other services that need to be run.

### 1.2.6 Development PROPATH

Each developer’s personal working directory is prefixed to the standard Agent PROPATH, allowing each to run code from their sandbox first, followed by common code. Developers do not need their own broker, but can share a common development broker. The alternative to this feature is to start a broker with a different PROPATH for each developer. Development only.

### 1.2.7 WebRunPath

Because WebSpeed by default will try to run web objects requested by the user regardless of where they reside on the server, this feature allows the admin to specify certain directories in which WebSpeed is allowed to run objects. These are directories where objects can be run by putting the object name in the URL or internally from a program running the run-web-object procedure. Any program can be run in the Agent’s PROPATH internally via the RUN statement executed within a web object.

Each entry in the list is treated like a standard Progress CAN-DO, which means that one can specify an exact path and object name or can place a wildcard at the end. An “!” (exclamation mark; the NOT symbol) can be included in front of the path, to indicate that something is NOT part of the path. However, all NOT entries must occur prior to any entry that would otherwise allow an object to run.

WebRunPath is not a replacement for the Agent’s PROPATH. In order to run a web object, it must be found in the PROPATH as well as the WebRunPath.

### 1.2.8 Session variables and across-agents global variables.

You can set and get variables for the current session based on the sessionID. This is file-based, but for dynamics it’s database based. You can also set and get global variables which for system purposes.

### 1.2.9 Check Database Connections

The WebSpeed Agent will automatically attempt to stay connected to a set of databases. The connection check is performed each web-request. It is possible to associate specific program-code with specific databases and the connection may happen either by connection parameters or through a program. By specifying a program and adding logic to a custom “end-request” procedure you can even perform logic driven database connections, important if databases are separated into customer segments.

For Agents running with Dynamics, the connection parameters will be read out of the Dynamics repository.

### 1.2.10 Database failover to backup databases.

When the 99.99% uptime matters then redundancy is the law. If the reconnect logic fails the agent.may set a “failover” condition and make sure all agent switch to a backup database set. The “failover” mode can also be set manually for maintenance situations. A “dbFailover” program may be specified to pick up the “failover” event and run programs to perform a system reset or maybe contact administrators.