Best Practice: WebCenter Sites Workflow Start Step

One of the key features of WebCenter Sites is its built-in workflow capabilities. While some see workflow as “onerous”, for auditing purposes it can’t be beat. For the majority of projects, we recommend clients adopt workflow for managing their web content as it will clearly identify who/what/when when it comes to who made the edit, […]

How to implement a custom WCS flex filter

I recently was made aware of a document authored by Noël Jaffré of OCS/EMEA that describes very succinctly how to implement a custom flex filter class for use with WebCenter Sites flex assets. Rather than refactor his well-written document, I simply present it here in its entirety. Anyone who is scratching their head wondering where […]

A useful WC Sites “Tree” query

Sometimes WC Sites developers are required to efficiently obtain the hierarchical list of objects stored in the various “tree” tables as used by the product (e.g. LocaleTree, PublicationTree, SitePlanTree, AssetRelationTree). For example one might need to obtain the hierarchical list of locales for the current dimensionset (e.g. to deal with exceptions to the default fallback […]

Use of commercecontext.setsegments tag

I thought this would be useful to all the Sites developers out there. The <commercecontext.setsegments> tag is useful when under program control you unambiguously *KNOW* the segment(s) of the visitor. With this tag you can just set it as needed without having to do a “calculate segments” based on visitor attributes (which may or may […]

Exporting rendered assets from WebCenter Sites

In this blog post I explain how you can publish rendered assets from WebCenter Sites into other systems. This allows assets to be exported in a rendered form, so they can be consumed by external systems, like Oracle Commerce or a Content Distribution Network (CDN). The initial focus of this work was to improve the […]

Three Patterns for Integrating WebCenter Sites with Oracle Commerce

The A-Team is please to announce the general availability of the white paper Three Patterns for Integrating WebCenter Sites with Oracle Commerce. This paper can be downloaded here. Three Patterns for Integrating WebCenter Sites with Oracle Commerce_v1.1   Note: sample source code to support integrations with 3rd party apps is available here: All content listed […]

Leveraging Fingerprinting with WebCenter Sites

Introduction A common question asked by clients is “how do I create segments for anonymous visitors?”. While tracking anonymous visitors and calculating appropriate segments is a deep subject worthy of its own blog post (check back later!), one must first deal with “how do we uniquely identify a returning visitor who wants to remain anonymous?” […]

Integrating back-end services with WebCenter Sites using a lightweight MVC framework

Introduction Many customers want to use Sites as a ‘thin’ rendering framework and mix web content with back-end applications. An example of such a back-end service might be a application that exposes its interface through a REST API. In this blog I explore a pattern to expose the interaction with such a API through Sites. […]

Working with Multiple Versions of an Asset Concurrently in WebCenter Sites

Working with Multiple Versions of an Asset Concurrently   Introduction 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 […]

Localization Patterns Using WebCenter Sites

Introduction Translating and managing localized web content is a complex undertaking for most enterprises. The number of use-cases WebCenter Sites (WCS) clients have come up with that we have seen in the real-world is enormously varied. One might think that with regard to translations that “all clients have the same requirements” but that is simply […]

Sites Asset Modeling when integrating with Endeca

Introduction The combination of Sites + Endeca is a good fit as the products complement each other nicely with little overlap. However, there is no current best practice for what kinds of modeling changes should be considered (if any) when the two products are integrated. Since Endeca has exceptionally robust tools to precisely control denormalization, […]

Calling the Render tags from Groovy Templates

The WebCenter Sites API does not have a full Java API for the Render tags. Creating a URL for a page or a blob in a Groovy element is not straight forward. Also calling another Template from a Groovy element or any java code, requires a bridge API. In this article we’ll explorer that API. […]

Why use Groovy with WebCenter Sites?

Besides the “cool” factor, one of the main use-cases for Groovy with WebCenter Sites is to invoke it from an XML wrapper or small utility pages like SystemEvents. The wrapper can just be a caller to a java class without the need to wrap it in a Seed and use CALLJAVA. For instance the open-source […]

How to prevent overcaching with WC Sites

Introduction A lot of clients end up implementing a large number of pagelets/components per page which if you are not careful with the details may result in many roundtrips between Sites’ ContentServer servlet and Remote Satellite Server. We can best describe this situation as a classic case of “overcaching”. To build their pages, the vast […]

How to leverage MVC with WC Sites

Introduction MVC is a proven methodology for creating web applications. How can we best leverage this in WC Sites? Main Article There are various ways one could leverage proven MVC design patterns when it comes to implementing projects using WC Sites. For the remainder of this paper, I will take the following approach: MVC at the pagelet level, […]

WebCenter – All articles

Index of WebCenter Sites articles

Single CAS Web Application in a Cluster

Sharing of a single CAS web application is a cluster can be done by externalizing the property in a system property.

Site Preview in WebCenter Sites

Site Preview

Many times, I am asked a question, “the client wants to approve an asset in advance, but the article should go live only at a given time. How can this be implemented?” In WebCenter Sites this functionality is provided through “Site Preview”. This functionality behaves differently on management server and on delivery server.

  • On Management Server
    •  Allows Content Editors to ‘preview’ site in Insite interface for a future date
      • Content Editors see the site as it will appear on a future date
    • Can have a site for summer, winter, fall & spring season or can have a special sale on “New Year Day”.
  • On Delivery Server 
    • Article will go live at the given date & time./>

This functionality utilizes startdate & enddate. These are default fields in all asset types. Content Editor can specify the time when the article appears on the site. On delivery system, the article must appear between the startdate and enddate. For this the cache should be expired at proper times. But, on management server, one should be able to preview the content before the start date. This is achieved by using asset:filterassetsbydate in the JSP templates.

To use this functionality, the Content contributors must create an appropriate set of assets, and the developers must update the templates that render the assets to include the tag asset:filterassetsbydate. This tag performs the following:

  • Determines if it is management or delivery server
  • On management server it:
    • Disables caching of the current page being rendered
    • Accepts the date parameter – passed from the InSite screen date picker
  • On Delivery Server, it ignores the date passed in the date parameter, but uses the system date instead
  • Filters the input list of assets based on the given date to produce the output list.


Caching Considerations

On the delivery system, in order for web pages to be displayed appropriately for the current date, cache must be expired at the proper times. Therefore, WebCenter Sites Cache Engine includes start and end dates in the factors it uses to calculate the expiry time for cached pages.

On the management system, when a page is previewed in the InSite interface, the asset:filterassetsbydate tag disables page caching for that page. This ensures that the page being served always displays assets filtered by the date being passed from the InSite date picker.

Creating Sets of Assets

When different versions of the same item need to be displayed on different dates, content creators need to create multiple assets. For example, suppose you are creating a page in a web site. You want to run a special version of the page for a one-day New Year’s Day sale event. You would need three />different assets to accomplish this task. Here is how you would create the one-day sale: 

  • Create the regular asset, setting its end date to the date before the sale day, December 31st 23:59:00
  • Create the sales event asset, setting the start date to the beginning of the sale day, January 1st 00:00:00, and the end date to the end of the sale day, January 1st 23:59:00.
  • Duplicate the regular asset, setting the start date to the day after the sale, January 2nd 00:00:00

On Management Server, the filter tag will filter the input set of assets according to the given date. Date can be set from preview screen. Pages whose rendering templates use the filter tag are not cached on Management Server.

Limitations of Site Preview

Site Preview allows content editors to preview how the site will appear at a future date. It also ensures that on delivery content will go live at the proper time. But it has the following limitations:

  • The content must be published to delivery in advance
  • It requires creating different sets of assets


Coding for Site Preview

To code template for site preview functionality, the developers must:

  • Create the input list of assets.  List should have assettype & assetid as columns
  • Filter assets using asset:filterassetsbydate tag
  • Process the output list

Create the input list

<%// create the input list %>

// create the input listobject for filtering

%><listobject:create name=’__templist’ columns=’assettype,assetid’ /><%







    %><listobject:addrow name=’__templist’>

                <listobject:argument name=’assettype’ value='<%=ics:GetVar(“c”)%>’ />

                <listobject:argument name=’assetid’ value='<%=ics.GetVar(“cid”)%>’ />




    <listobject:tolist name=’__templist’ listvarname=’__templist’ />


Filter assets using asset:filterassetsbydate tag

<%// filter by date%>


IList templist = ics.GetList(“__templist”);

if (templist != null && templist.hasData())



        <asset:filterassetsbydate inputList=’__templist’ outputList=’__assetlist’    date='<%=ics.GetSSVar(“__insiteDate”)%>’/>





Process the outputlist

The _assetlist now has the filtered assets. One can loop through the _assetlist and display the results.




Read Only User in WebCenter Sites

ReadOnly User in WebCenter Sites

 Recently, I was at a client, and they had a requirement to create a ReadOnly User for WebCenter Sites. By default, WebCenter Sites does not have a ReadOnly user. However, to create a ReadOnly User is a simple task. Before I go into details about how to create a ReadOnly user, let me briefly talk about authorization in WebCenter Sites.

WebCenter Sites uses a combination of ACLs and Roles to provide authorization. Access to assets is controlled using ACLs, Roles, Start Menus & Tabs, permissions in ini files, functional privileges for assets in work-flow, and Access Privileges for controlling access to individual assets.

Access Control Lists

In WebCenter Sites, Access Control Lists, or ACLs allow access to:

  • Read/Write access to database tables
  • Access to URLs (Site Catalog records)
  • Features of the GUI (e.g. xcelpublish allows you to publish)

Some ACLs are preconfigured in the System, and other custom ACLs can be added. All users must have the following ACLs:

  • Browser
  • Element Reader
  • PageReader
  • UserReader
  • xceleditor

These ACLs allow users to be able to login to WebCenter Sites UI. The scope of ACLs is system wide. That is, a user will have the same ACLs, irrespective to the site the user is logged into. ACLs play a role in both Management & Delivery environments. In Management they are needed so a user can login to WebCenter Sites UI and can read/write from database tables. In Delivery, ACLs can restrict the URLs, and pagelets (Site Catalog records) a user can view.


In WebCenter Sites, Roles allow access to:

  • Different User Interfaces (e.g. Advanced User, DASH User)
  • Start Menus & Tabs
  • Workflow States & Function Privileges

Roles are site specific. A user can have different roles on different sites. For example, he can be a Content Editor on one site, and an Approver on another site.

Controlling Access to Assets

Once users are granted permission to access a site their ability to work with the site’s content is managed through:

  • Start menus, determine whether the users can create, search for, and edit assets of certain types.
  • Permissions to assets that are not part of a workflow process.
    Access to assets that are not part of work-flow are controlled through access policies that define which roles have permissions to perform different functions on assets.
  • Permission to assets that are part of workflow process.
    Access to assets that are part of workflow process is controlled through Functional Privileges. Functional Privileges are part of the workflow definitions.
  • Permissions to WebCenter Sites’ tree.
    Using Roles, one can control users’ permissions to the tree, tabs in the tree, nodes in the tabs, and items in the nodes.

Setting Access Permissions from Property Files

Access permissions can be set from futuretense_xcel.ini. One can either grant or deny permissions by setting the following properties:

  • xcelerate.grant.functionname = rolelist
  • xcelerate.deny.functionname = rolelist

where functionname is the name of the function, as shown in the futuretense_xcel.ini file, on the Authorization tab. rolelist is a comma-separated list of roles for which the permission is either denied or granted. If the permission is granted or denied in the futuretense_xcel.ini, it is granted or denied for all assets, irrespective of the asset type. These permissions can be overridden by specifically setting access permissions on an asset-by-asset basis, using WebCenter Sites’ access permissions feature.

Creating Read Only User

To create a Read Only User, one must do the following:

  1. Create a role, say ReadOnly. The ReadOnly Users must be assigned only this role.
  2. Create another role, say Editor. This role must be assigned to all other users. The read only users must not be assigned this role.
  3. Make sure that ReadOnly user can not access any Start Menus for creating assets, e.g. ‘New Article’.
  4. Set the Access Permission in futuretense_xcel.ini to deny ReadOnly role functions like edit and delete.
  5. Set the Access Permission in futuretense_xcel.ini to grant Editor role these functions.

Typically, the following entries may be made in futuretense_xcel.ini file to create a ReadOnly user. These may be changed/configured depending exactly what functions have to be granted/denied to ReadOnly user, and the exact name of the ReadOnly role & Editor role.

  • xcelerate.deny.checkout=ReadOnly
  • xcelerate.deny.delegate=ReadOnly
  • xcelerate.deny.setExportData=ReadOnly
  • xcelerate.deny.placepage=ReadOnly
  • xcelerate.deny.showparticipants=ReadOnly
  • xcelerate.deny.rollback=ReadOnly
  • xcelerate.deny.setparticipants=ReadOnly
  • xcelerate.deny.removefromgroup=ReadOnly
  • xcelerate.deny.removefromworkflow=ReadOnly
  • xcelerate.deny.edit=ReadOnly
  • xcelerate.deny.setprocessdeadline=ReadOnly
  • xcelerate.deny.setnestedworkflow=ReadOnly
  • xcelerate.deny.setstepdeadline=ReadOnly
  • xcelerate.deny.approve=ReadOnly
  • xcelerate.deny.copy=ReadOnly
  • xcelerate.deny.authorize=ReadOnly
  • xcelerate.deny.delete=ReadOnly
  • xcelerate.deny.share=ReadOnly
  • xcelerate.deny.abstainfromvoting=ReadOnly
  • xcelerate.grant.setparticipants=Editor
  • xcelerate.grant.removefromgroup=Editor
  • xcelerate.grant.delete=Editor
  • xcelerate.grant.setnestedworkflow=Editor
  • xcelerate.grant.showparticipants=Editor
  • xcelerate.grant.copy=Editor
  • xcelerate.grant.authorize=Editor
  • xcelerate.grant.setstepdeadline=Editor
  • xcelerate.grant.setExportData=Editor
  • xcelerate.grant.placepage=Editor
  • xcelerate.grant.abstainfromvoting=Editor
  • xcelerate.grant.checkout=Editor
  • xcelerate.grant.delegate=Editor
  • xcelerate.grant.share=Editor
  • xcelerate.grant.approve=Editor
  • xcelerate.grant.edit=Editor
  • xcelerate.grant.setprocessdeadline=Editor
  • xcelerate.grant.removefromworkflow=Editor
  • xcelerate.grant.rollback=Editor

In addition to these, if work-flow is being using, functional privileges should be configured so ReadOnly user can not edit/delete an asset. Now, any user that is assigned only ReadOnly role, will only be able to inspect, preview, and check the stats of an asset, and will not be allowed to do other functions.