Portal Content Management

A key component of any portal is its content. WebLogic Portal provides content by using a Content Manager. A Content Manager provides content and document management capabilities for use in personalization services to target users with dynamic web content. It works with files or with content managed by third-party vendor tools. While developing portal resources, you will have to configure the Content Manager and use various content-related tags so that the user has access to the most relevant content available.

This section includes information on the following subjects:

Adding Content by Using the Bulk Loader

The easiest way to add content to a portal is to use the bulk loader scripts provided by BEA. To implement this strategy, use this procedure:

For this strategy to succeed, the CMS must be able to publish document metadata in one of the three ways the BulkLoader supports:

BulkLoader Performance Tips

The following suggestions will improve BulkLoader performance.

Clean Up the Cache

Figure 8-1 Flushing the Cache

Restarting the ConnectionPool

If you used the E-Business Control Center to add new metadata properties, you need to restart the connectionPool. To do so:

Configuring the Content Manager

If you are using a third-party Content Management System to populate a portal, you will need to configure it to work with WebLogic Portal. This section explains the configuration procedures you will need to perform.

The Content Manager is a run-time subsystem that provides access to content through tags and EJBs. When developing JSPs, the Content Management tags allow you to receive an enumeration of content objects by querying the content database directly by using a search expression syntax. The Content Manager component works alongside the other components to deliver personalized content, but does not have a GUI-based tool for edit-time customization.

The following section describes the tasks required to configure a Content Manager. It includes information on the following subjects:

Configuring the DocumentManager EJB Deployment Descriptor

The DocumentManager EJB deployment descriptor handles the EJB portion of the Content Management component configuration and must be configured to recognize the correct environmental settings. To configure the DocumentManager EJB, ensure that the following environment settings are in its deployment descriptor:

Configuring the PropertySetManager EJB Deployment Descriptor for Content Management

The DocumentManager needs to be integrated into the PropertySetManager EJB deployment descriptor so that content property sets are exposed to the system. To configure the PropertySetManager EJB Deployment Descriptor for content management, add the following environment settings:

Alternately, you can set the JNDIName attribute of the DocumentManager MBean to the JNDI Home name of the DocumentManager. The ${APPNAME} construct can be used in the value; it will be replaced by the current J2EE application name. The com.bea.p13n.content.PropertySetRepositoryImpl will automatically pick up those DocumentManagers and the J2EE EJB reference is not required.

Configuring DocumentManager MBeans

The DocumentManager implementation uses DocumentManager MBeans to maintain its configuration. A deployed DocumentManager finds which DocumentManager MBean to use from the DocumentManagerMBeanName EJB deployment descriptor setting. You will need to configure the DocumentManager MBeans in the application so that their values correspond to the Name attributes in the DocumentManagerMBeanName EJB deployment descriptor.

Listing 8-1 Modifying the <DocumentManager> Element in an Application's META-INF/application-config.xml File

<DocumentManager
  Name="default"
  DocumentConnectionPoolName="default"
  PropertyCase="none"
  MetadataCaching="true"
  MetadataCacheName="documentMetadataCache"
  UserIdInCacheKey="false"
  ContentCaching="true"
  ContentCacheName="documentContentCache"
  MaxCachedContentSize="32768"
>
</DocumentManager>

Using the WebLogic Server Administration Console to Modify DocumentManager MBeans

To modify DocumentManager MBeans by using the WebLogic Server Administration Console, use this procedure.

Disabling an MBean

You can enable or disable an MBean from the WebLogic Server Administration Console. To do so, use this procedure.

Restoring a Disabled MBean

To restore the MBean disabled in the preceding procedure, click its acssociated checkbox to select it. Again, once you've restored all necessary MBeans, click Submit.

Setting Up Document Connection Pools

The DocumentManager implementation uses connection pools to a specialized JDBC driver to handle searches on content. A deployed DocumentManager finds the document connection pool to use via either the DocumentConnectionPoolName attribute of its DocumentManager MBean or the DocumentConnectionPoolName EJB deployment descriptor setting. That value must correspond to a DocumentConnectionPool MBean.

Listing 8-2 Modifying an Application's META-INF/application-config.xml File to Configure a DocumentConnectionPool MBean

