BEA ホーム | 製品 | デベロッパ・センタ | support | askBEA
 ドキュメントのダウンロード   サイト マップ   用語集 
検索

開発者ガイド

 前 次 目次 索引 PDFで表示  

ポータル コンテンツ管理

どのようなポータルであれ、重要なのはそのコンテンツです。 WebLogic Portal では、コンテンツ マネージャを用いてコンテンツを提供します。 コンテンツ マネージャには、パーソナライゼーション サービスでユーザに動的な Web コンテンツを提供するためのコンテンツおよびドキュメント管理機能が用意されています。 コンテンツ マネージャが扱うのは、サードパーティ ベンダ製ツールで管理されるファイルやコンテンツです。 ポータル リソースの開発時には、利用できる最も適切なコンテンツにユーザがアクセスできるように、コンテンツ マネージャのコンフィグレーションを行い、さまざまなコンテンツ関連タグを使用する必要があります。

この章では、以下のトピックを扱います。

 


Bulk Loader を用いたコンテンツの追加

ポータルにコンテンツを追加する最も簡単な方法は、製品に付属しているバルク ローダ スクリプトを使用することです。 この方法を実行するには、以下の手順に従います。

  1. ファイル システム上のディレクトリに、指定された時間間隔でファイルをパブリッシュ(公開)します。 該当するドメイン フォルダ内の¥dmsBase ディレクトリのサブディレクトリにコンテンツをパブリッシュするのが理想的です。 たとえば、広告であれば、以下の場所に格納します。

    <BEA_HOME>¥weblogic700¥samples¥portal¥<DOMAIN_NAME>¥dmsBase¥ads

  2. ディレクトリ システム上のファイルにコンテンツをパブリッシュし終わったら、以下のスクリプトのいずれか一方を実行して BulkLoader を実行します。

    このロード スクリプトは以下の場所にあります。

    <BEA_HOME>¥weblogic700¥samples¥portal¥<DOMAIN_NAME>¥

    これらのスクリプトを実行するには、コマンド ライン(または、Windows NT/2000 では[スタートファイル名を指定して実行] )でそれらを入力するか、 あるいは、Windows エクスプローラを開き、実行したいスクリプトを見つけ、ファイル リスト内でそれをダブルクリックします。 コマンド ラインから BulkLoader を実行する場合には、表8-1 に示した任意のコマンドライン スイッチを使用することもできます。

    表8-1 Bulk Loader のスイッチ設定

    スイッチ設定

    解説

    -verbose

    詳細なメッセージを表示する。

    +verbose

    実行時にメッセージを表示しない(デフォルト)。

    -recurse

    ディレクトリ内を再帰的に処理する(デフォルト)。

    +recurse

    ディレクトリ内を再帰的に処理しない。

    -delete

    データベースからドキュメントを削除する。

    +delete

    データベースにドキュメントを挿入する(デフォルト)。

    -metaparse

    HTML ファイルの <meta> タグを解析する(デフォルト)。

    +metaparse

    HTML ファイルの <meta> タグを解析しない。

    -cleanup

    指定された場合、-d 引数をドキュメント ベースとして、テーブルのクリーンアップだけを実行する(すべてのファイルはそのディレクトリ下に存在しなければならない)。

    +cleanup

    テーブルのクリーンアップを実行せずに、ドキュメントをロードする(デフォルト)。

    -hidden

    隠しファイルおよび隠しディレクトリを無視するよう指定する(デフォルト)。

    +hidden

    隠しファイルおよび隠しディレクトリも処理の対象に含めるよう指定する。

    -inheritProps

    再帰処理時にメタデータ プロパティを継承するよう指定する(デフォルト)。

    +inheritProps

    再帰処理時にメタデータ プロパティを継承しないよう指定する。

    -truncate

    データ値がデータベースにとって大きすぎる(loader.properties で指定)場合、値の切り捨てを試みる。

    +truncate

    データ値の切り捨てを試みない(デフォルト)。

    -ignoreErrors

    ドキュメントのロード中は、エラーをすべて無視する(エラーの報告は行われる)。

    +ignoreErrors

    エラー発生時には処理を停止する(デフォルト)。

    -htmlPat <pattern>

    <meta> タグの解析を行うかどうかを判断する際にどのファイルが HTML ファイルなのかを判断するためのパターンを指定する。 これは何度でも指定可能。 何も指定されない場合には、*.htm*.html が使用される。

    -properties <name>

    connectionPool が定義されている loaddocs.properties ファイルの位置を指定する。 このファイルには、-columnMap 引数と同様の jdbc.column.<columnName>=<propname> という形式のエントリを記述してもよい。

    -conPool <name>

    BulkLoader による接続情報の取得先となるプロパティ ファイルに記述されている connectionPool 名 を指定する。

    -schema <name>

    BulkLoader によって生成されるスキーマ ファイルのパスを指定する
    (デフォルトは document-schema.xml)。

    +schema

    指定された場合、スキーマ ファイルは作成されない。

    -schemaName <name>

    BulkLoader によって生成されるスキーマの名前を指定する。 デフォルトは「LoadedData」。

    -encoding <name>

    使用するファイル エンコーディングを指定する。 デフォルトは、システムのデフォルト エンコーディング(有効なエンコーディング名については JDK マニュアルを参照)。

    -commitAfter <num>

    この数のドキュメントがロードされたあとに JDBC トランザクションをコミットする。 デフォルトでは、すべてをロードしたあとでのみコミットする。

    -match <pattern>

    BulkLoader の処理の対象となるファイル パターンを指定する。 これは何度でも指定可能。 何も指定されない場合には、すべてのファイルとディレクトリが対象となる。

    -ignore <pattern>

    BulkLoader の処理の対象とならないファイル パターンを指定する。 これは何度でも指定可能。

    -d <dir>

    相対パスの基準となる docBase を指定する。 指定されない場合には、「.」(カレント ディレクトリ)が使用される。

    -mdext <ext>

    メタデータ プロパティ ファイルのファイル名拡張子を指定する。 必ず 「.」で始まる値を指定する(デフォルトは .md.properties)。

    -filter <filter class>

    ファイルを処理する際に用いる LoaderFilter のクラス名を指定する。 これを複数回指定すれば、LoaderFilte のリストに追加することができる。

    +filters

    LoaderFilter の現在のリストをクリアする(デフォルト フィルタもクリアされる)。

    --

    後続のものがすべてファイルまたはディレクトリとみなされる。

    -columnMap <file.properties>

    DOCUMENT テーブルの追加カラム(-column を参照)のリスト(各エントリは jdbc.column.<columnName>=<propname,...> の形式)が記載されているプロパティ ファイルを指定する。 これは、標準カラムの動作をオーバーライドするために使用することはできない。

    -column <columnName>=<propName,...>

    DOCUMENT テーブルの追加カラムと、そのカラムにマップされるプロパティ名を指定する。 これは、標準カラムの動作をオーバーライドするために使用することはできない。

    +columns

    コンフィグレーション済みの追加カラムをすべてクリアする。


     

  3. アプリケーションの META-INF/application-config.xml に記述されている(または、WebLogic Server コンソールを通じて設定される)DocumentConnectionPool が正しいディレクトリを指すようにコンフィグレーションされていることを確認します。

  4. docPool が XML スキーマ ファイルを再ロードするためには、再起動する必要があります。

この方法がうまくいくためには、BulkLoader でサポートされている以下の 3 通りの方法のいずれかで、CMS がドキュメントのメタデータをパブリッシュ(公開)できなければなりません。

BulkLoader のパフォーマンス向上のヒント

以下の推奨事項に従えば、BulkLoader のパフォーマンスが向上します。

キャッシュをクリーンアップする

ページへの細かい更新を多数行った場合には、BulkLoader を実行する前に、キャッシュをクリーンアップしたほうがよいでしょう。 Administration Console の [Cache Manager] ノードの [管理] タブで、図 8-1に示すように [キャッシュ全体をフラッシュするか] を選択し、[フラッシュ] をクリックします。

図8-1 キャッシュのフラッシュ


 

フラッシュは、以下のキャッシュに特に有効です。

Connection Pool を再起動する

