The OpenEngagement DMS can be made to be very fast. Some sites, for example, can handle up to 2,000 page requests/second, and a local copy of OpenEngagement DMS may also operate at this or greater speeds. However, this requires a great deal of work if the site has large volumes of data or heavy traffic.

The main strategies to improve the performance of OpenEngagement DMS instances are: caching, improving the hardware and/or operating system used, packing the database, using ZEO, reducing data volume, reducing site traffic, de-fragmenting the database files, and clearing the browser cache.

Caching is done generally by fronting the DMS with either Apache or Squid.

The DMS benefits greatly from improving the hardware on which it runs, particularly by giving it more RAM. Users should also adjust the database cache size to take full advantage of the RAM that is available on the computer.

The DMS must run on Windows to operate properly. It is possible to run the DMS on Linux, or high performance operating systems such as NetBSD or FreeBSD, but this is not supported by OpenEngagement out of the box. It is possible, though, and is done on the OpenEngagement Hosted Solutions by splitting the server over multiple boxes, one of which runs Windows. Windows is necessary to parse the CaseWare client files as they are uploaded, to extract the period ends and other such information.

The database will be packed automatically on a nightly basis. However, after uploading many files to the DMS, the site may slow down, and may benefit from being packed. Only Administrators have permission to pack the database.

ZEO is easy to install on Linux/UNIX computers, but is not as easy to install on Windows, though it is documented and is certainly possible.  ZEO is useful for improving the speed of DMS instances where performance is suffering due to high web traffic. ZEO will not improve the performance of the OpenEngagement DMS otherwise. ZEO allows firms to use several computers for their OpenEngagement DMS. ZEO must be combined with a load balancing application, such as Pound.

Firefox has a highly effective system for maintaining its browser cache so as to prevent the browser from becoming slow, but IE does not. For this reason users may benefit from clearing their browser caches manually from time to time when using IE, or from using Firefox. As well, users may download or purchase browser cache management applications for managing their IE caches. Some of these application actually manage the browser cache and others simply notify the user when the cache should be manually cleared. Many are quite inexpensive.

The Hosted solutions use Squid and Apache, though this is transparent to the users other than in terms of performance improvements. It is also possible to use these applications with Local Solutions.

Apache and Squid are open source web servers. Apache is the most popular web server on the internet, being used virtually since the beginning of the web, and now used on approximately 60-70% of the web servers in the world. Squid is a less general-purpose but also very popular alternative. It is most often used purely for caching. Many feel it provides better page caching performance than Apache. Though simple on Linux, Squid is somewhat involved to install on Windows, so we assume most users will use either Apache or IIS if anything. IIS is the Microsoft alternative to Apache.

The OpenEngagement CMS includes an HTTP server, so does not require using IIS or Apache. In general, it is simpler to use the OpenEngagement DMS without these. There are some advantages to using IIS or Apache with the OpenEngagement DMS though, so some users may wish to consider this option. To use IIS requires an add-on, which may be purchased from a company called Enfold. Using Apache with the OpenEngagement CMS may be done without financial cost, and using Apache with Plone is well-documented.

We list here some benefits of using IIS, Apache or Squid.

Benefits:

• File caching (described below) can improve the performance of the OpenEngagement CMS.
• Firms can put IIS or Apache on one computer and the OpenEngagement CMS on another, which can improve speed by allowing parallel processing
• Firms can put IIS or Apache outside a firewall and the OpenEngagement CMS inside, which may be a desirable security configuration for some users.
• You can set up several OpenEngagement CMS instances on the same server, and configure IIS or Apache to direct all HTTP requests. This requires also using a Virtual Host Monster, which is not difficult to set up.
• Apache and IIS allow for SSL, which provides security by allowing only HTTPS connections to the OpenEngagement CMS server.
• Apache has numerous add-on modules, such as mod_security, which firms may find useful.

Apache is not a feature-rich or complicated application. Its main feature is its simplicity, portability and ease of installation. It does, though, allow users to cache frequently accessed files, java script files, .css file and images, as well as pages that change very infrequently. It should not be used to cache content that can change regularly, as this will result in serving out of date content. The idea of caching is: Apache stores whichever pages it is able, and when these are requested, Apache locates the file in its cache and returns it immediately, without even accessing the OpenEngagement DMS.

