Web Content Management White Paper

Web-based media is one of the most important collateral items a company has if it uses the Internet to promote its image and products, and engage in electronic commerce. The content of the web site defines the corporate image and its presence to customers, employees, business partners, and distributors of its products. The accuracy of the information that is present is crucial to the way viewers perceive the company and its services.

Some content applications (i.e. Microsoft FrontPage, Adobe GoLive, Macromedia Dreamweaver, etc.) provide tools for designing and creating web site content in a professional manner. What these applications do not adequately address, however, are the issues of submitting and managing changes to the site.

Many Content Management System (CMS) products available today claim to overcome most, if not all, of the issues involved in managing a web site. Many of them require the purchaser to adapt web server infrastructure and organizational processes as part of the implementation process. Others require extensive customization and lengthy expensive consultation before the existing web content can be managed effectively across the enterprise.

To properly and cost-effectively address these issues of submission and approvals management, the content management application must provide an economical and secure way to submit content and ideas for content. This application must be easy for submitters and approvers to learn and use. It must also be flexible enough to adapt to the organization's existing web server architecture, require minimal integration and configuration, and most importantly, conform to the organization's existing workflow and approval processes.

There are many other reasons an organization may use when selecting their application. Just as there are many CMS systems to choose from. Unless you know that your CMS requirements will not change over time, I strongly recommend that you ensure your CMS solution can adapt itself to changing environments and requirements. Which dynamic server and/or personalization system you use should be your decision, and not the dictates of CMS vendors.

To properly address concerns for managing web site content, a CMS should allow anyone in the organization to submit ideas or formatted media for consideration. For example, a user-configurable web browser interface, Web Distributed Authoring and Versioning (WebDAV), and even e-mail can allow users to submit new content or requests to change existing content. Other members of the web content management team can edit the submissions content using their web browser or local applications, passing them on to other members of the organizational workflow process for final review and publication. The CMS should meet the needs of a busy, decentralized, distributed environment while emulating or complementing the organizations existing processes.

Selecting a ‘server-based’ application that runs on a web server allows users to use their web browser as the client application, regardless of the platform base. This capability also has a definite advantage over system that require a client application to be distributed to each user’s workstation.

WebSite Director (WSD), CyberTeams' answer to managing content, addresses CMS security and easy of use by implementing the entire User Interface via dynamically-generated HTML forms and HTML pages (some Javascript codes are also used to simplify navigation for browsers that have Javascript enabled). And, because organizations can use existing browsers for their content management, costs of this management are dramatically reduced. Plus, by providing access to content through a web browser, WSD can be used over the public Internet or a private corporate intranet from anywhere in the world.

Because WSD does not require access to the server's root directory, it is ideal for high-security environments. Additionally, because of its unique architecture, multiple instances of WSD can be installed on the same server, making it the perfect solution for multi-domain server environments such as Internet Service Providers (ISP), web hosting companies, or where organizational constraints required the isolation or segregation of information.

WSD is a modular application, consisting of thirteen separate modules. This type of implementation improves the performance of the web server in loading CGI applications. Instead of loading the entire WSD application each time a button is pressed, the web server loads only the WSD module designed to process that specific request.

The following diagram shows these modules and the overall system architecture of WSD:

WSD Modules
The modules displayed in the System Architecture Diagram are described below:

Approval Processing Module (wsdapprove)
This CGI (Common Gateway Interface) application is the heart of WSD. It performs all of the review, editing, and approval processing. The View Request, Comments processing, and all of the Properties screens are processed here also. The Approve Request and Disapprove Request functions update the current state of the specified request and the approval history records in the WSD database.

Approval Status Notification Module (wsdnotify)
This module is a standalone application that can be run in real-time by the System Administrator or configured to run as one of the overnight processes. This program scans the WSD database and identifies the current status, by individual user, of all requests that are being processed in each of the approval stages. It generates an e-mail message for each user who has requested notification messages for specific approval stages.

Database Integrity Verification Module (wsdverify)
This module is a standalone application that can be run in real-time by the System Administrator or configured to run as one of the overnight processes. This program scans all of the records in the WSD database and reports any inconsistencies between related records. This module also compares the list of pending requests in the database with the collection of request files in the Requests directory, and reports any mismatches.

E-Mail Submission Module (wsdsavemail)
This module runs as a filter application on incoming e-mail to process web site update requests that are sent to a WSD "alias e-mail address" via e-mail messages. This module can be used with any mail system that can feed e-mail messages to the "standard input" of a filter program. Incoming e-mail messages and associated attached files are processed by WSD as new update requests, in a similar fashion to requests entered through the Web Browser Submission Module.

