Update Web Connection Web Resources

When you update Web Connection on your server you need to replace a number of files in the various Web directories. To facilitate this process Web Connection can automatically copy resources to the Web directory for you using a Url like the following:

http://localhost/yourVirtual/WebResourceUpdate.wc?wwMaint~WebResourceUpdate

In order for this to work however you have to ensure that the following directories exist in your Web Connection installation (whereever the the EXE lives):

• Ensure that the latest /scripts directory is on the server
  
• Ensure that the latest /templates directory is on the server
  

This operation updates:

• the /scripts folder with wc.dll and webconnectionmodule.dll
  
• the /images directory with all images used by Web Connection
  
• the /scripts directory with the jquery and wwscriptlibrary plus any other scripts
  
• an updated westwind.updated.css is also written but not explicitly updated until you click a special link
  

Web Connection Request Log

By default the Web Connection server automatically logs each request that hits the server. The wwServer's LogEntry() method automatically logs the following into RequestLog.DBF (customizable with the wwServer::cLogFile property) located in the Web Connection startup directory:

• Time
  The date time entry when the request occurred

• Request
  The full Query String (anything following the ?) of the URL that caused the request to occur.

• Script
  Name of the DLL/EXE/ISA file or script mapped page. .WC and .WCS pages show up here.

• RemoteAddr
  The IP Address of the user that incurred the request. This is the Referrer CGI variable pulled from the Web server. In addition the end of the string contains a numeric value that reflects VFP's memory usage (SYS(1016)) to help pinpoint memory usage problems.

• Duration
  The time the request took. This value contains the time the user VFP code took to execute - it does not include the request messaging process or the time it takes to get the actual response back to the user over the Internet. Use this value to see how efficient your code runs and to pinpoint any server slowdowns based on memory usage etc.

• Memory
  Holds the memory usage (SYS(1016)) for VFP objects.

• Error
  Logical value set to .t. when an error is logged. Used for simplified error retrieval.
  

In addition you can set the following in WCONNECT_OVERRIDE.H:

#UNDEFINE WWC_EXTENDED_LOGGING_FORMAT
#DEFINE WWC_EXTENDED_LOGGING_FORMAT    .T.

To force Web Connection to use an extended logging format. In this mode it also logs:

• Browser
  The User Agent browser string for every request

• ReqData
  Any data posted to the server from the client. This allows you recreate much more accurately what was going on during a particular request.
  

Note that using the extended format collects significantly more data and should be used cautiously - primarily for debugging purposes if you have problems or need to track down a malicious client.

Viewing the Log

To show the contents of the Log from an HTML page do:

wc.dll?wwMaint~ShowLog
Note that you'll only see the last 400 records. This is done to keep the request short and not overload the browser's HTML table display. If you have the Office Web Components installed on the server Web Connection will also generate a chart of traffic over the last 25 hours.

You can override the number of records to show by providing a LogSize parameter:
wc.dll?wwMaint~ShowLog~&LogSize=1000

By default the log displays in normal, non-extended mode. To show extended log information including browser and POST data use:

wc.dll?wwMaint~ShowLog~&ExtendedLog=True&LogSize=500

wc.dll?wwMaint~LogSummary
You can also view a summary of hits tallied request. This works only for numbered parameters (wwDemo~TestPage for example). You can group by each parameter number. So, application would be 1, request would be 2 etc. Currently there's no support for scripts - script pages will not be counted.

wc.dll?wwMaint~ClearLog~NOBACKUP
In order to clear the log only one session can be running as exclusive access to the log file is required. When the log is cleared only the data up to the current day is cleared - today's data always stays in the file. When clearing the data in the log is appended to LOGBACK.DBF for archive purposes. Ideally, you want to run a daily log and keep the archive for reporting purposes. This file can get big, and clearing can get slow because of the APPENDs to the LOGBACK file. If you don't want a backup use the NOBACKUP parameter.

Displaying the ISAPI DLL Error Log

In addition to viewing the Web Connection Server server generated DBF file log you can also view the ISAPI DLL log of errors by using the Show DLL Errors link. DLL show any problems that may be occurring with the ISAPI DLL from minor notifications to serious exceptions. For description of common errors and what they mean see the previous section on wc.dll settings and commands. You can also clear the log from this link. The error log file lives in <wctemppath>\wcerrors.txt.

Management of Multiple Sessions for File Based Messaging