For greater caching flexibility, users will need to use Squid. Squid is used by users requiring many hundreds of hits per second, which is almost always unnecessary for OpenEngagement DMS users.

Firms should properly test their sites once caching is enabled. If done improperly, it may allow users to access content they do not have permission to view. For example, if a site does not use Apache or Squid, and a user requests a page, the CMS will first check if that user has permission to view the page before displaying it. But, if Apache or Squid cache this page and a user requests it, they may simply return the page without checking the CMS to ensure user has permission to view it.

With respect to caching files, Apache has a module which can perform very effective caching, though Squid, another open-source product, is designed specifically for this purpose, and can likely do a somewhat better job. Many Plone sites use both Squid and Apache, though this is overkill unless you have very high web traffic. With caching, it takes some effort to tweak the settings so that performance is near optimum. The idea of caching is, if pages are accessed often, such as perhaps the OpenEngagement DMS home page, or a view on a commonly-accessed Engagement, it is not efficient for the OpenEngagement DMS to generate the page for every access; it is more efficient for Apache or Squid to cache the page, and to simply serve this cached page to users. This can, though, result in displaying out-of-date information, often referred to as stale data. For example, a user, say, Mary, accesses the Local Roles page of Engagement tax2001, then another user, say, Sam, changes the local roles on Engagement tax2001, causing the display of the Sharing page to change. If Mary then navigates to another page in the CW CMS, and then back to that page, and if Apache or Squid simply gives her the cached version of the page, instead of one created at that time by the OpenEngagement DMS, the page will be out of date; it will not show Sam's changes. It is recommend firms only cache .css, images, and java script files in order to eliminate this possibility.

Caching files can also lead to security holes. For example, Apache or Squid may cache the page related to the View tab for a given Document. If a user who does not have permission to view this page requests this page, Apache or Squid will not check the permissions of the user; if the page is cached they will simply return it to the user.

Note as well, while most images may be safely cached, firms likely do not wish to cache all images. Some images may represent, for example, scanned documents or other content whose access should be protected by the OpenEngagement security system.

The Zope Management Interface (ZMI) is available only to users of the Local Solutions. The ZMI is a collection of administrative pages for the OpenEngagement DMS. Administrators have full access to the ZMI and Managers have access to most of the ZMI. Other users have no access to the ZMI.

The ZMI is, in a sense, an alternative view on the DMS. But, it is best to think of the ZMI as a place where certain specific and discrete tasks are performed, which are distinct from those performed outside the ZMI. For example, content should never be added in the ZMI (this causes problems later when searching for data, performing state transitions etc.)

This document does not describe the ZMI itself, but does discuss some specific tasks that can be performed in the ZMI one at a time. It is highly recommended users do not perform any tasks in the ZMI otherwise, as it is full of opportunities to adversely affect your site, is very large, making things difficult to find or undo, and is generally quite confusing.

The OpenEngagement DMS keeps the files uploaded to Engagement and File objects on the file system and not within its database. This ensures the files are safe given a database failure. The OpenEngagement DMS uses a database known as the Zope Database, which is very widely used and is generally considered to be more stable than SQL databases. However, failures are possible with any software, and if the database becomes corrupt, the files will still be safe; users will not have to recover them from a backup.

External Storage is visible only to Local Solutions users, but is used by Hosted Solutions as well.

External storage preserves the file's original name, so a user may, if they wish, run the Engagement Manager on the computer on which the DMS is installed, and they will see all the client files stored within the DMS.

Usually though, users will not need to look at the external storage unless it is necessary to restore a site.

The OpenEngagement DMS has a number of tasks that are scheduled to run daily at midnight. Users may notice the site slows down during this time.

On Local Solutions, this includes a database backup. The backup includes only the database itself, and not the files which are kept in External Storage. Firms should backup the entire DMS instance themselves regularly, so this backup should be redundant, but is included for additional security for users.

All other scheduled tasks run on both Local and Hosted Solutions. These include: catalogue re-indexes, error log rotation, automatic archiving of Documents, and database packs.

Local Solutions users may, if they wish, modify the scheduling of these tasks in the Windows control panel.

With Hosted Solutions, restore operations will be performed by OpenEngagement. Users should simply notify OpenEngagement of database problems, and we will address these if we have not already begun to do so.