E-Business Control Center を用いて新しいメタデータ プロパティを追加してある場合には、Connection Pool を再起動する必要があります。 それには、以下を実行します。

  1. Administration Console の左ペインで、以下のノードを開きます。
    [<yourDomain>|デプロイメント|アプリケーション|<yourPortal>|Service Configuration|Document Connection Pool Service|default]

    Document Connection Pool サービスの [default] タブ (図 8-2 に示す)が、Console の右ペインに表示されます。

    図8-2 Connection Pool の再起動


     

  2. [適用後再起動] をクリックします。

 


コンテンツ マネージャのコンフィグレーション

サードパーティ製のコンテンツ管理システムを利用してポータルにコンテンツを供給する場合には、そのコンテンツ管理システムを、WebLogic Portal と連携するようにコンフィグレーションする必要があります。 この節では、必要なコンフィグレーション手順について説明します。

コンテンツ マネージャは、タグと EJB を通じてコンテンツにアクセスできるようにする実行時サブシステムです。 JSP を開発する際には、コンテンツ管理タグを使用すれば、検索式構文を用いてコンテンツ データベースに直接クエリを発行することでコンテンツ オブジェクトの一覧を取得できます。 コンテンツ マネージャ コンポーネントは、その他のコンポーネントと連携して、パーソナライズされたコンテンツを配信しますが、編集時カスタマイズに使用できる GUI ベースのツールは備えていません。

以下の節では、コテンツ マネージャのコンフィグレーションに必要な作業について説明します。 以下のトピックを扱います。

DocumentManager EJB デプロイメント記述子をコンフィグレーションする

DocumentManager EJB デプロイメント記述子は、コンテンツ管理コンポーネントのコンフィグレーションの EJB 部分を扱うもので、正しい環境設定を認識するようにコンフィグレーションする必要があります。 DocumentManager EJB をコンフィグレーションするには、そのデプロイメント記述子に必ず、以下の環境設定が記載されていなければなりません。

PropertySetManager EJB デプロイメント記述子をコンテンツ管理用にコンフィグレーションする

コンテンツ プロパティ セットがシステムにエクスポーズされるように、DocumentManager を PropertySetManager EJB デプロイメント記述子に統合する必要があります。 PropertySetManager EJB デプロイメント記述子をコンテンツ管理用にコンフィグレーションするには、以下の環境設定を追加します。

あるいは、DocumentManager MBean の JNDIName 属性を DocumentManager の JNDI ホーム名に設定することもできます。 その値では ${APPNAME} 構文要素を使用することができ、それは現在の J2EE アプリケーション名に置き換えられます。 com.bea.p13n.content.PropertySetRepositoryImpl では、それらの DocumentManager を自動的に見つけるので、J2EE EJB 参照は必要ありません。

DocumentManager MBean をコンフィグレーションする

DocumentManager 実装では、DocumentManager MBean を用いて、そのコンフィグレーションの保守を行います。 デプロイされた DocumentManager は、どの DocumentManager MBean を使用すべきかを DocumentManagerMBeanName EJB のデプロイメント記述子設定から知ることができます。 それらの値が DocumentManagerMBeanName EJB デプロイメント記述子内の Name 属性に一致するように、アプリケーション内の DocumentManager MBean をコンフィグレーションする必要があります。

DocumentManager MBean をコンフィグレーションするには、アプリケーションの META-INF/application-config.xml ファイルを修正して、 以下の XML(リスト 8-1 に示す) に追加または変更することができます。

コード リスト 8-1 アプリケーションの META-INF/application-config.xml ファイル内の <DocumentManager> 要素の修正

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

application-config.xml ファイル内で直接これらの属性を変更しようとしてはいけません。 その代わり、WebLogic Server Administration Console を用いて DocumentManager MBean を修正する で説明しているように、WebLogic Server Administration Console を使用します。

WebLogic Server Administration Console を用いて DocumentManager MBean を修正する

WebLogic Server Administration Console を用いて DocumentManager MBeans を修正するには、以下の手順に従います。

  1. WebLogic Server を起動し、Web ブラウザを開きます。

  2. [アドレス] フィールドに以下の URL を入力して、WebLogic Server Administration Console を開きます。
    http://<hostname>:<port>/console

    たとえば、サーバ上でコンソールを起動する場合、デフォルト URL は以下のとおりです。

    http://localhost:7501/console

  3. Enter〕を押します。

    WebLogic Server のサインイン画面が表示されます。

  4. ユーザ名とパスワードを入力し、[サインイン] をクリックすることで、サインインします。 デフォルトのユーザ名/パスワードは、 system/weblogic です。

  5. 図 8-3 に示すような WebLogic Server Administration Console が表示されます。

    図8-3 WebLogic Server Administration Console


     

  6. 左ペインで以下のノードを順に選択して、アプリケーションの DocumentManager MBean まで階層を下ります。

    MyDomainデプロイメントアプリケーションMyApplicationService ConfigurationDocument ManagerMyMBean

    ここで、

    portalApp というアプリケーションの Document Manager のデフォルト MBean (default)まで階層を下る際に選択するノードの例を図 8-4 に示します。

    図8-4 MBean までのナビゲーション


     

    MBean ノードを選択すると、その MBean の [Document Manager サービス] 画面(図 8-5 に示す)が右ペインに表示されます。 MBean 名がタブに表示されていることに注意してください。

    図8-5 [Document Manager サービス] 画面


     

  7. 属性を必要に応じて変更し、[適用] をクリックします。 これらの属性を 表8-2 に示します。

    表8-2 DocumentManager MBean の属性

    属性

    画面上の表示名/コントロール タイプ

    解説

    DocumentConnectionPoolName

    [ドキュメント接続プール名]

    テキスト ボックス

    DocumentManager で使用する DocumentConnectionPool MBean の名前を指定する。

    PropertyCase

    [プロパティの大文字/小文字の区別]

    ドロップダウン リスト

    入力されるプロパティ名が DocumentManager によってどう変更されるかを指定する。

    lowerupper のどちらにするかは、使用するドキュメント接続プール実装によって決まる。 ドキュメント参照実装の場合には、PropertyCase を指定してはいけない。

    MetadataCaching

    [メタデータ キャッシングが有効か]

    チェックボックス

    検索の結果得られる Document メタデータを DocumentManager でキャッシュするか否かを指定する。 true の場合、DocumentManager では、MetadataCacheName で指定される com.bea.p13n.cache.Cache に検索結果がキャッシュされる。キャッシュしない場合には、false を指定する。 デフォルトは true

    MetadataCacheName

    [メタデータ キャッシュ名]

    テキスト ボックス

    MetadataCachingtrue に設定されている場合に使用する com.bea.p13n.cache.Cache の名前を指定する。 デフォルトは documentMetadataCache

    UserIdInCacheKey

    [ユーザ ID がキャッシュ キーに含まれているか]

    チェックボックス

    ドキュメントのメタデータまたはコンテンツをキャッシュする際にユーザの識別子をキーの一部として使用するか否かを指定する。 デフォルトは true。 WebLogic Portal の参照実装ドキュメント管理システムを使用する場合には、false に設定する。

    ContentCaching

    [コンテンツ キャッシングが有効か]

    チェックボックス

    DocumentManager でドキュメント コンテンツ(すなわち、ドキュメントのバイト データ)をキャッシュするか否かを指定する。 DocumentManager にドキュメント コンテンツのバイトデータをキャッシュさせる場合には true に設定し、そうでなければ false に設定する。 デフォルトは true

    ContentCacheName

    [コンテンツ キャッシュ名]

    テキスト ボックス

    ContentCachingtrue に設定されている場合に使用する com.bea.p13n.cache.Cache の名前を指定する。 デフォルトは documentContentCache

    MaxCachedContent
    Size

    [キャッシュされるコンテンツの最大サイズ]

    テキスト ボックス

    ContentCaching が true の場合に DocumentManager でキャッシュされるドキュメント コンテンツの最大バイト数を指定する。 デフォルトは 32768 (32K) バイト。

    JNDIName

    該当せず

    この MBean に接続される DocumentManager EJB の JNDI ホーム名を指定する。 その値では ${APPNAME} 構文要素を使用することができ、それは現在の J2EE アプリケーション名に置き換えられる。 これは、com.bea.p13n.content.PropertySet RepositoryImpl において、ドキュメント プロパティ セット情報を PropertySetManager に結び付けるために使用される。


     

