|
|
Before developing content and incorporating it within your portal application, you must choose the types of repositories you will use and connect them to the Virtual Content Repository. This chapter discusses your repository options.
When you create a portal application, it is configured to use a WLP repository. If you decide to use a WLP repository, you need to choose which type of repository to use: the default database repository or a file system repository.
If you already have existing content in another repository, you can connect it to the Virtual Content Repository using an SPI (Service Provider Interface) implementation. For information on how to do this, see the Content Management SPI Development Guide.
This chapter includes the following sections:
Regardless of what type of repository you use to store your content, all repositories must be connected to the Virtual Content Repository in WebLogic Portal. The Virtual Content Repository allows content contributors to access repositories using the content tools in the WebLogic Portal Administration Console. The Virtual Content Repository also connects your repositories to your portal application so that developers can deliver repository content to your portal users.
| Note: | You can connect the same repository to multiple portal applications. When using the same repository for multiple applications, only the most immediate application will have access to immediate changes. You can adjust your repository cache settings to ensure that repository views are updated frequently. For more information about setting a repository caches, see Modifying a WLP Repository. |
Users (content contributors, administrators, and developers) can access the Virtual Content Repository through the WebLogic Portal Administration Console, shown in Figure 2-1.
| Note: | If you are using a third-party repository, whether or not you can modify content using the Virtual Content Repository depends on the implementation used to connect to the Virtual Content Repository. For more information about using third-party repositories, see Connecting to a Third-Party Repository. |
The default WLP repository comes pre-configured for use within your portal environment. It includes library services which provide content workflows and versioning. For more information about library services, see Adding Content to a WLP Repository.
The default configuration uses tables in the portal database to store metadata, content, and content versions. For more information about the WLP default repository, see Configuring WLP Repositories.
WLP file system repositories allow you to use a file system in tandem with the database to store your content. When you use a file system repository, content binary files (stored as binary properties) are stored in the file system you designate, while the metadata associated with the files (content type information) is stored in the a database.
This can increase performance for both data retrieval within your portal and portal tools. Content queries are executed against the database, and results are returned from the file system.
| Caution: | When using a file system repository, content contributors must use the WebLogic Portal Administration Console to work with content. If content is directly manipulated within the file system, data will be out of sync and behave unpredictably. |
When using a file system repository with library services, versioned content is stored in the database. This provides an additional safeguard if the file system is damaged or removed. For more information about library services, see Adding Content to a WLP Repository.
For more information about using a file system repository, see Configuring WLP Repositories.
You can use third-party content repositories with WebLogic Portal. Some third-party content management systems provide connection interfaces for the Virtual Content Repository. Oracle provides a set of Java classes called the WebLogic Portal Content Service Provider Interface (SPI), which many content management vendors have implemented. If the vendor of your content management system has implemented the SPI, then adding your repository to the Virtual Content Repository will simply require a configuration within the WebLogic Portal Administration Console.
However, if your vendor has not implemented Oracle’s SPI, follow the instructions in the Content Management SPI Development Guide.
If you are using a JSR 170-compliant repository, you do not need to write an SPI. WebLogic Portal includes JSR 170 connector to connect to any JSR 170-compliant repository.
When using a third-party repository to store content, you can continue to use that repository’s content tools to add and modify content, or depending on the implementation, you may be able to use Oracle’s content tools.
If the SPI implementation is read only, you need to use the third party repository’s tools to create and edit content. However, if the implementation is read/write, then you use either the WebLogic Portal Administration Consoleor the third-party repository’s tools.
When you use a WLP repository, you need to decide how to logically organize your content to ensure that it is easily retrieved, managed, and used within your portal. Specifically, you should set up a hierarchy of content folders and create the content types that define the content properties. Content properties provide values, such as name and author, for content contributors when they create content.
| Tip: | Content types and their associated properties provide a flexible way to search for content within the repository. Portal developers can also retrieve content based on its location path within a repository. By thoughtfully planning your content types and content folder hierarchy, you make it easier for portal developers to retrieve and deliver content within your portal application. For complete details on content types, see Using Content Types in Your WLP Repository. |
Portal developers can use the metadata (properties) associated with content types to retrieve content files to display within your portal. When you set up content types, you want to be sure to include properties that are useful when retrieving and displaying content, such as the size of an image, whether portal users can click the content, and an expiration date.
| Tip: | Use metadata to implement a start date so that developers can schedule a go-live time at a future date. |
When using a library services-enabled WLP repository, you can also create and assign content workflows to content to ensure that content contributors can route content to the appropriate approvers before content is published. For complete details on using content workflows, see Using Content Workflows in Your WLP Repository.
When setting up Delegated Administration and Visitor Entitlements, you determine who can add, edit, or delete content within the repository by defining users, groups, and roles.
Visitor Entitlements allow a way for portal administrators to limit what content portal users can view. For example, within a human resources portal, you can entitle content published for managers so that only a user with a manager role can view that content.
You can use Delegated Administration to create administration roles for users and groups who create content or maintain your repository within the WebLogic Portal Administration Console. For example, you can set up a role for users responsible for publishing content, where the role displays only features related to creating and editing content and does not display any other administrative features such as creating types or workflows. You can also create a separate role for creating content types or new folders.
For more information about setting up security, see the WebLogic Portal Security Guide.
For more information about setting up users and groups, see the WebLogic Portal User Management Guide.
|