With Local Solutions, users should perform regular, complete backups on a scheduled basis. Because the firm's content is kept in one location, backups are simpler for firms when using the OpenEngagement DMS than when not using it, but backups are still necessary. These firms should backup the entire Data/var directory of the DMS, as to cover the database (the Data.fs file) and the External Storage (all files uploaded to Engagement and File objects). The backup should copy the var directory to another computer, to protect the backup against hard-drive failures, viruses and so on. Ideally, the backup should be to another building, so firms are also protected from fire and other such issues.

The OpenEngagement for Local Solutions ships with a database backup. This provides a minimal degree of security for firms, but it includes only the Data.fs file and not the External Storage. Firms should not rely on this backup. The data.fs file includes the metadata, user accounts, local roles and similar information. It includes all data other than the uploaded files themselves.

If firms do their own full backup and there is a database failure, they should do a restore using this backup. If this is not available, or there is no recent backup, firms may use the backup of the Data.fs file. However, this may be out-of-synch with the External storage, so not all of the DMS will be accessible. In this case, portions of the DMS may need to be re-created.

The script to provide the backup of the data.fs file is called BackupWithRepozo.bat. A readme file is associated with this file. The readme file explains how the script may be modified to backup to another destination. Most firms can use the default backup directory.

Firms using Local Solutions are also advised to also use replication, or to at least have backup hardware available in the event of a hardware failure.

SSL is provided with Hosted Solutions. Firms using Local Solutions may also wish to use SSL, and, if so, will likely wish to install an SSL certificate.

Installing a certificate will allow users to avoid the dialog asking users if they will accept the certificate when accessing an OpenEngagement site that uses SSL through a web browser. Some firms may wish to keep this dialog, as it is a simple means to confirm the OpenEngagement server is, in fact, using SSL. Others may wish to remove this dialog. It is displayed because Internet Explorer, Firefox and other web browsers have, by default, only a small number of recognized Certificate Authorities. If these instructions are not sufficient, additional information may be found on-line as well, as this is common administrative task with secure websites.

Note: These steps require a .pem file, which may be supplied by OpenEngagement. This file actually contains an RSA key and certificate. When installing this via these instructions, only the certificate part of the file is needed. Therefore, users will need to delete everything in the file before "-----BEGIN CERTIFICATE".

Installing a Certificate

To use the OpenEngagement CMS without being prompted with certificate security warnings every time you visit the page, you will need to install the OpenEngagement security certificate. Installing the certificate will allow your browser to accept that you have deemed the OpenEngagement CMS secure and that the browser does not need to ask if you wish to continue every time you visit.

You will need to manually set up your web browser to accept the certificate. The method of configuring your web browser is outlined below for Internet Explorer and Firefox.

Internet Explorer

First, open Internet Explorer. Once the browser is open, open up Internet Options (Tools | Internet Options) and click on the Content tab.

Next, click the Certificates… button near the centre of the window.

Now click the “Trusted Root Certification Authorities” tab at the top of the window.

Click the Import button.

On the first new windows that welcomes you to the Certificate Import Wizard, you can just click the Next button. You should read the information before clicking Next if you want more information about exactly what you are doing.

After clicking next, click on the Browse button on the new window.

In this window, you will first need to set the Files of type option to All Files (*.*)

Now, you will need to Browse to the location of the permissions file. This will be stored in the OpenEngagement directory. The name of the file will be apache.pem or just apache.

After selecting the certificate you want to use, clicking open, then clicking next, you will be presented with a new window. On this window, you need to set it to place all certificates in the “Trusted Root Certification Authorities”. If your screen does not show “Trusted Root Certification Authorities” like it does in the screen-shot, you may need to click the Browse button and select “Trusted Root Certification Authorities” and click OK. After ensuring the box says “Trusted Root Certification Authorities”, click next.

After this, you might be presented with a security dialog. This dialog may also appear after clicking Finish at the next step. Either way, click Yes at this dialog as long as it identifies the certification authority as “www.openengagement.com”

That’s all there is to it, just click Finish and you are done. When accessing the OpenEngagement DMS from now on, there should be no more prompts asking you if you are sure this website is secure.

Firefox

