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, Ive 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.
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.
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).
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.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.
WEM Framework:
-Easily extend the WEM suite with custom or third-party applications .
Seamless user experience across WebCenter Sites (and integrated third-party apps)

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.

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







Way Handling a HTTP request in Fatwire
When the user enters a URL in the browser, and hits on enter, the following sequence of
actions take place in order to complete the request and give the webpage as a response.
1. The Webserver / load balancer routes the HTTP request to the Satellite Server.
2. The Satellite server checks for the page in its cache.
3. If the page is found in its cache, the page is returned as response.
4. If the page is not found in its cache, the Satellite server routes the request to the
Content Server.
5. The Content Server checks for the page in its cache.
6. If the page is found in its cache, the page is returned to satellite server.
7. If the page is not found in the Content Servers cache, the page is rendered by the
Content Server, and it is stored in the CS Cache. Then sends the copy of the page to
the Satellite Server.
8. The Satellite server then stores the page in its cache, and returns it to the user.
In this way, the HTTP request is handled in Fatwire

Significance of ElementCatalog & SiteCatalog tables in Fatwire / Oracle
WebCenter Sites
Firstly, the ElementCatalog and SiteCatalog are two important tables which are present in the
Content Server Database.
ElementCatalog table : 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.
SiteCatalog table : hen 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. http://www.MySite.com/servlet/ContentServer?pagename=MySite/Home
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.
Whats new in Oracle WebCenter Sites?
1. The UI has been completely modified. Earlier, in Fatwire 7.6, we used to have four interfaces.
Advanced User Interface
Dash User Interface
Insite Interface
WEM Interface (For selected users)
But now, in the latest version, i.e, Oracle WebCenter Sites 11g, we have only three interfaces.
Admin Interface
Contributor Interface
WEM Interface (For selected users)
2. The page building model and process has been redesigned. The management of page content can
be accomplished using drag-and-drop functionality in combination with dock-able search results,
sidebar trees, and strategically available toolbars. Once page creation is initiated, content can be
dragged to predefined slots. Slots can be constrained by asset type and role-based user permissions
per slot can be assigned. Non-technical users can easily control the presentation of content with
graphical layouts and predefined arguments.
3. It is now possible to drag content from search results and sidebar trees to both asset forms and
page slots. Drag and drop can also now be used to quickly order the pages of a site plan.
4. Assets as well as their dependencies can now be approved with a single operation

WebCenter Sites Product Architecture

Explain Users, Groups and Roles.
Two levels of User Privileg
Content Server ACLs Access Control List
Content Server Roles

An ACL specifies specific types of access. For example read and write access to
database tables.


Content Server Roles -
Define a business responsibility (author, approver, checker)
Can be assigned to a set of users
Can be used for different CM sites
Are determined by site administrators to permit access to certain content and functionality

Content Server Roles are NOT mapped to ACLs (and vice versa)


Asset Models Types

Basic vs Flex

Characteristics Basic Asset:
One primary storage table per asset type
Attributes correspond to columns
Each new instance is a new row in the table
No inheritance
Created using the Asset Maker Utility
- Requires an Asset Descriptor File
Schema is fixed

Characteristics Flex Asset:
Create an organizational taxonomy of data with successive
Levels (i.e. folder-like structure)
Children inherit traits (attribute values) from their parents and
grandparents, etc.
Several database tables to support one flex family
Attributes can be added/removed at any time
Support for Multi-valued attributes
Ability to use Attribute Editors and Flex Filters

Flex Family Members:
Flex Attribute
Flex Parent Definition
Flex Asset Definition
Flex Parent
Flex Asset
Flex Filter


What is use of CatalogMover?

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.

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.

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

What is Dynamic Publishing?

Dynamic publishing is the process of copying assets and their underlying schema from one
WebCenter Sites system to another. This Dynamic Publishing is of two types.

1. Mirror to Server : Mirror to Server is the method used to copy database rows to remote
dynamic server

2. Real time Publishing : Real time Publishing is the method used to copy assets to remote
dynamic server.

What is RealTimePublishing?

RealTime publishing is a dynamic publishing process. In RealTime publishing, this process is
broken up into five stages. The System performs all the five steps in an order, to perform the
RealTime publishing.

RealTime publishing is the preferred method for publishing. Using the RealTime user
interface, an administrator can monitor the progress of a publishing session, bulk publish
selected assets using the on demand queue, bulk un-approve the assets that are approved for
publishing, cancel publishing process, and redo publishing sessions, etc.


What are Five Stages of Publishing?

