Sophora Server

The Sophora Server manages the entire content repository. There are three different roles a Sophora Server can have: Master, Staging and Fall-back.

Live-Workspace

Beside the default workspace, a second so called "live" workspace exists in the repository. The default workspace contains the last available state of every document. Every operation (save, publish, delete, ...) modifies the document in the default workspace. In contrast the live workspace contains the last live state of every published document.

Only documents which currently have a live version are included in the live workspace. Every time a document is published, a copy of the document is saved in the live workspace. Every time a document is set offline or deleted, the document is deleted from the live workspace. Thus, the live workspace represents a complete set of currently available live documents. To avoid redundant data in the repository all binary properties are omitted when copying documents from the default to the live workspace.

The live workspace is used for efficient execution of queries dealing with the live state of documents. E.g. the execution of timing action scripts (com.subshell.sophora.api.scripting.ITimingActionScript) which refer to document properties (e.g. broadcast date) of the last live version. If these properties were modified in the last working version without being published, it was impossible to find the relevant documents in former versions of Sophora. Now the queries for timing action scripts are executed in the live workspace and thus refer to the properties of the last live version.

For compatibility reasons, the queries for existing timing action scripts continue to be executed in the default workspace. To enable the new query mode the timing action scripts must implement the interface ITimingActionScriptSearchInLiveWorkspace (from package com.subshell.sophora.api.scripting).

To use the new live workspace in other contexts, the IContentManger interface offers a new method findPublishedDocumentUuids().

For every workspace in general, a separate folder in the directory repository/workspaces exists. So beside the default workspace in repository/workspaces/default now a folder repository/workspaces/live exists. It contains the separate lucene search index and a workspace.xml. If the data is stored in a derby database, also a folder for the database ( repository/workspaces/live/db ) exists. The workspace.xml contains the configuration for the database. If the file does not exist it is created with a default configuration. In this configuration the derby persistence store is used. In most cases the database for the live workspace is much smaller than the database for the default workspace (because of the omitted binary data). In addition the data within the live workspace can be derived from the data in the default and the version workspace (see next chapter). Thus, the requirements for the database are not as high as for the other workspaces (default and version).

Updating the live workspace

After an update to the new Sophora version, the live workspace is created automatically without any data. To fill all currently available live documents into the new workspace an update process has to be started.

To update the live workspace, you need to connect via JMX to the Sophora server. There is a MBean LiveWorkspaceUpdater on which the operations startUpdate and stopUpdate can be called. Moreover you can set an interval (in milliseconds) which is waiting between the copy operations for each document. After the update is started, you can see the number of documents currently in the live workspace (ExistingDocumentsInLiveWorkspaceCount), and the number of published documents in the default workspace (DocumentsWithLiveVersionCount). The attribute RemainingDocumentsCount shows you, how many documents still have to be processed. To determine RemainingDocumentsCount a query called, so monitoring can slow down the Sophora Server.

Automatic Workflow

Documents in Sophora have different workflow states: for example working, released, published. Changes to these states can be done manually via the rich client or by other programs via the Sophora API. Beside this, there are state changes which are done automatically by the Sophora Server.

If the Sophora Server is not running while a date for an automatic workflow step is reached, the document state will be changed two minutes after the Sophora Server start.

Publish at

It is possible to schedule an automatic publish operation on a document. To accomplish this, two steps have to be done:

Setting the property sophora:publishAt with a date in the future
Publish the document

When the date of the property sophora:publishAt is reached, the Sophora Server publishes the document without any checks. It is not relevant whether the document had an older published version or had no published version at all. The publish operation is done by the Sophora Server, however, the value for "published by" is taken from the configured value in the property sophora.autoPublish.username. If this property is set to "[LAST_MODIFIER]" the Sophora Server takes the "modified by" value from the document and copies it into the "published by" property of the document.

Online to (End date)

It is possible to schedule an automatic offline operation on a document. To accomplish this, two steps have to be done:

The property sophora:endDate must be set.
The document must be published.

Changing the document afterwards will not stop the automatic offline operation. To change the offline date, the document must be published with the changed (or removed) date. The Sophora Server always takes the offline date from the last published document version. The offline operation is done by the Sophora Server, however, the value for "published by" is taken from the configured value in the property sophora.autoOffline.username. If this property is set to "[LAST_MODIFIER]" the Sophora Server takes the "modified by" value from the document and copies it into the "published by" property of the document.

Cyclic Online/Offline

It is also possible to configure a cyclic online/offline workflow where documents will be set online/offline via a cron expression. To configure such a behaviour, you have to configure two properties:

sophora:cronOff
The cron expression set in this property will be used to set the document offline periodically.

sophora:cronOn
The cron expression set in this property will be used to publish the document periodically.

You can configure these properties by including the mixin sophora-mix:cronControl in your node type. You will also get two additional properties: sophora:cronNextOffDate and sophora:cronNextOnDate. These properties will be used internally and should not be edited manually.

Changing the document afterwards will not stop the automatic online/offline operation. To change the behaviour, the document must be published with the changed (or removed) properties. The Sophora Server always takes the cron expressions from the last published document version. The offline and publish operations are done by the Sophora Server, however, the value for "published by" is taken from the configured value in the property sophora.cronOffline.username. If this property is set to "[LAST_MODIFIER]" the Sophora Server takes the "modified by" value from the document and copies it into the "published by" property of the document.

The content of this page is licensed under the CC BY 4.0 License. Code samples are licensed under the MIT License.