Repository Guide

Working with BEA Repositories

WebLogic Portal uses the Virtual Content Repository to access content repositories. The Virtual Content Repository can contain multiple content repositories, including third-party repositories. Because the Virtual Content Repository maintains connections with all associated content repositories (according to parameters you set), it allows you to federate your content management tasks across all repositories such as creating content types, delegated administration roles and content search.

Many Portal subsystems interact with the Virtual Content Repository, including:

Content Management JSP tags that execute queries to deliver dynamic content to end users
Content Selectors
Campaigns that deliver dynamic, personalized content to users, based upon personalization rules or conditions

Architectural Overview of BEA Repositories

Generally, each BEA Repository uses the portal database to store content and associated content metadata. However, depending on your needs, this configuration can change. This section discusses Virtual Content Repository terminology, basic architectural points, and some diagrams to illustrate different types of repositories.

When To Create Repositories

You must create connections to any content repositories (third-party or BEA) before packaging your application into an EAR file. This means creating only the root repositories, not the content nodes and content items. After you create repositories, they are registered in the application-config.xml deployment descriptor. When you create the application EAR, application-config.xml becomes read-only and cannot be modified within the EAR. That is, you cannot add or remove repositories in the WebLogic Administration Portal when the application is in an EAR file.

For information on creating repositories, see the "Add a New Repository Connection" in the WebLogic Administration Portal help system at http://download.oracle.com/docs/cd/E13218_01/wlp/docs81/adminportal/help/CM_CreateNewRepository.html.

Table 1-1 BEA Repository Terminology

Term	Definition
Repository	The physical store for all folders (nodes), content items, properties and types. For a BEA Repository, this can be just a database, or a database plus a filesystem. A repository can also be a third-party or in-house content repository.
Repository Connection	The configuration information that describes how to connect and interact with a repository. This includes the SPI implementation information, the repository name and other additional properties specific to the repository implementation.
Database	The physical database used to store: Content metadata Content binaries (if you are not using a separate filesystem) Published content (if using Library Services)
Filesystem	The physical location of the filesystem that contains the binary content files associated with the metadata stored in the database.
Virtual Content Database	The database tables used to store versioning and lifecycle information for non-published content, when using BEA's Library Services.

Architectural Summary

Within any repository configuration, the following guidelines apply:

Content metadata is always stored in the database.
If you are using Library Services, additional database tables are used to store non-published binaries and their associated metadata.
If you choose to use a filesystem to store your binary content (instead of a database), the metadata for those binaries will still be stored in the database.
If you use a third-party repository and/or content management system, you will need to create a Repository Connection to that repository so it is "known" to the Virtual Content Repository.

Figure 1-1 Architecture of a Database-based BEA Repository

Architecture of a Database-based BEA Repository

This is the simplest architecture used and outlines the structure of the default BEA Repository.

Figure 1-2 Architecture of a Filesystem-based BEA Repository

Architecture of a Filesystem-based BEA Repository

With a filesystem-based repository is the repository connection goes directly to the path of the repository filesystem where the binaries are kept.

Figure 1-3 Architecture of a Filesystem-based BEA Repository that uses Library Services

Architecture of a Filesystem-based BEA Repository that uses Library Services

When a repository uses Library Services, separate database tables are used to store versioning and lifecycle information. Only the binaries with a status of "published" are stored in the filestore. For more information, see Using Library Services with a Filesystem Repository.

Working with a Filesystem Repository

Filesystem repositories allow you to store your binary content in a filesystem, yet still access that content with the functionality provided by the Virtual Content Repository.

Typically, this increases performance for both data retrieval within your portal and bulkloading large amounts of data (and its associated metadata) to a repository database within the WebLogic Portal Virtual Content Repository.

Using Content Types

There are two considerations for using content types within a fileystem repository.

Content types must have ONE and only one binary property definition. This property definition must be declared as primary and required.
In a filesystem repository, a hierarchy node (folder) cannot be associated with a content type. In other words, folders cannot be with associated with metadata.

Adding Content to a Filesystem Repository

When you create a filesystem repository, you use the Virtual Content Repository to add and delete content from the filesystem. The structure of the filesystem will mimic the structure of the repository. For example, creating a folder in a filesystem repository creates a folder in the shared directory.

Note: When organizing content within a filesystem repository, content items cannot contain other content items. Only content folders (hierarchy nodes) can contain content items.

Naming Content Items

When adding content, the name of the content item will match the name of the associated binary file, see Modifying Content within a Filesystem Repository . When you use the Bulkloader to add new content items, content items are named according to the binary file name associated with them.

Modifying Content within a Filesystem Repository

When you replace the binary file associated with a content item, the original binary file is deleted from the filesystem repository and replaced with the new file. The name of the content node is changed to match the name of the new file.

