Posts Tagged ‘Enterprise Content Management’


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 http://www.MySiteOne.com . The client has later come up with a requirement to create another site called http://www.MySiteTwo.com 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 Information Technology, no software stands and plays alone for a long time. There are number of new technologies coming these days, getting popular, well noticed by customers / clients. But after some time, a day comes where these technologies are dominated by other technologies.

Coming to the Content Management Systems, there are many niche players like EMC, Oracle, etc. And Adobe joined them by redesigning Communique 4. It has released ADOBE DAY CQ5, basing on Communiqué 4. ADOBE DAY CQ5 is a new WEB EXPERIENCE MANAGEMENT SYSTEM.

What is Adobe Experience Manager?

Adobe Experience Manager helps you organize and manage the delivery of creative assets and other content across your digital marketing channels, including web, mobile, email, communities, and video.

Similar to Oracle WebCenter Sites,  ADOBE DAY CQ5 helps us to build compelling content-centric applications that combine Web Content Management, Workflow Management, Digital Asset Management and Collaboration sites.

Prerequisites for development within CQ

For the developers,  to build WEM site using the Day CQ5, following technologies are required:

  • HTML
  • CSS
  • JavaScript
  • JSP

The documentation for Adobe Day CQ5 can be accessed from http://dev.day.com/docs/en.html

I’m now starting with Day CQ5, and will be updating topics on Day CQ5 from now on.

ADOBE DAY CQ5


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.


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.

Tables

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.

Untitled

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.


Types of Database Tables

We will now discuss about the Database tables in Fatwire. There are five different types of tables in the Content Server database:

  1. Object tables
  2. Tree tables
  3. Content tables
  4. Foreign tables
  5. System tables
Object Tables

These tables hold the data as objects and provide a unique identifier for each row in the table. Object tables store data as an object and can be represented in hierarchies. The primary key for object tables is always the ID (id) column and that cannot be changed. When we add an object table, it creates an ID column automatically in that table.

Tree Tables

These tables hold the hierarchical information about relationships between objects in object table, i.e., the object tables can be represented in hierarchies, but the hierarchy itself is stored in a tree table — the hierarchy is the tree.

The examples of tree tables are:

  1. AssetRelationTree
  2. SitePlanTree
Content Tables

Content tables store data as flat data (rather than as objects) and that information cannot be organized in a hierarchy. You use content tables for simple lookup tables. The CS doesn’t provide a unique identifier for the rows in the table.

Foreign Tables

A foreign table is one that Content Server does not completely manage. These can be the tables which can be:

Tables that are outside of the Content Server database but that Content Server has access to.

Tables that are in the Content Server database but that Content Server did not create.

Content Server can query foreign tables and cache the resultsets just as it does for its own object and content tables.

System Tables

These are core Content Server application tables. The schema of these tables cannot be modified, i.e., these are the Content Server tables whose schema is fixed. You can add rows to some of the system tables (say using the Content Server Explorer tool or using some other way), but you cannot add or modify the columns in these tables in any way. Also, we cannot add system tables to the database.

The examples of System Tables are:

  1. ElementCatalog
  2. SiteCatalog
  3. SystemACL
  4. SystemInfo
  5. SystemPageCache
  6. SystemUsers .. etc…
How to know the Table’s Type:

We can identify the type of any table using the SystemInfo table. The system table is the one that lists all the tables in the database.

Following are the steps to identify the Table’s type:

  1. Open the Content Server Explorer and log in to the Content Server database.
  2. Open the SystemInfo table.
  3. Examine the systable column. The value in this column identifies the type of table represented in the row. Refer the screen below:

Untitled

Here are the codes for identifying the tables:

  1. YES = System table
  2. NO = Content table
  3. OBJ = Object table
  4. TREE = Tree table
  5. FGN = Foreign table

Now, we are going to see the usage of CatalogMover tool of Fatwire / Oracle WebCenter Sites 11g.

CatalogMover is a tool which is used to export / import the database tables. We can even export the ElementCatalog and SiteCatalog tables. We can export all the assets like page assets, content assets, etc., and import all of these assets into another system (target system). We can export / import all the database tables as HTML / ZIP files. This tool can be used with Windows machine by the Windows Interface. In the rest of the operating systems, it can be used through the Command Line Interface. The advantage of CatalogMover over CS-Explorer is that this tool can be used in any operating system.

We can do the following activities with CatalogMover.

  1. Export Tables: Exporting is the process of retrieving table rows and their content from the database and saving them in local HTML files and associated data directories.
  2. Import Tables: Importing is the process of sending locally stored HTML files and the associated data to the server. You can select a particular HTML file to import, or you can choose to import all HTML files.

To Start the CatalogMover, Execute the following scripts at the MS DOS prompt or in a UNIX shell:

  • For Windows: CatalogMover.bat
  • For Solaris: CatalogMover.sh

Following is the screenshot of CatalogMover.

Untitled


To make our work of building websites simple, Fatwire ships with a few Tools and Utilities. These are called CONTENT SERVER TOOLS AND UTILITIES. Using these tools, we can see the tables, modify them and their data, export the tables, view and edit the properties, etc. Following are the CS Tools and Utilities that ship along with Fatwire.

  1. Content Server Explorer
  2. CatalogMover
  3. PROPERTY EDITOR
  4. XMLPost

In this Article, we will discuss about the CS-Explorer. We will discuss about a few of them in upcoming posts.

Content Server Explorer

One of the most popular Tools used by the developers to make their work easy. It is called as CS-Explorer. It has many features that attract the developers. We can edit, update the tables and rows in the CS Database. We can edit, update the Templates, CSElements written XML, JSP. Following are some of its uses.

  • Maintains Revision Tracking
  • Can edit the templates, elements etc, instead of going to the advanced UI, and editing there.
  • Add entries to the tables of database
  • Create and delete the tables
  • Export and Import the tables and records.

The screen of CS-Explorer:

Untitled

NOTE: CS-Explorer is a Microsoft Windows based application. Hence, it can’t run on other operating systems. In other operating systems, use CatalogMover for similar kind of works.

Stay tuned for rest of the CS Tools and Utilities.….!