Posts Tagged ‘oracle webcenter sites 11g’

No doubt, WebCenter Sites has provided a great tool called CSExplorer in JSK for exploring the Database contents. But this tool has limitations. This works only on the Windows environments. But in reality, developers work on different environments aswell like MAC, Linux, etc.

I really felt bad when I couldn’t find someway to explore the database contents. while working on MAC. Fortunately, I have gone through some other website, and came to know how to explore the HSQLDB using eclipse.

I want to explain now how to explore the underlying tables of WCS using Eclipse, more elaborately.

Step  1 :

Open your server.xml file. It can be found under the below location:

[WCS installation Dir ]/apache-tomcat-7.0.42/Sites/conf/server.xml

Get the below values:

  • Username
  • Password
  • URL

See below screen shot.


Step  2:    

Have your eclipse installed. You can get it from

Step  3:     

Download the Data tools platform from eclipse marketplace. To do this, go to the Eclipse market place window, and search for ECLIPSE DTP (DATA TOOLS PLATFORM) 1.11.1 KEPLER, and install the plugin.


 Step 4:     

Now open the Perspective ” Database Development“.

You can do this by going to the Eclipse -> Window -> Open Perspective -> Other – > Database Development

Step 5: 

In the left hand, you will see a new tree opened called DATA SOURCE EXPLORER.

Right click on DATA CONNECTIONS, and click on NEW.


 Step 6:    

You will now get the following CONNECTION PROFILE window. Select HSQLDB from the available list of options, and click on NEXT button:


 Step 7:    

Enter the DB connection details in the below window:

Enter the following values from the inputs taken in step 1.

  • Database Location  : [WCS Installation Dir ] /App_Server/apache-tomcat-7.0.42/Sites/default/data/hypersonic/csDB
  • UserName  :   sa
  • Password    : blank

Then click on the TEST CONNECTION button. It shows a PING SUCCESSFUL dialog box. Now click on FINISH button.

DB Info Screen

NOTE:  You need to add the hsqldb.jar in the above window, by clicking on the + button available against the DRIVER  drop down.

Step  8:  

That’s it. In the Data source explorer tree of left hand side, you can see a new DB connection created to your local JSK. You can explore the tables as shown in the below screenshot.




That’s it for now.






Oracle has introduced a new feature called Vanity URL in Oracle WebCenter Sites, which provides us the ability to define and manage the VANITY URLs for any asset. In this post, we will discuss about how to enable the Vanity urls in the ContentServer, and its usage.

 1)Creation of Vanity URLs for Assets:

Vanity URLs for an asset  can be created in two way, Manually and Auto-Generated. WebCenter Sites supports two types of Vanity Urls ie Asset URLS and Blob(File) Urls. An Asset Url can be either auto-generated(pattern defined by the Administrator in Admin Interface) or created in the Contributor Interface). A Blob (File) Url is created only by the Administrator in Admin Interface using pattern, but Blob(File) url cannot be created from Contributor UI.

 i) Manually creation from the Contribute UI:

From the Contribute UI, vanity URL can be created by Content Contributors. Open the asset for which you wish to create a Vanity url. Access the asset’s edit view in the Form mode. In the form section selector, select URL. Fill the following fields.

URL :   Enter the vanity url.

Host :  Form the dropdrown, select the root url.

Template : Select the layout to render the asset on the website.

After enter click the “Add” button, then the vanity URL is displayed. The Vanity URL will not work, until the asset is “Saved”.

 ii) Auto-Generated Vanity URLs:

Vanity URLs can be generated automatically for individual assets based on the patterns configured. Once a pattern is registered, the vanity URL is generated when the asset is saved.

Login to the Admin UI and under Admin tab, expand the AssetTypes node, then expand the node for the specific asset type you are creating and auto-generated URL. Expan the URL Pattern and double click on “Add New”

Name :  Unique name for the pattern.

Site  : The pattern will be applied for the list of sites for which the asset type is enabled.

Host : The WebRoot which the vanity URL applied to.

Pattern : Enter the rule that define the vanity URL. The pattern define will be appended to the WebRoot which is mentioned in the HOST attribute, for this pattern to create Oracle provided pre-defined functions like


So, the vanity url will be something like http://localhost:8080/cs/avi/samplesubtype/sample_by_krishna.html


So, the vanity url will be something like  http://localhost:8080/cs/avi/1330543070443.html


So, the vanity url will be something like  http://localhost:8080/cs/avi/sample+by+krishna.html

(Spaces are converted into + symbols by default)

AutoGenerate for Asset:  URL pattern generation of Assets vanity url.

AutoGenerate  for Blob(File): URL pattern generation of Blob File vanity url.

The Below section “Evalutate URL Pattern” in the above images, is used to validate the auto generate url.

2) To Enable the Vanity URLs in the Content Server]

By default, these would be enabled for first site II and avi sports sites.

2.1) Configure SitePrefix : The WebCenter Sites know which URLs to treat as vanity URLs. In the Content Sever web app enter the following filter. Do the setting in the Web.xml.

If there are multiple site, need to specify comma separated SitePrefix in the param-value tag.

Location : <>/webapps/cs/WEB-INF

Add this  filter just below the   “… WEM SSO Filter … ” entry.
Add filtermapping just below  the filter-mapping of  “..WEM SSO Filter …” entry.

2.2) Create WebRoots:  Login to the Admin UI and under Admin tab, expand the WebRoots node and Add New. The WebRoots can be of Absolute , Relative or Combination.

HostName          : Enter the HostName which is unique identified for the WebRoot instance.

Root URL           : This can be Absolute or relative.

Virtual Root URL : If need to used the Virtual Url,  In futuretense.ini file for the property sites.environment specify the environment value as management/delivery.

It has two parameter the Environment and Root URL. For each environment will have one url,  enter environment name Root url and click add for

each environment.

Example : For Management environment, specify Environment = management,  Root URL =

Sites                  :  Enable WebRoot for specific sites.

3) System tool – URL Utility:   

Login to the Admin UI and under Admin tab,  can view all the vanity URLs defined in the system. This tool can be used to resolve the conflicts in the vanity urls.    Using this “URL Utility” admin can view  the conflicting urls, and can delete the vanity urls which are not required.

4) Tags to get Vanity URL: 

     The normal tags can be used to get the Vanity URL. If the vanity url is present for the given asset then below tags will return the vanity url.

i)  render:gettemplateurl

ii)  render:getpageurl

ii)  render:getbloburl

iv) satellite:link

In the real world implementation, there may be more than one web-site that a company maintains.

For example, lets assume that we have client called “X”. This client has engaged with the Oracle WebCenter Sites developers team to get a Content Management Site created, say . The client has later come up with a requirement to create another site called using Oracle WebCenter Sites / Fatwire.

To create a new site from scratch, we need to create all the stuff like attribute editors, asset types, templates, elements, etc.

Oracle WebCenter Sites / Fatwire comes with a utility that can be used in such a situation, which will replicate the structure of an existing site (please mind that the first site is also created using Fatwire), and creates a  new site automatically with all the above said stuff such as attribute editors, asset types, templates, elements, etc.

This utility tool provided by Oracle WebCenter Sites is called as SITE LAUNCHER UTILITY.

Site Launcher Overview

To minimize your effort in creating new sites, WebCenter Sites provides a site-replication utility called “Site Launcher.” This utility is designed not for backing up CM sites, but for spinning them off.

Some important points to be noted about the Site Launcher utility.

  1. Site Launcher replicates source sites directly on their native WebCenter Sites system, reusing the existing database schema. The sites are replicated quickly and easily, without the need for coding.
  2. Site replication can be carried out only by the general administrator.
  3. We can either copy or share the assets (templates, asset types, attributes, etc) between both the sites.
  4. While COPY of assets will create a new set of assets into the site, SHARING will share the same asset between both the sites
  5. In the new site, we can remove the existing assets, or add new assets according to the requirements
  6. New asset types, templates, elements etc can be created in the new site.
  7. New users can be created for the newly created site.
  8. Site Launcher can be used to replicate almost any CM site: small, large, functional,incomplete, independent of other sites, and overlapping other sites by the sharing of components.


In Oracle WebCenter Sites, when we create a site, few tables will be created by the Content Server.  These tables will be used by the CS to write information about the sites that are created in the system. Following are the tables that will be created.

  1. Publication Table
  2. PublicationTree Table
  3. SitePlanTree Table
Publication Table:

This table is used by the CS to store all the info related to the sites that are created in your system. This holds the information like NAME, DESCRIPTION, PUBLICATION ID of the site. Each row in this table resembles a site in your system, and its information.

publication table

PublicationTree Table:

This table is used by the CS to store the information about the asset types that are enabled for your site.  It stores the information about the different asset types that you have created  / shared from other sites in your system.

SitePlanTree Table: 

This table stores information about the hierarchical structure of a site and its page assets. This table lists sites and page assets. We can code your CSElements to extract and display information from the SitePlanTree table

There will be a top level node (Page), which will have the rest of the pages placed below it.

The SitePlan in the Admin console of WCS resembles this table in database.

