Overview of Content Management

The content you want to show users, whether it is a single line of text, an HTML file, a graphic, or an animation file can be stored in a content repository. BEA's Virtual Content Repository, included with WebLogic Portal, provides a single interface that lets you store content in BEA repositories as well as seamlessly incorporate BEA-compatible third-party content management systems. This overview provides information on the following subjects:

The Virtual Content Repository

The Virtual Content Repository can contain multiple content repositories. It provides services such as federated search (a search that returns a result set from all the relevant content across the plugged in repositories), content lifecycle management, Delegated Administration and content type management. Many Portal subsystems interact with the Virtual Content Repository. Content Management tags execute queries to deliver dynamic content to end users. Content Selectors and Campaigns deliver dynamic, personalized content to user based upon personalization rules or conditions.

The Content Hierarchy

WebLogic Portal Content Management is organized hierarchically. The Virtual Content Repository (VCR) is the top-level node in the content management system. Repositories are the immediate children of the VCR. These repositories can be made up of multiple BEA Systems repositories, multiple third-party repositories, or custom content repositories.

Hierarchy Nodes and Content Nodes comprise the next level of the hierarchy tree and are organized much like a file system. Hierarchy Nodes can contain both Hierarchy Nodes and Content Nodes. Content Nodes can only contain other Content Nodes. Nodes can be created based upon Content Types. For example:

Content Repositories provide the storage mechanism for content, and they comprise the second-level of the Virtual Content Repository hierarchy. Content Repositories may include multiple instances of BEA repositories, 3rd party repositories, or customer repositories. To plug into the Virtual Content Repository, you must implement the BEA Content Management Service Provider Interface – the CM SPI. See the com.bea.content.spi package in the WebLogic Portal Javadoc.

Hierarchy Nodes are organizational mechanisms that help you organize and group content in the hierarchy, much like folders in a file system. Hierarchy Nodes can contain other Hierarchy Nodes as well as Content Nodes. They can also be typed so that they function similarly to Content Nodes.

Content Nodes represent content stored in the repository. A complete content node comprises a set of data property values defined by a content type. This data structure may include files such as a word processing document, HTML file, spreadsheet or image. It may also include metadata such as the author, version number or summary. Content Nodes can also have child Content Nodes. For example, The Content Node for an HTML document may have child Content Nodes for the images used by the HTML document.

Content Types

Content Types define the set of properties that make up a Content Node or Hierarchy Node. This may include any combination of the supported data types, such as date and time, number, text (string), Boolean (true/false), or binary (file).

For example, the Content Type for image content may have a number property "width" and a number property "height," while the Content Type for news article content my have a text property "Author", a text property "Summary", a date property "Published Date", and a binary property "Article" for a file containing the formatted article. Types do not have to include a binary, although a common example of a type is a single binary with a set of non-binary properties that describe the document.

Content Types also define the available values for a given property, including whether it can contain multiple values. For example, a property called "Priority" may only allow a single choice among the values "High", "Medium", and "Low", while a property called "Favorite Color" may allow multiple pre-defined values to be chosen.

Each repository has its own set of content types. You can create types in BEA repositories and third-party repositories that support this feature.

Creating and Modifying Content

After you connect a BEA-compatible content management system to the Virtual Content Repository you can continue to add and modify content directly in your BEA-compatible content management system. Changes appear automatically in the Virtual Content Repository. You can create and manage content in the Administration Portal, in the My Content Portlet, or with the bulkloader.

WebLogic Administration Portal
BEA's Virtual Content Repository, available in the WebLogic Administration Portal under "Content Management," lets you add and modify content nodes and assign types (metadata) to those nodes. Through these tools, you can manage content in all the repositories plugged into the Virtual Content Repository that support management functions.
Bulkloader
The BulkLoader is a command-line application that is capable of loading document metadata into the reference implementation database from a directory and file structure. The BulkLoader parses the document base and loads all the document metadata so that the Content Management component can search for documents.
My Content Portlet
My Content portlet provides you with tools to manage your content in the BEA Virtual Content Repository. You can create, update, and delete content directories and nodes as well as browse content hierarchies and search for content.

Using Content in Personalized Applications

WebLogic Workshop extensions support development of personalized applications, while the WebLogic Administration Portal enables portal administrators to adapt site interaction to fit the needs of the audience. The core of the Personalization system is the underlying rules engine that matches users with appropriate content. Content Selectors, Placeholders and Campaigns are the aspects of content management visible to administrators. Also, User Segments contain the criteria that define the target visitor, such as gender or browser type.

The Content Management component provides the run-time API by which content is queried and retrieved. The functionality of this component is accessible via tags. The content retrieval functionality is provided using either the provided reference implementation or third-party content retrieval products.