Best Practices from Oracle Development's A‑Team

Working with Multiple Versions of an Asset Concurrently in WebCenter Sites

Vivek Singh
Principal Solutions Architect

Working with Multiple Versions of an Asset Concurrently



Many times there is a requirement to work on the multiple versions of an asset concurrently. For example, you may be working on one version of Home Page. But, before the version of Home Page goes live, you may have to start work on the next version of the Home Page. Some companies change their Home Page every day, and the business process require several days before a version of the Home Page is approved. In such cases, you may need to work on multiple versions of the Home Page concurrently.

WebCenter Sites does not support multiple versions of an asset. It does have revision tracking. You can save old versions of an asset. But, there can be only one current version. So clearly, one cannot use revision tracking to create multiple versions of an asset and work on them concurrently.

In this blog, I examine the issues, and look at some of the strategies to be able to work on multiple versions of an asset concurrently.


Site Preview Capability

The Site Preview Capability allows assets to have Start-Date & End-Date. In the delivery system, the asset is displayed between Start-Date & End-Date. In the Management/Authoring system, Content Authors can set the date and preview site as it will look on that date. I had written a paper on “Site Preview In WebCenter Sites” in A-Taem Chronicles. For more details about Site Preview, you can access that paper here.


Limitations of Site Preview Capabilities

Site preview was designed to enable content authors to create, approve and publish assets in advance. If a promotion is designed to go live at 2:00 AM EST on Sunday, the promotion can be approved and published on Friday (or earlier). It will go live at the designated time. But, Site Preview functionality was not designed to take care of multiple versions of the same asset. However, it is possible to use Site Preview Functionality to meet the business requirements of working with multiple versions of the same asset.


Using Site Preview to Render Multiple Versions of Same Asset

Let us examine the case of a company that wants to change its Home Page every day, and has a business cycle of one week to approve the Home Page. In this case, the Home Page must be created every day and put in work-flow for a week. During the week, it gets all the approvals. Every day, the Home page for next day gets published to delivery.

Let’s look at what does this case entails:

  • It requires that you create one Home Page asset every day.
  • That you should be able to put the Home Page through a work flow.
  • While this Home Page asset is in work-flow, you should be able to create the Home Page asset for next day, and put that also in work-flow.
  • In fact, there will be six or seven Home Page assets in workflow at any given time.
  • The Home Page assets should use Start-Date, End-Date and Site Preview capability to make sure the correct Home Page is rendered in the live website.
  • The Home Page asset can be associated with other content assets, and those content assets can have their own Start-Date and End-Date.


All this can be done by using Site Preview capability. However, only using Site Preview capability throws up the following issues:

  • Each Home Page asset is a separate asset, and has its own URL. As a result URL for the Home Page will change every day.
  • Since you are creating Home Page asset every day, over time you will create lots of Home Page Assets, and they need to deleted and purged from the system.


Using a Page Container Asset

To take care of the limitations of simply using multiple Home Page assets and Site Preview capability, we can create a Home Page Container asset, and associate the Home Page assets with the Home Page Container asset. Now the URL for the Home Page is the URL for the Home Page Container, and it always stays the same.

Also, we can create seven Home Page assets, one for each day in the review cycle, and associate all the seven Home Page assets with the Home Page Container. The start-date & end-date for each Home Page asset should ensure that at a given time, there is only one valid Home Page asset. There is no need to create one new Home Page asset every day, but we can recycle and use the old Home Page assets. Say on eighth day, we re-use Home Page asset 1, and on ninth day, we can re-use Home Page asset 2. Thus there is no need to delete and purge old and expired Home Page assets.

The structure of the Home Container, Home Page assets and content assets may look like following:




Advantages of This Approach:


This approach has the following advantages:

  • It utilizes all out-of-the box functionality from Sites. There is no customization. All the feature and power of Sites is fully available to the Content Authors.
  • Business Users can utilize the Site Preview functionality to preview how the website will look at a future date.
  • The Home Page assets are associated with Home Page Container during initial set-up days. Once the Home Page Container is associated with all the Home Page assets, and published to delivery, it does not have to be re-published to delivery again. Thus there is no need to publish Home Page Container every day.
  • It avoids creating new Home Page assets every day, because we are re-using the Home Page assets. Thus there is no need to delete and purge old Home Page assets.



Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha