Posts Tagged ‘Oracle webcenter sites’

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

In this article, we will see a few important tables that are created in the database, when a Flex Family is created in Fatwire.

The Flex Asset model, as the name itself suggests, is a FLEXIBLE Asset model. The Database design of the Flex Asset Model is very complex, as compared to the Basic Asset model. Each asset type in a flex family will have several database tables.

Following are few Important Tables that are created in Database, when a Flex Family is created.

A Table with the name of the asset itself:

The primary storage table for the flex asset type. For example, the primary storage table for the sample asset type named MyFlex is MyFlex.

The  _Mungo Tables:

The flex asset and flex parent asset types have an AssetType_Mungo table (Example, MyFlex_Mungo), where AssetType is the name of the flex asset type. Its purpose is to store the attribute values assigned to an asset when an asset of this type is created. Each attribute value has a separate row. For example, if we create a Flex Asset type called MyFlex (MyFlex_C) , then the table MyFlex_Mungo holds the attribute values for MyFlex assets.

The MungoBlobs Table:

There is one single table called MungoBlobs, which holds all the values for all flex attributes of type BLOB. This table is used for all the flex attribute types in your system. Each attribute value has a separate row in the table.

The _AMap Tables:

Flex asset and flex parent asset types have an AssetType_AMap table (Example, MyFlex_AMap). Its purpose is to map the asset to the attributes it inherits from its parents.

There are several other tables that store data about the relationships between the flex assets as well as other information.

For more information regarding these tables, please refer to Fatwire/Oracle WebCenter Sites Developer and Administrator guides.

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.

Fatwire ships with a lot of Attribute Editors, like TextArea, TextField, etc. But sometimes, you may require to create some custom attribute editors.


When the author enters some unwanted value in the attribute field, you may want to display some message, or an alert to the user. In such a case, the system attribute editors will not be helpful. You need to create a custom attribute editor. This is just a weird example. But there might be some serious situations, where you require the usage of custom attribute editors.

To create a custom attribute editor, you need to CREATE two things :

1. The main ELEMENT (CSElement) which defines the behavior of the Attribute Editor.
2. The Attribute Editor XML file, which we generally create in the Administrator UI.

Creation of the CSELEMENT:

Points to be Noted:

1. The name of the ELEMENT (CS-Element) must be the same name, as which we use in the attribute editor code. For example, the following TEXTAREA tag has a default TEXTAREA.xml


<TEXTAREA>        …….     This TEXTAREA refers to the TEXTAREA.XML Element



2. The new ELEMENT must be placed under the following path :


For the sake of simplicity, I would like to Create a custom attribute editor called My_TextField_Editor with the features of TextArea attribute editor, along with my custom changes. Hence, I need copy the features of TEXTAREA attribute editor, and want to add some other features.

So, create a new CS-Element with  OpenMarket/Gator/AttributeTypes/My_TextField_Editor.  (Include your own features along with the TEXTAREA element).

Creation of the Attribute Editor:

Now, that the element is created, we need to create the Attribute Editor.

Create an Attribute Editor with the same name of the ELEMENT, i.e, My_TextField_Editor (in this case).


<<<<<Code for Attribute Editor goes here…>>>>

 <PRESENTATIONOBJECT NAME=”Sample”> <My_TextField_Editor>

</My_TextField_Editor> </PRESENTATIONOBJECT>

<<<<<Code for Attribute Editor goes here…>>>>


That’s it.

Your new CUSTOM ATTRIBUTE EDITOR is created.

Now, To check the attribute editor, create an attribute, include it in a content definition, and then try to create the content. In the content creation screen, the design of the custom attribute editor appears.


We have two types of dependencies in Fatwire / Oracle WebCenter Sites:

1.Approval Dependency :  This is the dependency that is logged when an asset is approved for publish. When you approve your asset for publishing, the Approval dependency is logged. This dependency is between the asset that is being approved and its dependent (child) assets. This dependency will verify whether the asset that is being approved can be published to the target machine or not. If there are dependent assets, that need to be approved, then this asset cannot be published.

The Approval dependency is logged when the asset is approved for publish.

2. Compositional Dependency : This can be called as Page Composition Dependencies. As the name itself specifies, it is the dependency between the asset and the  pages / pagelets that are rendering this asset. This dependency determines whether the page needs to be regenerated, in case when assets are modified.

The CS logs compositional dependencies when it renders the pages.  On the other hand, the CacheManager checks the dependency log, whether to regenerate any pages, whose content has been outdated.

How Approval dependencies are logged?

The dependencies are logged based on the type of publishing methodology.

Export To Disk :  If the publishing methodology is Export to Disk, the dependencies are calculated basing on the tags that are present in the code of the template that renders the asset.

Mirror To Server : If the publishing methodology is Mirror to Server, the dependencies are calculate basing on the Family Relationships (for Flex Assets )  / Associations (for Basic Assets) between the assets. Both these type of relationships create approval dependencies.

Types of Approval Dependencies:

The Approval dependency type for CSElements and SiteEntry assets, embedded links and pagelets cant be changed. The approval dependency type for the flex family asset types also can’t be changed. The approval dependency of basic asset types can be modified. We set the type of approval dependency for their associated assets when you configure the associations.

Approval dependency can be of three types:

  1. Exists: If this dependency is selected, then the dependent assets (child asset) must just exist on the target machine, and the version number of the child asset doesn’t matter, as long as the child asset is approved and published to the same machine. This means that the asset that is approved (parent asset) can be published even if the child assets changes (in version, content, etc) between source and target machines.
  2. Exact: If this dependency is selected, then the dependent asset must be of the same and exact version on the target machine. The parent asset can’t be published, if the versions of parent and child assets on the source machine do not match the versions of parent and child assets on the target machine.
  3. None: If this dependency is selected, then the approved asset can be published to the target machine, without bothering about the version / state of the dependent assets.
How Compositional Dependencies are logged?

Compositional dependencies are recorded in different ways. There are several tags that log compositional dependencies.

When Content Server executes an asset:load tag, it automatically logs a compositional dependency for the asset that is loaded, and the page that is going to be rendered

Similarly, assetset:setasset, assetset:setsearchedassets, assetset:setlistedassets tags render compositional dependency. When an asset from the assetset is rendered, the compositional dependency is logged.

When these tags are executed, Content Server logs a dependency between the rendered page and the asset by writing this information in the SystemItemCache table.

Fatwire Interview Questions:

Fatwire Interview Questions” is one of the most frequently googled search term in Google. Hence, I’m coming today with a list of Fatwire Interview questions. The same will be applied for Oracle WebCenter Sites as-well.

Note: These are the questions which I’ve faced from most of the interviewers.

  1. What are the different versions of Fatwire that you have worked on?
  2. Explain difference between Basic Asset Model and Flex Asset Model?
  3. Explain difference between CSElement and Template?
  4. Explain about templates and its need in Fatwire CMS?
  5. Explain how will you handle multi-level languages in Fatwire?
  6. Explain about Asset and Asset Type?
  7. Explain about the Basic Asset Model?
  8. Explain about the Flex Asset Model?
  9. Explain about Rendering?
  10. Explain about different Publishing methodologies?
  11. Explain about the types of publishing Fatwire supports?
  12. Explain about Roles and ACLs?
  13. Explain about Attribute Editors and how will you create Attribute Editors?
  14. Explain about Workflow?
  15. Explain about the default asset types of Fatwire?
  16. Explain the use of Page Asset Type in Fatwire CMS?
  17. Explain the use of CSElement, SiteEntry and Template Asset Types?
  18. When will you use asset:getattributevalues and assetset:getmultiplevalues?
  19. What are the limitations of the tag assetset:getmultiplevalues?
  20. What is the difference between asset:list and assetset:getassetlist tag?
  21. How will you perform Error handling in JSP?
  22. What happens behind the scene when I hit an URL and invoke a page in Fatwire CMS?
  23. I want to know how many flex assets are available in my Article AssetType. Is it possible to know that? If so, how can we know that?
  24. Explain about the Recommendations, Collections, Queries, Segment, and Promotion?
  25. How to re-use the asset types that are present in one site, in another site?
  26. Explain about XMLPost and BulkLoader utilities?

Happy Job Hunting…. 

While building a website (Either by a WCM or normal html, etc), there will be certain images or other assets which seldom change, like Company Logo, etc. Say for example, CompanyLogo.png.

As we know, the images (even pdfs, etc) are nothing but blobs in Fatwire / Oracle WebCenter Sites.

The performance of the over all site can be improved by changing the way of serving these NEVER-EXPIRING BLOBS. The never expiring images / blobs which we discussed above in the first paragraph, need not be called from Satellite Server Cache / Content Server Cache. If we use an alternative method, the performance can be improved, as the number of calls have been reduced.

Follow the below mechanism for serving the NEVER-EXPIRING BLOBS in Fatwire / Oracle WebCenter Sites.

  1. Copy those Never-Expiring Blobs to your Satellite Server hosts. Place them under the doc root for your web server.
  2. In the code, instead of the satellite:blob tags, use <img src=”…”> tag to access the blob placed on your Satellite Server.

NOTE: While using this mechanism for serving never-expiring blobs, make sure that you place those blobs (ex: images) in all the Satellite Server host locations. If the blob is not present in any of the location, the Satellite Server cannot warn you that one of the Satellite Server hosts does not contain the same blob, that is contained in other hosts.

Following is the link for documentation  for Fatwire 7.x and Oracle WebCenter Sites. Here, you can download the javadocs, and required documentation.

The following link is for Oracle WebCenter Sites 11g release:

The following link is for Fatwire 7.6  Patch 2 and all its below versions, down to 6.3:

Today, we will see the significance of ElementCatalog and SiteCatalog tables, which we might have seen at many situations.

Firstly, the ElementCatalog and SiteCatalog are two important tables which are present in the Content Server Database.

When we code a Template or a CSElement, the actual ELEMENT is stored in the ElementCatalog table. That is, the code which write (JSP / XML / HTML) will be stored in this ElementCatalog table.

When we give a name for the Element, either in the Template creation, or SiteEntry creation, the PAGENAME will be stored in the SiteCatalog table. That is, the SiteEntry holds the names of the pages and pagelets.

Hence, Each row in the SiteEntry points to an entry in the ElementCatalog.

The Element in the ElementCatalog is called the ROOT ELEMENT, which is being pointed by the Page in SiteCatalog.





We will see how the process of rendering happens, basing on the page name being requested through browser.

  1. I have entered the following URL in the browser.
  2. Here, the page name is MySite/Home.
  3. Content server looks up the SiteCatalog table for the entry : MySite/Home
  4. From there, basing on the entry,  it will invoke the corresponding entry in the ElementCatalog table.
  5. The Element is executed. If caching is enabled, the output is cached.
  6. Output is rendered in the browser.

In this way, the SiteElement and ElementCatalog form crucial part in rendering the pages.