SitePlanTree table

We are now going to discuss the Content Server Architecture of Fatwire / Oracle WebCenter Sites 11g. Content Server Arcitecture has the following levels of components. All these combinedly working, brings a high performance site, as desired by the customer.

CS Architecture

  1. Database
  2. Application Server
  3. Content Server
  4. Satellite Server
  5. CS-Direct
  6. CS-Direct Advantage
  7. Engage (Optional)
  8. Analytics (Optional)

Now, we are going to see each of these sections in detail.


Like every other architecture, in this CS-Architeture, the Database is the one which sits on the bottom of all the components.The Database can be of our own choice. This may include Oracle Database, MS SQL, DB2, etc. We can choose an Database of our choice, and perform the installation. The installation guides will have enough information for providing the right databases, and their installation, etc.

Application Server.

The application server sits above the database, and it acts as the main component for running the Content Server. The Content Server Context (CS) is deployed in this application. Hence, all the requests from the components above this level, like Engage, Analytics, etc will be passed to the CS Context through this Application Server. This application server could be of our own choice, like Apache Tomcat, JBoss. etc. But, I’ve seen Apache Tomcat with most of the installations.

Content Server:

As mentioned above, the Content Server Context will be typically deployed in the application server. But, the actually installation of Content Server Software will be done in some other directory of our choice.

The Content Server context provides access to the Java servlets that compose Content Server. What language we code : XML or JSP, we code in the Content Server context. These XML and JSP tags provide an easy-to use interface to Content Server’s Java objects, so that even web designers with no Java knowledge can create Content Server web pages.

This Content Server will have cache storage, and this cache is used to store the pages, content, blobs, etc., which are frequently requested, as well as recently requested by the end users. In this way, the need for requesting the DB for each and every query coming from end user, will be drastically reduced, and hence, improving the overall performance.

CS-Direct (or) XCELERATE :

This CS-Direct module of the Content Server sits on the top of Content Server. The concept of Basic Asset Model is introduced by the CS-Direct module of the content server. The code name for this CS-Direct is XCELERATE. You can see the name XCELERATE in many places, like naming conventions, directory names, etc.

But, the Basic Asset Model has many disadvantages, which are later revisited and solved by the Flex Asset Model.

CS-Direct Advantage (or) GATOR :

This CS-Direct Advantage module of the Content Server is an extension to the CS-Direct. It adds additional functionalities to the existing data model. It sits on the top of CS-Direct.

The concept of Basic Asset Model has some limitations. Hence, to overcome those limitations, the CS-Direct Advantage module of the content server is introduced.
The CS-Direct Advantage introduces us with the Flex Asset Model. As this data model is an extension of the existing Basic Asset Model, they might have named it as Flex Asset Model (My assumption is FLEXIBLE Asset Model).

The code name for this CS-Direct is GATOR. You can see the name GATOR in many places, like naming conventions, directory names, etc.

Fatwire Engage:

In this e-commerce world, every customer is valuable and very important. So, there is a need to keep the visitor (customer) ENGAGED to the site, so that he revisits the site frequently, and gives a good business. This will increase the overall business profits.

So, to keep them engaged to the site (business), we can use the ENGAGE software of Fatwire. This is an optional software that can be installed, so that the end user will be kept informed about the recent attractions of his interest.

It is an application that enables your marketing team to divide your site visitors into segments and then target those segments with personalized messages, or promotional, marketing, and informational messages.

Fatwire Analytics:

Again, Analytics is an optional product. It is a Content Server plug-in that monitors and analyzes website traffic. It helps you to track visitors interactions with content from the time visitors start browsing your site, up to the time they leave your site.

Satellite Server :

Satellite Server can be divided into two components. Co-Resident Satellite Server, and Remote Satellite Server. By having two such servers, the caching will be hugely improved, and thus improving the site performance, and the overall turnaround time.

The Remote Satellite Server is a caching application that speeds the performance of your delivery system by serving cached images and Content Server pages from remote servers. Remote servers over here refers to different locations, like America, Asia, Australian location servers.

Satellite Server reduces the load on the Content Server delivery system and to deliver pages more quickly.

The Remote Satellite Server is offered as a stand-alone product to help you optimize system performance according to the load on the system.

In most of the cases, the Remote Satellite Server will be installed in the same server where the web server resides.

In an article written by me, a long time back, we have seen the information about various content server tables.

Now, for the next upcoming few articles, I’m going to share the detailed information about these tables.

In this article, we will see about the CACHE MANAGEMENT DATABASE TABLES in Fatwire / Oracle WebCenter Sites.

