Application Framework
Application FrameworkConfiguration Overview Programming
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
You can set and get variables for the current session based on the sessionID. This is file-based, but for Progress Dynamics it’s database based. You can also set and get global variables which for system purposes.
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 Progress Dynamics, the connection parameters will be read out of the Progress Dynamics repository.
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.