SCHEDULED PROCESSES This tutorial discusses WebSite Director (WSD) processes designed to be run on a scheduled basis, and provides instructions below for setting up these processes on both UNIX and Windows NT servers. It includes the following sections: What are WSD Scheduled Processes How to Set Up Scheduled Processes for UNIX How to Set Up Scheduled Processes for Windows NT/2000 How to Configure the Windows NT Scheduler Service  Scheduling the Processes We recommend that you schedule them to run at least once each day, possibly overnight. Depending on your configuration and/or other environmental considerations, you may choose to run some/all of them more frequently. Button/icons are provided from the Application Desktop to run each process immediately. For the Explorer Navigation, go to System Administration and open Scheduled Processes. For Browser Naviagtion, click the System Administration button/icon and select a Process from the right column. What are WSD Scheduled Processes?   WSD provides the following five independently executable programs that perform the functions recommended for periodic processing:  wsdpublish - This module publishes all documents approved for publication and scheduled for publication at the time this program is executed. If the document has been approved for publication, and the Publish Date: field on the document's Document Info screen has been set to "Tonight," the document will be published the next time this module is executed. Note: If there is no publish time associated with a document (or the Publish Date Selection System Policy is set to "Date Only"), each execution of wsdpublish will publish all documents approved for publishing that are marked for "Tonight" or have "Today's Date" in the date fields. For example, if you have selected "Future Date:" but the date value is still set to today's date, the document will be published the next time this module is executed. wsdnotify - This module creates and sends all scheduled e-mail notification messages regarding documents awaiting editing and/or approval in individual approval stages. wsdcleanup - This module performs an analysis to verify of the integrity of the WSD database and the WSD Document Repository, and automatically cleans up of any/all of the following: Abandoned Pending Requests not saved (requests resulting from closing browser windows for new requests without performing a "Save" or "Submit" to Complete the Request) that have been in the file system longer than the value specified in "Temp File Cleanup Age (in days):" on theSystem Configuration screen. Abandoned temporary files for Previews, Version History displays, Document Properties screens, and Upload-related files left in the file system when users or system failures close WSD-related browser windows before completion of these processes. Interim Version files resulting from Revision Control System (RCS) errors reported in the WSD error log. Request History files that have been in the file system longer than the value specified in "Request/Approval History Age (in days): on the System Configuration screen. "Orphaned" content check - identifying all files that are not pointed TO by any documents maintained by WSD. Orphan Check processing automatically creates "Delete" requests as needed when the "Auto Submit Delete for Orphaned Documents" System Policy is set; excluding all content located in directories with the "Skip Orphan Document Check" Directory Property set and individual content with the "Skip Orphan Document Check" value set for the "Options " Document Property. "Expired" content check - identifying all content with an "Expiration Date" Document Property equal to or earlier than today's date. The "Expiration Date" preocessing, creates automated "Delete" or "Modify" requests as needed based on the "Expiration Date " Document Property value. When this module is run as a scheduled process and errors are detected, this module will generate an e-mail, sent to the System Administrator.  When this module is excuted from the browser, all output is displayed in the user's browser window . wsdverify  - This module checks for mismatches between the SQL database contents and the WSD-manged portion of the server's file system for errors that will require administrator intervention to be corrected. Checks include verifying the integrity of databse table relationships, dependencies, and comparing request-related database contents against the actual request files in the WSD Requests subdirectory on the server. This module generates output only when errors are detected. wsdutils - This is not a CGI (Common Gateway Interface) application.  This module performs an analysis, checks directory and file permissions on the web server and produces the Server Permissions Check screen.   This module may be run manually, as needed, to perform one of several system utilities in WSD. It may also be scheduled to run in the wsd.bat (Windows) or wsd.cron (Unix) files. The utility functions provided by this module include the following: wsdutils lock - locks the WSD database wsdutils unlock - unlocks the WSD database wsdutils export <filename> [tablename] - exports the entire WSD database (or only the WSD table specified in the optional [tablename] parameter to the file specified in <filename> wsdutils import <filename> - imports the entire WSD database from the file specified in <filename> wsdutils checkperms - generates a text version of the Check Permissions screen (see System Administration ) wsdutils extract <filename> - extracts a subset or all of the WSD SQL Journal file into the file specified in <filename> in a format suitable for loading directly into the WSD database using the "import" command.  The user is prompted for a starting and ending timestamp to provide the range of journal entries to extract.  Either or both can be left blank, defaulting to the beginning and ending of the journal file. wsdutils publishcopy <request/filename> <prop/template> <target> [strip] - primarily used in WSD filter scripts, this command generates a copy of a published document into a specific target file using a different template than the original document.  The <request/filename> parameter specifies either a WSD request ID (provided to filter scripts) or the filename of a published document.  If a filename is used, it must begin with a '/' or '\' character and the filename path must be relative to the Document Root directory.  The <prop/template> parameter is either a WSD property in the request that contains the template name to use or the filename of a file containing WSD layout template tags.  If the property name is used, the corresponding property in the request specified in the previous parameter (only the request form of the previous parameter can be used in this case) is retrieved to identify the layout template to use in formatting the output document.  If a template filename is specified, it must be a full path and filename to the file containing the WSD layout template tags to use in formatting the output file.  The <target> parameter is the full path and filename of the file on the web server to publish the results of merging the content and layout information into.  The [strip] parameter is optional and if present, all layout template tags will be removed from the published document. wsdutils exportdb <template> <dbtable> <directory> -  used to export records from any SQL database into content files formatted for WSD's database publishing.  The <template> parameter specified the filename (not path) of a WSD page layout template containing the database connection commands and the template fields that match the database table.  The database template specified in the <template> parameter should have template fields defined for each of the database record fields.  If the template field name does not match the database record field name, you must add a new 'dbfield= "<databaserecord field name>"' attribute to the template field definition so that the exportdb function can match up the template field with the associated database record field.  The "dbfield" template field attribute is ignored in any other template processing < /FONT> < /FONT> < /FONT> < /FONT> The <dbtable> parameter identifies the database table (specified in <template>) from which you want to export records.  The <directory> parameter identifies the directory relative to the Document Root in which the content files will be generated. This <directory> must already exist and should be empty before running the exportdb function. In addition to scheduling these processes for execution, you can also execute any or all of these modules immediately from the System Administration screen by selecting one of the following functions from the "Scheduled Processes" box.  FUNCTION MODULE PUBLISH OVERNIGHT wsdpublish SEND NOTICES wsdnotify CLEANUP DATABASE wsdcleanup VERIFY DATABASE wsdverify CHECK PERMISSIONS wsdutils How to Set Up Scheduled Processes for UNIX To set up these modules to run as scheduled processes, you must configure your web server's "cron" service. You can configure cron to run all four modules one after another, or you can schedule each one to run at separate times. If you want to schedule all four modules for one time, you should use the wsd.cron script that was installed with the WSD program files. Here is the sample wsd.cron script that is set up to run all four modules:  #  # wsd.cron - cron script to run WebSite Director #            scheduled programs  #  # cd <WebSite Director Installation Directory>  wsdpublish  wsdnotify  wsdcleanup  wsdverify On some servers, you might need to add the line "#!/bin/sh" at the beginning of the script (check the cron documentation for your server to make sure). You can either uncomment the line that starts with "cd" and edit the line with the correct directory for the WebSite Director scheduled modules, or you can specify the full path to each module.  To schedule the processes, you will need to edit the cron configuration to specify the wsd.cron script (or each module if you want to schedule them separately). You edit the cron configuration by issuing the command "crontab -e". You need to add a line to the cron configuration that looks something like this:  0 1 * * * /usr/local/etc/httpd/cgi-bin/wsd/wsd.cron You will need to specify the correct path to the wsd.cron script. The above example will run the wsd.cron script at 1:00 am every morning. Check the cron documentation for information on scheduling the job for a different time.     How to Set Up Scheduled Processes for Windows NT/2000   As part of the installation process, a batch file named wsd.bat is placed in the WSD Installation directory. This .bat file, shown below, runs the first three of the five modules.  Note: You must un-comment line 5 of the wsd.bat file (contains: rem cd "WebSite Director Installation Directory") by removing the "rem" and replacing "WebSite Director Installation Directory" with the fully qualified path to your WSD Installation directory (for example: "c:\Program Files\Apache Group\Apache\cgi-bin\wsd") before using or making copies of this file. wsd.bat file @echo off rem rem wsd.bat - Batch file to run WebSite Director scheduled programs rem rem cd "WebSite Director Installation Directory" wsdpublish wsdnotify wsdcleanup You may choose to schedule execution of all or only some of the three modules using the Windows NT Scheduler Service. You can make copies of the "wsd.bat" file and remove the names of any modules you do not wish to schedule together and then schedule each copy of the .bat file at a different time. You may make as many versions of the "wsd.bat" file as you wish for independent scheduling of individual modules.  The following provides instructions on configuring the Windows NT Scheduler Service and scheduling these processes.  How to Configure the Windows NT Scheduler Service  Start the Windows "Control Panel" Locate and double-click "Services" Windows will open the Services window Locate and single-click "Schedule" Then click [Start] to start the scheduling service Note: If you want the scheduler to startup automatically whenever the NT Service starts, then:  Click [Startup] The Service window displays Click [Automatic], then click [OK] The Services window returns Click [Close] The Services window closes Scheduling the Processes  The Windows AT command is used to create entries that will be executed by the Windows NT Scheduler. Entries are entered using a (DOS) Command Prompt from within an MS-DOS window. For each .bat file you want to schedule, you must do the following:  Start an MS-DOS task Use the following syntax to type the Windows NT "AT" command for the batch file you are scheduling: at <time> <frequency> "<full path and name of batch file>"  where: <time> is the time of day in 24-hour clock notation Example: 14:25 is 2:25 PM <frequency> is in the form: /every:M,T,W,Th,F,S,Su Example: /every:M,W,F will schedule the job for execution at the specified <time> every Monday, Wednesday, and Friday. Note: If frequency is omitted, the scheduled job will only be run once at the specified time after the scheduler becomes active. <full path and name of batch file> Example: "c:\Program Files\Apache Group\Apache\cgi-bin\wsd\wsd.bat" Press Enter to complete the AT command and place it into the scheduling queue You can display a list of outstanding AT requests by typing: AT <Enter>, causing a display of outstanding AT requests. Example: Status ID  Day                   Time       Command Line  -----------------------------------------------------------------  1  Each M T W Th F S Su  1:00 AM    "C:\Server\cgi-bin\wsd.bat"  After you have completed steps 2 and 3 for each batch file you want to schedule, close the MS-DOS window For additional help on use of <frequency>, see AT command documentation (help, "At command" then At in the Windows NT Help).