CacheManager manages these tables:

We already know about the CacheManager (the Page Caching Utility), and how it operates the CS Cache and SS Cache.

As the cache manager keeps track of the information about the PAGES that need to be cached, and the ASSETS that are referred by these CACHED PAGES, the CacheManager makes use of a few DataBase tables. They are as follows:

  • SystemPageCache
  • SystemItemCache

As and when the pages expire, or when the assets referred by these pages are modified, the CacheManager Adds / Removes the Pages / Assets to the tables specified above.

SystemPageCache Table:  When ever a new page is to be added to the cache, a new ROW is created in this table, by the CacheManager. Hence, ONE ROW FOR ONE PAGE. When the page expires, its corresponding row is removed from the table. Hence, depending on the pages in the cache, this table expands / contracts accordingly.

SystemItemCache Table:   We know that the page refers to other assets like images, pagelets, blobs, etc. For storing the information about those items which are referred by the CACHED PAGES, this table is used. Here also, the formula is same. ONE ROW FOR ONE ASSET. Depending on the assets referred by the cached pages, this table also expands / contracts accordingly.

For example, if a Page (Cached Page) is created from a page Asset that has associations to four article assets, there would be five rows for that cached page (One row for PAGE ASSET, and Four rows for Article assets), in the SystemItemCache table.

To view the content of these tables, just open the CS-EXPLORER, enter your log-in details. Expand the TABLES directory. You will be able to see the above stated tables, and their contents. Refer the below screen shot.


We will see the other Content Server Database tables in my upcoming articles.

Stay tuned….

Some times, we need to modify the Fatwire Flex Content Definitions, that have been already created.

Say for example, there are thousands of Flex Assets, created using a Flex Content Definition. I would wish to remove / add few attributes to the content definition. I’ve done it.

Now, how the new attributes will reflect in the existing thousands of assets?

Simple answer: Just edit and save the assets. The new attributes will be reflected in the existing assets as well.

This is okay, if there are assets in tens, or around that. But, there will be thousands of assets, in reality. We can’t go and edit all the assets which are there in the system, as it is a lot of time taking process.

So, what to do now?

We can load all the assets through code, and use the tags like asset:load, asset:canedit, asset:save, etc to perform our job.

Here is a sample code, which loads and edits the asset, adding a value for the DESCRIPTION field.

//Checkout the asset. This is optional. But, suggestible to be used.

< asset : checkout type=”<%=ics.GetVar(“c”)%>” objectid='<%=ics.GetVar(“cid”)%>’>


//Load the asset.

< asset : load name=”SampleAsset” type='<%=ics.GetVar(“cid”)%>’ objectid='<%=ics.GetVar(“cid”)%>’ editable=”true”  >

//Scatter the asset’s attributes.

<asset:scatter name=”SampleAsset” prefix=”Sample“/>

//Set the new value

< ics:setvar name=”Sample:description” value=”THIS IS NEW DESCRIPTION” />

//Gather all the variables
<asset:gather name=”SampleAsset” prefix=”Sample” />

//Save the asset to the database
<asset:save name=”SampleAsset” />

//Checkin the asset.
<asset:checkin name=”SampleAsset” />

Now, INSPECT the assets from the Admin UI. You will find them updated.

Most of us might have seen the concept of Wrapper page in Fatwire projects. Even I too used to wonder what purpose this page might be serving, why is this used, etc.

I have seen this concept in many of the projects, and even in the FIRSTSITEII example site shipped with JSK. We will now see in brief, about wrapper page in Fatwire

A WRAPPER PAGE in FATWIRE is an ELEMENT (a CSElement, infact) that is called to perform the logic on the content server. Its sole purpose is to perform logic that must always be performed on Content Server even in a fully cached environment.

Following are few of the usages of a wrapper page:

  1. Checking security measures
  2. Setting default locale
  3. Getting the current locale
  4. Setting default values for parameters
  5. Validating URL
  6. Redirecting pages accordingly, etc.

The wrapper page (CSElement)  is usually not cached, while the Layout (template) usually is cached.

Creation of a wrapper page is a two step process.

  1. A CSElement should be created.
  2. A SiteEntry that points to the previously created CSElement. The SiteEntry must be declared as a “Wrapper Page”. Refer the below screenshot. The screen below shows the wrapper page option, in the SITEENTRY creation screen.


When you have a wrapper page created, you can even remove the external accessibility of the Layout.  In this case, the wrapper page will act as the ONLY entry point for a site.

