5.2.2 Authoring Environments 

Table of contents | Next | Previous

Authoring Environments - sample configurations

The authoring environment for Web Content Management is where the content authors and developers create content. Assuming a three-tiered environment, content will be developed and created within an authoring environment, then ultimately syndicated out to a staging environment, and finally, syndicated out to the production environment. The objective of this article is to discuss configuration examples, best practices and considerations for configuring the authoring environment. Throughout this article, we will be refer to the RiverBend context. Specific topics include:

• Configuration of a Typical Authoring environment
• Authoring Environments - Separating Content and Design Editing
• Advanced Previewing of draft content in the context of WebSphere portal
• Geographi cally distributed authoring

 

Typical Authoring environment

In a typical environment, WebSphere Portal and Web Content Management are deployed on the same node.  In failover scenarios, there is a backup node and the nodes are clustered.  WebSphere Portal and Web Content Management share a common user registry (LDAP server).  However, they have unique database servers. Authors and designers access the portal and Web Content Management through an HTTP server that direct them to the first available node in the cluster.
 
The following figure shows a typical clustered authoring environment.

Example of a typical authoring environment

The use of a cluster in an authoring environment is optional, however its use can provide failover, when the Backup Node is configured for failover only, and/or performance benefits, when the Backup Node is configured for load balancing and failover.

The figure below illustrates the following design for an authoring environment that the RiverBend Company decided to use.

Example of Authoring Environment implimented at RiverBend Tea and Coffee company

 

Authoring Environments - Separating Content and Design Editing

If you need a separate design editing environment that is separate from content creation, then consider the split-authoring server approach.
 
In the configuration shown in the following figure, the authoring user interface on the design editing server should be locked.  Authors should not access content on the design editing server. A common LDAP server is used for both servers.
 

Sample configuration with separate Content and Design editing servers

 
Content Creation

Content authors work on the Content Editing Server.  They add, modify, and delete content, such as sites and site areas in the Content Library on the Content Editing Server. They can optionally work with images and file resources too.
 
Test content can be created either in the real Content Library that’s syndicated from the ‘Content Editing’ server OR in a separate ‘Test Content’ library
 

Design Creation

Designers add, edit, and delete design components, such as page designs, categories, workflow definitions, templates, and additional images or file resources.  These resources are located in the Design Library on the Design Editing Server.
 
When creating Menu’s and Navigators (that use Site Areas and Categories), they are configured to point to the local copy of the Content library 
 
To conduct design reviews:

1. All design components should be placed within a three-stage workflow.
2. Design reviewers then preview design components in the approve stage using content from the Test Content Library. 
3. Reviewers promote design components to the final stage after the review is complete.
4. All live design components are syndicated to the Content Editing Server.
5. The designers then update the presentation and authoring templates mappings on the Content Editing Server as needed.
6. All live design components and content are then syndicated to the Staging or Delivery environment.
   

Note: If you don’t want to enable workflow on design elements, then change the syndication from the ‘Design Editing’ server to the ‘Content Editing’ server to be manual instead of automatic. The syndication from the ‘Content Editing’ server to the ‘Design Editing’ server can be manual if you want the content on the design server to be stable during design changes The Authoring UI on the ‘Design Editing’ server should be locked down so that the ‘Content Author’s can’t access it A common LDAP server is implied

Because the RiverBend team will be handling both the development of the authoring system and the entry of the content itself, they decide to use a single server for both the development and authoring phases. This reduces the number of servers the team will need to maintain, which is good. But it will also require their team to communicate well to ensure that changes from one developer do not affect the work of another. Since the RiverBend WCM team is relatively small, they are comfortable that the single-server approach will work well.

Advanced Previewing of draft content in the context of WebSphere portal

The Sales and Marketing team of RiverBend is providing the WCM team with the raw content, but before the content goes live on the intranet, the content needs to be reviewed and approved by Corporate Communications and Legal representative. Because the Web Content Management content will appear on a page that includes information from other portlets, it is important that the content be reviewed in context. To make this possible, RiverBend decides to use the same portal development server that is used to develop and maintain the RiverBend intranet site to preview the Web content. Using a remote rendering portlet on the portal development server, Corporate Communications representatives will be able to review the content in the intranet context before the updates are moved to the delivery server. The content displayed in the rendering portlet is sourced from the authoring server. Only when they are happy with any changes to content and design will they syndicate these changes to a staging server.