Warning: When you rename a content item, the associated binary file is also renamed. Because of this, be sure to always include the file extension when renaming content items within a filesystem repository.

Deleting Content from a Filesystem Repository

When you delete a folder or content item within a filesystem repository, both the binary file (stored in the filesystem) and the associated metadata (stored in the database) are deleted.

Using Library Services with a Filesystem Repository

A filesystem repository can be Library Services-enabled. When using Library Services, only content items with a "published" status are kept in the filesystem. Non-published versions of content items are stored in the database. This provides an additional safeguard if the filesystem gets damaged or removed. If you use Library Services with a filesystem repository, you automatically have a backup of all non-published binaries which are kept in the Virtual Content Database (see Figure 1-3, Architecture of a Filesystem-based BEA Repository that uses Library Services, on page 1-4).

Bulkloader Considerations

When using Library Services with a filesystem repository, you cannot use the Bulkloader to update existing content (or its metadata).

When you add new content to a filesystem repository that is using library services, all new content will be created as checked out in Draft status under bulkloader's username.

Configuring a Filesystem Repository

When you configure a repository within the Virtual Content Repository, you are creating a connection to the repository's datastore. In the case of a filesystem repository, the datastore is a filesystem on your network. When you add filesystem repository, you also need to add custom properties that direct WebLogic Portal to that filesystem.

The two steps required for configuring a filesystem repository are:

Creating a connection to the new filesystem repository
Using the Bulkloader to upload the metadata associated with the filesystem repository data

Before You Begin

The recommended way to implement a filesystem repository is to modify the properties of the default BEA repository. By default, the BEA repository class remains deployed even after you modify the connection information. This is intended because the BEA repository classes (com.bea.content.spi.internal.RepositoryImpl) are used to store metadata in the database.

Create a Connection to the New Filesystem Repository

Using the Portal Administration Portal, configure a connection to the soon-to-be new repository.

View the Manage Repositories tree by selecting Repository from the View drop-down list.

In the Manage Repositories tree, right-click the existing BEA repository.

Select Edit Repository from the pop-up menu.

In the Editor pane, provide the following information:

Input Field	What Is Needed:
Repository Name	Enter the name of the repository you are creating. For example, FileRepository.
Connection Class	If you are using a filesystem repository, the connection class is the following: `com.bea.content.spi.internal.FileSystemRepositoryImpl`
User Name	Enter the user name you want to use to login to this repository.
Password	Enter the password associated with the user name used to login to this repository.
Enable Library Services	Mark this checkbox if you want to use WebLogic Portal's library services for this repository. Library Services cannot used with third-party content management systems. If you want remove Library Services, you will need to create a new instance of the repository.

Click Add Property.

In the Key field, enter cm_fileSystem_path.
In the Value field, enter the path to the filesystem that contains your content. For example: /home/myData.

Be sure that the your portal application has network access to your filesystem.

Optionally, if you are accessing your filesystem through a web server, you can add an additional property. Click Add Property.

For example, your cm_fileSystem_path could be set to /home/myData but the same path could be referred externally as http://mydomain.com/data/myData which can be set via the cm_fileSystem_webpath property.

In the Key field, type cm_fileSystem_webpath.
In the Value field, enter the URL of your filesystem.

Although not required, it is highly recommended that you set the cm_fileSystem_webpath property if your filesystem is exposed via a web server as it can significantly improve performance.

In the Cache Properties box, edit the cache properties, if necessary. You can also choose to accept the default cache settings.

Click Create.

Warning: Do not set the STREAMING_ENABLED property for a filesystem repository.

Use the Bulkloader to Upload Metadata for the Associated Filesystem

Note: This example uses the following sample names:

The cm_fileSystem_path of the filesystem repository is /home/myData
The name of the repository within the Virtual Content Repository is FileRepository.
The name of the filesystem directory is filesystem.

Populate /home/myData with the directory that you want to upload.

Call the BulkLoader with the following arguments:

java com.bea.content.loader.bulk.BulkLoader -fileSystem -application <myApp> -repository FileRepository /home/mydata/filesystem

This will upload all the data into the filesystem repository.

Open the Virtual Content Repository within the Portal Administration portal to view your uploaded data. In this example, you would see a folder called filesystem below the FileRepository that would contain all the uploaded data.

Warning: If the Bulkloader fails during upload for any reason, you will need to delete the cm_fileSystem_linked property for the filesystem repository you created in the Virtual Content Repository. This property is temporary and used by the Bulkloader during upload. If the upload fails, delete this property before you try again.

For more detailed information about using the Bulkloader, see the Bulkloader Guide.

Working with a Third-Party Repository

For more information about working with third-party repositories, see http://download.oracle.com/docs/cd/E13218_01/wlp/docs81/whitepapers/vcr/index.html.