Posts Tagged ‘Oracle webcenter sites’


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.

Complete Publishing Mode:

When the destination is configured for complete publishing mode, the process proceeds without interruption.

Delayed Publishing Mode:

When configured for delayed publishing mode, the process pauses before the fourth step. User interaction is needed for the session to complete. It continues to stage 4 only after the administrator selects the Resume button on the “Publish Console” or “Publishing Status” screen.

As the publishing session proceeds, you can monitor the progress of each stage on the ‘Publishing Status’ screen.

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.

RealTime Publishing

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 system’s 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.

Advertisements

First things first. We need the following the components for integrating Oracle WebCenter Sites Devloper Tools with Eclipse:

  1. Latest Eclipse (Can be downloaded from http://www.eclipse.org/downloads/)
  2. CSDT plugin (Developer tools plugin)
Integrating Developer Tools with Eclipse

By following the below steps, we can integrate the Developer tools provided by Oracle WebCenter Sites with Eclipse.

  1. Download and Install WebCenter Sites JDK.
  2. Download the latest version of Eclipse, and install it.
  3. In the WebCenter Sites distribution package, there is a filde called csdt.zip. Unzip it.package. Open the csdt-eclipse folder and save the com.fatwire.csdt.eclipsecsdt_1.0.0.jar file to the plugins folder under your Eclipse installation
  4. Start your local instance of WebCenter Sites (JDK).
  5. Start Eclipse (eclipse.exe) and configure its settings according to your preferences.
  6. In the Eclipse menu bar, select Window > Open Perspective > Other … > Oracle WebCenter Sites.
  7. The configuration screen is displayed. In the configuration screen, fill in the following fields with the information for your WebCenter Sites instance
  8. In the “Sites Installation Directory” field, click Browse to select the directory containing the futuretense.ini file for the WebCenter Sites instance.
  9. In the “Username” field, enter the user name of a general administrator. This user must be a member of the RestAdmin group.
  10. In the “Password” field, enter the password for the user name you entered.
  11. In the “Project name” field, enter a name for the project on which you will be working.
  12. In the “Sites Log File” field, enter the location of your log file (for example, C:/ WCS/logs/sites.log).
  13. The Configuration screen looks as below:Config Screen
  14. Click OK.

 

Configuration is now Complete. Now, the “Oracle WebCenter Sites” perspective opens.  The Oracle WebCenter Sites perspective looks as shown in the below image:

Eclipse IDE

Now you can create and play with templates, elements etc, from eclipse, then sync them with WCS and enjoy coding. Happy Coding 🙂

Related Articles

All the Fatwire / Oracle WebCenter Sites developers are familiar with coding the templates through either Admin interface, or using a text editor such as notepad, etc.  But, Oracle WebCenter Sites provides us with a plugin called DEVELOPER TOOLS (In Fatwire, it was called as CONTENT SERVER DEVELOPER TOOLS plugin), which enables us to work with an Integrated Development Environment like Eclipse. What all we need to do is to use this plugin, and make our work easy by working with Eclipse IDE.

The Developer Tools kit enables developers to work in a distributed environment using tools such as the Eclipse IDE and version control system integration. The developer interacts with Developer Tools (and WebCenter Sites), primarily through Eclipse, which upon integration provides a  set of WebCenter Sites-specific tools for managing assets and other resources.

The Developer Tools kit enables synchronization of resource development in Eclipse with resource development in WebCenter Sites, and resources of WebCenter with resources of Eclipse.

Eclipse Plug-in

 

 

USES OF ECLIPSE IDE Integration

 

There are pretty good usages of integrating the plugin with Eclipse, and coding through Eclipse. Following are the uses through Eclipse integration:

  • Create, edit, and delete Templates, CSElements, and SiteEntries.
  • Develop JSPs with Eclipse features such as tag completion, syntax highlighting, debugging, etc.
  • Export and import assets, asset types, flex families, sites, roles, tree tabs, and start menu items
  • View the output, i.e, Previewing of WebCenter Sites pages within the Eclipse IDE using the preview browser
  • View the WebCenter Sites log file in the error console.

 


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 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.

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.