<DocumentConnectionPool

Name="default"DriverName="com.bea.p13n.content.document.   jdbc.Driver"URL="jdbc:beasys:docmgmt:com.bea.p13n.content
   document.ref.RefDocumentProvider"
Properties="jdbc.dataSource=weblogic.jdbc.pool.commercePool;
   schemaXML=D:/bea/user_projects/myNEWdomain/dmsBase/
   doc-schemas;docBase=D:/bea/user_projects/myNEWdomain/dmsBase"
InitialCapacity="20"
MaxCapacity="20"
CapacityIncrement="0"

/>

Editing a DocumentConnectionPool MBean in the WebLogic Console

Figure 8-9 Document Connection Service Pool Screen

Configuring the Web Application

Listing 8-3 Mapping the ShowDocServlet

<servlet>
  <servlet-name>ShowDocServlet</servlet-name>
  <servlet-class> com.bea.p13n.content.servlets.ShowDocServlet
  </servlet-class>

  <!-- Make showdoc always use the local ejb-ref DocumentManager -->

  <init-param>
    <param-name>contentHome</param-name>
    <param-value>java:comp/env/ejb/DocumentManager</param-value>
  </init-param>

</servlet>

...

<servlet-mapping>
  <servlet-name>ShowDocServlet</servlet-name>
  <url-pattern>/ShowDoc/*</url-pattern>
</servlet-mapping>

This will allow the ShowDoc/ URI under your Web Application's context root (for example, /wlcs/ShowDoc) to be sent to the ShowDocServlet. The contentHome <init-param> will cause that ShowDocServlet to always use the ejb/DocumentManager EJB reference; you can take this out to allow ShowDocServlet to obey any contentHome request parameters.

To access the Content Management tag libraries, you will need to:

Using Content-Selector Tags and Associated JSP Tags

A content selector is one of several mechanisms that WebLogic Portal provides for retrieving documents from a content management system. You can use content selector JSP tags and a set of other JSP tags to retrieve and display the content targeted by the content selector.

This section describes how to use content-selector tags and their associated JSP tags to manage content. It includes information on the following topics:

Using the <pz:contentSelector> Tag

The <pz:contentSelector> selector tag allows you to do the following:

Identify the Content Selector Definition

The content selector definition created in the E-Business Control Center determines the conditions that activate a content selector and the query that the active content selector runs.

To refer to this definition, use the rule attribute:

<pz:contentSelector rule= { definition-name | scriptlet } >

You can use a scriptlet to determine the value of the rule attribute based on additional criteria. For example, you use a content selector in a heading JSP (heading.inc), which is included in other JSPs. You can create different content selectors for each page that includes heading.inc.

Listing 8-4 Using a Scriptlet in heading.inc

 String banner = (String)pageContext.getAttribute("bannerPh");
   banner = (banner == null) ? "cs_top_generic" : banner;

%>

<!-- ------------------------------------------------------------- -->

<table width="100%" border="0" cellspacing="0" cellpadding="0"
   height="108">

  <tr><td rowspan="2" width="147" height="108">
  <pz:contentSelector rule="<%= banner %>" ... />

</td>

Identify the JNDI Home for the Content Management System

The content selector tag must use the contentHome attribute to specify the JNDI home of the content management system. If you use the reference content management system or a third-party integration, you can use a scriptlet to refer to the default content home. Because the scriptlet uses the ContentHelper class, you must first use the following tag to import the class into the JSP:

<%@ page import="com.bea.p13n.content.ContentHelper"%>

Listing 8-5 Specifying contentHome in a Content-Selector Tag

<pz:contentSelector
contentHome="<%=ContentHelper.DEF_DOCUMENT_MANAGER_HOME %>"
... />

If you create your own content management system, you must specify the JNDI home for your system instead of using the ContentHelper scriptlet. In addition, if your content management system provides a JNDI home, you can specify that one instead of using the ContentHelper scriptlet.

Define the Array That Contains Query Results

Create and Configure the Cache to Improve Performance

To extend accessibility of retrieved content and to improve performance, you can optionally use content selector attributes to create and configure a cache that contains the array contents. Without the cache, you can access the content selector array only from the current JSP page, and only for the customer request that created it. In addition, each time a customer requests a JSP that contains the content selector tag, the content selector must run the query, potentially slowing the overall performance of WebLogic Portal.

Associated Tags That Support Content Selectors

Using Content Selector Tags and Associated Tags

The combination of content selector definitions, tag attributes, and associated JSP tags creates a powerful set of tools for matching documents to customers in specific contexts. The following tasks are the most common uses of content selectors and associated tags:

Retrieving and Displaying Text-Type Documents

To retrieve and display text-type documents, use this procedure:

Note: This procedure assumes that the content selector query created in the E-Business Control Center includes a filter to retrieve only text documents.

Listing 8-6 Code to Import Classes and Tag Libraries

Listing 8-7 Content Selector Tag Example 1

Listing 8-8 Verifying the Content Type

Retrieving and Displaying Image-Type Documents

To retrieve and display image-type documents, use this procedure:

Listing 8-9 Code to Import Classes and Tag Libraries if They are not Already in the JSP

Listing 8-10 Content Selector Tag Example 2

Listing 8-11 Surrounding an <img> Tag with a Scriptlet

<% if (anImageDoc .getMimeType().contains("image"))
{
%>
  <img src="ShowDoc/<cm:printProperty
  id="anImageDoc" name="identifier" encode="url"/>">
} 
%>

Retrieving and Displaying a List of Documents

To retrieve and display a list of documents, use this procedure:

Listing 8-12 Code to Import Classes and Tag Libraries if They are not Already in the JSP

Listing 8-13 Content Selector Tags Example 3

To access a content selector cache on a Different JSP, use this procedure:

Listing 8-14 Content Selector Tag Attributes

Listing 8-15 Adding an Identical Tag

<pz:contentSelector rule="SpringSailing" 
contentHome="<%=ContentHelper.DEF_DOCUMENT_MANAGER_HOME %>"
id="docs" 
useCache="true" cacheId="SpringSailingDocs" cacheTimeout="120000"
cacheScope="application" /> 

Integrating External Content Management Systems

For customers who have larger amounts of content and want more control over the publishing and tagging of content, BEA partners with third-party vendors to add flexibility to WebLogic Portal. Third-party content management systems provide robust, content-creation management solutions while the Content Manager personalizes and serves the content to the end user.

Integration Strategies

BEA recommends three strategies for integrating a third-party content management system with the WebLogic Portal:

Adding Content by Implementing a DocumentProvider Interface

The DocumentProvider object is the entry point into an SPI implementation. It consists of methods that access the underlying content management system. When developing a DocumentProvider, you do not need to be concerned about transactional state or thread safety. Since a DocumentProvider does not need to perform write actions, a transaction is not required to access a DocumentProvider.

Implementing a DocumentProvider interface involves writing implementations of Java interfaces contained in the com.beasys.p13n.content.document.spi package. These interfaces are:

The following sections describe how these interfaces are implemented to integrate a CMS with WebLogic Portal.

The following steps present a high-level description of how to implement a DocumentProvider interface.

Step 1. Ensure that the CMS Meets the Minimum Use Requirements

If all of these requirements cannot be met in some fashion, it will not be possible to fully integrate the CMS with WebLogic Portal. Additionally, since WebLogic Portal does not provide document creation and editing functionality, the CMS must have some way for users to create and edit documents.

Step 2. Write the SPI Implementation

Additional DocumentProvider Classes to Implement

In addition to the interfaces listed in Table 3-1, you can use some of the abstract classes in the com.bea.p13n.content.document.ref package as base classes to implement some SPI functionality. These classes include:

Other classes that can help in developing a DocumentProvider implementation include:

Implementing Search and Schema Methods

In general, integating a third-party CMS requires that you implement both search methods and schema methods.

Search methods return metadata about a document; that is, the data that determines the appearance of the data returned. You will need to determine how the search criteria passed into the search object corresponds to the search methods allowed by the CMS and then define this mapping in order for the search to work.

Schema methods return the "bytes"; that is, something that represents the data to be consumed by the Web application. Assuming that the necessary data exists in the polled CMS, these methods will return:

Step 3. Place Code Into the Application

Once the SPI implementation is written, WebLogic Portal needs to be configured to use it. To do this, you can either:

OR

Modify the Existing DocumentConnectionPool

The first method is to simply modify an existing DocumentConnectionPool in the application's META-INF/application-config.xml. The DocumentManager implementation uses connection pools to a specialized JDBC driver to handle searches. A deployed DocumentManager finds the document connection pool to use via either the DocumentConnectionPoolName attribute of its DocumentManager MBean or the DocumentConnectionPoolName EJB deployment descriptor setting.

Configure a New DocumentConnectionPool and DocumentManager

The second way to configure WebLogic Portal is to set up a new DocumentConnectionPool in the application's META-INF/application-config.xml file and to deploy a new DocumentManager EJB in the application.

Next, put together the new EJB by using the following procedure:

Listing 8-16 Creating a New <session>

<!--  The Newsletter DocumentManager  --> 
<session>
<ejb-name>NewsletterDocumentManager</ejb-name>
   <home>com.bea.p13n.content.document.DocumentManagerHome</home>
   <remote>com.bea.p13n.content.document.DocumentManager</remote>
   <ejb-class>com.bea.p13n.content.document.internal.
      SPIFastDocumentManagerImpl</ejb-class>
   <session-type>Stateless</session-type>

   <transaction-type>Container</transaction-type> 

   <!--
    This controls which DocumentManager MBean this instance
    will look for in the application-config.xml.
   --> 

   <env-entry>
      <env-entry-name>DocumentManagerMBeanName</env-entry-name>
      <env-entry-type>java.lang.String</env-entry-type>
      <env-entry-value>newsletter</env-entry-value>
   </env-entry>
</session>

Listing 8-17 Adding <assembly-descriptor> and <container-transaction> Entries

<assembly-descriptor>
   <container-transaction>
      <method>
         <ejb-name>NewsletterDocumentManager</ejb-name>
         <method-name>*</method-name>
      </method>
      <trans-attribute>Required</trans-attribute>
   </container-transaction>
   .
   .
   .
</assembly-descriptor>

Listing 8-18 Creating a New <weblogic-enterprise-bean> Entry

<weblogic-ejb-jar>
   <weblogic-enterprise-bean>
      <ejb-name>NewsletterDocumentManager</ejb-name>
      <entity-descriptor>
         <persistence>
            <persistence-type>
               <type-identifier>WebLogic_CMP_RDBMS
               </type-identifier>
               <type-version>7.0</type-version>
               <type-storage>META-INF/weblogic-cmp-rdbms-jar.xml
               </type-storage>
            </persistence-type>
            <persistence-use>
               <type-identifier>WebLogic_CMP_RDBMS
               </type-identifier>
               <type-version>6.0</type-version>
            </persistence-use>
         </persistence>
      </entity-descriptor>

   <jndi-name>${APPNAME}.BEA_portal_examples.
      NewsletterDocumentManage</jndi-name>

</weblogic-enterprise-bean>

Step 4. Make the .jar Accessible to the Application

Next, you need to make the .jar file you created accessible to the application accessing the CMS. You can do this by using one of these methods:

Step 5. Restart the Server

Because, by this point, you have made a number of configuration changes and changes to classpaths, we recommend that you restart the server.

Step 6. Apply the Portal

Publishing to Reference Implementation

This strategy involves directly publishing to the WebLogic Portal reference implementation database tables and XML schema files.

To implement this strategy:

Constructing Content Queries

This section, which provides guidelines for constructing queries to a content management system, includes information on the following topics.

Structuring Queries

WebLogic Portal queries are similar in syntax to the SQL string syntax that supports basic Boolean-type comparison expressions, including nested parenthetical queries. In general, the query includes a metadata property name, a comparison operator, and a literal value. For example:

attribute_name comparison_operator literal_value

The following constraints apply to queries constructed using this syntax:

The following examples illustrate full expressions:

Example 1:

((color=`red' && size <=1024) || (keywords contains `red' && creationDate < now))

Example 2:

creationDate > toDate (`MM/dd/yyyy HH:mm:ss', `2/22/2000 14:51:00') && expireDate <= now && mimetype like `text/*'

Using Comparison Operators to Construct Queries

Notes: The search parameters and expression objects support negation of expressions using a bit flag (!).