Detailed information about the generation and the publication of a rendition
This document describes the relation between state, renditions and publishing.
My document is not available
A document can be in one of the following states: WIP, Staging, Approved, Active or Expired.
The difference between Approved and Active documents is that Approved documents have their activation date set in the future. When the activation date arrives the document status will be set to Active.
Documents in the WIP, Staging and Active states are published to a server specific to their state. Approved documents are published on the Staging server; Expired documents are not published at all.
The following table shows how a document can change its state.
|WIP||n.a.||Promote||Powerpromote before activation date||Powerpromote after activation date||n.a.|
|Staging||Demote||n.a.||(Power)promote before activation date||(Power)promote after activation date||n.a.|
Note that this table only shows the state of one version of a document, but different versions can be in different states. However, between all versions the labels are unique; i.e. there can only be one version in Staging at the time.
When a document is edited, a new version is created in WIP. The previous version will continue its own lifecycle.
Publishing and regeneration
Publishing a document means transferring it to a web server so it can be viewed. There are different ways to publish a document:
- On your request (via the menu)
- As a side effect of another operation, such as a promote, regeneration or webview
- Via the publication job that runs every night minutes and picks up unpublished documents that were changed since the last run
Changes in the HTML rendition of documents can be caused by operations you do, such as changing the attributes or the content but can also be the result of an action done by another user.
An HTML rendition depends on the language coverage and state of the documents that it is referring to, so it must be recreated when a referred document changes; e.g. when a translation is added or when it is moved.
The system detects these events and demands a regeneration of all referring documents.
Another reason for the recreation of an HTML rendition can be a scheduled regeneration.
Most of the regenerations are done by the DocGen application. The DocGen application reads from the regeneration queue that holds references to the documents that should be regenerated.
Sometimes there can be many documents in the queue and it can take a while before the new rendition is created. The queue supports prioritized requests; requests with a higher priority are always treated before requests with a lower priority. The following table gives an overview of which action leads to which priority.
|Send to Queue||3|
|Send Subsite to Queue||2|
|Send Subsite to Queue (descending)||1|
|Apply XSL small batch||3|
|Apply XSL large batch (> 30)||2|
|(Power) promote small batch||5|
|(Power) promote large batch (>50)||4|
Note that the 'Regenerate and Publish' action does not go via the Regeneration Queue, it is executed immediately.
When documents are regenerated because of a change in another document the following priorities apply:
Documents updated by the DocGen are put in the publishing queue. The DocPub application monitors this queue and publishes the documents as soon as possible.
Promoting a document
When you promote a document to Staging its HTML rendition is published on the Staging server before the HTML rendition is regenerated. To repair this the document is regenerated by the DocGen application with a high priority.
When you promote, or power-promote, a document to Active, this does not happen. The rendition is recreated, again with high priority, before it is published.
Note that documents that are regenerated as a side effect of this promote have a low priority. It will take more time for them to have a rendition that takes the change into account. They are published as soon as their rendition is recreated.