So, when you create a WRAPPER PAGE in your implementation, what ever the page you view, the request will go to the WRAPPER PAGE first. Then the control will be passed to the respective pages (According to what we code in the wrapper). Hence, WE ARE NOT invoking the wrapper page manually. The wrapper page is getting invoked automatically by the content server.

In general, it is a good and common practice to implement a wrapper page and call it, rather than calling the layout page directly.

To import the assets through XMLPost, we need to invoke the XMLPost Utility. We will now see how to invoke XMLPost through a program:

1. To invoke the XMLPost utility programmatically, first we need to create an XMLPost object.

Example: COM.FutureTense.XML.Post.XMLPost samplePoster = new COM.FutureTense.XML.Post.XMLPost();

2. Using that object, we need to call the doIt method of the XMLPost.

Syntax: doIt(String[] args)

3. The elements of the array are the path values of source file and ini files. Here, the source parameter can point to:

            • A single file, like -s/sample/Article-add.xml

            • A directory of XML files, like -s/sample/source-xml-files/

           •  A list file, like -s/sample/xmlpostfiles.lst

The list file provides a list of all the files that you want to import. It is similar to an .ini file but with extension of .lst.

In total, we need to program as follows. Include other calls to any other elements basing on your requirement.

………… Your code here…………..

strSourceFileDir = “-s/sample/Article-add.xml”;
strConfigFile = “-c/sample/Article-add-config.ini”;

String args[]  = {strSourceFileDir,strConfigFile};

COM.FutureTense.XML.Post.XMLPost samplePoster = new COM.FutureTense.XML.Post.XMLPost();
    samplePoster.doIt(args);   // here we are supplying the xml and ini file values
catch (Exception e)
    ics.LogMsg(” —- your error message here —–“);
  ………… Your code here…………..

That’s it. The XMLPost will be invoked, and basing on the source files the importing of assets will be done.

Introduction to XMLPOST:

In any Content Management System, the CONTENT forms the main part, i.e., the Content Assets. In general, in most of the scenarios, the content is actually generated through feeds / or some other data sources. We need to import data from such sources, and create content assets into the Content Server Database on the management system.

The Fatwire / Oracle WebCenter Sites Content Server delivers with a utility to perform such imports, hence reducing most of the efforts of the developer to write code for importing the data. That utility is nothing but the XMLPost Utility.  To import any data from external sources into the Content Server database, we can use the XMLPost utility. This utility is delivered with the CS – Direct.

All we need to do is to invoke the XMLPost Utility from our program, or through command line.

In this article, we will know about the components involved and the steps involved in the process. We will see more about XMLPost in future posts.

Components involved in the Process:

Following are the components involved in importing the data:

1. The XMLPost Utility, which ships by default with the Content Server.

2. The Posting Element, which also ships by default.

               a.  CS – Direct provides one posting element:  (For Importing BASIC ASSETS)

                         1. RemoteContentPost (OpenMarket/Xcelerate/Actions/RemoteContentPost)

               b.  CS – Direct Advantage provides three posting elements: (For Importing FLEX ASSETS)

                         1.  addData (OpenMarket/Gator/XMLPost/addData)

                         2.  modifyData (OpenMarket/Gator/XMLPost/modifyData)

                         3.  deleteData (OpenMarket/Gator/XMLPost/deleteData)

3.  The Configuration file (.ini file), which specifies the information about the source files (in XML  format), what assets need to be imported, information about the host, usernames, passwords, etc.

4.   The Source files.  These are the well-formed XML files, which contains the data to be imported. This data is to be enclosed within respective tags.

The Process:

1. First, we create the configuration files (.ini files), which has the information about the data that is to be imported.

2. Then we create the source files (XML files), which has the actual data that is to be imported.

3. Place these two files in a directory, and then invoke the XMLPost Utility.

4. Then the XMLPost Utility parses

              a) The configuration file, which has been supplied by us.

              b)The Source files, and creates name / value pairs.

XMLPost Process

The Process image from Fatwire Developer guide

5. Basing on the type of assets that we are trying to import, the Content Server invokes either of the elements.

              a)  Basic Assets

                         1.  RemoteContentPost

              b)  Flex Assets

                         1.  addData

                         2.  modifyData

                         3.  deleteData

6.  The RemoteContentPost or addData/modifyData/deleteData elements perform the required actions and create the asset.

7. A HMTL will be returned to the XMLPost, to indicate whether the import operation has been succeeded or not. The information is logged into the log files, whose information is specified in the configuration files (the above specified .ini files).

8. If you specify to delete the source files (need to specify the parameter in the configuration file), the source files will be deleted once the import has been done.

We will see more in detail about XMLPost in the upcoming articles.

Stay tuned…..