Delivery

Web Content Management is ready for you to use as is to preview draft content in a WebSphere Portal site. However, it does not let you preview the draft content in any menus, navigators, or JSP pages or validate the security settings for the published content.
 
To preview drafts with menus, navigators, JSP pages, and valid security, use the architecture illustrated in the following figure.

Sample configuration with Preview Server
 
This preview server configuration (shown in the figure above) uses a three-stage workflow (Draft, Approve, and Publish).  

• Both the Authoring Server and Review Server contain copies of the static portal site.
  • The Authoring Server has its preview portlets configured to show draft content around the static portal site.
  • The Review Server has local rendering portlets deployed to show published content around the static portal site.
• When Authors are ready to have their content/objects approved, they must first move the document to the Approve stage on the Authoring Server.
  
• If only a simple review is required (textual content only):
  • Reviewers on the Authoring Server locate items in the Approve stage and preview them in the available preview portlets on that server.
  • If reviewers are happy with the changes, they approve the items on the Authoring Server. 
  • If reviewers are unhappy with the changes, they click Decline on each item in the Authoring Server.  If the content or object has a two-stage workflow, then reviewers restart the workflow instead of clicking Decline.
• If an advanced review is required to preview the draft content in any menus, navigators, or JSP pages, or to validate the security settings of the published content:
  • Reviewers on the Review Server locate any items in the Approve stage and click the Approve button to make the items live.
  • After the items are live on the Approve Server, they can be reviewed in the context of the portal site.
    • If reviewers accept the changes, they approve the items again on the Authoring Server.
    • If reviewers do not accept the changes, they click Decline on each item in the Authoring Server. 
    • Note: - If the content or object has a two-stage workflow, then reviewers restart the workflow instead of clicking Decline.
      

The RiverBend Web site is powered by WebSphere Portal Version 6.1. The new content that is created by the RiverBend Corporate Communication team is working on will ultimately be made available to the internet customers as part of an existing set of information currently displayed through several portlets. The new information needs to fit seamlessly into the existing page structure,so RiverBend decides to deliver the Web Content Management content with a remote rendering portlet on the delivery server (which is already in place as the current internet portal). The content displayed within the rendering portlet is sourced from the staging server.

Geographically distributed authoring

When your company’s content authors are geographically distributed across a distance that prohibits various departments from working on a single, centralized server, use the distributed authoring approach.
 
The following figure shows an example of a distributed authoring environment.

Example of a distributed authoring configuration

• A common LDAP server is used for all authoring servers.
• The taxonomy tree and common components are created on the Common-Design Authoring Server.
• Each set of Department Authors and Designers work on their own server and the respective authoring portlet on each department server is locked to prevent access by other departments.
  • Department Authors should only be able to view the content management section of the authoring portlet.
  • Department Designers should not be able to view the category management section of the authoring portlet
• The data on the Enterprise Authoring Server can be backed up to avoid having to re-syndicate the data from each Department Server.
  
• Several options exist exist for developing the site framework in a geographically distributed authoring environment. These scenarios include:
  
  • A separate site per department in which:

  • Designers on each department server create and maintain their own site framework.
  • A separate Web Content Management library exists for each department and a separate Web Content Management library exists for the common design elements.
    

  • A shared site across all departments
  • Designers on the common design-authoring server create the top level site object and two levels of site areas per department. This concept is illustrated in the figure below:

  

  • For example:
    • The security is configured so that only the designers on the common design-authoring server have edit access to the top level site and the root site areas for each department. The department designers are the only users who can edit the second level (such as, Department 1 Main or Department n Main) site areas.  For example, the common designers create the second level site areas for each department, then remove themselves from the list of people able to edit each site area.
    • Web Content Management content authored on the department servers are placed under the second and subsequent site area levels, rather than under the root site area for each department.
    • Page designs and templates created by the designers on the common design-authoring server are associated at either the top level site or the root site area of every department

The objective of this article is to discuss configuration examples, best practices and considerations for configuring the authoring environment.