Workgroup Server

The Content Manager Workgroup Server provides a connection between the client computer and the primary database, content index and object stores. Ideally, one Workgroup Server is configured for each group of users in a local area network (LAN).

The Workgroup Server:

• Opens connections to the primary database.

  A connection is shared by users in the Workgroup and significantly reduces the number of connections that the database server is required to manage.

• Re-directs retrievals to replicated database tables - if this feature is selected - document content indexes and cached objects
• Handles update buffering for the main database.

  Content Manager sends transactions to the Workgroup Server in a job lot.

• Supports streamed document caching, whereby it displays pages as they are received rather than waiting for the entire document to download
• Processes events to update the dataset
• Coordinates date and time details between the client computers and the Content Manager Servers.

  If there is a difference of more than 10 seconds between the two clocks, it prevents updates as this would indicate that someone has manually changed the clock on the local computer while logged on to Content Manager.

  If this is the case, the user must log out and then log back in to re-synchronize with the network clock.

  If a user's system clock date does not match the server date, the Workgroup Server will deny that user access to the Workgroup Server.

The Workgroup Server implements the connection pooling component of Microsoft Data Access Components (MDAC). Content Manager clients use the functions of the Workgroup Server to obtain data from the dataset. The connection is established at the Workgroup Server and then passed on to the client. This enables client computers to operate without the significant overhead of database specific communication layers. This connection is restricted to users of user type Inquiry User.

All Content Manager updates are formatted at the client computer and then passed to the Workgroup Server. This packaging is transaction-based which enables multiple updates to be collected into single transactions.

One of the key functions is to allocate serialized unique record identification (URI) numbers. Every row in every table has a URI. Content Manager Workgroup Servers generate serialized numbers for records, Classifications and other objects and filename identifier numbers for documents.

Content Manager’s Workgroup Server can support a replicated database environment.

It redirects search requests to a local read-only replica of the primary database while still performing all updates, inserts, deletes and lock processing on the primary database.

Semi-static data such as Record Types, Thesaurus terms, Classifications etc. are held in an in-memory record set cache. When the Workgroup first connects to a particular dataset, it reads this data from the dataset into the Workgroup Server memory. Requests from clients for this data are resolved at the Workgroup Server. The Workgroup Server responds to messages that indicate that the cached data has been changed, and reloads it on demand.

The Workgroup Server provides all electronic document services. This includes the storage and retrieval of documents. In addition, the Workgroup Server maintains a cache of all documents that were added through that server, or were requested for retrieval from clients of that server. This means that clients can access electronic documents at LAN speed rather than across the slower Wide Area Network (WAN).

The Workgroup Server is designed to remove potentially time consuming tasks from client computers and process them centrally. It ensures the best possible performance of Content Manager by making certain maintenance and support tasks a simple background process and is responsible for batch processing of non-critical data.

Content Manager collects events and sends them to the Workgroup Server as part of an SQL transaction.

For example, a user has used dragging to copy the file report1234.doc to Content Manager. The metadata that is created as part of this process is a series of inserts and updates which are accumulated until the code reaches a commit() request. Various events will be included as part of the transaction request. The SQL transaction is sent to the Workgroup Server for processing.

The Workgroup Server keeps a record of all currently logged in Content Manager users, mainly to assist with administration activities.

Each Content Manager client needs to be configured to connect to a particular Workgroup Server which is typically on the same fast local area network (LAN).

The SQL database can be accessed remotely over a wide area network (WAN).

You can set up as many Workgroup Servers as needed to manage the load.

Workgroup Servers have a self-registration process.

A generic Workgroup Server can be defined to provide default values for Workgroup Servers that are not defined explicitly. Workgroup Servers that are not defined explicitly use these defaults.

Configuration details are written to an .xml file. This configuration file is version stamped. Each Workgroup Server has a copy of it and is capable of synchronizing with other Workgroup Servers to make sure they all have the most recent version. When a Workgroup Sever starts up, it finds the largest version number and requests a copy of it. When a Workgroup Server receives an updated configuration file, it takes the necessary steps - for example:

• the administrator may have requested that no further activity happen against the database

  or

• the Workgroup Server cache setup has changed