MBean を無効にする

WebLogic Server Administration Console から MBean を有効または無効にすることができます。 それには、以下の手順に従います。

注意: この手順では、WebLogic Server に接続済みで Administartion Console が開かれていることを前提としています。そのための手順は、WebLogic Server Administration Console を用いて DocumentManager MBean を修正するの節で説明したとおりです。

  1. 左ペインで [Add or remove service configurations] ノードを選択します。このノードは、図 8-6 に示すように、[Service Configuration] ノードの下にあります。

    図8-6 [ Add or remove service configurations] ノードの選択


     

    図 8-7 に示すような [ Service Configuration ] 画面が右ペインに表示されます。

    図8-7 [ Service Configuration ] 画面


     

  2. 削除したい MBean をリストから見つけ、図 8-8 に示すように、該当するチェックボックスをチェックして選択を解除します。

    図8-8 MBean の選択解除を行った [ Service Configuration ] 画面


     

  3. 無効にしたい MBean をそれぞれ選択解除します。 作業が完了したら、[Submit] をクリックします。

    「これらの変更を反映させるには、アプリケーション [APP_NAME] を再デプロイする必要があります。 」というメッセージが表示されます。

  4. アプリケーションを再デプロイするか、サーバを再起動します。

無効にした MBean を再度有効にする

上記の手順で無効にした MBean を再度有効にするには、該当するチェックボックスをクリックして選択します。 必要な MBean をすべて元どおり選択したら、やはり、[Submit] をクリックします。

ドキュメント接続プールをセットアップする

DocumentManager 実装では、専用の JDBC ドライバへの接続プールを使用して、コンテンツに関する検索を処理します。 デプロイ済みの DocumentManager では、使用するドキュメント接続プールを、自分の DocumentManager MBean の DocumentConnectionPoolName 属性か DocumentConnectionPoolName EJB デプロイメント記述子設定のいずれかを用いて見つけます。 その値は、DocumentConnectionPool MBean に一致する必要があります。

DocumentConnectionPool MBean をコンフィグレーションするには、以下の XML(リスト 8-2 に示す)に追加または変更することで、アプリケーションの META-INF/application-config.xml ファイルを修正します。

コード リスト 8-2 アプリケーションの META-INF/application-config.xml ファイルの修正による 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"
/>

WebLogic Console で DocumentConnectionPool MBean を編集する

DocumentManager MBean の場合と同様に、DocumentConnectionPool MBean の修正には、WebLogic Server Administration Console を用いる必要があります。 その方法については、WebLogic Server Administration Console を用いて DocumentManager MBean を修正するの節で示した手順を参照してください。 なお、DocumentConnectionPool MBean の場合には、[Document Connection Pool Service] ノードを選択し、[Document Connection Pool サービス] 画面(図 8-9 に示す)で変更を行う必要があることに注意してください。

図8-9 [ Document Connection Pool サービス ] 画面


 

DocumentConnectionPool MBean の変更可能な属性を 表8-3 に示します。

表8-3 DocumentConnectionPool MBean の属性

属性

画面上のラベル/
コントロール タイプ

解説

DriverName

[ドライバ名]

テキスト ボックス

使用する JDBC ドライバ クラス名を指定する。 これは、com.bea.p13n.content.document.jdbc.Driver に設定しなければならない。

URL

[ JDBC URL]

テキスト ボックス

使用する JDBC URL を指定する。

jdbc:beasys:docmgmt:com.bea.p13n.content.document.ref.RefDocumentProvider

jdbc:beasys:docmgmt:<classname>

ここで、<classname>com.bea.p13n.content.
document.spi.DocumentProvider の実装の完全修飾クラス名。

Properties

[JDBC プロパティ]

テキスト ボックス

プロパティの「名前=値」 ペアをセミコロンで区切って並べたリストで、URL に指定された DocumentProvider にこれが渡される。参照実装で認識されるプロパティの一覧については、表8-4 を参照のこと。

InitialCapacity

[プールの初期容量]

テキスト ボックス

ドキュメント接続プールの起動時に作成される接続の初期数を指定する。

MaxCapcity

[プールの最大容量]

テキスト ボックス

このプールで作成および維持管理される接続の最大数を指定する。

CapacityIncrement

[容量増分]

テキスト ボックス

利用可能な接続を作成することが必要になるたびにプールで作成される接続の数を指定する。

LoginTimeout

該当せず

接続を待つ時間(この時間が過ぎたら、例外が送出される)を指定する。 プールにタイムアウトさせない場合には、0 以下を使用する(これがデフォルト)。

ClassPath

該当せず

接続プールで Driver クラスと DocumentProvider クラスのロード時に使用すべき追加のディレクトリや JAR をセミコロンで区切って並べたリスト。 指定されるパスはすべて、アプリケーション ディレクトリからの相対パスとみなされる。


 

DocumentConnectionPool MBean に設定できる有効な参照実装プロパティを表8-4 に示します。

表8-4 参照実装プロパティ

プロパティ

解説

jdbc.dataSource

データベース接続の取得に使用する javax.sql.DataSource の JNDI 名を指定する。 このデータソースは、 DOCUMENT テーブルと DOCUMENT_METADATA テーブルの入ったデータベースに接続しなければならない。

jdbc.url

接続先の JDBC URL を指定する。 jdbc.dataSource が指定されている場合には、これは無視される。

jdbc.driver

ロードすべき JDBC ドライバ クラスを指定する。 jdbc.dataSource が指定されている場合には、これは無視される。

jdbc.isPooled

true の場合、jdbc.urljdbc:weblogic:pool または jdbc:weblogic:jts で始まる場合、あるいは、jdbc.dataSource が指定されている場合には、 接続はプールされておりキャッシュされないと仮定される。 それ以外の場合には、接続はプールされておらず 1 つの接続のみを維持すると仮定される。

jdbc.supportsLikeEscape   Clause

基礎となるデータベースで SQL の LIKE ESCAPE 句がサポートされているか否かを指定する。 これが指定されない場合には、接続はクエリされる。

jdbc.docBase

ドキュメントがどのベース ディレクトリ下に格納されているかを指定する。 データベースに格納されているパスはすべて、ここに指定したディレクトリからの相対パスとみなされる。

jdbc.schemaXML

プロパティ セット情報が記述された XML ファイル(ドキュメント スキーマ DTD に準拠)の格納先ディレクトリのパスを指定する。 システムはこのディレクトリ内を再帰的に調べて、.xml で終わるファイルをすべてロードする。

jdbc.isolationLevel

データベース接続に設定するトランザクション アイソレーション レベルをコンフィグレーションする。 指定可能な値は以下のいずれか。

READ_COMMITTED

READ_UNCOMMITTED

SERIALIZABLE

REPEATABLE_READ

NONE

未指定の場合には、デフォルトで SERIALIZABLE とみなされる。

詳細については、『Javadoc API マニュアル』内の java.sql.Connection を参照のこと。

jdbc.column.<colName>

DOCUMENT テーブルの追加カラムを指定する。 値は、そのカラムにマップされるプロパティ名をカンマで区切って並べたリスト。 これは何度でも指定可能。 BulkLoader の -columnMap 引数と -column 引数の両方あるいはいずれか一方と一緒に使用しなければならない。 同じプロパティが複数のカラムにマップされる場合には、結果がどうなるかはわからない。


 

図 8-9 に示すように、WebLogic Server Administration Console を使用すれば、DocumentConnectionPool MBean を編集して、属性値やプロパティ値を必要に応じて変更することができます。

Web アプリケーションをコンフィグレーションする