1. Gathering data to publish:
a. The WebCenter Sites source system locks the assets that are approved for this
publishing session. This ensures the assets that need to be published from being
edited during publishing.

b. The list of assets to be published from source to destination systems are created in a
file called MANIFEST. The manifest identifies the assets that must exist together on
the destination to prevent broken links and incomplete pages.

2. Serializing data:
a. The WebCenter Sites source system mirrors the following items:
- Asset types
- Tables
- Approved assets

b. The data that needs to be published to the target will be serialized at the source
system (i.e, translation into binary format).

3. Sending data to the target:
a. The destination WebCenter Sites database locks assets that are approved for
this publishing session. When assets on the target are locked, they cannot be
edited.

b. The WebCenter Sites source system sends the serialized data and the
manifest file to the destination.




4. Deserializing and saving data:
a. The WebCenter Sites destination system de-serializes (to WebCenterSites format)
the mirrored asset types, tables, and approved assets.

b. The destination systems database updates asset types and tables with the
deserialized ones, or adds them as new data.

c. The destination system uses the manifest to determine when to commit assets to its
database.

5. Updating page caches:
The destination system completes the publication process, and does the following tasks:

a. To remove the expired pages, the page cachce is flushed.

b. If any new pages are added, they are added to the cached.

In this way, the RealTime publishing works in Oracle WebCenter Sites.












TAGS USED IN WEBCENTER

The FTCS Tag :
Each WebCenter Sites XML template or element must have the ftcs tag as its first and
last tags. This tag creates the WebCenter Site s context, alerting WebC enter Sites that code
contained within the opening and closing FTCS tags will contain WebCenter Sites tags.
You must code within the opening and closing ftcs tags; WebCenter Sites is unaware of
any code which falls outside of these tags.

render:satellitepage (JSP) :

<render:satellitepage
pagename=nameOfPageEntry
[cachecontrol=expiration_date_and_time]>
<[render:argument name=variable1 value=value1 ]/>
</render:satellitepage>

RENDER.SATELLITEPAGE requests a WebCenter Sites pagelet and caches that pagelet in
both WebCenter Sites and Satellite Server, if the pagelet is not already in cache. If you
wish to call a page or pagelet without caching it individually, use the
RENDER.CALLELEMENT tag. The RENDER.SATELLITEPAGE tag has a stacked scope, so
the only variables available to the page are ones that you explicitly pass in.

render:callelement (JSP)

<ics:callelement element="element name">
<ics:argument name=" argument name" value="arg value"/>
</ics:callelement>
RENDER.CALLELEMENT is similar to the RENDER.SATELLITEPAGE tag in that both tags
call other WebCenter Sites code, either in an element or in a page. However, code called
by RENDER.CALLELEMENT does not get cached as an individual page or pagelet on
Satellite Server.
Use RENDER.CALLELEMENT to process the content of an element that you wrote for the
WebCenter Sites Content Applications and you want the scope of that element to be
stacked. The element must ex ist in the ElementCatalog.

render:getpageurl (JSP)

<render:getpageurl outstr= myURL pagename="SiteCatalogPageEntry"
cid="IDofAsset"
[p="IDofParentPage"]
[c="AssetType"]
[addsession= true]
[dynamic=true]
[packedargs= stringFromPACKARGStag ]
<[render:argument name= xxx value= yyy]/>
</render:getpageurl>

render:satelliteblob (JSP)

<gsf:asset-load name='objContentdetail' c='${cs.c}' cid='${cs.cid}'
attributes="h1title,body,link,inlinehtml,iframeheight,linktext,metadescript
ion,metakeyword,metatitle,image,contacts,tools,onlinetools,signinto,promoti
ons,contentparent" />

<gsf:asset-children c='${cs.c}' cid='${cs.cid}' list="relatedLinks"
assoc="relatedlinks" />


<insite:calltemplate slotname="Featured Highlight Subcategory"
clegal="CSElement" emptytext="Drag CSElement" />

<insite:edit field="body" params="{noValueIndicator: '[ Enter Body Content
]',width: '627px', height: '500px',toolbar: 'Toll_WEB', customConfig:
'../ckeditor/config.js'}" value="${objSubCategory.body}" editor="ckeditor"
/>

Navigation

PageWRANavigationHelper pgNavHelper = new PageWRANavigationHelper(ics);

NavNode topNavNode = pgNavHelper.getSitePlanByPage(2,"TopNav");

List <NavNode> toolsNavNodeList = null;

topNavNodeList = topNavNode.getChildren();