First, open Firefox. Once the browser is open, open up Options (Tools | Options) and click on the Advanced button and click the Security tab. Now click the View Certificates button

Now click the “Authorities” tab at the top of the window and then click the Import button.

Now click on the Browse button and browse to the location of the permissions file. This will be stored in the OpenEngagement directory. The name of the file will be apache.pem or just apache.

At the “Downloading Certificate” dialog, check all three check-boxes before clicking the OK button.

That’s all there is to it. When accessing the OpenEngagement DMS from now on, there should be no more prompts asking you if you are sure this website is secure.

When re-installing the DMS you must first un-install it, which may be done from Add/Remove Programs in the Control Panel. Running the un-install operation, the database will not be wiped out, as there may be data your firm wishes to keep. You may, after running the un-install, manually delete any other files if you wish. Running the un-install may work sufficiently, but where it does not you must follow these directions. Note: do not do this when simply upgrading to a new version of the DMS server; this will wipe out the database and all external storage. 

Running the Un-Install

The un-install removes some, but not all, files associated with OpenEngagement, removes the scheduled tasks, the Zope service, removes the Manage OpenEngagement shortcut and Start Menu program group. After doing this, you should be able to run the install program again. If OpenEngagement was not completely removed, however, the installer will simply perform an un-install operation. After this completes, you may run it again to perform the install.

To completely un-install Open Engagement manually:

First, the Zope service should be stopped. This can be done through the control panel, Administrative Tools, Services. If there is any Zope service listed as Started, you may stop it.

If this does not work, you may try stopping it manually. Open a command prompt and navigate to your Instance Directory (C:\Program Files\Open Engagement\ by default). Navigate to \bin. Type python.exe zopeservice.py stop. Type python.exe zopeservice.py remove

This should stop and then remove the Zope Service. You may check this in Control Panel | Administrative Tools | Services. Check that the Zope Service at C:\Program Files\OpenEngagement is no longer included in the list of Services.

Go to Add\Remove Programs and un-install any instances of OpenEngagement, then any of Plone, then any of Zope.

You can now safely delete the entire C:\Program Files\Open Engagement\ instance directory (note all user data will be lost) as well as c:\Program Files\Plone 2 and c:\Program Files\Zope. The actual location of these folders will vary depending on where you specified they be created during the original installation.

Go to Control Panel | Scheduled Tasks and delete any Open Engagement scheduled tasks.

Once this is done, restart the computer.

Finally, you can remove the Open Engagement keys from the Registry, which are located in HKey Local Machine\SOFTWARE\Zope. Additionally, check for references to OpenEngagement under CaseWare and CaseWare International. Delete the OpenEngagement registry entries. You may then search for and remove any other instances of OpenEngagement, Plone or Zope in the registry.

At this point you may re-install OpenEngagement. If it is not yet possible to re-install, you may use the Windows Installer Cleanup Utility. There will still be a record of the Open Engagement installation in the Windows Installer Database. You can remove this by using the Windows Installer Cleanup Utility (use with caution; you can break other programs if you select them by accident). Look for the (All Users) Open Engagement entry, select it and press Remove.

The Windows Installer Cleanup Utility can be located here: http://support.microsoft.com/default.aspx?scid=kb;en-us;290301. Do not use this utility unless necessary. Once installed, it should appear in C:\Program Files\Windows Installer Clean Up\msicuu.exe. You may check here first to see if the utility is already installed.

By default, the OpenEngagement CMS uses port 80, which is the standard port for HTTP (i.e., for web sites). Firms may wish to use other ports for a variety of reasons. One may be to allow another application on the same computer to use port 80. Another reason may be to allow installing multiple instances of the CMS on the same computer. To change the port used, modify the port in the zope.conf file and restart the CMS.

Re-indexing is not available on Hosted Solutions.

Re-indexing (or re-cataloging) the database is a technique that may be used to improve the performance of the site or to correct errors in the site, such as items not appearing properly in the navigation portlet or in searches.

In the ZMI, goto portal_catalog, and under the ‘Advanced’ tab, click Update Catalog.

Re-indexing the site is also done nightly as a scheduled task. This script may also be run manually at any time. To do this, through a web browser, log in an Administrator or Manager and enter the URL of the site followed by /reindexSites.