コンテンツ管理サービスへのアクセスに必要な J2EE リソース(EJB、サーブレット、JSP タグ ライブラリなど)に Web アプリケーションからアクセスできるようにコンフィグレーションする必要があります。 つまり、ejb/ContentManagerejb/DocumentManager への EJB 参照をコンフィグレーションする必要があります。 さらに、com.bea.p13n.content.servlets.ShowDocServlet を Web アプリケーションにマップしておくことが必要です。 BEA では、リスト 8-3 に示すように、Web アプリケーションの /ShowDoc/* URL にマップすることをお勧めします。

コード リスト 8-3 ShowDocServlet のマッピング

<servlet>
<servlet-name>ShowDocServlet</servlet-name>
<servlet-class> com.bea.p13n.content.servlets.ShowDocServlet
</servlet-class>
  <!-- showdoc が常にローカルの 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>

これによって、Web アプリケーションのコンテキスト ルート(たとえば /wlcs/ShowDoc)下の ShowDoc/ URI を ShowDocServlet に送ることができるようになります。 初期化パラメータ contentHome<init-param> タグ内) が上記のように設定されているので、その ShowDocServlet は常にejb/DocumentManager EJB 参照を使用するようになります。この設定を削除すれば、ShowDocServlet は任意の contentHome リクエスト パラメータに従って動作できるようになります。

コンテンツ管理タグ ライブラリを利用するには、以下を実行する必要があります。

 


コンテンツ セレクタ タグおよび関連する JSP タグの使い方

コンテンツ セレクタは、コンテンツ管理システムからドキュメントを取得するためのメカニズムとして WebLogic Portal に用意されているものの 1 つです。 コンテンツ セレクタ JSP タグなどの一連の JSP タグを使用すれば、コンテンツ セレクタで絞り込まれたコンテンツを取得し表示することができます。

この節では、コンテンツ セレクタ タグとそれらに関連する JSP タグを用いてコンテンツを管理する方法を説明します。 以下のトピックスを扱います。

WebLogic Portal のコンテンツ関連 JSP タグを WebLogic Portal のコンテンツ管理サービス プロバイダ インタフェース (SPI) へマップする方法については、 http://edocs.beasys.co.jp/e-docs/wlp/docs70/jsp/p13njsp.htm にある『JavaServer Pages ガイド』の「パーソナライゼーション JSP タグ」を参照してください。

<pz:contentSelector> タグの使い方

<pz:contentSelector> セレクタ タグを用いて行えることは、以下のとおりです。

コンテンツ セレクタの定義を識別する

E-Business Control Center で作成されるコンテンツ セレクタ定義では、コンテンツ セレクタがアクティブになる条件と、アクティブなコンテンツ セレクタで実行されるクエリを決定します。

この定義を参照するには、次のように rule 属性を使用します。

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

スクリプトレットを使用すれば、付加的な基準に基づいて rule 属性の値を決定することができます。 たとえば、あるヘッダー JSP (heading.inc) でコンテンツ セレクタを使用し、その JSP を他の JSP にインクルードするとしましょう。 このとき、heading.inc をインクルードするページごとに、異なるコンテンツ セレクタを作成することができます。

heading.inc でスクリプトレットを使用して、インクルードされた JSP ファイルが現在表示されているページに応じた属性値を設定します。リスト 8-4 に、その例を示します。

コード リスト 8-4 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>

コンテンツ管理システムの JNDI ホームを識別する

コンテンツ セレクタ タグでは、contentHome 属性を用いてコンテンツ管理システムの JNDI ホームを指定する必要があります。 参考版のコンテンツ管理システムを使用する場合や、サード パーティ製のコンテンツ管理システムと統合する場合には、スクリプトレットを用いてデフォルトのコンテンツ ホームを参照することができます。 スクリプトレットでは ContentHelper クラスを使用するので、まず、以下のタグを用いてそのクラスを JSP にインポートする必要があります。

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

そのあと、コンテンツ セレクタ タグを使用する際には、リスト 8-5 に示すように contentHome を指定します。

コード リスト 8-5 コンテンツ セレクタ タグでの contentHome の指定

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

独自のコンテンツ管理システムを構築する場合には、ContentHelper スクリプトレットを使用するのではなく、システムの JNDI ホームを指定する必要があります。 さらに、その独自コンテンツ管理システムが JNDI ホームを提供する場合には、ContentHelper スクリプトレットを使用するのではなく、その JNDI ホームを指定することができます。

クエリ結果を格納する配列を定義する

表8-5 に示した属性を用いて、コンテンツ セレクタでのクエリの結果を格納する配列をコンフィグレーションすることができます。

表8-5 クエリ結果を格納する配列を定義する属性

属性

解説

id

配列の名前を指定する。 この属性は必須。

たとえば、<pz:contentSelector id="docs" .../> と指定すると、docs という名前の配列にドキュメントが格納される。

max

コンテンツ セレクタ用の配列に格納されるドキュメントの数の上限を指定する。

たとえば、<pz:contentSelector max="10" .../> と指定すると、配列にドキュメントが 10 個格納された時点で、コンテンツ セレクタはドキュメントの取得を止める。

この属性は省略可能で、デフォルト値は -1(上限なし)。

sortBy

配列内のドキュメントのソートに用いるドキュメント属性を任意の数だけ指定する。 sortBy 属性の指定には、SQL の order by 句の構文を用いる。

この属性は省略可能。 この属性を指定しない場合、コンテンツ セレクタは、コンテンツ管理システムから返された順にクエリ結果を返す。

たとえば、<pz:contentSelector sortBy="creationDate" .../> と指定すると、ドキュメントは作成日の早い順に配列に格納される。

また、<pz:contentSelector sortBy="creationDate ASC, title DESC" .../> というタグでは、ドキュメントは作成日の早い順に配列に格納され、同じ日に作成されたドキュメントが複数あれば、それらはタイトルの逆アルファベット順にソートされる。


 

キャッシュを作成およびコンフィグレーションしてパフォーマンスを向上させる

取得されたコンテンツによりアクセスしやすくなるように、また、パフォーマンスを向上させるために、コンテンツ セレクタ属性を用いて、配列の内容を格納するキャッシュを作成しコンフィグレーションすることができます。 キャッシュを使用しなければ、コンテンツ セレクタ用の配列にアクセスできるのは、そのセレクタ タグを含む JSP ページ内だけであり、しかも、その配列を作成した顧客リクエストに限られます。 さらに、コンテンツ セレクタ タグを含む JSP を顧客が要求するたびに、コンテンツ セレクタでクエリを実行しなければならず、そのため WebLogic Portal 全体のパフォーマンスが低下するおそれがあります。

配列の内容をキャッシュするには、表8-6 に挙げた属性を使用します。

表8-6 配列の内容をキャッシュするための属性

属性

解説

useCache

コンテンツ セレクタ用の配列をキャッシュに格納するかどうかを指定する。 キャッシュを有効にするには、この属性を true に設定する。 たとえば、<pz:contentSelector cache="true" ...> と指定する。

キャッシュを無効にするには、この属性を false に設定するか、この属性をタグに付けない。 たとえば、以下の指定は機能的に等価。

<pz:contentSelector cache="false" .../>

<pz:contentSelector ...>

cacheId

キャッシュの名前を指定する。 この属性を指定しない場合、キャッシュ名には配列の名前(id 属性で指定する必要がある)が使用される。 配列を作成した JSP またはユーザ セッション以外からキャッシュにアクセスする場合には、cacheId を指定する必要がある。

cacheTimeout

WebLogic Portal でキャッシュが保持される時間をミリ秒単位で指定する。 コンテンツ セレクタは、指定された時間が経過するまでクエリを再実行しない。

たとえば、次のようにタグを記述するとしよう。

<pz:contentSelector cache="true" cacheTimeout="300000" .../>

顧客がこのコンテンツ セレクタ タグを含むページを要求する。 顧客はいったん別のページに移動し、2 分(120000 ミリ秒)後に再びこのページを要求する。 このとき、コンテンツ セレクタでキャッシュのタイムアウト条件が評価されるが、コンテンツ セレクタがキャッシュを作成してから 120000 ミリ秒しか経過していないため、クエリは再実行されない。 その代わり、キャッシュ内のドキュメントが表示される。

cacheScope

キャッシュへのアクセスを許可する範囲を指定する。 この属性に指定できる値は以下のとおり。


 

コンテンツ セレクタを補助する関連タグ

コンテンツ セレクタを補助する JSP タグを表8-7 に示します。

表8-7 コンテンツ セレクタの機能を補助する JSP タグ

タグ

解説

<um:getProfile>

現在ページを閲覧している顧客のプロファイルを取得する。 コンテンツ セレクタでは、その顧客プロファイルを用いて、顧客プロパティに絡む条件を評価する。

たとえば、「Gold Customer」という顧客セグメントに属するあらゆる顧客用のクエリを実行するコンテンツ セレクタを作成する場合、そのコンテンツ セレクタでは、顧客プロファイルにアクセスして、プロファイルがこの顧客セグメントに合致するかどうかを判定する必要がある。

コンテンツ セレクタでの条件評価に顧客プロファイルを現在使用していない場合でも、JSP に <um:getProfile> タグを組み込んでおくことを推奨する。このタグがパフォーマンスに及ぼす影響はごくわずかであり、またこのタグがあれば、開発者に JSP の修正を依頼しなくても、顧客プロファイルに関わる条件をコンテンツ セレクタに追加できる。

このタグは、コンテンツ セレクタ タグの近くではなく、JSP の冒頭付近に記載する必要がある。

<es:forEachInArray>

コンテンツ セレクタでのクエリの結果を格納する配列内のデータを順に処理する。 このタグを用いれば、配列内の各ドキュメントに対して以下の処理を実行できる。


 

コンテンツ セレクタ タグと関連タグの使い方

コンテンツ セレクタの定義、タグ属性、および関連する JSP タグを組み合わせれば、特定のコンテキストで顧客に合うドキュメントを用意するための強力なツール セットになります。 ここでは、以下の作業例を通じて、コンテンツ セレクタとその関連タグの最も一般的な使い方を示します。

WebLogic Portal のコンテンツ関連 JSP タグを WebLogic Portal のコンテンツ管理サービス プロバイダ インタフェース (SPI) へマップする方法については、 http://edocs.beasys.co.jp/e-docs/wlp/docs70/jsp/p13njsp.htm にある『JavaServer Pages ガイド』の「パーソナライゼーション JSP タグ」を参照してください。

テキスト タイプのドキュメントを取得し表示する

テキスト タイプのドキュメントを取得し表示するには、以下の手順に従います。

注意: この手順では、E-Business Control Center で作成されたコンテンツ セレクタ クエリに、テキスト ドキュメントだけを取得するフィルタが組み込まれているものとします。

  1. JSP をテキスト エディタで開きます。

  2. 必要なクラスおよびタグ ライブラリがまだ JSP に組み込まれていない場合には、リスト 8-6 に示す数行を JSP の冒頭付近に追加して、それらをインポートします。

コード リスト 8-6 クラスおよびタグ ライブラリをインポートするためのコード

<%@ page import="com.bea.p13n.content.ContentHelper"%>
<%@ taglib uri="es.tld" prefix="es" %>
<%@ taglib uri="pz.tld" prefix="pz" %>
<%@ taglib uri="um.tld" prefix="um" %>

  • 以下のタグがまだ JSP に含まれていない場合には、このタグを追加して顧客プロファイルを取得します。

    <um:getProfile>

    JSP で他の目的のために既にこのタグが使われている場合には、このタグにはおそらく何らかの属性が付いているでしょう。 このタグは、<pz:contentSelector> タグ(次のステップで使用する)の近くではなく、必ず JSP の冒頭付近に記載してください。

  • リスト 8-7 に示す一連のタグを追加します。ここで、SpringSailing は、E-Business Control Center で作成されたコンテンツ セレクタの名前です。
  • コード リスト 8-7 コンテンツ セレクタ タグの例(その 1)

    <pz:contentSelector rule="SpringSailing"
    contentHome="<%=ContentHelper.DEF_DOCUMENT_MANAGER_HOME %>"
    id="textDocs"/>
    <es:forEachInArray array="<%=textDocs%>" id="aTextDoc" type="com.bea.p13n.content.Content">
    <p><cm:printDoc id="aTextDoc"/></p>

    </es:forEachInArray>

    注意: コンテンツ タイプが正しいかどうかを表示前に確認するには、<% "<P>" + aTextDoc + "</P>" %> というスクリプトレットを別のスクリプトレットで囲むことができます。リスト 8-8 に、その例を示します。

    コード リスト 8-8 コンテンツ タイプの確認

    <% if (aTextDoc.getMimeType().contains("text") != -1)
    {
    %>
    <p><cm:printDoc id="aTextDoc"/></p>
    <%
    }
    %>

  • JSP を保存します。 Web アプリケーションを WAR ファイルとしてデプロイする場合には、Web アプリケーションを JAR アーカイブ化し直してから、デプロイします。

    WebLogic Portal によって、変更内容がデプロイされます。 Web アプリケーションのページ チェック率を指定してある場合には、WebLogic Portal はそのページ チェック間隔が経過するのを待ってから、変更内容をデプロイします。

  • 画像タイプのドキュメントを取得し表示する

    画像タイプのドキュメントを取得し表示するには、以下の手順に従います。

    1. JSP をテキスト エディタで開きます。

    2. 必要なクラスおよびタグ ライブラリがまだ JSP に組み込まれていない場合には、リスト 8-9 に示す数行を JSP の冒頭付近に追加して、それらをインポートします。

    コード リスト 8-9 クラスおよびタグ ライブラリがまだ JSP に組み込まれていない場合にそれらをインポートするためのコード

    <%@ page import="com.bea.p13n.content.ContentHelper"%>
    <%@ taglib uri="pz.tld" prefix="pz" %>
    <%@ taglib uri="um.tld" prefix="um" %>
    <%@ taglib uri="cm.tld" prefix="cm" %>

  • 以下のタグがまだ JSP に含まれていない場合には、このタグを追加して顧客プロファイルを取得します。

    <um:getProfile>

    JSP で他の目的のために既にこのタグが使われている場合には、このタグにはおそらく何らかの属性が付いているでしょう。 このタグは、<pz:contentSelector> タグ(次のステップで作成する)の近くではなく、必ず JSP の冒頭付近に記載してください。

  • リスト 8-10 に示す一連のタグを追加します。ここで、SpringSailing は、E-Business Control Center で作成されたコンテンツ セレクタの名前です。
  • コード リスト 8-10 コンテンツ セレクタ タグの例(その 2)

    <pz:contentSelector rule="SpringSailing"
    contentHome="<%=ContentHelper.DEF_DOCUMENT_MANAGER_HOME %>"
    id="ImageDocs"/>

    <es:forEachInArray array="<%=ImageDocs%>" id="anImageDoc" type="com.bea.p13n.content.Content">

    <img src="ShowDoc/<cm:printProperty

    id="anImageDoc" name="identifier" encode="url"/>"

    </es:forEachInArray>

    注意: 上記のタグでは、E-Business Control Center で作成されたコンテンツ セレクタ クエリに、画像ドキュメントだけを取得するフィルタが組み込まれていることを前提としています。 コンテンツ タイプが正しいかどうかを表示前に確認するには、<img> タグをスクリプトレットで囲むことができます。リスト 8-11 に、その例を示します。

    コード リスト 8-11 スクリプトレットで囲まれた <img> タグ

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

    1. JSP を保存します。 Web アプリケーションを .war ファイルとしてデプロイする場合には、Web アプリケーションを JAR アーカイブ化し直してから、デプロイします。

      WebLogic Portal によって、変更内容がデプロイされます。 Web アプリケーションのページ チェック率を指定してある場合には、WebLogic Portal はそのページ チェック間隔が経過するのを待ってから、変更内容をデプロイします。

    ドキュメントのリストを取得し表示する

    ドキュメントのリストを取得し表示するには、以下の手順に従います。

    1. JSP をテキスト エディタで開きます。

    2. 必要なクラスおよびタグ ライブラリがまだ JSP に組み込まれていない場合には、リスト 8-12 に示す数行を JSP の冒頭付近に追加して、それらをインポートします。

    コード リスト 8-12 クラスおよびタグ ライブラリがまだ JSP に組み込まれていない場合にそれらをインポートするためのコード

    <%@ page import="com.bea.p13n.content.ContentHelper"%> <%@ taglib uri="es.tld" prefix="es" %>
    <%@ taglib uri="pz.tld" prefix="pz" %>
    <%@ taglib uri="um.tld" prefix="um" %>

  • 以下のタグがまだ JSP に含まれていない場合には、このタグを追加して顧客プロファイルを取得します。

    <um:getProfile>

    JSP で他の目的のために既にこのタグが使われている場合には、このタグにはおそらく何らかの属性が付いているでしょう。 このタグは、<pz:contentSelector> タグ(次のステップで作成する)の近くではなく、必ず JSP の冒頭付近に記載してください。

  • リスト 8-13 に示す一連のタグを追加します。ここで、SpringSailing は、E-Business Control Center で作成されたコンテンツ セレクタの名前です。
  • コード リスト 8-13 コンテンツ セレクタ タグの例(その 3)

    <pz:contentSelector rule="SpringSailing"
    contentHome="<%=ContentHelper.DEF_DOCUMENT_MANAGER_HOME %>"
    id="docs"/>
    <ul>
    <es:forEachInArray array="<%=docs%>" id="aDoc"
    type="com.bea.p13n.content.Content">

    <li>The document title is: <cm:printProperty id="aDoc"
    name="Title" encode="html" />
    </es:forEachInArray>
    </ul>

  • JSP を保存します。 Web アプリケーションを .war ファイルとしてデプロイする場合には、Web アプリケーションを JAR アーカイブ化し直してから、デプロイします。

    WebLogic Portal によって、変更内容がデプロイされます。 Web アプリケーションのページ チェック率を指定してある場合には、WebLogic Portal はそのページ チェック間隔が経過するのを待ってから、変更内容をデプロイします。

  • 別の JSP 上のコンテンツ セレクタ キャッシュにアクセスする

    別の JSP 上のコンテンツ セレクタ キャッシュにアクセスするには、以下の手順に従います。

    1. テキスト エディタで、コンテンツ セレクタ タグが含まれている JSP ページを開きます。 たとえば、以下のタグの実行結果をキャッシュするとします。
      <pz:contentSelector rule="SpringSailing" id="docs".../>

    2. リスト 8-14 に示すように、コンテンツ セレクタ タグに属性を追加します。

    コード リスト 8-14 コンテンツ セレクタ タグの属性

    <pz:contentSelector rule="SpringSailing"
    contentHome="<%=ContentHelper.DEF_DOCUMENT_MANAGER_HOME %>"
    id="docs"

    useCache="true" cacheId="SpringSailingDocs" cacheTimeout="120000"
    cacheScope="application" />

    これらの属性を指定することで作成されるキャッシュは、WebLogic Portal によって 2 分間(120000 ミリ秒間)保持され、Web アプリケーションの任意のページから任意のユーザによって SpringSailingDocs という名前でアクセスすることができます。 cacheScope属性の取り得る値の詳細については、キャッシュを作成およびコンフィグレーションしてパフォーマンスを向上させる を参照してください。

  • JSP を保存し、デプロイします。

  • 作成したキャッシュにアクセスする JSP をテキスト エディタで開きます。

  • キャッシュへのアクセスには、ステップ 2 で作成したのと同一のコンテンツ セ レクタ タグを使用します。 たとえば、現在開いている JSP に、リスト 8-15 に示すタグを追加 します。
  • コード リスト 8-15 同一タグの追加

    <pz:contentSelector rule="SpringSailing" 
    contentHome="<%=ContentHelper.DEF_DOCUMENT_MANAGER_HOME %>"
    id="docs"

    useCache="true" cacheId="SpringSailingDocs" cacheTimeout="120000"
    cacheScope="application" />

    1. JSP を保存し、デプロイします。

     


    外部コンテンツ管理システムとの統合

    大量のコンテンツがあり、コンテンツの発行とタグ付けに対するもっと強力な管理機能を必要とする顧客向けに、BEA では、サードパーティ ベンダと提携して WebLogic Portal の柔軟性を高めます。 サードパーティ製のコンテンツ管理システムは堅牢なコンテンツ作成管理ソリューションを提供するのに対して、コンテンツ マネージャはコンテンツをパーソナライズしてエンド ユーザに配信します。

    統合戦略

    BEA では、サードパーティ製のコンテンツ管理システム (CMS) を WebLogic Portal に統合するための戦略として、以下の 3 つをお勧めします。

    DocumentProvider インタフェースを実装することでコンテンツを追加する

    DocumentProvider オブジェクトは、SPI 実装へのエントリ ポイントとなるものです。 これは、基礎となるコンテンツ管理システムにアクセスするメソッドから成ります。 DocumentProvider を開発する際には、トランザクション状態やスレッド セーフティ(スレッド保証)を気にかける必要はありません。 DocumentProvider では書き込みアクションを実行する必要がないので、トランザクションの中で DocumentProvider にアクセスする必要はありません。

    DocumentProvider インタフェースを実装するには、com.beasys.p13n.content.document.spi パッケージに含まれている Java インタフェースの実装を作成することが必要になります。 これらのインタフェースは下記のとおりです。

    以下の各節では、CMS を WebLogic Portal に統合するためのこれらのインタフェースの実装方法について説明します。

    これらのインタフェースの詳細については、『Javadoc』を参照して com.beasys.p13n.content.document.spi を調べてください。

    以下の手順では、DocumentProvider インタフェースの実装方法を大まかに示します。

    ステップ 1: CMS が使用上の最低要件を満たしていることを確認する

    コンテンツ管理システム (CMS) を WebLogic Portal にうまく統合するには、表8-8 に挙げた機能を CMS がサポートしている必要があります。

    表8-8 CMS の使用上の最低要件

    要件

    解説

    ユニークなドキュメント ID

    ドキュメントをシステム内の他のすべてのドキュメントから一意に識別する単一のキーが存在しなければならず、そのキーは String として表現できなければならない。 たとえば、コンテンツ管理システムの中には、ドキュメントにオブジェクト ID を割り当てるものもあれば、相対パスを用いるものもある(参照実装はこちらのほう)。

    ドキュメント メタデータ

    ドキュメントに関するメタデータをすべて取得する手段が存在しなければならない。 メタデータは、WebLogic Portal の標準データ型(Boolean、Integer、Float、DateTime、String、多値) で構成されているか、あるいはそれらのタイプに変換できなければならない。 このメタデータには、少なくともドキュメントのサイズ(バイト単位)と MIME タイプ(MIME 1.0 に準拠)が含まれていなければならない。

    ドキュメント コンテンツの取得

    ドキュメントの未処理のバイト データを取得する何らかの手段が存在しなければならない。

    検索

    CMS には、ドキュメント メタデータに対するクエリに基づいてドキュメントを検索する何らかのメカニズムが用意されていなければならない(WebLogic Portal では全文検索は必須ではない)。

    スキーマ

    CMS には、ドキュメント メタデータ スキーマをエクスポーズするメカニズムが用意されていなければならない。 スキーマには、メタデータ属性およびそれらのデータ型とドキュメント タイプとの関連付けが記述されている。 ルール エディタはこのスキーマ情報を用いて、パーソナライゼーションを実現するコンテンツ セレクタ ルールの作成を可能にする(通常のドキュメント検索方法ではスキーマ情報は使用されないため、パーソナライズされていないドキュメントの取得はスキーマがなくても可能)。

    Java からのアクセス

    CMS では、Java コードからドキュメントにアクセスするのに利用できる何らかのメカニズムがサポートされていなければならない。 これに該当すると思われるものには、Java クラス ライブラリ、JNI からアクセスできるネイティブ共有ライブラリ、ソケット ベースのアクセス(HTTP、DCOM、クライアント/サーバなど)、DBMS レベルのアクセス、ファイル ベースのアクセス、eLink 対応のアクセスなどがある(ただし、これらに限定されない)。 なお、WebLogic Portal に用意されている参照実装内にパブリッシュする場合には、Java からのアクセスは必須ではない。


     

    これらの要件のいずれかが何らかの形で満たされない場合には、CMS を WebLogic Portal に完全に統合することはできません。 そのうえ、WebLogic Portal にはドキュメント作成/編集機能がないので、CMS には、ユーザがドキュメントを作成および編集するための何らかの手段が用意されていなければなりません。

    ステップ 2: SPI 実装を作成する

    次に、表8-9 に示したインタフェースと、DefaultDocumentProviderに挙げたその他のデフォルト クラスおよびヘルパー クラスを実装することで、SPI をコーディングする必要があります。 これらのインタフェースでは、BEA オブジェクトを CMS 側で認識可能なオブジェクトに変換するので、Web アプリケーションと CMS の間の双方向通信が可能になります。

    表8-9 DocumentProvider のインタフェース

    インタフェース

    解説

    DocumentIterator

    DocumentIterator インタフェースは、close() メソッドを追加して java.util.Iterator インタフェースを拡張したもの。 この close() メソッドは、DocumentIterator がもう使用されなくなったときに呼び出され、DocumentIterator に結び付けられているリソースをすべてクリアする。 このインタフェースによって呼び出されるメソッドは null を返してはいけない。 それらのメソッドは、例外が必要な場合には DocumentException を送出しなければならない。 結果セットが空の場合には、空の DocumentIterator を返さなければならない。

    DocumentMetadataDef

    DocumentMetadataDef インタフェースは、ドキュメントのメタデータ属性を表す。 このインタフェースには、明示的メタデータを取得するメソッドと暗黙的(CMS 定義)メタデータを取得するメソッドが両方とも含まれている。 getProperty(String name) メソッドは暗黙的メタデータを取得するためのもので、明示的属性名(identifier、size、version、author、creationDate、lockedBy、modifiedDate、modifiedBy、description、comments、および mimeType)の入力に対してデータを返してはいけない。 明示的プロパティを取得する際には、対応するメソッドがインフラストラクチャによって個別に呼び出される。

    DocumentDef

    DocumentDef インタフェースは、ドキュメント コンテンツの未処理のバイト データを表す。 このインタフェースでは 2 つのメソッドを実装する必要があるが、主に呼び出されるのは openStream() メソッドである。 openStream() から返される InputStream では、skip() メソッドと available() メソッドを効率的な方法でサポートすることをお勧めする。 skip() メソッドは、コンテンツのひとまとまりのバイト データを WebLogic Portal に返す際に用いられる。 また、available() メソッドは、ストリームから入手できるバイト データの残量を決定するのに用いられる。

    DocumentSchemaDef

    DocumentSchemaDef は、基礎となる CMS で利用可能な単一のスキーマを表す。 このインタフェースには、属性の名前、データ型、取り得る値、および概要を問い合わせるためのメソッドが 含まれている。


     

    WebLogic Portal のコンテンツ関連 JSP タグを WebLogic Portal SPI へマップする方法については、 http://edocs.beasys.co.jp/e-docs/wlp/docs70/jsp/p13njsp.htm にある『JavaServer Pages ガイド』の「パーソナライゼーション JSP タグ」を参照してください。

    実装すべきその他の DocumentProvider 関連クラス

    表 3-1 に挙げたインタフェースの他に、SPI の一部機能を実装するための基本クラスとして、 com.bea.p13n.content.document.ref パッケージ内の抽象クラスの一部を用いることができます。 それは以下のクラスです。

    DocumentProvider 実装の開発に役立つクラスには、その他に以下のものがあります。

    注意: 各クラスの詳細については、WebLogic Portal の『Javadoc』を参照してください。

    検索用およびスキーマ用のメソッドを実装する

    一般に、サードパーティ製の CMS と統合するには、検索用のメソッドとスキーマ用のメソッドを両方とも実装する必要があります。

    検索用メソッドは、ドキュメントに関するメタデータ、すなわち返されるデータの全体的イメージを特定するデータを返します。 検索が機能するには、検索オブジェクトに渡される検索条件が、CMS に用意されている検索メソッドにどう対応するかを決定したうえで、そのマッピングを定義する必要があります。

    スキーマ用メソッドは、「バイト データ」、すなわち Web アプリケーションで使用されるデータを表すものを返します。 必要なデータがポーリング先の CMS に存在すると仮定すれば、これらのメソッドから返されるものは以下のとおりです。

    ステップ 3: コードをアプリケーション内に配置する

    SPI 実装の作成が完了したら、それを使用できるように WebLogic Portal をコンフィグレーションする必要があります。 それには、以下のいずれかを行います。

    または

    既存の DocumentConnectionPool を修正する

    最初の方法は、アプリケーションのMETA-INF/application-config.xml に記述されている既存の DocumentConnectionPool を単に修正することです。 DocumentManager 実装では、専用 JDBC ドライバへの接続プールを用いて検索を処理します。 デプロイされた DocumentManager では、DocumentManager MBean の DocumentConnectionPoolName 属性か DocumentConnectionPoolName EJB のデプロイメント記述子設定のどちらかを参照して、使用するドキュメント接続プールを見つけます。

    新しい DocumentConnectionPool と DocumentManager をコンフィグレーションする

    WebLogic Portal をコンフィグレーションする 2 番目の方法は、新しい DocumentConnectionPool をアプリケーションの META-INF/application-config.xml ファイルにセットアップし、新しい DocumentManager EJB をアプリケーションにデプロイすることです。

    まず、WebLogic Server Administration Console を用いて DocumentManager MBean を修正する の節で説明した手順に従って、新しい接続プールを作成します。その DocumentConnectionPool には、必ずアプリケーション内でユニークな名前(たとえば、「myConnectionPool」)を付けます。

    次に、以下の手順に従って、新しい EJB を作成 します。

    1. <application-directory>/document.jar ファイルを一時ディレクトリに 解凍します。

    2. 作成済みの実装コードを適切なディレクトリに追加します。

    3. META-INF/ejb-jar.xml で、DocumentManager のエントリを基に、新しい <session> エントリを作成します。 必ず、<ejb-name> エントリをユニークな名前に変更します。たとえば、リスト 8-16 では、NewsletterDocumentManager としています。

    コード リスト 8-16 <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>
       <!--
    これにより、このインスタンスが application-config.xml で
    どの DocumentManager MBean を探すかが決まる
    -->
       <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>

    1. META-INF/ejb-jar.xml 内の新しい <session> エントリで、DocumentManagerMBeanName の <env-entry> に含まれている <env-entry-value> をユニークな名前(ここでは「NewsletterDocumentManager」)に変更します。 この値は、application-config.xml ファイルで後ほど使用されます。

    2. META-INF/ejb-jar.xml に、新しい <session> エントリ用の <assembly-descriptor> エントリと <container-transaction> エントリを追加します。 既存のコードをコピーしてもかまいませんが、<ejb-name> を必ず上記の値(ここでは「NewsletterDocumentManager」)に変更してください。リスト 8-17 に例を示します。

    コード リスト 8-17 <assembly-descriptor> エントリと <container-transaction> エントリの追加

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

    1. META-INF/weblogic-ejb-jar.xml を編集して、DocumentManager のエントリを基に、新しい <weblogic-enterprise-bean> エントリを作成します。 <ejb-name> エントリを必ず、先ほど用いた名前(ここでは「NewsletterDocumentManager」)に変更してください。リスト 8-18 に例を示します。

    コード リスト 8-18 <weblogic-enterprise-bean> エントリの新規作成

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

    1. META-INF/weblogic-ejb-jar.xml で、新しい <weblogic-enterprise-bean> エントリ内の <jndi-name> を然るべき値に変更します。 この値が、新しい DocumentManager への EJB 参照で用いられる JNDI 名になります。 たとえば、以下のように指定します。
      <jndi-name>${APPNAME}.BEA_portal_examples.
      NewsletterDocumentManage</jndi-name>

    2. 一時ディレクトリを document.jar にアーカイブ化し直します。

    ステップ 4: .jar ファイルにアプリケーションからアクセスできるようにする

    次に、CMS にアクセスするアプリケーションから、作成した .jar ファイルにアクセスできるようにする必要があります。 それには、以下のいずれかの方法を用います。

    ステップ 5: サーバを再起動する

    これまで、コンフィグレーションとクラスパスに数々の変更を加えてきたので、ここでサーバを再起動したほうがよいでしょう。

    ステップ 6: ポータルを適用する

    統合を完了するには、最後に、CMS データの表示先となるポータルを作成する必要があります。 ポータルやポートレットの作成方法については、ステップ 3: ポートレットの追加を参照してください。

    参照実装にパブリッシュする

    この戦略では、WebLogic Portal の参照実装データベース テーブルおよび XML スキーマ ファイルに直接パブリッシュすることが必要になります。

    この戦略を実行するには、以下の手順に従います。

    1. ドキュメント エントリとドキュメント メタデータをデータベース テーブルに格納します。

    2. ドキュメント メタデータ スキーマを WebLogic Portal の XML スキーマ ファイルに記述します。

    3. ドキュメント ファイルをファイル システム上に配置します。

     


    コンテンツ クエリの作成

    この節では、コンテンツ管理システムへのクエリを作成するためのガイドラインを示します。以下のトピックを扱います。

    クエリを構造化する

    WebLogic Portal のクエリは、SQL 文字列構文と構文的に似ていて、基本ブール型の比較表現 (括弧でネストされたクエリを含む) をサポートしています。 概して、クエリには、メタデータ プロパティ名、比較演算子、およびリテラル値が含まれます。 たとえば、以下のように指定します。

    attribute_name comparison_operator literal_value

    注意: クエリ構文の詳細については、『Javadoc API マニュアル』で com.bea.p13n.content.expression.ExpressionHelper を参照してください。

    この構文を用いて作成するクエリに適用される制約は、以下のとおりです。

    以下に、式全体の例を示します。

    例 1:

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

    例 2:

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

    クエリ作成のための比較演算子の使い方

    高度な検索をサポートするため、WebLogic Portal では、比較演算子を組み込んだネストしたブール型クエリを作成することができます。 表8-10 はメタデータ型に利用可能な比較演算子をまとめたものです。

    表8-10 各メタデータ型に対して利用可能な比較演算子

    演算子の種類

    特徴

    ブール (==, !=)

    ブール属性では、Boolean.TRUE または Boolean.FALSE に対して一致するかどうかのチェックが可能。

    数値 (==, !=, >, <, >=, <=)

    数値 (Numeric) 属性では、java.lang.Number に対して、標準的な大小比較 (等しい、大きい、小さい) が可能。

    テキスト (==, !=, >, <, >=, <=, like)

    テキスト文字列では、標準的な同等性チェック (大文字/小文字の区別あり) に加え、辞書順での大小比較が可能。 さらに、文字列では、ワイルドカード パターン マッチング (すなわち、like 演算子) を用いた比較も可能。SQL の「LIKE」演算子や DOS プロンプトのファイル名照合と同様。 この場合、任意の文字列と照合するにはアスタリスク (*) を、任意の 1 文字と照合するには疑問符 (?) を用いる。 間欠的な照合 (例えば [] を使うもの) はサポートされていない。 「*」や「?」そのものと照合するには、バックスラッシュ (¥) をエスケープ文字として使用する。

    日時 (==, !=, >, <, >=, <=)

    日時属性では、java.sql.Timestamp に対して、標準的な大小比較 (等しい、大きい、小さい) が可能。

    多値の比較演算子 (contains, containsall)

    多値属性では、contains 演算子がサポートされる。この演算子は、その属性のサブタイプのオブジェクトを 1 つ取り、それが属性値の中に含まれているかどうかをチェックする。 さらに、多値属性では、containsall 演算子もサポートする。これは、属性のサブタイプのオブジェクトのコレクションを取り、それらのすべてが属性値の中に含まれているかどうかをチェックするものである。

    多値属性に適用された単値の演算子は、属性の値のコレクション全体に適用されることになる。 なんらかの値が演算子およびオペランドと一致すれば、true が返される。 たとえば、多値のテキスト属性 keywords が、値として、BEAComputer および WebLogic を持ち、オペランドが BEA の場合、< 演算子は true を返し (BEAComputer よりも小さい)、> 演算子は false を返し (BEA よりも小さな値はない)、== 演算子は true を返す (BEABEA と等しい)。

    ユーザ定義の比較演算子

    現在、ユーザ定義の属性に適用できる演算子はない。


     

    注意: 検索パラメータと式オブジェクトでは、ビット フラグ (!) を用いた式の否定が利用できます。

    参照実装コンテンツ管理システムは、単値のテキストおよび数値プロパティしか持てません。 暗黙のプロパティはすべて単値テキストです。

    Java を用いたクエリの作り方

    Content Management コンポーネントで用意されているクエリ言語を使う代わりに Java 構文を使ってクエリを作るには、『Javadoc API マニュアル』で com.bea.p13n.content.expression.ExpressionHelper を参照してください。

    ContentManager セッション Bean は、Content Management コンポーネントの機能への主要なインタフェースです。 ContentManager インスタンスを使用すると、コンテンツは、埋め込まれた com.bea.p13n.expression.Expression (式ツリーを表す) と一緒に、com.bea.p13n.content.expression.Search オブジェクトに基づいて返されます。

    ContentManager で有効な式ツリーとして使用するには、下記の注意事項に留意する必要があります。

    com.bea.p13n.expression.operator.logical.LogicalAnd、com.bea.p13n.expression.operator.logical.LogicalOr、com.bea.p13n.expression.operator.logical.LogicalMulitAnd、 または  com.bea.p13n.expression.operator.logical.LogicalMultiOr。

    com.bea.p13n.expression.operator.comparative.Equals、com.bea.p13n.expression.operator.comparative.GreaterOrEquals、 com.bea.p13n.expression.operator.comparative.GreaterThan、com.bea.p13n.expression.operator.comparative.LessOrEquals、com.bea.p13n.expression.operator.comparative.LessThan、com.bea.p13n.expression.operator.comparative.NotEquals、com.bea.p13n.expression.operator.string.StringLike、 com.bea.p13n.expression.operator.collection.CollectionContains、 または com.bea.p13n.expression.operator.collection.CollectionsContainsAll

    Document サーブレットの使い方

    Content Management コンポーネントには、Document オブジェクトのコンテンツを出力する能力を備えたサーブレットがあります。 このサーブレットは、コンテンツ管理システム内に存在する画像コンテンツをストリーミングする時や、HTML リンクが選択された際にコンテンツ管理システム内に格納されているドキュメントのコンテンツをストリームする場合に役立ちます。 このサーブレットでサポートされる Request/URL パラメータを、表8-11 に示します。


     

    表8-11 Document サーブレットでサポートされるリクエスト パラメータ

    リクエスト パラメータ

    必須

    解説

    contentHome

    場合による

    contentHome 初期化パラメータが指定されない場合は、必須で、DocumentHome の JNDI 名として使用される。 contentHome 初期化パラメータが指定されている場合は、これは無視される。

    contentId

    いいえ

    取り出すための Document の文字列識別子。 指定されない場合、サーブレットは PATH_INFO 内を探す。

    blockSize

    いいえ

    読み出すデータ ブロックのサイズ。 デフォルトは 8K。 1 回の操作でブロック全体を読み出すには、0 以下を指定する。


     

    サーブレットは、Document のみをサポートし、Content の他のサブクラスはサポートしません。 Content-TypeDocument の mimeType に設定され、Content-LengthDocument のサイズに設定され、Content-Disposition を、ブラウザからのファイル保存時に正しいファイル名を表すべく、正しく設定されます。

    例 1: JSP での使い方

    この例は、夕方に表示するニュース項目を検索し、 それらを箇条書きのリストにして表示します。

    <cm:select sortBy="creationDate ASC, title ASC"
    query=" type = `News' && timeOfDay = `Evening' && mimeType like `text/*' "id="newsList"/>
    <ul>
    <es:forEachInArray array="<%=newsList%>" id="newsItem" type="com.bea.p13n.content.Content">
         <li><a href="ShowDoc/<cm:printProperty id="newsItem"
    name="identifier" encode="url"/>"><cm:printProperty
    id="newsItem" name="title" encode="html"/></a>
      </es:forEachInArray>
    </ul>

    例 2: JSP での使い方

    この例は、キーワードに「bird」が含まれている画像ファイルを検索し、その画像を箇条書きリストにして表示します。

    <cm:select max="5" sortBy="name" id="list"
    query=" KeyWords like `*birds*' && mimeType like `image/*' "
    contentHome="java:comp/env/ejb/MyDocumentManager"/>
    <ul>
    <es:forEachInArray array="<%=list%>" id="img" type="com.bea.p13n.content.Content">
       <li><img src="/ShowDoc/<cm:printProperty id="img"
    name="identifier"
    encode="url"/>?contentHome=<es:convertSpecialChars
    string="java:comp/env/ejb/MyDocumentManager"/>">
    <es:forEachInArray>
    </ul>

     

    ページの先頭 前 次