Since Visual FoxPro is a single threaded application (actually, it isn't - several threads run, but only one thread is available to application code) the only way to provide support for simultaneous requests is to run multiple instances of Visual FoxPro and Web Connection. Running multiple sessions can provide your application a better feel although the overall response time is probably not improved much by running multiple sessions. Rather multiple sessions should be used to balance request loads so that longer requests are not hogging the CPU and tying up the pipe while short requests have to wait for long requests to complete. On a single processor box two simultaneous sessions provide good performance without noticable slowdown - more sessions will see requests slowing down considerably when running simultaneously. On a dual processor box the cutoff point comes at 4-5 sessions. If you need more sessions the next step is to move off to different machines and run them across the network (see previous section).

Running multiple sessions can provide the scalability needed to run simultaneous requests, but it also causes some maintenance headaches. If you're running multiple sessions it becomes crucial that you can shut down sessions so you can perform maintenance tasks that might require exclusive access to your data files. How often this occurs depends on your site, but if you are running a site that's running offline from another database application with data being shuffled back and forth maintenance tasks occur frequently.

Session management for Automation servers is handled via the DLL Maintain functions described in the previous section. For file based messaging the DLL has no control over the standalone VFP EXE files and thus can't manage them. The wwMaint module handles some of the chores by using the RUN and QUIT commands to manage running sessions using its Sessions method.

Note: In order to start a new session of Visual FoxPro development you need to set the following key in the wcmain.ini file in the Web Connection root:
[wwMaint]
RestartExePath=c:\vfp\vfp.exe -t wcmain.prg
or
; RestartExePath=c:\wconnect\wcdemo.exe

The URL syntax for the available functionality is:

wc.dll?wwMaint~Sessions~KILL
Kills a session that's running by executing a QUIT from the server that's hit.

wc.dll?wwMaint~Sessions~START
Starts a new session. Note that at least one session must already be running for this to work since Web Connection implements this mechanism. Web Connection actually issues a RUN command to start another session. If all sessions are dead you can use the next link to start a new instance.

wc.dll?_maintain~StartExe
This URL will restart a Web Connection server as a standalone EXE file from the ISAPI extension. The ISAPI extension reads the location of the EXE file from wc.ini in the EXEFILE key.
NOTE: the server will start invisibly (no UI). Make sure you test starting servers in this fashion. Note that servers started in this fashion act differently than servers started from the Desktop. Servers are started using the SYSTEM account so set your permissions accordingly.

Note:
File based server sessions are not recommended. If you need to manage multiple Web Connection instances it's highly recommended you use COM messaging, which allows full control over loading and unloading of servers including status information and crash recovery.

Update Code Online

This option allows you to copy a new EXE file from a specified location. This feature is most useful with COM operation where you can upload a file to a pre-specified location and then cause a hotswap of the Server Exe files. How you get the file up, is up to you. You can FTP the file or use the BLD_<YOURAPP>.PRG that gets created with a Web Connection project which FTPs programmatically. Just make sure you configure the FTP paths and login names.

You can also use the Upload File: input box to upload with HTTP directly from this page. The File gets copied to the server based on the UpdateFile key in wc.ini. Another key ExeFile specifies the target file of a Code update.

When you click the button the Web Connection ISAPI DLL will try to delete the ExeFile first. This ensures that the file can be unloaded and is not running on the server. It then copies the UpdateFile to the ExeFile location. In COM mode, COM servers are unloaded before the delete and copy operation occurs. In file mode, no special action occurs - you're responsible for unloading servers on the Web Server using the Admin commands or other mechanism.

Warning:
This operation is based entirely on the keys defined in wc.ini. If you have either of these keys incorrectly set it's possible that a running file is deleted and not copied back. Make 100% sure you test this before making critical live site code updates!

Server Statistics

There's also a simple link to display basic statistics about the Web server itself. Check out the following link:

wc.dll?wwMaint~ServerStatus
wc.dll?wwMaint~ShowStatus
These pages report settings for the server. The first requires IE 4.0 and allows editing the same server settings you can interactively change on the server's status form. The latter only displays stats about the running application.

Warning! It's highly recommended that you add Authentication to the requests discussed here or else risk the consequences of people messing with your site. If you check out the wwMaint.prg file Process method you'll find some commented out code that enables security based on a password defined in a #DEFINE that you set up. In addition it's a good idea to set security on the Maintain.htm page that contains all the links to these requests.

wc.dll?wwMaint~EditConfig
It's also possible to edit the Web Connection Configuration files remotely. This link displays a page with the server's config files for the DLL Ini file (wc.ini) or the Web Connection Server (wcMain.ini or whatever your main program is). The files are displayed in textboxes and can be edited and updated via a edit box and button.

Note: Updates work only if the Web Connection server resides on the same box as the Web Server. This request will not work if the INI files reside on remote machines due to the paths that are returned by the Web Server for the DLL and INI files. You can however modify the code in wwMaint.prg to hardcode the appropriate server path.

The actual update links for the INI files are:

wc.dll?wwMaint~EditConfig~SaveDLLIni
wc.dll?wwMaint~EditConfig~SaveWCIni

If you're running COM/Automation you can use the [Automation Servers] section to add and remove servers from the poo