Main Module
This CGI application is the user's "Application Desktop" interface to WSD. It processes all "button-clicks" from the WSD Application Desktop screen. This module also handles the User Administration screens. When the user presses the Process Requests or View Requests buttons, this module transfers control to the Approval Processing Module. When the user presses the Submit New Request button, this module transfers control to the Web Browser Submission Module. Pressing the System Admin button starts the System Administration and Configuration Module, and pressing the System Reports button starts the Reporting Module.

File System and Database Cleanup Module (wsdcleanup)
This module is a standalone application that can be run in real-time by the System Administrator or configured to run as one of the overnight processes. It cleans up temporary files and the WSD database using values set in the WSD System Configuration screen. WSD creates temporary files during dynamic content preview, while editing, or when processing new request submissions. Except for dynamic content preview temporary files, WSD deletes these files when a user finishes editing the document and presses the "Return" button, saves the new request by pressing the "Save Request" button, or cancels the new request by pressing the "Cancel Request" button. This prevents the accumulation of temporary files from taking up space on the web server.

Reporting Module (wsdreports)
This CGI application provides all of the reporting functions of WSD. This module is invoked when the user presses the System Reports button on the main WSD screen. The user may choose to "bookmark" this module's entry page. This module can be accessed independently of the other WSD modules.

Site Publishing Module (wsdpublish)
This module is a standalone application that can be run in real-time by the System Administrator or configured to run as one of the overnight processes. This module is designed to run as a process that is called from the Approval Processing Module or as a standalone application, either started by the UNIX "cron" program, or as a Windows NT/2000 Scheduled Process, as part of the overnight processing. This program should be run as one of the overnight processes to scan the WSD database looking for update requests to process. An update request is processed and its corresponding document is updated on the public web site when a request has completed all of the approvals and the publication date for the request has arrived. This module will also be called directly from the Approval Processing Module following the "final approval" of any request that has the publication date set to publish the document "immediately" or from the System Configuration Module to process a "Publish Immediately" request. This module updates the public web site and the WSD document repository, and moves the request information into the request history records in the WSD database.

System Administration and Configuration Module (wsdconfig)
This CGI application manages all System Administration activities. The Maintain Stages, Maintain Groups, Maintain Templates, Maintain Trash Bin, Maintain Publish Stage, and Maintain Web Site screens are all processed by this module. The System Policies are maintained by this module. This module calls the Site Publishing Module to publish documents in the Publishing Status screen. It also calls the Approval Processing Module when approving a document in the Maintain Trash Bin screen or disapproving a document in the Publishing Status screen. And finally, this module provides a real-time launch pad for all of the Overnight Processing modules.

Username Request Module (wsdrequest)
This CGI application processes the Username Request form that can be set up on the WSD entrance page. It validates the input from the form, updates the user information in the WSD database, adds the password information to the WSD password file, and sends the username request to the WSD administrator.

Version History Module (wsdversions)
This CGI application supports access and update to the Document or Template version information in the WSD Document Repository. This module supports the Version History functions in the Properties screens. This module is also called from the Web Browser Submission Module to retrieve the latest version of a published document or template for an update request.

Web Browser Submission Module (wsdsubmit)
This CGI application is the user's WSD entry point for "new" web site update requests. The user may choose to "bookmark" this module's entry page. This module can be accessed independently of the other WSD modules. This module is also accessed when the user presses the "Submit New Request" buttons on either the main screen or any of the approval stage screens. This module provides navigation processing for all of the files on the public web site. This module also provides data entry processing for any type of update request, from adding a new document to deleting an existing document.

System Utilities Module (wsdutils)
This module may be run manually, as needed, to perform one of several system utility functions in WSD. The utility functions provided by this module include checking for proper file system access permissions, locking and unlocking the WSD system, exporting the WSD database into a text file of database records, importing a text file of database records into the WSD database, extract portions of the SQL journal file, publish a copy of a pending request or published document, and export database records for database publishing.

There are many resons for choosing specific Content Management System (CMS) applications. Just as there are many CMS systems to choose from. Unless you know that your CMS requirements will not change over time, I strongly recommend that you ensure your CMS solution can adapt itself to changing environments and requirements. Which dynamic server and/or personalization system you use should be your decision and not the dictates of your CMS vendor.