Web Content Management Authoring Environments 

Typical Web Content Management authoring environment
Separating Web Content Management content and design
Authoring and Preview Environments
Geographically distributed authoring with Web Content Management

Typical Web Content Management 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.

Separating Web Content Management content and design

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.


Notes

• 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

Previewing draft Web Content Management content in a portal

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 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.

If only a simple review is required (textual content only):
1.        Reviewers on the Authoring Server locate items in the Approve stage and preview them in the available preview portlets on that server.
2.        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:
1.        Reviewers on the Review Server locate any items in the Approve stage and click the Approve button to make the items live.
2.        After the items are live on the Approve Server, they can be reviewed in the context of the portal site.
3.        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.  If the content or object has a two-stage workflow, then reviewers restart the workflow instead of clicking Decline.

Geographically distributed authoring with Web Content Management

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.
  
  Options for developing site framework
  Various scenarios exist for developing the site framework in a geographically distributed authoring environment.
  • 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 in which:
      • Designers on the common design-authoring server create the top level site object and two levels of site areas per department. 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.