Upload Login /
...

IBM Workplace Web Content Management V6.0

by user

on
Category: Documents
>> Downloads: 3
21

views

Report

Comments

Description

Transcript

IBM Workplace Web Content Management V6.0
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
IBM Workplace Web Content Management V6.0 の利用にあた
ってのベスト・プラクティス
David De Vos
Lab Product Specialist, Web Content Management
Australia Development Lab, Sydney
Melissa Howarth
Lab Product Specialist, Web Content Management
Australia Development Lab, Sydney
2006 年 12 月
© Copyright International Business Machines Corporation 2006. All rights reserved.
© Copyright IBM Japan 2007
この記事は、製品開発、サポート、および顧客対応を通じて IBM® Workplace Web Content Management™
V6 の使用経験を積んだサービス担当者、開発担当者、サポート担当者から寄せられたヒントとガイドラ
インをまとめたものです。この記事の情報は Workplace Web Content Management バージョン 6.0.x レベル
にのみ適用されます。その他のバージョンではベスト・プラクティスが異なる可能性があります。
この記事は Workplace Web Content Management システムの実装担当者を対象としたガイドとして作成され
ており、扱うトピックは限られています。この記事の内容を理解するには、Web Content Management の
基本的な知識を理解している必要があります。Web Content Management の基本知識を理解する上で役立
つ資料については、『参考資料』を参照してください。
Dec 06
Page 1
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
1
1.1
1.2
1.3
1.4
2
2.1
2.2
2.3
2.4
2.5
作業を始める前に _______________________________________________________________ 4
行うべき作業
4
行うべきでない作業
6
検討事項
6
マイグレーションに関する検討事項
6
コンテンツの作成 _______________________________________________________________ 6
行うべき作業
6
行うべきでない作業
6
アクセス制御ストラテジー (**v6.0 で変更)
6
分類、カテゴリー、およびオーサリング・テンプレート
6
コンテンツ作成および承認プロセスの最適化
6
3
3.1
3.2
3.3
3.4
3.5
3.6
拡張機能 ______________________________________________________________________ 6
マルチロケール
6
検索
6
IBM Workplace Web Content Management API
6
カスタム・オーサリング・インターフェース
6
Web Content Management と Portal Document Manager の統合
6
Web Content Management と Portal Personalization の統合
6
4
4.1
4.2
4.3
4.4
4.5
4.6
4.7
デプロイ ______________________________________________________________________ 6
行うべき作業
6
行うべきでない作業
6
配信/レンダリング環境
6
オーサリング環境
6
クラスタリング
6
シンジケーション
6
複数環境にわたる複数 LDAP サーバー
6
5
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
パフォーマンス _________________________________________________________________ 6
行うべき作業
6
行うべきでない作業
6
データベース・チューニング
6
LDAP のチューニング
6
メニュー・コンポーネントの最適化
6
ナビゲーション・コンポーネントの最適化
6
Portal Personalisation ルールの最適化
6
キャッシングと事前レンダリング
6
6
6.1
6.2
7
7.1
7.2
7.3
管理 __________________________________________________________________________ 6
行うべき作業
6
行うべきでない作業
6
結論 __________________________________________________________________________ 6
参考資料
6
著者について
6
謝辞
6
Dec 06
Page 2
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
はじめに
IBM® Workplace Web Content Management™ 環境の設計および構築の早期段階には、環境のスケーラビリ
ティー、管理の容易性、拡張性、およびパフォーマンスに影響を及ぼす、数多くの決定と選択を行いま
す。多くの顧客は、社内外のサイトへのコンテンツ配信に Workplace Web Content Management を使用して
います。このような実装から、この製品の機能を最大限に活用して Web コンテンツのニーズに対応する
方法を学ぶ貴重な機会を得ました。この記事に記載されているベスト・プラクティスをは、Workplace
Web Content Management 6.0.x 環境で設計上の決定を行う際のガイドラインとしてご利用ください。
Dec 06
Page 3
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
作業を始める前に
1
ベース・プロダクトのインストール後、Web サイトの構築を開始する前に行うべき作業があります。
1.1 行うべき作業
1. 次に示す参考資料を読む。
•
WebSphere Portal および Workplace Web Content Management の Information Center (US) (WebSphere
Portal を選び『サイトのコンテンツ管理』から『Web コンテンツの管理』セクション) を検索する。
•
IBM Redbook™「IBM Workplace Web Content Management for Portal 5.1 and IBM Workplace Web
Content Management 2.5(US)」を読む。
•
developerWorks Workplace Web Content Management (US)を参照する。
注:InfoCenter には、必要な情報を検索できる検索機能があります。また、2006 年 1 月に発行された
Redbook には、多数の事例と役立つ情報が収録されています。
2. 構築作業を開始する前に、経験のある担当者にプロジェクトの要件分析および技術設計を依頼する。
•
顧客が、分析と設計に時間と予算をかけたがらないことが原因で、多くのプロジェクトにおいて、
予想以上に構築の時間がかかったり、後で保守不能な状態になったりすることがあります。分析
と設計を実施することで、構築段階での時間を節約でき、問題やギャップを容易に解決できる段
階でこれらの問題を検出できます。この結果、管理の容易なサイトを構築でき、長期的にコスト
を節約できます。また、長期的な目標を検討することで、このような目標を容易に実現できるサ
イトを設計できます。
•
構築作業を開始する前に、分析設計文書に次の内容を記述してください。
- *業務、運用、長期(実行時期・期間が長期にわたる際の判断)、およびサイトの目的
- *ユーザーとその目的
- *サイト・フレームワークと情報構造
- *分類
- ワークフロー・モデル
- ライブラリー・アーキテクチャー
- オーサリング・テンプレートおよびプレゼンテーション・テンプレートの定義
- デプロイメント・アーキテクチャー
- セキュリティー・モデル
- マルチロケール・アーキテクチャー
- パーソナライゼーションの要件
- その他の製品との統合
* これらの項目は Workplace Web Content Management に限定されるものではありませんが、プロ
ジェクト開始前に確定しておく必要があります。分析が不十分なために多くのプロジェクトが失
敗しています。
•
3.
包括的なプロジェクト計画を策定します。
経験のあるサービス担当者からトレーニングまたは支援を受ける。
Dec 06
Page 4
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
4.
Workplace Web Content Management の機能を使用する上で必要なスキルを習得せずに
Workplace Web Content Management を導入直後 (OOB: out-of-the-box) に使用しようとしたこと
が原因で、多くのプロジェクトが失敗しています。例えば、あるコンサルタントが多数の
Workplace Web Content Management API 呼び出しを使用したレンダリング・ポートレットを独
自に作成し、非常に線形なサイト・フレームワークを設定したケースがありました。これは
大量のカスタマイズ作業を伴い、パフォーマンスは不十分でした。しかし、製品スキルが導
入されると間もなく、Workplace Web Content Management のすぐに利用可能な (OOB) 機能と
ローカル・レンダリング・ポートレット (LRP) を使用して同じ機能が作成されました。
•
コンテンツ作成者には HTML のスキルは不要であっても、サイト構築担当技術者には HTML
の知識が必要であり、またサイトの複雑さによっては JavaScript や Java の知識も必要となる
ことを覚えておいてください。
関連する修正プログラムをすべて適用する。
•
•
5.
•
「リリース情報(US)」を参照し、現在判明している制約事項と利用可能なフィックスの詳細
を確認します。
「Recommended fixes and updates for WebSphere Portal(US)」サイトを参照します。
Workplace Web Content Management オブジェクトを作成する前に、以下の作業を行う。
•
•
6.
ポータル・セキュリティーを有効にします。
必要に応じてワークフローを設定します。
o ワークフロー、ワークフローステージ、および ワークフローアクションではワークフロ
ーを使用可能に設定しないでください。ただし、その他の設計コンポーネントでワー
クフローを使用可能に設定することを検討してください。
o
ワークフローは、承認の施行とセキュリティー設定の適用のために使用し、各種項目
の作成を制限するためには使用しないでください。各種項目の作成を制限する方法につ
いては、本文書の『コンテンツの作成』の『アクセス制御ストラテジー』 を参照してく
ださい。
• 選択したデータベースにリポジトリーを配置します。
o
詳しくは『データベースの構成(US)』で、InfoCenter のトピックを参照してください。
o 最終的に希望するとおりの状態に Workplace Web Content Management をセットアップし
ておけば、コンテンツを大量に作成した後に、リポジトリーを後から調整するために
かかる時間を大幅に節約できます。
すべてのパーツに命名標準 (パーツ・タイプ別プレフィックスを含む) を適用する。
•
パーツ・タイプを使用して命名標準を設定すると、パーツの識別と検出が容易になります。
コンテンツ項目の命名規則を設定すると、サイト内でのコンテンツの順序を維持しやすくな
ります。コンポーネントに記述的な名前を使用する命名規則を使用すると、他の開発者が再
利用するコンポーネントを特定しやすくなり、維持する必要があるコンポーネントの数が減
ります。
7. グループを作成する。
•
Dec 06
分析フェーズで定義したグループをセットアップします。少なくとも、サイト開発者、サイト管
理者、コンテンツ作成者、コンテンツ承認者のグループは作成してください。これにより、コン
テンツまたはコンポーネントのセキュリティー設定で個人ユーザーが使用されることがなくなり
ます。
Page 5
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
8. Web コンテンツ・ライブラリーを作成する。
•
•
•
•
•
デフォルト・ライブラリーを使用する代わりに、各自の Web コンテンツ・ライブラリーを作成
しておくことをお勧めします。
必要な Web コンテンツ・ライブラリーの作成時に、ライブラリーにアクセス権限とリソース・
タイプを割り当てます。例えば、コンテンツ作成者に対しコンテンツの表示操作のみを許可し、
すべての管理リソースを非表示にするように設定できます。詳しくは、本文書の『コンテンツの
作成』の『アクセス制御ストラテジー』を参照してください。
推奨されるアーキテクチャーについての詳細は、InfoCenter の 『ライブラリーでの作業』を参照
してください。
デフォルト・ライブラリーを使用する場合は、デフォルト・ライブラリーを別のマシンのデフォ
ルト・ライブラリーにシンジケートできない点に注意してください。デフォルト・ライブラリー
の名前が同一である場合がありますが、実際にはそれぞれ異なるライブラリーです。
項目を別のライブラリーに移動する際には、コピーしてから (元のライブラリーを) 削除する操作
ではなく、移動機能を使用することをお勧めします。これは、移動機能では移動された項目への
参照も更新されるためです。
9. コンテンツ作成計画を策定する。
•
Web サイトを構築している間に、コンテンツの収集と作成を管理するユーザーが存在することが
重要です。Web サイト全体の設計、構築、およびテストが完了していながら、コンテンツが準備
できなかったために Web サイトの開始が 1 年遅れたケースや、まったく開始できなかったケー
スがあります。これもプロジェクト計画に組み込んでください。
1.2 行うべきでない作業
1.
wpsadmin ですべての作成作業を行わない。
•
2.
wpsadmin を複数のユーザーに割り当てない。
•
3.
wpsadmin ID は最終的にはシステムから削除されるため、LDAP 内の ID を使用してセキュリ
ティーを有効にし、設計とコンテンツ作成作業を行ってください。
同じ ID の 2 ユーザーが同時に存在していると、予期しない結果が生じる可能性があります。
Workflow、ステージ、またはアクションではワークフローを使用可能に設定しない。
•
Workflow、ステージ、およびアクションでワークフローが使用可能になっていると、シンジ
ケーションで問題が発生します。
1.3 検討事項
1.
Ephox EditLive! などのサード・パーティーのリッチ・テキスト・エディター (RTE) を使用する。
•
2.
OOB RTE に現在搭載されていない RTE 機能が必要な場合に利用できる適切な製品として、
Ephox エディター (http://www.ephox.com/products/editliveforiwwcm/) があります。
文書管理に Portal Document Management (PDM) を使用する。
Dec 06
Page 6
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
•
PDM は文書の再利用と管理に適していますが、シンジケーションの調整を考慮する必要があ
る点に注意してください。
•
デフォルトでは、Portal Document Manager にアップロードできる文書の最大サイズは 10 MB
です。
o この制限を変更するには、<WAS_ROOT>\AppServer\config\cells ディレクトリーにある
plugin-cfg.xml ファイルを編集し、PostSizeLimit 設定を変更します。
o Portal Document Manager の InfoCenter によれば、サポートされている最大サイズは
500000000 (500 MB) です。
3. ポータルのナビゲーションに PathCmpnt タグおよび URL マッピングを使用する (以下に示されてい
る Redbook を参照)。
•
•
Portal によるナビゲーションと Workplace Web Content Management によるナビゲーションと
の調整はサイトの構造に影響するため、早期の段階で計画しておく必要があります。
•
その 1 つの方法としては、どのチームがナビゲーション管理を担当するかを検討します。例
えば、WebSphere Portal 管理チームが上部と横のナビゲーションを管理する場合、このナビ
ゲーションは WebSphere Portal で行われる必要があります。Content チームがページ内のナビ
ゲーションを管理する場合、このナビゲーションは Workplace Web Content Management で行
われる必要があります。
ナビゲーションの管理責任の計画と調整についての詳細は、Redbook「IBM Workplace Web
Content Management for Portal 5.1 and IBM Workplace Web Content Management 2.5(US)」の該当する
セクションを参照してください。
4. カスタム起動ページを使用する。
•
•
一般的な作成作業を合理化し、カスタム起動ページを作成することを検討してください。これに
より、日常的な作業を行うために必要なクリック回数が減ります。例えば、起動ページには一般
的なコンテンツ・タイプの作成や、承認者の承認待ちである文書の表示などの操作へのリンクを
組み込むことができます。
詳しくは、本文書の『拡張機能』の『カスタム起動ページ』および、InfoCenter の『カスタム起
動ページの作成』を参照してください。
5. 表の最大行数を増やす。
•
6.
オーサリング・ポートレットの構成モードでは、表あたりの最大行数を増やせます。最大行数を
増やすと、1 ページ内に表示できるコンテンツが増えます。操作を容易にする目的で、デフォル
ト値 10 を増やすことができますが、値を大きくしすぎないように注意してください。この値が
大きすぎると、ページのロードにかなりの時間がかかります。
サイトのプロトタイプを作り、操作性を調べる。
•
Dec 06
サイト・フレームワークとプロセスのプロトタイプを作成します。これにより、対象ユーザ
ーに対して最適なサイトを作成するために操作性を調査できます。構築するサイトがどれほ
ど技術的に素晴らしいものであっても、ユーザーがそのサイトを効果的に利用できないので
あれば、成功とはいえません。数人のユーザーによる単純なペーパー・プロトタイプでも、
まったくプロトタイプを行わないよりはましです。ペーパー・プロトタイプの実施方法につ
いては、Web 上に多数の参考情報があります。
Page 7
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
7. 複数の環境を使用する。
•
開発環境
開発者は、単体テスト専用の環境を利用できる必要があります。
•
統合およびステージング環境
統合およびステージング環境は、予定されている本稼働環境 (プラットフォーム、データベース、
およびオペレーティング・システム・レベルなど) を模倣したものである必要があります。
•
本稼働環境
本稼働環境の設計には、スケーラビリティー、冗長性、フェールオーバーを取り入れます。
1.4 マイグレーションに関する検討事項
•
InfoCenter の『Web Content Management のマイグレーション』、特にマイグレーション後のステ
ップのセクションを読み、推奨される変更を行うよう計画する。
•
「Portal 6.0 Migration Best Practices guide(US)」を参照する。
•
マイグレーションを開始する前に、「Recommended fixes and updates for WebSphere Portal(US)」サ
イトで推奨されるフィックスを確認し、フィックスを適用する。
•
マイグレーション・プロセスを円滑化するため、マイグレーションを開始する前に Workplace
Web Content Management データベースを調整する。
o 詳しくは、本文書の『パフォーマンス』の『データベース・チューニング』を参照して
ください。
•
古い Workplace Web Content Management 構成ファイル (connect.cfg、aptrixjpe.properties、
aptrixsearch.properties) でカスタマイズした設定を、新しい
<WPS_ROOT>\wcm\shared\app\config\wcmservices\WCMConfigServices.properties ファイルに手動で
入力する必要がある点に注意する。
•
マイグレーション・データを格納するライブラリーは 1 つだけ作成される。マイグレーション後
に、必要なライブラリーをセットアップし、マイグレーションしたコンテンツをこれらのライブ
ラリーに移動します。
•
マイグレーション実行中は、コンテンツ入力操作を禁止する。
•
マイグレーション完了後に必ずログを調べる。
Dec 06
Page 8
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
コンテンツの作成
2
InforCenter の『 Web コンテンツの管理』
このセクションでは、Web サイト作成時に実行すべき作業と実行すべきでない作業を説明します。
2.1 行うべき作業
1. Workflow を使用してコンテンツのセキュリティーを設定する。
•
Workflow ステージでコンテンツ・セキュリティーを設定できます。コンテンツ提供者がアクセ
ス権限を設定する代わりに、この方法でコンテンツをセキュリティー保護してください。
2. Workplace Web Content Management の分類と Personalization Server (PZN) を使用してパーソナライゼー
ションを追加する。
•
コンテンツを分類することで、サイトのパーツをパーソナライズできます。これを実行するには、
Workplace Web Content Management API ではなく、メニュー・コンポーネントと Personalization
ルールを使用します。
3. カスタム・オーサリング・テンプレートを作成する (v6.0 の新機能)
•
•
•
たくさんのオーサリング・テンプレートを作成する代わりに、オーサリング・テンプレートで各
項目のアクセス制御設定を使用し、作成作業を合理化します。
コンテンツ作成者に対して表示する必要のないフィールドをすべて非表示にします。
可能な場合は、作成者が不適切なデータを入力する状況を最小限に抑えるため、フィールド・ヘ
ルプとプロンプトを入力し、すべての必須フィールドを必須としてマークし、値範囲を制限し、
jsp 検証を実装します。
4. プレゼンテーション・テンプレートと HTML/リッチ・テキスト・フィールドに画像を追加するには
「イメージの挿入」ボタンを使用する。
•
•
コンテンツ作成者は、「イメージの挿入」ボタンを使用して html コンポーネントおよびリッチ・
テキスト・コンポーネントに画像を挿入できます。画像はイメージ・ライブラリーから選択でき
ます。また、作成者は画像をファイル・システムから選択してイメージ・ライブラリーにアップ
ロードできます。
リンク作成時に画像サイズの指定変更を許可します。
InfoCenter の 『 画像をエレメントに挿入』
5. 再利用可能なコンポーネントを作成する。
•
Workplace Web Content Management の特長の １ つに、Web ページのコンポーネント・モデルが
あります。開発時にはこの概念を念頭においておくことが重要です。開発者が作成する各コンポ
ーネントは多数のページで再利用される可能性があるため、各コンポーネントを再利用可能なモ
ジュール形式で作成します。コンポーネントを新規に作成する前に、類似したコンポーネントが
既に存在しているかどうかを確認します。再利用可能なコンポーネントの例:ページのヘッダー
とフッター、メニューのヘッダーとフッター、メニュー・レイアウトとナビゲーター・レイアウ
ト、HTML ヘッダー、javascript の宣言
Dec 06
Page 9
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
•
その他の例については、Redbook「IBM Workplace Web Content Management for Portal 5.1 and IBM
Workplace Web Content Management 2.5(US)」を参照してください。
6. 特殊なニーズに対応するため、サイトとサイト・エリアにコンポーネントを組み込む (サイト・エリ
アにリンクしている画像、Personalization ルール、ナビゲーターの特殊文字など)。
•
サイトとサイト・エリアにコンポーネントを追加することで、サイトに独自の外観を設定できま
す。例えば、各部門サイトに部門幹部役員の画像や最新のチームの写真などを組み込むことがで
きます。サイトのコンテンツ・リストを表示するパーソナライゼーション・コンポーネントまた
はメニュー・コンポーネントを組み込むために、参照コンポーネントを追加することもできます。
スタイルシートとログを各サイトに保存し、複数のサイトに独自のルック・アンド・フィールを
持たせることができます。
7. 他のサイトで再利用される可能性があるコンポーネントには一般的な名前を使用する。
•
5 つのイントラネット・サイトを運用しており、各サイトのレイアウトは同一であるが、ロゴと
カラー・スキームがそれぞれ異なるとします。各イントラネット・サイトで「3 パネル表示」と
いう名前のプレゼンテーション・テンプレートを再利用し、変更を行う場合はこのテンプレート
だけを変更します。ロゴとスタイルシートをサイトに保存しておき、プレゼンテーション・テン
プレートでこのロゴとスタイルシートを参照すると、イントラネット・サイトに独自の外観を設
定できます。1 番目のイントラネット・サイトで「財務イントラネット・プレゼンテーション」
というプレゼンテーション・テンプレートを作成すると、このテンプレートの再利用は限定され
ます。
8. モジュール形式
•
すべてのオブジェクトがモジュール形式であることが理想的です。つまり、オブジェクトで
<table> タグを閉じる場合やオブジェクトの前後に <script> タグを配置する場合などに、他のオブ
ジェクトに依存しないようにします。あるコンポーネントを少しでも変更する場合、それに依存
する別のコンポーネントがあるならば、そちらも変更しないと 2 つのコンポーネントが機能しな
くなる可能性があります。すべての機能は、この機能を必要とするコンポーネント内に (コンポ
ーネントに直接コーディングするか、または別の完全なコンポーネントとして) 保持される必要
があります 。不必要に他のコンポーネントに依存するコンポーネントは、管理が非常に困難です。
9. 項目のレイアウトには HTML コンポーネントを使用する。
•
メニューとナビゲーターに使用するレイアウトが含まれている html コンポーネントを作成すると
効率的です。例えば、「ItemLayout-TitleDateSumary」および「ItemLayout-TitleSummary」という
html コンポーネントを作成します。このように作成された html コンポーネントは再利用できま
す。また、変更を行う場合には、これらのコンポーネントだけを変更するだけで、すべてに反映
されます。
9. すべての内部リンクおよび外部リンクにはリンク・コンポーネントを使用する (v6.0 の新機能)。
•
すべての外部 URL リンクと内部 Workplace Web Content Management リンクに、リンク・コンポ
ーネントを使用してください。
InfoCenter の『 リンク』
10. メニュー、ナビゲーター、および検索結果のページ操作にはページ・ナビゲーション・コンポーネン
トを使用する (v6.0 の新機能)。
Dec 06
Page 10
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
•
•
メニュー、ナビゲーター、または検索から大量の結果が戻される場合は、結果結果のページ操作
にページ・ナビゲーション・コンポーネントを使用します。結果リストが長いと、これに伴い
html コードが増えるため、ページのロードとレンダリングに時間がかかります。
現在、パーソナライゼーション・コンポーネントでは、ページ・ナビゲーション・コンポーネン
トがサポートされていない点に注意してください。
InfoCenter 『ページ・ナビゲーション・エレメント』
11. スタイルシート・コンポーネントを使用する (v6.0 の新機能)
•
作成者が入力するコンテンツの外観を制御し、スタイルをいつでも容易に変更できるようにする
ため、スタイルシートを使用するようにリッチ・テキスト・フィールドを構成してください。
InfoCenter の 『スタイルシート・エレメント』
12. インライン編集を使用し、サイト内でコンテンツを編集、作成できるようにする (v6.0 の新機能)。
•
•
•
インライン編集では、メニュー、ナビゲーター、またはコンテンツから文書を編集および作成で
きるため、作成作業の効率が向上します。インライン編集のセットアップ方法についての詳細は、
InfoCenter を参照してください。
複数の環境で同一項目を編集する場合に発生するシンジケートの競合を防ぐため、インライン編
集をオーサリング環境でのみ使用することをお勧めします。
詳しくは、本文書の『コンテンツの作成』の『インライン編集機能』を参照してください。
13. メニューの「結果なし」フィールドに html を入力する (v6.0 の新機能)。
•
メニューから結果が戻されない場合に表示するメッセージを入力するか、またはメニューに問題
がある場合のトラブルシューティングを支援する非表示の html を入力します。
14. ループを回避する。
•
メニューやナビゲーターなどのコンポーネントを使用して動的に生成されるコンテンツを作成す
る場合、コンポーネントから戻されるデータに、そのコンポーネント自体への参照が含まれてい
ないようにすることが重要です。
15. サイトの最上位レベルにサイト・エリアのプレゼンテーション/オーサリング・テンプレートのマッ
ピングを追加する。
•
オーサリング・テンプレートおよびプレゼンテーション・テンプレートのマッピングは親サイト
から継承されるため、サイトの最上位レベルにこれらのマッピングを指定します。また、常にデ
フォルトのコンテンツを割り当て、削除されないようにこのコンテンツをロックしてください。
すべてのマッピングを 1 か所にまとめておくと、マッピングの検索と変更を 1 か所で行うことが
できるため、管理が容易になります。
16. サイトとサイト・エリアには常にデフォルトのコンテンツを割り当てる。
•
•
•
Dec 06
ナビゲーターでの誤ったリンク指定を避けるため、サイトとサイト・エリアにデフォルトのコン
テンツを割り当てます。サイト・エリアに手動でリンクを作成する場合も、デフォルトのコンテ
ンツを割り当てます。
管理者の承認なしにデフォルトのコンテンツが削除または変更されることを防ぐため、デフォル
トのコンテンツをロックすることを検討してください。
Workplace Web Content Management v6 では、デフォルト・コンテンツが割り当てられていないと、
サイト・エリアに最初に追加されたコンテンツ項目が表示される点に注意してください。
Page 11
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
17. オーサリング・テンプレートの変更を適用するには「テンプレートの適用」ボタンを使用する。
•
オーサリング・テンプレートを使用してコンテンツを作成した後に、オーサリング・テンプレー
トを変更して新しいコンポーネントを組み込む場合は、新しいコンポーネントを個別にコンテン
ツに追加するよりも、テンプレートをコンテンツに再適用する方が簡単です。
18. WebSphere Portal で使用する場合はコンテンツとコンポーネントの表示を分離する。
•
ポートレット内に Workplace Web Content Managemen コンテンツを表示するときに使用するプレ
ゼンテーション・テンプレートを作成するときには、表示するコンテンツだけを参照します。メ
ニューやナビゲーションなどのコンポーネントは別のポートレットに表示し、必要に応じてコン
テンツ・ポートレットにリンクします。
19. 「表示タイトル」フィールドを変更せずに使用するか、またはカスタマイズして使用するかどうかを
検討する。
•
•
元々の「表示タイトル」フィールドは、コンテンツに非 ASCII 名またはローカライズされた名前
でタグ付けできるようにすることを目的としています。これらの名前は、Workplace Web Content
Management オーサリング UI 内で使用され、またリンク生成のために使用されます。
o 例: タイトルを「Chinese News」に設定し、表示タイトルには「News」を中国語に翻訳し
たものを設定する。
サイトでコンテンツの各部分に表示タイトルを使用する必要があるが、オーサリング UI で使用
する独自の命名規則を設定している場合は、カスタム「表示タイトル」フィールドを使用し、
Web Content Management の「表示タイトル」フィールドを空白のままにしてください。
o 例: タイトルを「A08567 - Top Ten Mistakes」と設定し、表示タイトルをブランクにし、
値を「Top Ten Mistakes」に設定したカスタム・テキスト・エレメントを追加する。
20. パーソナライゼーションにはセキュリティーを使用しない。
•
パフォーマンスの問題が発生する可能性があるため、パーソナライゼーションにセキュリティー
を使用しないでください。代わりに、プロファイリングと Portal Personalization サーバーの機能を
使用することを検討してください。
21. ページに必要以上に多くの Workplace Web Content Management ポートレットを表示しない
•
•
WebSphere Portal のベスト・プラクティスに従い、ページには適正な数 ( 5 未満) のポートレ
ットを表示するようにします。
ページに複数の Workplace Web Content Management ポートレットを表示する場合は、セッシ
ョン処理を有効にします。
22. ページに必要以上に多くの Workplace Web Content Management メニューを表示しない
•
ページをキャッシュできない場合、多数のメニューを組み込むとページのロードに時間がか
かるため、ページに組み込むメニューの数を適正な数 (5 以下) にします。
23. コンポーネント参照を定義する際には、ライブラリーが 1 つだけの場合でも、ライブラリー・プレフ
ィックスの使用を検討する。
•
Dec 06
ライブラリーが 1 つだけの場合、理論的にはコンポーネントにライブラリー名をプレフィックス
として使用する必要はありません。
Page 12
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
•
•
•
今後ライブラリーを新規に作成する場合に備えて、プレフィックスを使用できます。これにより、
使用されているライブラリーが混同されることがなくなります。
複数のライブラリーを使用して自己完結型コンテンツ (すべての参照オブジェクトが同一ライブ
ラリー内にあるコンテンツ) を作成する場合には、プレフィックスを使用しません。
現行ライブラリーをターゲットとして指定するには、プレフィックスとして「./」を使用します。
2.2 行うべきでない作業
1.
サイト、サイト・エリア、およびコンテンツには 51 文字以上の長いオブジェクト名を使用しない。
•
•
•
2.
整合性が維持されなくなるため、ID を外部に保存しない。
•
3.
JSP などの製品コードを変更すると、サポート対象外になります。また、新しいバージョン
やリリースが公開される場合に、すべての変更を再適用しなければなりません。
コンテンツを保護する目的でパーソナライゼーションを使用しない。
•
5.
ID はパーツを指し示す内部ポインターであり、パーツの更新やワークフローでの移動に伴い
変更される可能性があります。複数のセッションを通じてこれらの ID が有効であることは
確実ではないため、ID を外部に保存しないでください。ID を外部に保存すると、リンクが
壊れる可能性があります。
製品の Java ファイルまたは JSP (view.jsp など) を変更しない。
•
4.
サイト、サイト・エリア、およびコンテンツの名前を使用して URL が作成されるため、長す
ぎる URL が作成されないように注意する必要があります。URL が長すぎると、一部の Web
サーバーやプロキシーで問題が発生する可能性があります。
サイトが事前にレンダリングされる場合、URL の長さは宛先サーバーのオペレーティング・
システムの最大パス長よりも短くなければなりません。
長い名前はまた、オーサリング UI で表示の問題の原因となる場合があります。
パーソナライゼーションではコンテンツは保護されません。コンテンツをロックするには、
ワークフローとセキュリティー設定を使用してください。(これにより、引き続きコンテンツ
にアクセスでき、他のエリアからコンテンツにリンクできます)
Workplace Web Content Management ポートレットで使用する URL にコンテキスト・パスを使用しない。
•
•
Workplace Web Content Management ポートレットで使用するコンテンツで URL を作成する場合、
コンテキスト・パスではなくサーブレット・パスを使用してください。
詳しくは InfoCenter の『Web Content Management コンテンツへのリンクを作成する』を参照して
ください。
6. 内部 API を使用しない (公開 API のみサポート)。
7. 有効な実動サーバーで開発作業を行わない。
•
1 台のサーバーですべての作業を行う環境はお勧めできません。ただし、予算の制限からサーバ
ーが 1 台のみである場合は、テスト専用のライブラリーを作成し、すべての項目の読み取りアク
セス権限を「全ユーザー」以外に設定します。
8. コンテンツ名または表示タイトルにサイト・エリア名を使用しない
Dec 06
Page 13
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
•
サイト・エリア別コンテンツを表示するには「サイトエリア別コンテンツ」ビューを使用します。
コンテンツ名にサイト・エリア名が使用されていると、コンテンツを移動したり複数のサイト・
エリアにリンクした場合に混乱が生じます。
2.3 アクセス制御ストラテジー (**v6.0 で変更)
InfoCenter の『– アクセス制御ストラテジーの開発』
プロジェクトの設計フェーズで、以下を含むアクセス制御ストラテジーを設計することが重要です。
ライブラリーと項目タイプのセキュリティー: オーサリング・ポートレット、ライブラリー、およびライ
ブラリー内のビューとアクションへのユーザーのアクセス権限を決定します。
項目レベルのセキュリティー : Web サイトとオーサリング・ポートレットにコンテンツを表示すると
きにエンド・ユーザーに対して表示される内容を決定します。
設計文書にセキュリティーの表を組み込んでおくと便利です。匿名アクセスが許可されているパブリッ
ク Web サイトで InfoCenter で説明する追加方法と以下に定義するグループを使用した場合の例を次に示
します。
グループ
WCM 管理者: すべての機能へのアクセス権限
サイト管理者: ワークフロー・ステージ、アクション、およびワークフローを除くすべての機能へのアク
セス権限
サイト設計者: コンテンツ、プレゼンテーション・テンプレート、オーサリング・テンプレート、および
コンポーネントへのアクセス権限
コンテンツ作成者: コンテンツとコンポーネントへのアクセス権限
コンテンツ承認者: コンテンツへのアクセス権限
2.3.1
ライブラリーへのアクセス権限
グループ
役割
ユーザー
参加者
編集者
管理者
アドミニスト
レーター
2.3.2
伝播の
許可
継承の
許可
X
X
X
X
X
X
X
X
WCM
管理
者
サイト
管理者
サイト
設計者
コンテン
ツ作成者
コンテン
ツ承認者
[全ユーザー]
X
X
X
X
X
X
項目タイプへのアクセス権限
オーサリング・テンプレート
グループ
役割
ユーザー
参加者
Dec 06
伝播の
許可
継承の
許可
X
X
X
X
WCM
管理者
サイト
管理者
サイト
設計者
コンテンツ
作成者
コンテンツ
承認者
Page 14
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
編集者
管理者
アドミニスト
レーター
X
X
X
コンポーネント
グループ
伝播の
許可
役割
X
ユーザー
X
参加者
X
編集者
X
管理者
X
アドミニスト
レーター
コンテンツ
グループ
役割
ユーザー
参加者
編集者
管理者
アドミニスト
レーター
X
X
X
X
X
継承の
許可
WCM
管理者
X
X
X
X
X
X
X
伝播の
許可
継承の
許可
WCM
管理者
X
X
X
X
X
X
X
X
X
X
Dec 06
サイト
設計者
コンテンツ
作成者
X
X
サイト
設計者
コンテンツ
作成者
コンテンツ
承認者
X
サイト
管理者
コンテンツ
承認者
X
X
X
サイト
設計者
コンテンツ
作成者
コンテン
ツ承認者
コンテンツ
作成者
コンテン
ツ承認者
X
X
プレゼンテーション・テンプレート
グループ
伝播の 継承の WCM
管理者
許可
許可
役割
X
X
ユーザー
X
X
参加者
X
X
編集者
X
X
管理者
X
X
X
アドミニスト
レーター
サイトおよびサイト・エリア
グループ
伝播の 継承の
許可
許可
役割
X
X
ユーザー
X
X
参加者
X
X
編集者
X
X
管理者
X
X
アドミニスト
レーター
サイト
管理者
WCM
管理者
サイト管
理者
X
X
サイト
管理者
サイト設
計者
X
X
Page 15
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
分類
グループ
役割
ユーザー
参加者
編集者
管理者
アドミニスト
レーター管理
者
伝播の
許可
継承の
許可
WCM
管理者
X
X
X
X
X
X
X
X
X
X
X
サイト
管理者
サイト設
計者
コンテンツ
作成者
コンテン
ツ承認者
サイト設
計者
コンテンツ
作成者
コンテン
ツ承認者
X
ワークフローおよびワークフロー・エレメント
グループ
伝播の 継承の WCM
サイト
管理者 管理者
許可
許可
役割
X
X
ユーザー
X
X
参加者
X
X
編集者
X
X
管理者
X
X
X
アドミニスト
レーター
注:
•
•
2.3.3
各役割で実行できる操作の説明と、ライブラリーの構成方法の詳細については、InfoCenter を参
照してください。
「管理者マネージャー」役割と「アドミニストレーター」役割では、項目タイプごとのアクセス
権限が似ていますが、「アドミニストレーター」役割をライブラリー全体に割り当てると、すべ
ての項目タイプのビューからこの役割を削除できなくなります。「管理者」役割にはこれは該当
しません。
個々の項目のセキュリティー
個々の項目ベースでアクセス権限を制限する、最下位レベルのセキュリティーです。Workplace Web
Content Management では 3 種類のアクセス権限レベルを項目に割り当てることができます。
読み取りアクセス権限
•
ユーザーは Workplace Web Content Management オーサリング・ポートレットとレンダリングされ
たサイトで項目を表示できます。(注:ライブ・アクセス権設定は使用できなくなりました。)
編集アクセス権限
•
ユーザーは項目を編集できます。
削除アクセス権限
•
ユーザーは Workplace Web Content Management からオブジェクトを削除できます。
各アクセス権限レベルは、下位レベルから上位レベルに継承される点に注意してください。つまり、編
集アクセス権限が付与されているユーザーには、読み取りアクセス権限も付与されていることになりま
す。
項目セキュリティーの表
Dec 06
Page 16
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
ワークフローがないすべてのコンポーネントのシステム定義セキュリティーの設定を以下に示します。
ワークフローが有効に設定されているコンポーネントの場合、現行ワークフロー・ステージによりセキ
ュリティーが定義されるため、この表に示す項目は必要ありません。
グループ
コンポーネント
オーサリング・
テンプレート
コンポーネント
ワークフロー、
アクション、お
よびステージ
プレゼンテーシ
ョン・テンプレ
ート
サイトおよびサ
イト・エリア
分類
WCM
管理者
サイト管理者
サイト開発者
作成者/承認者
D
D
E
R
D
D
D
E
R
R
D
D
E
R
D
D
E
R
D
D
E
R
[全ユーザー]
D – 削除、E – 編集、R- 読み取り
ワークフロー・セキュリティーの表
読み取り
編集
作成者
承認
作成者
承認者
公開 - 匿名
[全ユーザー]
作成者
ドラフト
削除
WCM 管理者
サイト管理者
WCM 管理者
サイト管理者
WCM 管理者
サイト管理者
承認
作成者
承認者
作成者
2.4 分類、カテゴリー、およびオーサリング・テンプレート
詳しくは InfoCenter の『 分類の計画』
分類、カテゴリー、およびオーサリング・テンプレートを使用する状況が分かりにくいことがよくあり
ます。
分類コンポーネントが分類の最上部に位置しており、分類コンポーネントの子がカテゴリー・コンポー
ネントです。分類の例を次に示します。
一般にカテゴリーは、コンテンツの内容と対象ユーザーに関連しており、プロファイルを作成するとき
に使用されます。オーサリング・テンプレートは、類似プロパティーを持つコンテンツのタイプを定義
するときに使用されます。
図 1. 分類とオーサリング・テンプレートの例
Dec 06
Page 17
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
分類
¾
すべてのカテゴリー
ƒ すべてのロケーション
¾ ニューヨーク
¾ パリ
¾ ローマ
¾ サンフランシスコ
¾ シドニー
ƒ すべての部門
¾ 販売
¾ 製造
¾ 研究
¾ マーケティング
ƒ すべての従業員
¾ 管理者
¾ マネージャー
¾ コンサルタント
¾ スペシャリスト
ƒ すべてのニュース・タイプ
¾ 旅行
¾ エンターテイメント
¾ スポーツ
¾ ビジネス
オーサリング・テンプレート
¾ ニュース
¾ ポリシー/レポート/ガイド
¾ 求人
分類は、サイトをパーソナライズするときに使用できます。分類カテゴリーを使用して作成されたプロ
ファイルをユーザーに設定できます。この同じ分類カテゴリーが、作成者によりコンテンツのプロファ
イルに割り当てられます。メニュー・コンポーネントでこれらのプロファイルのマッチングが実行され
ます。この場合、「カテゴリー」の「追加のオプション」>「選択されているユーザー」を使用します
(図 2 と 3 を参照)。
図 2. コンテンツとユーザー・プロファイルのマッチング
User Profile
Categories
News Types
Content Profile
News Articles
Discounts on Airfare now
Travel
Entertainment
Sports
Business
Dec 06
Exciting trip to the Island
Thumbs up for this movie
Super Bowl Sunday, get ready
Tech stocks gain steam
Lotusphere rocks in Orlando
Page 18
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
図 3. カテゴリー・マッチングのためのメニューの指定
ユーザー・プロファイルは次の 3 つの方法で割り当てることができます。
1.
2.
3.
管理者がオーサリング UI で一度に 1 ユーザーずつ処理し、設定する。ユーザーが多数いる場合には実
用的ではありません。
分類コンポーネントを使用してユーザーに対しカテゴリー・リストを表示する。この方法では、
ユーザー自身が必要に応じて管理できます。
動的マッパーを使用してユーザー・プロファイル・カテゴリーを設定する。Workplace Web
Content Management にはサンプル・マッパーがあります。ほとんどの場合、顧客はこのコードを
変更し、LDAP 属性、グループ・メンバーシップ、または Personalization ルールを使用してユー
ザーのカテゴリーを設定します。
2.5 コンテンツ作成および承認プロセスの最適化
Web サイトのコンポーネント (サイト・フレームワークやオーサリング・テンプレートなど) を作成する
ときには、コンテンツ作成者と承認者双方にとっての使いやすさに留意してください。
Workplace Web Content Management v6 の次の新機能により、この作業が容易になります。
• 強化されたオーサリング・テンプレート・フォーム
• インライン編集機能
2.5.1
強化されたオーサリング・テンプレート・フォーム
作成者が入力する必要のあるコードの量を最小限に抑えることが重要です。無駄なオプションをなくし、
意味のある内容だけを入力できるように、オーサリング・テンプレートを合理化する必要があります。
Dec 06
Page 19
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
オーサリング・テンプレートを作成するときには、次の 2 つの設定タブを使用します。
「オーサリング・テンプレートの設定」は、次のようなテンプレート全体の設定を制御します。
• フォームのスタイル
• サイト・エリア選択
• 属性を追加できるかどうか
• テンプレートのヘルプ・テキスト
「デフォルト・コンテンツの設定」は、編集作業を合理化するために設定するデフォルトの属性設定と
追加の属性設定を制御します。次のような設定があります。
•
•
•
•
•
•
各種属性およびセクションの表示/非表示。
フィールドの幅や高さなどの表示オプションの設定。
検証ルールの定義。
属性に基づくセキュリティーの設定。これにより、属性を表示できるグループ/ユーザーや、属性
を編集できるグループ/ユーザーを設定できます。
ヘルプ・テキストの設定。
JSP snippet によるその他の表示および検証の割り当て。
コンテンツ作成者による入力作業を最小限に抑えるための推奨設定を次に示します。
2.5.1.1 オーサリング・テンプレートの推奨設定
設定
デフォルト・スタイルシート
コンテンツ・フォーム・レイ
アウト
追加エレメントを許可する
サイト・エリア選択
サイト・エリア保存オプショ
ン
推奨
社内標準を使用する
ほとんどのセクションを非表
示にする場合は、「セクショ
ンなし」を選択することを検
討する
「いいえ」
「選択したサイト・エリアの
み」
可能な場合は「オプションな
し」
コメント
これにより、フォームに必要
なスペースが減ります。
作成者に対し「エレメントの
管理」ボタンが表示されなく
なります
サイト・エリアを事前に選択
しておく必要があります
作成者がサイト・エリアを選
択する必要がなくなります。
2.5.1.2 デフォルト・コンテンツの推奨設定
設定
すべての属性
名前
Dec 06
推奨
ヘルプ・テキストを入力する
最小サイズと最大サイズを設
定する
コメント
フィールドの検証について明
確に説明します。
• 常に必須フィールドで
す。
• 長すぎる名前を許可しな
いでください。名前が長
すぎると、長い URL が生
Page 20
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
成されます。
表示タイトル
説明
作成者、所有者
プロファイル
コンテンツ・プロパティー
追加エレメント
ワークフロー
アクセス
履歴
最小サイズと最大サイズを設
定する
不要な場合は非表示にする
非表示にする
必須カテゴリーおよびキーワ
ードを選択し、セクションを
非表示にする
セクションを非表示にする
• 表示、検証、およびセキ
ュリティーのオプション
を設定する
• すべての必須フィールド
を必須としてマークする
• カスタム JSP を使用して
他の機能を追加する
•
•
表示する必要があるスペ
ースを最小限に抑えま
す。
カスタム JSP についての
詳細は、InfoCenter の
『JSP を使用するエレメン
トのカスタマイズ』を参
照してください。
ワークフローを選択して、セ
クションを非表示にする
セクションを非表示にする
セクションを非表示にする
ヒント:オーサリング・テンプレートの設定を検証するには「プレビュー」機能を使用します。
2.5.2
インライン編集機能
Workplace Web Content Management v6 の新機能であるインライン編集機能では、Web サイトのコンテキ
ストから編集アクションを実行できるため、コンテンツの作成、変更、および承認が容易になります。
作成者がアクションを指定すると、表示ポートレットのコンテンツが、指定されたコンテンツのオーサ
リング・テンプレートに置き換えられます。その後作成者が変更または追加を行うことができます。変
更を確認するには「保存して終了」を選択します。また、変更を「ドラフト」として保存するようにオ
ーサリング・ツールを設定できます。その後、コンテンツの通常のワークフロー・プロセスが施行され
ます。
インライン編集を有効にするには、まず使用可能にするアクションの外観を指定するオーサリング・ツ
ール・コンポーネントを作成します。アクションを無効にするには、そのアクションの「デザイン」を
をとりやめます。
エンド・ユーザーがアクションを実行するには操作対象の項目に対して適切なアクセス権限が必要であ
るため、インライン編集機能を使用してもセキュリティーが回避されることはありません。
オーサリング環境とレンダリング環境の両方を含む従来のプロジェクトでは、インライン編集機能をオ
ーサリング・サーバーでのみ使用することをお勧めします。インライン編集機能をレンダリング・サー
バーで使用する場合は、オーサリング・サーバーとの間で双方向シンジケーションが必要となり、シン
ジケーションの競合が発生する可能性があります。
オーサリング・サーバーでのみインライン編集機能を有効にする場合は、ローカル・レンダリング・ポ
ートレットおよびリモート・レンダリング・ポートレットの代替プレゼンテーション・テンプレート機
Dec 06
Page 21
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
能を使用して、オーサリング・サーバーで、インライン編集が有効に設定されている別のプレゼンテー
ション・テンプレートを使用することができます。
詳しくは、InfoCenter の『オーサリング・ツール・エレメント』を参照してください。
Dec 06
Page 22
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
拡張機能
3
3.1 マルチロケール
マルチロケール対応 Web サイトを構築する場合は、次のベスト・プラクティスに基づいてマルチロケー
ル・コンテンツを作成および管理してください。
•
•
•
•
ロケールごとに個別のライブラリーを使用する。
すべてのロケールで同じサイト・フレームを使用する。
文書のすべてのロケール・バージョンで同じ「タイトル」フィールドを使用する
ワークフローの「共同承認」機能を利用し、各ロケール所有者にマスター文書またはロケール別
バージョンでの変更を通知する。
詳しくは、InfoCenter の『さまざまなロケール用の Web サイトの作成』を参照してください。
3.2 検索
Portal 6.0 リリース以降、Workplace Web Content Management 検索モジュールが利用できなくなりました。
つまり、リポジトリーを検索する方法は次の 3 つになりました。
• WebSphere Portal Search
• Workplace Web Content Management API
• サードパーティーの検索プロダクト
3.2.1
行うべき作業
1.
InfoCenter の『ポータル検索』および『サイトの検索』を参照する。
2.
検索の要件を理解する。
•
3.
ユーザーが行う検索操作を理解する。
•
4.
ユーザーが拡張検索機能を使用する可能性がない場合は、拡張検索機能について検討する必要は
ありません。検索機能はユーザーが使用しやすく明確である必要があります。
HTML メタ・タグではなく Dublin Core メタ・タグを使用する。
•
5.
検索対象コンテンツ、コンテンツの格納場所、コンテンツの量とフォーマット、検索する必要が
あるフィールド、照会の形式、結果の表示方法を理解します。これらの情報を理解しておくこと
で、ポータル検索エンジンが要件に対応しているかどうか、またはサードパーティー検索エンジ
ンが必要であるかどうかを判別できます。
Dublin Core メタ・タグは、WebSphere Portal Search を含む多くのエンタープライズ検索エンジン
によりサポートされています。HTML メタ・タグは現在では使用されていません。
保護されているコンテンツを検索する。
•
保護されているコンテンツも検索してください。ただし、認証を使用して認証ユーザーのみが文
書を参照できるようにしてください。
Dec 06
Page 23
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
6.
サード・パーティー検索エンジンの使用を検討する。
•
3.2.2
プロジェクトの検索要件が広範囲にわたる場合は、サード･パーティーの検索エンジンの統合を
検討してください。詳しくは、IBM Redbook™「IBM Workplace Web Content Management for
Portal 5.1 and IBM Workplace Web Content Management 2.5 (US)」を参照してください。
行うべきでない作業
1. API を使用してカスタム検索機能を作成できる場合でも、カスタムサーチを使わない。
•
ポータル検索機能が検索要件に対応していない場合は、API を使用して独自の検索エンジンを構
築する前に、既存の検索プロダクトの利用を検討します。
3.3 IBM Workplace Web Content Management API
詳しくは InfoCenter の『 API』
3.3.1
行うべき作業
•
パフォーマンスを強化するため、セッション中に各ユーザーの「ワークスペース」オブジェクト
をキャッシュする。Workplace Web Content Management では、ユーザーのワークスペース作成操
作に時間がかかります。これは、ユーザーのアクセス権限を事前に計算する必要があるためです
(これにより以降の API 操作の速度が向上します)。
o この操作の例については、本文書『カスタム起動ページ』の例を参照してください。
o 注:これは、Web Content Management 6.0.0.0 でこの操作を実行する場合の既知の問題です。
この問題を解決するには、PK35144 (Repository not logged in error when using the WCM API)
を適用します。
•
共通機能をユーティリティー JSP ファイルに組み込み、「jsp:include」タグを使用してそれらを
統合する。これにより JSP ファイルが「コンポーネント化」されます。1 か所で共通機能を変更
すると、その機能を使用するすべての JSP ファイルが自動的に更新されます。
•
Workplace Web Content Management JSP コンポーネントによって使用される JSP ファイルを次に
示す場所にコピーする必要がある。
o
o
Workspace Web Content Management WAR ディレクトリー (サーブレット・レンダリング、
Web ページとしてのプリビュー、およびリモート・レンダリング・ポートレットでのプ
リビュー/レンダリング用)
ローカル・レンダリング・ポートレット WAR ディレクトリー (ローカル・レンダリン
グ・ポートレットでのプリビュー/レンダリング用)
注:ローカル・レンダリング・ポートレットまたは Workplace Web Content Management アプリ
ケーションが更新されるたびにカスタム・デプロイ JSP が削除されるため、この JSP を所定
の場所に再コピーする必要があります。
•
Dec 06
Workplace Web Content Management JSP コンポーネントにより使用される JSP ファイルはシンジ
ケートされないため、必ずこれらの JSP ファイルをすべてのサブスクライバー・サーバーに手動
でコピーする。
Page 24
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
•
取得するコンポーネントを編集しない場合、または別のコンテナーに追加しない場合は、パフォ
ーマンスを改善するため、 getComponent() ではなく getComponentByReference() メソッドを使用す
る。getComponent() は、基礎となるコンテンツ・コンポーネントを複製/コピーします。コンテン
ツ・コンポーネントの一部の情報を読み取るだけの場合は、これは無駄な操作です。
•
Workplace Web Content Management により管理されていない JSP (Workplace Web Content
Management JSP コンポーネントで参照されていない JSP) から API を使用する場合は、JSP によ
る要求処理の完了後に必ず Repository.endWorkspace() メソッドを呼び出す。これは、
endWorkspace メソッドがその名称とは異なり、実際にはユーザーのワークスペースを閉じるので
はなく、Workplace Web Content Management に対して現行要求が完了したことを通知するものだ
からです。その後、Workplace Web Content Management が各種「要求終了」セッション管理クリ
ーンアップ・ルーチンを実行します。
•
setCurrentDocumentLibrary メソッドを使用して呼び出しをライブラリー固有の呼び出しにする。
このメソッドを指定しないと、WCMConfigService.properties ファイルに指定されているデフォル
ト・ライブラリーが使用されます。
•
パフォーマンスを改善するため、セキュリティーに依存しない jsp ページの結果は dynacache を
使用してキャッシュすることを検討する。
•
カスタム・メニューを作成するときに API を使用しない (コンテンツの容量の増加に伴い API コ
ードが実行できなくなる可能性があるため)。Workplace Web Content Management のメニュー・コ
ンポーネントを使用し、照会ストリング引数を使用してこのコンポーネントの動作を指定変更す
る。詳しくは、InfoCenter の『メニュー・エレメント検索プロパティーの定義』を参照してくだ
さい。
3.3.2
•
行うべきでない作業
元々の機能で同じ処理を実行できる場合は、Workplace Web Content Management API および JSP
ファイルを使用しない。
3.4 カスタム・オーサリング・インターフェース
IBM Workplace Web Content Management オーサリング UI には多数の機能が組み込まれていますが、顧客
の要件によっては、カスタム・オーサリング・インターフェースが必要となることがあります。
Workplace Web Content Management v6 のオーサリング・テンプレートの機能拡張により、ほとんどのタイ
プのカスタム・オーサリング・インターフェースを使用する必要がなくなります。したがって、バージ
ョン 6 を初めて使用する場合は、カスタム・オーサリング・インターフェースを作成することを決定す
る前に、バージョン 6 で使用できる機能を確認する必要があります。
カスタム・オーサリング・インターフェースは主に Workplace Web Content Management API を使用して構
築されるため、この API のスキルと、Java® および WebSphere Portal のスキルが必要となります。
次の 2 種類のカスタム・オーサリング・インターフェースがあります。
• Workplace Web Content Management オーサリング・ポートレットを完全に置き換える代替インタ
ーフェース
• 公式 Workplace Web Content Management オーサリング・ポートレットのカスタム起動ページ
Dec 06
Page 25
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
1 番目のインターフェースは、Workplace Web Management オーサリング・ポートレットを完全に置き換
える別個のインターフェースであり、作成者が必要なオーサリング機能を完全に再構築します。2 番目の
インターフェースは、公式 Workplace Web Content Management オーサリング・ポートレットへのカスタ
ム・エントリー・ビューとして機能します。
3.4.1
Workplace Web Content Management オーサリング・ポートレット代替インターフェ
ース
前述したように、オーサリング・ポートレット代替インターフェースでは、作成者がオーサリング機能
を完全に再構築します。オーサリング・ポートレット代替インターフェースを使用する場合には通常膨
大な作業が必要となるため、本当にこのインターフェースが必要であるかどうかを慎重に検討してくだ
さい。可能な限り、オーサリング・ポートレット代替インターフェースは使用しないようにしてくださ
い。
また、オーサリング・ポートレット代替インターフェースは IBM サポートのサポート対象ではありませ
ん (作成者がサポートする必要があります)。ただし、使用されている Workplace Web Content Management
の公式 API は IBM サポートのサポート対象です。
サード・パーティーのアプリケーションと統合またはカスタム入力フィールドを使用して、コンテンツ
作成プロセス (公開プロセスではない) をカスタマイズする必要がある場合は、オーサリング・ポートレ
ット代替インターフェースが必要となることがあります。
Workplace Web Content Management オーサリング・ポートレット代替インターフェースの古い例として、
カスタム・テンプレート・ポートレット (CTP) があります。これは、ポートレット・カタログから現在
でも入手できます。バージョン 6 でオーサリング・テンプレートの機能が拡張されたため、この CTP の
合理化されたオーサリング処理を Workplace Web Content Management の公式オーサリング・ポートレット
でも実現できますが、オーサリング・ポートレット代替インターフェース作成の例としては今でも有効
なため、必要に応じて検討できます。
注:カスタム・テンプレート・ポートレット (CTP) はサポートされておらず、今後 CTP の機能拡張も予定
されていません。
3.4.2
カスタム起動ページ
カスタム起動ページによって、Workplace Web Content Management オーサリング・ポートレットの代替エ
ントリー・ビューを提供できます。
よく実行するアクション (特定のオーサリング・テンプレートを使用したコンテンツの作成、ユーザーの
承認を必要とする項目リストの表示 (各項目の承認/拒否の機能も提供する) など) へのショートカット・
リンクを表示するには、カスタム起動ページを作成します。
カスタム起動ページに機能を組み込む上で実際に制限となるのは、Workplace Web Content Management
API 機能の制約だけです。これ以外に、作成できる機能を制限するものはありません。
ユーザー・グループごとに異なる起動ページを表示するには、Workplace Web Content Management オーサ
リング・ポートレットのコピーを複数作成し、コピーごとに専用の起動ページを作成し、ポータル･レイ
アウトの「可視性ルール」を使用して各オーサリング・ポートレットでユーザーに対して表示する内容
を指定します。詳しくは、InfoCenter の『可視性ルール』を参照してください。
カスタム起動ページは単純かつ比較的静的にすることをお勧めします。起動ページが複雑だとレンダリ
ングに時間がかかり、何らかのカスタム・キャッシュ機能が必要になることがあります。
Dec 06
Page 26
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
詳しくは、InfoCenter の『カスタム起動ページの作成』を参照してください。
3.4.2.1 例 1:使用可能なすべてのオーサリング・テンプレートを使用したコンテンツの作成
この例では、現行ユーザーが使用できるすべてのオーサリング・テンプレートを使用してコンテンツを
作成するためのリンクを示す起動ページを作成します。
図 4. 使用可能なすべてのオーサリング・テンプレートを使用してコンテンツを作成するカスタム起動ペ
ージ
再現するには次の手順で操作します。
1.
<%@page
<%@page
<%@page
<%@page
新規 JSP ページを作成し、次に示すテキストをそのページにコピーします。
import="java.io.IOException"%>
import="com.ibm.workplace.wcm.api.*"%>
import="com.ibm.workplace.wcm.api.exceptions.*"%>
import="java.security.Principal"%>
<!-- An example of a Launch Page which shows a 'create content link' for each authoring template the
current user has access to -->
<%
// Get reference to current user
Principal currentUser = (Principal) request.getUserPrincipal();
%>
<b>Custom Launch Page for <%= currentUser.getName() %></b>
<%
// Get workspace for current user
Workspace theWorkspace = getCurrentUsersWorkspace(request, response, currentUser);
if (theWorkspace != null)
{
// Uncomment to specify which library to use
//theWorkspace.setCurrentDocumentLibrary(theWorkspace.getDocumentLibrary("<LIBRARY_NAME>"));
// Find all authoring templates that the current user has access to
DocumentIdIterator authoringTemplateIterator = theWorkspace.findByType(
DocumentTypes.AuthoringTemplate);
%>
<br><br><table>
<%
while (authoringTemplateIterator.hasNext())
{
DocumentId authoringTemplateId = (DocumentId)authoringTemplateIterator.next();
if (authoringTemplateId != null)
{
// Retrieve authoring template (to get display title)
Document currentAuthoringTemplate = theWorkspace.getById(authoringTemplateId);
if (currentAuthoringTemplate != null)
{
%>
<tr><td><a href="?wcmAuthoringAction=new&type=com.ibm.workplace.wcm.api.WCM_Content&atid=
<%= authoringTemplateId.toString() %>">Create a new Content Document using the
<%= currentAuthoringTemplate.getTitle() %> Authoring Template</a></td></tr>
<%
Dec 06
Page 27
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
}
}
}
%>
</table>
<%
}
%>
<br><a href="?wcmAuthoringAction=openmainview&view=contentbysitearea">Open Main Authoring UI</a>
<%!
/**
* Returns the current workspace for the user
*/
Workspace getCurrentUsersWorkspace(HttpServletRequest request, HttpServletResponse response,
Principal currentUser)
throws IOException
{
String workspaceSessionKey = currentUser.getName() + Workspace.WCM_WORKSPACE_KEY;
Workspace theWorkspace = (Workspace) request.getSession().getAttribute(workspaceSessionKey);
if (theWorkspace == null)
{
// theWorkspace wasn't in the session, create a new one and put it in the session
try
{
// Get workspace for current user
theWorkspace = WCM_API.getRepository().getWorkspace(currentUser);
// Store the workspace in the session to speed up next access
request.getSession().setAttribute(workspaceSessionKey, theWorkspace);
}
catch (ServiceNotAvailableException e)
{
response.getWriter().println("Error creating workspace, " + e.toString());
}
catch (OperationFailedException e)
{
response.getWriter().println("Error creating workspace, " + e.toString());
}
}
return theWorkspace;
}
%>
2.
3.
JSP ページをオーサリング・ポートレット (例: <WPS_ROOT>/installedApps/
WCM_Authoring_UI_PA_xxxxxxx.ear/PA_xxxxxxx.war/jsp/html) にコピーします。
新しい起動ページを使用するようにオーサリング・ポートレット構成を更新します。
3.4.2.2 例 2:カスタム承認インターフェース
この例では、現行ユーザーが承認する必要がある各コンテンツへのリンクを示す起動ページを作成しま
す。この起動ページでは承認/拒否機能も提供されます。
図 5. カスタム承認インターフェースを提供するカスタム起動ページ
Dec 06
Page 28
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
再現するには次の手順で操作します。
新規 JSP ページを作成し、次に示すテキストをそのページにコピーします。
1.
<%@page
<%@page
<%@page
<%@page
<!-<!-<!-<!-<!-<!-<!-<!--
import="java.io.IOException"%>
import="com.ibm.workplace.wcm.api.*"%>
import="com.ibm.workplace.wcm.api.exceptions.*"%>
import="java.security.Principal"%>
An example of a Launch Page which shows the list of content that the current user has to -->
approve, as well as the approval tools to perform the approval.
-->
For best performance:
-->
1. Only show this launch page to approvers
-->
2. Only give approvers 'read' access to items in the 'approve' stage.
-->
-->
NOTE: This sample only checks if the current user is directly an approver and not if
-->
he/she belongs to an approvers group
-->
<%
// Get reference to current user
Principal currentUser = (Principal) request.getUserPrincipal();
String currentUserName = currentUser.getName();
%>
<b>Custom Launch Page for <%= currentUser.getName() %></b>
<%
// Get workspace for current user
Workspace theWorkspace = getCurrentUsersWorkspace(request, response, currentUser);
if (theWorkspace != null)
{
// Indicates if the current user has items to approve
boolean hasItemsToApprove = false;
//Uncomment to specify which library to use
//theWorkspace.setCurrentDocumentLibrary(theWorkspace.getDocumentLibrary("<LIBRARY_NAME>"));
// Find all content that the current user has access to
DocumentIdIterator contentIterator = theWorkspace.findByType(DocumentTypes.Content);
%>
<br><br><table>
<%
while (contentIterator.hasNext())
{
DocumentId currentContentId = (DocumentId)contentIterator.next();
if (currentContentId.isDraft())
{
// Only process draft items
Content currentContent = (Content)theWorkspace.getById(currentContentId);
if (currentContent != null)
{
String currentContentApprovers[] = currentContent.getCurrentApprovers();
for(int i = 0; i < currentContentApprovers.length; i++)
{
if (currentUserName.equalsIgnoreCase(currentContentApprovers[i]))
{
if (!hasItemsToApprove)
{
%>
<tr><td align="left"><u>Documents pending approval:</u></td></tr>
<%
hasItemsToApprove = true;
}
// Current user is an approver of this item, should the approval tools
%>
<tr><td><%= displayApprovalTools(response, currentContent,
currentContentId) %></td></tr>
<%
break;
}
}
}
}
}
%>
</table>
<%
Dec 06
Page 29
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
if (!hasItemsToApprove)
{
%>
<i>No Items to approve</i><br>
<%
}
}
%>
<br><a href="?wcmAuthoringAction=openmainview&view=contentbysitearea">Open Main Authoring UI</a>
<%!
/**
* Displays the approval tools (Read, Approve and Decline)
*/
String displayApprovalTools(HttpServletResponse response, Content currentContent,
DocumentId currentContentId)
{
StringBuffer approvalTools = new StringBuffer();
String imagesDir = response.encodeURL("");
String idAsString = currentContentId.toString();
// Add Link to Open object in read form
approvalTools.append("<a href=\"?wcmAuthoringAction=read&docid=").append(idAsString);
approvalTools.append("\">").append(currentContentId.getName()).append("</a>");
// Add Approve Link
approvalTools.append("&nbsp;&nbsp;<a href=\"?wcmAuthoringAction=approve&docid=");
approvalTools.append(idAsString).append("\">");
approvalTools.append("<img style=\"vertical-align:middle;border=0\" src=\"");
approvalTools.append(imagesDir);
approvalTools.append("images/commands/Approve.gif\" alt=\"Approve\" border=\"0\"/></a>");
// Add Decline Link
approvalTools.append("&nbsp;&nbsp;<a href=\"?wcmAuthoringAction=decline&docid=");
approvalTools.append(idAsString).append("\">");
approvalTools.append("<img style=\"vertical-align:middle;border=0\" src=\"");
approvalTools.append(imagesDir);
approvalTools.append("images/commands/Decline.gif\" alt=\"Decline\" border=\"0\"/></a>");
return approvalTools.toString();
}
/**
* Returns the current workspace for the user
*/
Workspace getCurrentUsersWorkspace(HttpServletRequest request, HttpServletResponse response,
Principal currentUser)
throws IOException
{
String workspaceSessionKey = currentUser.getName() + Workspace.WCM_WORKSPACE_KEY;
Workspace theWorkspace = (Workspace) request.getSession().getAttribute(workspaceSessionKey);
if (theWorkspace == null)
{
// theWorkspace wasn't in the session, create a new one and put it in the session
try
{
// Get workspace for current user
theWorkspace = WCM_API.getRepository().getWorkspace(currentUser);
// Store the workspace in the session to speed up next
request.getSession().setAttribute(workspaceSessionKey,
}
catch (ServiceNotAvailableException e)
{
response.getWriter().println("Error creating workspace,
}
catch (OperationFailedException e)
{
response.getWriter().println("Error creating workspace,
}
access
theWorkspace);
" + e.toString());
" + e.toString());
}
return theWorkspace;
}
%>
2.
Dec 06
JSP ページをオーサリング・ポートレット (例: <WPS_ROOT>/installedApps/
WCM_Authoring_UI_PA_xxxxxxx.ear/PA_xxxxxxx.war/jsp/html) にコピーします。
Page 30
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
3.
新しい起動ページを使用するようにオーサリング・ポートレット構成を更新します。
注 1:パフォーマンスを最大限に引き出すには、次のようにします。
1. 承認者にのみこの起動ページを表示する。
2. 「承認」ステージの項目に対してのみ、承認者に「読み取り」アクセス権限を付与する。
注 2:この例では、現行ユーザーが直接に承認者であるかどうかのみを確認し、ユーザーが承認者グル
ープに属するかどうかは確認しません。
3.5 Web Content Management と Portal Document Manager の統合
Workplace Web Content Management 内ですべての画像とファイルを作成できますが、Portal Document
Manager の使用を検討したほうがよい場合もあります。
Workplace Web Content Management リソースと Portal Document Manager の機能の違いを次の表に示します。
この表の情報から、顧客固有の要件に基づいてどちらを使用するかを決定できます。
表 1. Workplace Web Content Management リソースと Portal Document Manager の機能比較
機能
バージョン管理のサポート
承認のサポート
API サポート
リッチ・テキスト・エディタ
ーでの作成操作のサポート
表示中の画像のサイズ変更
自動シンジケート
パスワード保護ファイルのサ
ポート
デスクトップ統合
表示中の変換の実行
アプリケーション内での編集
フォルダー内での編成
追加メタデータの関連付け
WCM リソース
はい
はい
はい (WCM API)
はい
Portal Document Manager (PDM)
はい
はい
はい (WCM API および PDM API*)
いいえ
はい
はい
いいえ
いいえ
いいえ
いいえ
いいえ
いいえ
いいえ
いいえ
いいえ
はい
はい
はい
はい
はい
* Portal Document Manager API は DOU に基づいて提供されます。必要な場合は IBM 営業担当員にご連絡
ください。
詳しくは、InfoCenter の『Web コンテンツでの文書の表示』を参照してください。
3.5.1
Portal Document Manager 文書のシンジケーションの処理
コンテンツのシンジケーションにより、さまざまなサーバー・クラスターで同一レベルのコンテンツを
維持できますが、Web Content Management Document Manager コンポーネントで参照される可能性のある
文書にはこれは適用されません。コンテンツのシンジケート前にこのような文書が移動または公開され
ていることを確認してください。
Portal Document Manager 文書が必ず最初に公開されるようにするための 1 つの方法を以下に示します。
1.
Dec 06
「外部コンポーネント」ライブラリーと呼ばれる個別のライブラリーにすべての Document
Manager コンポーネントを作成します。
Page 31
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
注:既に「有効な全項目」を使用してその他のコンポーネントが格納されているライ
ブラリーをシンジケートしている場合は、個別のライブラリーを使用する必要はあ
りません。
すべてのコンポーネントでワークフローを使用可能に設定していない場合は、使用可能に設
定します。
a. 詳しくは、InfoCenterの『Web コンテンツ・オーサリング・オプション』を参照して
ください。
コンポーネントを最初にドラフト状態で作成するように設定するワークフロー・ステージが
設定された Web Content Management ワークフローを使用します。
シンジケーター/サブスクライバーのペアを作成します。シンジケーターで「外部コンポーネ
ント」ライブラリーを選択します。
a. シンジケーターの項目ギャザラーとして「有効な全項目」を選択します。
InfoCenter の『文書ライブラリーをプロダクションに移すまでのステージング』を参照し、
このトピックに示されている方法で Portal Document Manager 文書を移動します。
Portal Document Manager 文書の移動/公開プロセスが完了したら、ドラフト・ステージの Web
Content Management Document Manager コンポーネントを承認します。
a.
2.
3.
4.
5.
6.
注:既存の Portal Document Manager 文書を変更し、その他の Web Content Management 関連の変更で
ステージングする必要がある場合は、Portal Document Manager 文書を新規に作成し、この新規
Portal Document Manager 文書を使用するように Web Content Management Document Manager コンポ
ーネントを更新することをお勧めします。コンポーネントの更新後に上記の手順で変更を展開し、
変更の公開後に古い Portal Document Manager 文書を削除します。
3.6 Web Content Management と Portal Personalization の統合
Workplace Web Content Management v6 では、Personalization ルールとの統合が拡張され、Web Conent
Management カスタム属性に対してルールが有効になりました。Personalization ルール･エディターの新し
い「ピッカー」により、ルール作成操作がさらに容易になりました。
Personalization ルールは、メニュー・コンポーネントと同様にコンテンツのリストを戻します。ただし、
ルールはメニュー・コンポーネントよりも柔軟性が高く、ビジネス・ユーザーが業務上の変更の必要に
応じてルールを変更および管理できます。ルールにより次の操作が可能になります。
• コンテンツのターゲットを動的プロファイルに設定する。
• 時間ベースのキャンペーン・コンテンツを配信する。
• クリック・ストリームまたはユーザー・アフィリエーションに基づいてコンテンツを推奨する。
• 外部ソース (リレーショナル表など) からコンテンツを表示する。
• カスタム検索ルールに基づき、オーサリング・テンプレート・フォームのエレメントを使用して
コンテンツを表示する。
一般に Web Content Management のメニューは単純な検索ルールに使用され、Personalization ルールはより
複雑な検索ルールに使用されます。ただし、上記のいずれかの操作を実行したい場合は、Web Content
Management のメニューではなく、Personalization ルールを使用します。
オーサリング・テンプレートのエレメントを使用してルールを作成する場合に使用できるコンポーネン
トは、テキスト、数値、および日付のみです。オーサリング・テンプレートのエレメントを使用したル
ールを多数使用しないようにしてください。これは、オーサリング・テンプレートのエレメントを使用
したルールは、標準メタデータ (キーワードやカテゴリーなど) を使用したルールよりもパフォーマンス
が低いためです。
Dec 06
Page 32
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
詳しくは、InfoCenter の『パーソナライズしたコンテンツの表示』とメインの『個別設定』を参照してく
ださい。
3.6.1
Portal の Personalization ルールのシンジケーション処理
コンテンツのシンジケーションにより、さまざまなサーバー・クラスターで同一レベルのコンテンツを
維持できますが、Web Content Management パーソナライゼーション・コンポーネントで参照される可能
性のあるルールにはこれは適用されません。コンテンツのシンジケート前にこのようなルールが移動ま
たは公開されていることを確認してください。
Portal の Personalization ルールが必ず最初に公開されるようにするための 1 つの方法を以下に示します。
1.
2.
3.
4.
5.
6.
「外部コンポーネント」ライブラリーと呼ばれる個別のライブラリーにすべての
Personalization コンポーネントを作成します。
a. 注:すでに「有効な全項目」を使用してその他のコンポーネントが格納されているラ
イブラリーをシンジケートしている場合は、個別のライブラリーを使用する必要は
ありません。
すべてのコンポーネントでワークフローを使用可能に設定していない場合は、使用可能に設
定します。
a. 詳しくは、InfoCenterの『Web コンテンツ・オーサリング・オプション』を参照して
ください。
コンポーネントを最初にドラフト状態で作成するように設定するワークフロー・ステージが
設定された Web Content Management ワークフローを使用します。
シンジケーター/サブスクライバーのペアを作成します。シンジケーターで「外部コンポーネ
ント」ライブラリーを選択します。
a. シンジケーターの項目ギャザラーとして「有効な全項目」を選択します。
InfoCenter の『Personalization ルールを実動に移動するステージング』を参照し、このトピッ
クに説明されている方法で Portal Personalization ルールを移動します。
Portal Personalization 文書の移動/公開プロセスが完了したら、ドラフト・ステージの Web
Content Management Personalization コンポーネントを承認します。
注:既存の Portal Personalization ルールを変更し、その他の Web Content Management 関連の変更でス
テージングする必要がある場合は、Portal Personalization ルールを新規に作成し、この新規 Portal
Personalization ルールを使用するように Web Content Management Personalization コンポーネントを
更新することをお勧めします。コンポーネントの更新後に上記の手順で変更を展開し、変更の公開
後に古い Portal Personalization ルールを削除します。
3.6.2
例:カスタム検索ルールに基づくコンテンツ・リンク・リストの表示
この例では、カスタム検索ルールに基づいて Web Content Management コンテンツへのリンクのリストを
表示する方法を説明します。
Dec 06
Page 33
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
1.
カスタム検索パラメーターを使用して Portal Personalization ルールを作成します。
2. このルールからコンテンツを表示する Personalization コンポーネントを作成します。
-- Design for each menu search result
<li><Placeholder tag="namelinkhref" start="" end=""/></li>
3.
既存のページに Personalization コンポーネントを追加するか、または Personalization コンポーネント
を直接表示するように Web コンテンツ・ビューアー・ポートレットを構成します。
Dec 06
Page 34
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
デプロイ
4
詳しくは InfoCenter の『 実動に向けた Web コンテンツのステージング』
詳しくは InfoCenter の『 構成シナリオ』
4.1 行うべき作業
1.
初めてシンジケートを実行した場合、または以降の変更操作の後に、ライブラリー・アクセス制御設
定を手動で設定する。
•
•
2.
実動 LDAP のユーザーを確認する。
•
3.
•
実稼働環境ですべてのオブジェクトが必要である場合 (実稼働環境でコンテンツを直接編集する
循環型シンジケーションのシナリオなど) を除き、すべての項目をシンジケートする必要はあり
ません。
必要なライブラリーをすべてシンジケートする。
•
6.
これにより、Workplace Web Content Management インスタンスで、後で別のサーバーにシンジケ
ートするためにオブジェクトの変更を追跡するモニター・タスクが実行されなくなります。
subscriber.only 設定を変更したら、サーバーの再始動前に必ず EventLog
(<WPS_ROOT>\config\WPSConfig wcm-reset-event-log) もリセットしてください。
実動サーバーへのシンジケートでは運用中の項目のみをシンジケートする。
•
5.
実動 LDAP にテスト・ユーザーが残っていないことを確認してください。テスト・ユーザーが残
っていると、そのユーザーを使用してシステムをハッキングされる恐れがあります。これには、
一般的あるいは推測しやすいユーザーとパスワードの組み合わせ (Mickey Mouse / password、
wpsadmin / wpsadmin、wpsadmin / password など) が含まれます
WCMConfigServices.properties で、リポジトリーを他のサーバーにシンジケートしないすべての
Workplace Web Content Management インスタンスの subscriber.only プロパティーを「true」に設定する。
•
4.
ライブラリー・アクセス権限はシンジケートされません。ライブラリーがサブスクライバー上に
ない場合は、シンジケート中に作成されますが、この新しいライブラリーにはアクセス制御設定
が指定されません。
レンダリング・サーバー上では異なるアクセス制御設定 (すべてのユーザーに対しコンテンツの
入力を禁止する設定など) を指定することがあります。
ライブラリー A のコンテンツがライブラリー B のコンポーネントを参照している場合は、ライ
ブラリー A と B の両方を 1 つのシンジケーターに含める必要があります。
サブスクライバーが多数の場合は、段階式シンジケーション構造を作成する。
•
Dec 06
1 つのサーバーから多数 ( 6 台以上) のサブスクライバーへシンジケートする代わりに、1 番目の
シンジケーターが 2 つのサーバーにシンジケートし、これらのサーバーがさらに他のサーバーに
シンジケートする段階構造を作成します。これにより、シンジケーター・サーバーにかかる負荷
が減るため、パフォーマンスが向上します。
Page 35
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
7.
非クラスター・メンバー間のシンジケーションでホスト名を使用することを検討する。
•
8.
クラスター間のシンジケートでは、シンジケーターとサブスクライバーのダイアログで各クラスター
の Web サーバー・アドレスを使用し、適切なフェールオーバーが発生するようにする。
•
•
9.
サブスクライバー/シンジケーター・ダイアログでは IP アドレスを使用するようマニュアルに記
載されていますが、トラフィックをリダイレクトする目的でホスト別名を追加できるため、ホス
ト名を使用すると便利な場合があります。ただし、使用する名前が、構成ファイルで使用されて
いる名前に一致することを確認してください。
変更のシンジケート中にサブスクライバー・ノードがダウンすると、そのシンジケートは失敗し
たと見なされ、次のサブスクライバー・ノードによりシンジケートが再試行されます。
シンジケート中にシンジケーター・ノードがダウンすると、次に使用可能なシンジケーター・ノ
ードを使用してシンジケートが続行されます。
複数の環境で項目を編集しない。
•
シンジケーションでは項目をオーバーライドすべきかどうかを最終変更日付から判断し、1 つの
項目に複数の変更を結合することができないため、特定の項目を複数の環境で編集すると、最後
に行われた変更が有効になり、これより前に行われた変更が失われます。
4.2 行うべきでない作業
1. ローカルの Workplace Web Content Management サーバーと通信するときにリモート・レンダリング・
ポートレットを使用しない。
•
リモート・レンダリング・ポートレットは、URL 接続を使用して Workplace Web Content
Management サーバーと通信します。URL 接続を使用してローカル・サーバーと通信すると、元
の要求を処理するために追加の要求スレッドが必要となります。負荷が高い状態で、ポートレッ
トに「入ってくる」要求の処理にすべての要求スレッドが使用される場合、ポートレットに入る
各要求が Workplace Web Content Management への「バックエンド」要求を確立できないため、サ
ーバーがハングします。
2. 実稼働環境に Cloudscape を使用しない。
•
Cloudscape は、デモや非常に小規模なデプロイでのみ使用が推奨される軽量データベース・サー
バーであり、IBM DB2© などのエンタープライズ・データベース製品ほど高性能ではありません。
3. 同名のライブラリーが含まれているサーバーへのライブラリーのシンジケートをセットアップしない。
•
このようにセットアップするとエラーが発生します。
4. 実動サーバーではシンジケーターを使用可能にしない。
•
5.
パフォーマンス上の理由から、実動サーバー上にシンジケーターを作成しないことをお勧めしま
す。
双方向シンジケートの実行時に、「有効な項目」スコープを使用して Web Content Management ライ
ブラリーをシンジケートするようにシンジケーターを構成しない。
Dec 06
Page 36
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
•
•
双方向シンジケーションでは、両方のシンジケーターが「すべての項目」スコープを使用してす
べてのライブラリーをシンジケートする必要があります。これ以外の方法でのシンジケーション
は正しく実行されません。
例えば次のシナリオでは、両方のサーバーですべてのライブラリーに対して「すべての項目」を
使用しないと失敗します。
o server1 のドラフト文書を「すべての項目」シンジケーションにより server2 に送信する。
ドラフト文書が server2 で公開される。server2 の公開文書を「有効な項目」シンジケーシ
ョンで server1 に送信しようとすると、既存のドラフトが最初に削除されないため、この
送信操作は失敗する。
4.3 配信/レンダリング環境
4.3.1
リモート・レンダリング
図 6.リモート・レンダリングの構成の例
•
Dec 06
リモート・レンダリングで API を使用できますが、クラスター B の Workplace Web Content
Management サーバーに JSP が配置されている必要があります。
Page 37
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
•
PDM 統合を使用する場合は、PDM 文書がクラスター B の Workplace Web Content Management サ
ーバーにあることを確認してください。
•
PZN 統合を使用する場合は、PZN ルールがクラスター B の Workplace Web Content Management
サーバーにあることを確認してください。
4.3.1.1 5.1.0.x Portal での V6.0 リモート・レンダリング・ポートレット
v6.0 リモート・レンダリング・ポートレットは Portal 5.1.0.x インスタンスで追加サポートされています。
配信サーバーで実行されている Portal アプリケーションを、Portal v6.0 対応のために再作成およびテスト
する必要がある場合、これは重要です。Workplace Web Content Management オーサリング・サーバーを
6.0 にアップグレードしてから、5.1 配信サーバーで v6.0 リモート・レンダリング・ポートレットを使用
する場合、配信環境全体を直ちにアップグレードする必要はありません。
注:5.1.0.x より古いバージョンの Portal はサポートされていません。また、このような古い Portal は JRE
レベルの要件が異なるため機能しません。
4.3.2
ローカル・レンダリング
図 7.ローカル・レンダリングの構成の例
4.3.3
リモート・レンダリングとローカル・レンダリングの使い分け
表 2. リモート・レンダリングとローカル・レンダリングの使い分け
リモート
量が少ない
必要な Workplace Web Content
Management ライセンスが少な
い
主な検討事項
大量の要求
コスト
ローカル
スループットが高い
必要な Workplace Web Content
Management ライセンスが多い
リモート
はい (リダイレクションをセッ
二次的な検討事項
Workplace Web Content
ローカル
いいえ
Dec 06
Page 38
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
トアップし、完全修飾 URL が
無効になっている場合)
低い
はい
複雑度が高い
ネットワーク・パスが長い
CPU 要件のため低い
必要
Management をファイアウォー
ルで保護できるかどうか
配信 Portal ノードでの
Workplace Web Content
Management CPU アクティビテ
ィー
WebSphere Portal とは独立して
Workplace Web Content
Management をアップグレード
する
複雑さ/管理
ネットワーク・トラフィック
ボックスあたりのハードウェ
アの要件
チューニング
高い
いいえ
複雑度が低い
ネットワーク・アクティビテ
ィーが少ない
高い性能が求められる
必要
4.4 オーサリング環境
4.4.1
一般的なオーサリング環境
図 8. 一般的なオーサリング環境の例
•
Dec 06
オーサリング環境ではクラスターの使用は任意ですが、クラスターを使用するとフェールオーバ
ー機能が実現し (2 次ノードがフェールオーバー用にのみ構成されている場合) 、パフォーマンス
が向上します (2 次ノードがロード・バランシングとフェールオーバーに対応するよう構成されて
いる場合)。
Page 39
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
4.4.2
その他のオーサリングの概念
4.4.2.1 コンテンツ編集と設計編集の分離およびオプションの設計レビュー
コンテンツの作成とは別に設計編集環境または設計レビュー (あるいはこの両方) が必要な場合は、次に
示すオーサリング・サーバーの分割を検討する必要があります。
図 9. 個別のコンテンツ編集サーバーと設計編集サーバーを使用する構成の例
1.
2.
3.
4.
5.
6.
コンテンツ、サイト、サイト・エリア、および画像/ファイル・リソース (オプション) の追加、
変更、削除は、「コンテンツ編集」サーバーの「コンテンツ・ライブラリー」でコンテンツ作成
者が行います。
設計コンポーネント (ページ設計、カテゴリー、ワークフロー定義、テンプレート、追加画像/フ
ァイル・リソース) の追加、変更、削除は、「設計編集」サーバーの「設計ライブラリー」で設
計者が行います。
設計レビュー:
o すべての設計コンポーネントを 3 つのステージからなるワークフローに配置する必要が
あります。
o 設計レビューアーは、(「テスト・コンテンツ・ライブラリー」のテスト・データに対し
て) 設計コンポーネントを「承認」ステージでプリビューし、レビュー完了後にこれらの
コンポーネントを最終ステージに移動します。
すべての有効な設計コンポーネントは「コンテンツ編集サーバー」にシンジケートされます。
設計者はコンテンツ編集サーバーでプレゼンテーション・テンプレート・マッピングとオーサリ
ング・テンプレート・マッピングを必要に応じて更新します。
最後に、すべての有効な設計コンポーネントとコンテンツがステージング/配信環境にシンジケー
トされます。
注 1:設計編集サーバーのオーサリング UI をロックし、コンテンツ作成者がオーサリング UI にアクセス
できないようにしてください。
注 2:共通 LDAP サーバーを前提にしています。
Dec 06
Page 40
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
4.4.2.2 WebSphere Portal のコンテキストにおけるドラフト・コンテンツの拡張プリビュー
Workplace Web Content Management の導入直後の状態では、WebSphere Portal サイトのドラフト・コンテ
ンツをプリビューできます。ただし、メニュー、ナビゲーター、JSP の中からはドラフト・コンテンツを
プリビューできません。また、コンテンツの公開セキュリティー設定を検証できません。この機能が必
要な場合は、以下の図に示されているアーキテクチャーの手法を使用してください。
図 10. プリビュー・サーバーを使用した構成の例
•
•
•
•
•
Dec 06
上記の図は、3 ステージ・ワークフロー (ドラフト、承認、公開) に基づいています。
オーサリング・サーバーとレビュー・サーバーには、静的ポータル・サイトのコピーがあります。
o オーサリング・サーバーのプリビュー・ポートレットは、静的ポータル・サイトの周囲
にドラフト・コンテンツを表示するよう構成されています。
o レビュー・サーバーには、静的ポータル・サイトの周囲に公開コンテンツを表示するた
めのローカル・レンダリング・ポートレットがデプロイされています。
作成者は、コンテンツ/オブジェクトの承認の準備ができたら、まず文書をオーサリング・サーバ
ーの承認ステージに移動します。
簡単なレビューのみが必要な場合 (テキスト・コンテンツのみ):
o オーサリング・サーバーのレビューアーは、「承認」ステージ内で項目を見つけると、
オーサリング・サーバーで使用可能な「プリビュー」ポートレットでこれらの項目をプ
リビューします。
o レビューアーが変更に満足した場合は、オーサリング・サーバーで項目を承認します。
o レビューアーが変更に満足しない場合は、オーサリング・サーバーで各項目の「辞退」
ボタンをクリックします。
ƒ 注:コンテンツ/オブジェクトに 2 ステージ・ワークフローが含まれている場合、
「辞退」ボタンをクリックする代わりにワークフローを再び開始する必要があり
ます。
拡張レビューが必要な場合 (メニュー、ナビゲーター、または JSP でのドラフト・コンテンツの
プレビュー、またはコンテンツの公開セキュリティー設定の検証を行う場合):
Page 41
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
o
o
o
レビュー・サーバーのレビューアーは、「承認」ステージで項目を見つけると、「承
認」ボタンをクリックして項目を有効にします。承認サーバーで項目が「有効」になっ
たら、さらに大きな Portal サイトのコンテキストでこれらの項目をレビューできます。
レビューアーが変更に満足した場合は、オーサリング・サーバーで項目を再承認します。
レビューアーが変更に満足しない場合は、オーサリング・サーバーで各項目の「辞退」
ボタンをクリックします。
ƒ 注:コンテンツ/オブジェクトに 2 ステージ・ワークフローが含まれている場合、
「辞退」ボタンをクリックする代わりにワークフローを再び開始する必要があり
ます。
4.4.2.3 地域分散オーサリング
社内のコンテンツ作成者が物理的に離れた地域に分散しており、各部門が中央の単一サーバーで作業で
きない場合は、次に示す分散オーサリング手法を検討してください。
図 11. 分散オーサリング構成の例
•
•
Dec 06
「共通設計編集」サーバー上に分類ツリーと共通コンポーネントを作成します。
部門別サーバーの「部門作成者/設計者」の作業データと、各サーバーのオーサリング・ポートレ
ットをロックし、他の部門からアクセスできないようにします。
Page 42
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
部門作成者が、オーサリング・ポートレットの「コンテンツ管理」セクション以外を参
照できないようにする必要があります。
o 部門設計者が、「カテゴリー管理」セクションを参照できないようにする必要がありま
す。
各部門サーバーからデータを再シンジケートしなければならない状況を回避するため、エンター
プライズ・サーバーのデータを任意でバックアップできます。
共通 LDAP サーバーを前提にしています。
o
•
•
サイト・フレームワークの開発方法
地理的に分散したオーサリング環境でサイト・フレームワークを開発するには、さまざまな方法があり
ます。
•
•
部門ごとに個別のサイトを使用する。
o この方法では、各部門サーバー上の設計者が部門専用のサイト・フレームワークを作成
し、維持します。
o この場合、部門ごとに個別の Workplace Web Content Management ライブラリーを作成し、
共通設計エレメント用に Workplace Web Content Management ライブラリーを別途作成す
る方法をお勧めします。
すべての部門が 1 つの共有サイトを使用する。
o この方法では「共通設計編集」サーバー上の設計者が、最上位オブジェクトと、部門ご
とに 2 つのレベルのサイト・エリアを作成します。例:
o
o
o
「共通設計編集」サーバーの設計者のみが最上位サイトと各部門のルート・サイト・エ
リアへの編集アクセス権限を持ち、部門設計者のみが第 2 レベル (「メイン」など) のサ
イト・エリアを編集できるようにセキュリティーが設定されます。
ƒ 例えば、共通設計者が各部門の第 2 レベルのサイト・エリアを作成してから、各
サイト・エリアを編集できるユーザーのリストから設計者自身を削除します。
「部門」サーバーで作成された Web Content Management コンテンツは、各部門のルー
ト・サイト・エリアではなく、第 2 レベル以下のサイト・エリアに配置されます。
「共通設計編集」サーバー上の設計者により作成されたページ設計とテンプレートは、
最上位サイトまたは各部門の「ルート」サイト・エリアのいずれかに関連付けられます。
4.5 クラスタリング
クラスタリングは、ロード・バランシング (要求フェールオーバーなど) および以下の追加機能の組み合
わせとして考慮できます。
•
•
Dec 06
セッション・パーシスタンス (セッション・フェールオーバー)
クラスター内の全ノードに対する単一リポジトリー (データ・フェールオーバーおよび構成の簡
易化)
Page 43
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
•
クラスター内の全ノードに対する単一管理インターフェース (構成の簡易化)
Workplace Web Content Management v6 以降では、レンダリング・サーバーとオーサリング・サーバーの両
方で完全なクラスタリングがサポートされています。
ただし、オーサリング・ノードがダウンすると、項目の未保存の変更が失われる点に注意してください。
変更のシンジケート中にレンダリング・ノードがダウンすると、そのシンジケートは失敗したと見なさ
れ、次のレンダリング・ノードによりシンジケートが再試行されます。シンジケート中にオーサリン
グ・ノードがダウンすると、次に使用可能なオーサリング・ノードを使用してシンジケートが続行され
ます。
クラスタリングの構成方法など詳細については、Portal InfoCenter のクラスタリングに関する、 InfoCenter
の『トピック』を参照してください。
4.6 シンジケーション
4.6.1
一般的なベスト・プラクティス
前述の『デプロイ』の『行うべき作業』と『デプロイ』の『行うべきでない作業』を参照してください。
4.6.2
複数のライブラリーを使用する場合のシンジケーション
Workplace Web Content Management v6 で複数のライブラリーを使用し、あるライブラリーが別のライブラ
リーを参照する場合は、この両方のライブラリーを 1 つのシンジケーターに含める必要があります。こ
れは、参照の整合性の問題を避けるためです。
4.6.3
シンジケート実行頻度の変更
シンジケート実行頻度は、<WPS_ROOT>\wcm\shared\app\config\wcmservices\WCMConfigServices.properties
の「ItemChangedTaskDelay」の設定により制御されます。以前のバージョンの Workplace Web Content
Management とは異なり、この設定値を大きな値に変更しても、シンジケートが実行されない状況は発生
しません。
シンジケートはシンジケーターとサブスクライバーの両方のパフォーマンスに影響するため、頻繁にシ
ンジケートを実行する必要のないサーバーでは、デフォルトのシンジケート実行頻度である 30 秒を増や
すことをお勧めします。例えばテスト/ステージング・サーバーの場合、10 ～ 20 分またはこれよりも大
きい値が適切です。
シンジケートを手動で実行する必要がある場合は、
<WPS_ROOT>\wcm\shared\app\config\wcmservices\WCMConfigServices.properties の
「connect.moduleconfig.syndication.inittasks」を false に設定します。手動モードでシンジケートを開始する
唯一の方法は、シンジケーター管理ポートレットとサブスクライバー管理ポートレットから手動で開始
する方法です。手動シンジケートはサーバー全体レベルでのみ設定できる点に注意してください。
4.6.4
•
Dec 06
制約事項
シンジケート実行頻度はサーバー単位でのみ設定できます (シンジケーターごとに設定すること
はできません)。
o また、手動シンジケートはサーバー単位でのみ使用可能に設定できます (シンジケーター
ごとに使用可能に設定することはできません)。
Page 44
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
•
•
•
•
•
•
ソース・ライブラリーと同名の既存のライブラリーにはシンジケートできません。各サーバーに
デフォルトで「Web Content」ライブラリーが作成されるため、特にこの制限に注意してください。
これらのライブラリーは同じ名前ですが、UUID が異なります。つまり、サーバー間で「Web
Content」ライブラリーをシンジケートするには、サブスクライバー・サーバーでライブラリーが
削除または名前変更されている必要があります。
検索コレクションはシンジケートされません。つまり、シンジケート実行前に両方のサーバーで
検索コレクションを作成する必要があります。
シンジケートする項目が参照する別の項目がサブスクライバー・マシンで削除されている (ただ
しパージされていない) 場合は、項目のシンジケートは失敗します。
o 解決策:削除をパージしてサブスクリプションを再作成します。これにより、削除された
項目が再送信されます。
シンジケートする項目と同じ名前および同じサイト・パスの別の項目がサブスクライバー・マシ
ンで作成されてる場合は、項目をシンジケートできません (これらの項目の ID は異なります)。
o 解決策:サブスクライバー・マシンで重複する項目を削除するか、または名前を変更しま
す。
Workplace Web Content Management JSP コンポーネントにより使用される JSP ファイルはシンジ
ケートされないため、必ずこれらの JSP ファイルをすべてのサブスクライバー・サーバーに手動
でコピーするようにしてください。
双方向シンジケーションを実行するには、シンジケーターが「全ての項目」スコープを使用して
すべてのライブラリーをシンジケートする必要があります。これ以外の方法でのシンジケートは
適切に機能しません。
4.7 複数環境にわたる複数 LDAP サーバー
すべての Portal/ Workplace Web Content Management サーバーがアクセスする 1 つの LDAP サーバーを準備
しておくことが推奨されますが、この単一 LDAP サーバーの作業負荷が高くなる場合や、顧客のセキュ
リティー・ポリシーによって複数サーバーの導入が指定されている場合は、複数の LDAP サーバーを導
入する必要があります。
デフォルトでは、セキュリティーが有効に設定されている場合に各 Portal インスタンスが各 LDAP ユー
ザーに対し一意のメンバー ID (WMM ID) を割り当てます。
Web Content Management は、識別名と WMM ID (コンテンツが作成されたサーバーの WMM ID) の両方
を使用してユーザーを参照するため、複数の LDAP を使用する際には十分に注意してください。そうし
ないと、サーバー間でのデータのシンジケート時に Web Content Management 認証が機能しないことがあ
ります。
Web Content Management セキュリティーが失敗する状況のシナリオを以下に示します。
•
•
複数の Web Content Management インスタンスが 2 つの異なる LDAP サーバーを指し示している
場合 (これらの LDAP サーバー内に同名のユーザーが含まれていたとしても) 。
セキュリティーが有効になっていない複数の Web Content Management インスタンスが相互にシン
ジケートしようとする場合。
WebSphere Portal では上記の 2 つの構成は予期されておらず、またサポートされていない点に注意してく
ださい。前述したように、Portal はすべてのインスタンスにおいて 1 つの中央 LDAP リポジトリーが共有
されることを前提としています。ただし、このような問題を緩和または改善する解決策がいくつかあり
ます。
実施可能な解決策:
Dec 06
Page 45
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
1.
Web Content Management がシンケートを実行するすべての環境で同一の LDAP を使用する。
2.
WMM 外部 ID を固有の LDAP 属性 (各ユーザー・レコードのユーザーの識別名またはその他の固
有属性) に再マップする。
•
3.
詳しくは、Portal InfoCenter の Member Manager での外部 ID のマッピングに関する InfoCenter
の『トピック』を参照してください。
Web Content Management/WPS 仮想グループ (「全ユーザー」、「匿名」、「すべての認証ポータ
ル・ユーザー」など) を使用してサーバーのユーザー・アクセス権限をセットアップする。
•
つまり、このエントリーは WMM / LDAP に格納されていないため、すべての環境において、
[全ユーザー] グループおよび「匿名」アクセス権限、またはその他の仮想グループを使用し
てオブジェクトへのアクセス権限を設定できます。したがって、1 つの Web Content
Management インスタンスでユーザー A、B、および C が開発作業を行っているが、2 つ目の
インスタンスのオブジェクトへのアクセス権限がない場合は、仮想グループにアクセス権限
を付与することで、セキュリティーを維持できます。この解決策を実施してもログに警告が
多数出力されるため、Web Content Management メンバー修正ツールを実行してデータをクリ
ーンアップするのがよいでしょう。この解決策の制限は、この解決策が仮想ユーザー/グルー
プでのみ機能することです。これは、仮想ユーザー/グループが WMM に格納されていないた
めです。WMM/LDAP に格納されているユーザー/グループ定義は機能しません。
4.
すべてのユーザー/グループとその固有 ID が、Web Content Management シンジケーション・シナ
リオで使用されるすべての LDAP サーバーで同期化されていることを確認してください。
• これを確認するには、LDAP ldif ファイルをエクスポートするか、またはサーバー間で何らか
の LDAP レプリケーションを維持するか、あるいはこの両方を実行します。
5.
サブスクライバー・サーバーで Web Content Management メンバー・フィクサーを定期的またはシ
ンジケーション・イベントの後に毎回実行します。
•
Dec 06
この方法では手動プロセスが必要になるため、推奨されません。
Page 46
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
パフォーマンス
5
5.1 行うべき作業
5.1.1
1.
2.
3.
4.
5.
6.
7.
8.
Dec 06
パフォーマンスに関する一般的な検討事項
次に示す iFix をインストールする (最新バージョンの Portal Update Installer を使用)
• Workplace Web Content Management 6.0.0.0:
• PK30057:Required Cumulative iFix 1 for Web Content Management 6.0
• PK30516:WCM performance enhancement for Site Area save
• PK31598:The Menu Cache is being cleared when any item is saved.
• PK31802:Retrieving Site or Site Area children via the WCM API can lead to OOM errors
• PK31933:Menu Cmpnt does not display with security enabled when using categories.
• PK32016:Performance improvement to WCM's base cache implementation
• PK32455:Performance improvement to WCM's resource cache implementation
• PK32457:Allow PrincipalInformations to be cached
• PK32538:Allow PrincipalInformations to be cached (for Admin Portlet)
• PK32541:Allow PrincipalInformations to be cached (for Local Rendering Portlet)
• PK32544:Allow PrincipalInformations to be cached (for Remote Rendering Portlet)
• PK32630:Controllables are not being retrieved from controllable cache
• PK32856:Memory leak after manipulating WCM page for several hours
• PK32944:Allow Versioning to be disabled
• PK32949:Allow Versioning to be disabled (for Authoring Portlet)
• PK33025:Avoid logging into JCR where possible
• PK33026:Library Cmpnts are not lazy loaded for rendering in Local Rendering Portlet
• PK33051:Memory leak after manipulating WCM page for several hours (for Local Rendering
Portlet)
• PK33578:Optimisation to Menu Cache processing for draft and expired items
• Workplace Web Content Management 6.0.0.1:
• PK35618:Required Cumulative iFix 1 for Web Content Management 6.0.0.1
JCR データベース (Workplace Web Content Management データが格納されているデータベース) が
適切に調整されていることを確認する。
• 詳しくは本文書の『データベース・チューニング』を参照してください。
LDAP サーバーが適切に調整されていることを確認する。
• 詳しくは本文書の『LDAP のチューニング』を参照してください。
InfoCenter の『チューニング』を読む。
Portal サーバーが適切に調整されていることを確認する。
• 詳しくは「Portal Tuning Guide (US 公式ガイド)」を参照してください
Workplace Web Content Management アプリケーションが適切に調整されていることを確認する。
• 詳しくは「Workplace Web Content Management Tuning Guide (US 公式ガイド)」を参照してく
ださい。
Portal ログに出力されているすべてのエラー (セキュリティー、コンポーネントの欠落など) を積
極的に解決する。
WCMConfigServices.properties で、リポジトリーを他のサーバーにシンジケートしないすべての
Workplace Web Content Management インスタンスの subscriber.only プロパティーを「true」に設定
する。
• これにより、Workplace Web Content Management インスタンスで、後で別のサーバーにシン
ジケートするためにオブジェクトの変更を追跡するモニター・タスクが実行されなくなりま
す。
Page 47
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
•
9.
10.
11.
12.
13.
14.
5.1.2
1.
2.
5.1.3
1.
subscriber.only 設定を変更したら、サーバーの再始動前に必ず EventLog
(<WPS_ROOT>\config\WPSConfig wcm-reset-event-log) もリセットしてください。
1 つのシンジケーターに多数のサブスクライバーをリンクしないようにする。
ホームページのサイズを 80KB 以下に抑える。
すべてのメニュー・コンポーネントが最適化されていることを確認する。
• 詳しくは、本文書『メニュー・コンポーネントの最適化』を参照してください。
すべてのナビゲーター・コンポーネントが最適化されていることを確認する。
• 詳しくは本文書『ナビゲーター・コンポーネントの最適化』を参照してください。
すべての Portal Personalization ルールが最適化されていることを確認する。
• 詳しくは、本文書『Portal Personalization ルールの最適化』を参照してください。
オーサリング・サーバーとレンダリング・サーバーの両方ですべての項目のバージョン管理機能
を無効にすることを検討する。
• 項目の古いバージョンを保存する必要がない場合は、この機能を無効にすると、保存とシン
ジケーションのパフォーマンスが向上します。
レンダリングのパフォーマンスに関するその他の検討事項
静的コンテンツのレンダリング速度を向上できる可能性がある事前レンダリング、サーブレッ
ト・キャッシュ (Dynacache など)、または Web Content Management 基本キャッシュを使用する。
o ポートレット・ベースのレンダリングでは基本キャッシュを使用できないため、代わり
に Web Content Management 拡張キャッシュ (SITE に設定) を使用します (結果は同じです)。
o キャッシュについての詳細は本文書『Caching』を参照してください。
Portal Search を使用する場合は、クローラーとインデクサーに専用サーバーを使用することを検
討する。
オーサリングのパフォーマンスに関するその他の検討事項
ページに多くのメニュー/ナビゲーターを組み込むことが避けられない場合は、新規コンテンツが
追加されたことを確認するためにこのようなページを表示する操作を行わないでください。代わ
りに、最大で 1 ～ 2 つのメニュー/ナビゲーターを組み込んだダミー・ページを使用してください。
5.2 行うべきでない作業
5.2.1
1.
2.
3.
4.
5.2.2
1.
2.
パフォーマンスに関する一般的な検討事項
実稼働環境では Cloudscape を使用しない。
必要でない限り「すべての項目」をシンジケートしない。代わりに「有効な全項目」を使用する。
パーソナライゼーションの目的でセキュリティーを使用しない。
１つの大きな画像を表示せずに、複数の小さな画像に分割する。
レンダリングのパフォーマンスに関するその他の検討事項
キャッシュ可能な項目とキャッシュ不可能な項目を １ つのページに混在させない。
パーソナライズ・コンテンツをキャッシュしない。
5.3 データベース・チューニング
•
•
•
Dec 06
専用サーバーを使用する。
データベース・サーバーの CPU アクティビティーをモニターし、必要に応じてハードウェアを
追加する。
データベース製品の資料に従ってデータベース・チューニングを行う。
Page 48
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
•
•
•
Dec 06
複数のスキーマが含まれる 1 つのデータベースを使用せずに、ポータル・ドメイン (WMM、
WPS、JCR など) をそれぞれ専用のデータベースに分割する。
時間の経過に伴うデータベースの使用状況をモニターし、顧客の使用パターンに基づいてパフォ
ーマンスを改善するためデータベース・インデックスを追加/削除する。
DB2:
o 「Official Portal Tuning Guide (US 公式ガイド)」の DB2 チューニングのセクションを参照
する。
o DB2 照会レベルを 2 に変更することを検討する (JCR データベース):
ƒ 使用可能にする方法:
• DB2 コマンド・プロンプトから次のコマンドを入力します。
o DB2 CONNECT TO <jcrdb_name> USER <db2admin_id> USING
<db2admin_pwd>
o DB2 UPDATE DB CFG FOR <jcrdb_name> USING
DFT_QUERYOPT 2
o DB2 DISCONNECT <dbname>
• DB2 サービスを再始動します。
• Portal Server を再始動します。
ƒ 使用不可にする方法:
• DB2 コマンド・プロンプトから次のコマンドを入力します。
o DB2 CONNECT TO <jcrdb_name> USER <db2admin_id> USING
<db2admin_pwd>
o DB2 UPDATE DB CFG FOR <jcrdb_name> USING
DFT_QUERYOPT 5
o DB2 DISCONNECT <dbname>
• DB2 サービスを再始動します。
• Portal Server を再始動します。
o バイナリー照合の使用を検討する。
ƒ 影響:
• バイナリー照合を使用すると、Web Content Management オーサリング UI、
メニュー、および Personalisation ルールの順序設定で大文字と小文字が
区別され、アクセント記号や英語以外の文字が含まれている単語の順序
が誤って設定されます。
• この機能を使用可能/使用不可にする操作は難しく、時間がかかります。
ƒ 使用可能にする方法:
• 別のマシンに新しいバージョンの Portal をインストールします。
• DB2 ストレージに切り替える前に、
<WPS_ROOT>PortalServer\config\templates\db\db2\createdb2.bat ファイルを
次のように編集します。
o 「CREATE DB..」行を最初のインスタンスの直後にコピーしま
す。
o １番目の「CREATE DB…」行をコメント化するため、この行の
先頭に「REM」を追加します。
ƒ 例: REM db2 -v "CREATE DB %1 USING CODESET UTF-8
TERRITORY us COLLATE USING UCA400_NO
PAGESIZE 8192"
o 2 番目の「CREATE DB…」行からストリング「COLLATE
USING UCA400_NO」を削除します。
• Portal InfoCenter の手順に従って DB2 ストレージに切り替えます。
• すべてのデータを新規サーバーにシンジケートします。
Page 49
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
•
ƒ
•
新規サーバーの使用を開始するか、またはデータの DB2 バックアップ
(US developerWorks 記事参考)を実行してデータを元のサーバーに復元し
ます。
使用不可にする方法:
• 別のマシンに新しいバージョンの Portal をインストールします。
• Portal InfoCenter の手順に従って DB2 ストレージに切り替えます。
• すべてのデータを新規サーバーにシンジケートします。
• 新規サーバーの使用を開始するか、またはデータの DB2 バックアップ
(US developerWorks 記事参考)を実行してデータを元のサーバーに復元し
ます。
Oracle:
o CLOB キャッシュを使用可能にします。
ƒ 使用可能/使用不可にする方法:Oracle の資料を参照するか、または Oracle のサポ
ートに連絡してください。
5.4 LDAP のチューニング
•
•
•
•
専用サーバーを使用する。
LDAP サーバーの CPU アクティビティーをモニターし、必要に応じてハードウェアを追加する。
LDAP 製品の資料に従ってチューニングを行う。
ネストしたグループが多すぎないようにする。
5.5 メニュー・コンポーネントの最適化
•
•
•
•
•
「メニュー・エレメント照会」セクションに指定する検索条件が多すぎないようにする。
本当に必要な場合を除き、各条件の「追加のオプション」セクションのオプションを使用しない。
カテゴリーまたはサイト・エリアの限定メニューでは、本当に必要な場合にのみ「祖先
(Ancestors)」と「子 (Descendents)」の両方を選択する。
本当に必要な場合を除き、「説明」順のソートを無効にする (無効にするには、この値をその他
のソート・フィールドのいずれかに設定する)。
セキュリティーで保護されていないサイト (コンテンツへの匿名アクセスが可能であるか、また
は管理者などの同一ユーザーが常にコンテンツにアクセスできるサイト) では、「含まれる最大
ページ数」と「読み進むページ数」を 1 に設定する。
5.6 ナビゲーション・コンポーネントの最適化
•
•
本当に必要な場合にのみ「祖先 (Ancestors)」と「子 (Descendents)」の両方を選択する。
セキュリティーで保護されていないサイト (コンテンツへの匿名アクセスが可能であるか、また
は管理者などの同一ユーザーが常にコンテンツにアクセスできるサイト) では、「含まれる最大
ページ数」と「読み進むページ数」を 1 に設定する。
5.7 Portal Personalisation ルールの最適化
•
Dec 06
オーサリング・テンプレートのエレメントを使用したルールは、標準メタデータ (キーワードや
カテゴリーなど)を使用したルールよりもパフォーマンスが低いため、オーサリング・テンプレー
トのエレメントを使用したルールを多数使用しないでください。
Page 50
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
5.8 キャッシングと事前レンダリング
•
•
•
Workplace Web Content Management Web サイトのパフォーマンスを改善するには、Workplace Web
Content Management のキャッシュ、サーブレット・キャッシュ (Dynacache)、および事前レンダリン
グを使用します。
最も高速なオプションは事前レンダリングですが、事前レンダリングにはさまざまな制約事項がある
ため、ほとんどの場合は事前レンダリングよりも Web Content Management キャッシングまたはサー
ブレット・キャッシングが選ばれます。
事前レンダリングと Web Content Management キャッシングについての詳細は、InfoCenter の『事前レ
ンダリング』と『キャッシング』に関するトピック、および DeveloperWorks の Dynacache と WCM
の使用に関する資料を参照してください。
5.8.1
•
•
使用するキャッシュの選択
前述の図では、キャッシュ・タイプ別のパフォーマンスの相違が示されていますが、使用するキャッ
シュの選択は、最も高速なオプションを選べばよいというほど単純ではありません。
使用するキャッシュを決定する際に検討できる選択肢を次に示します。
o サイトがパーソナライズされておらず、今後もパーソナライズされない場合:事前レンダラー
を使用する。
Dec 06
o
サイトにパーソナライズ済みコンテンツと非パーソナライズ・コンテンツが混在している場
合:
ƒ 非パーソナライズ・コンテンツのみをキャッシュする場合:サーブレット・キャッシ
ングを使用する。
ƒ パーソナライズ・コンテンツと非パーソナライズ・コンテンツの両方をキャッシュ
する場合:Web Content Management キャッシングのみを使用するか、または Web
Content Management キャッシングとサーブレット・キャッシングを組み合わせて使用
する。
o
サイトがすべてパーソナライズされている場合 (または今後このようにパーソナライズする
予定の場合):Web Content Management キャッシングを使用する。
Page 51
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
•
Web Content Management キャッシングを使用する場合、使用する Web Content Management キャッシ
ングのタイプを決定する際に検討できる選択肢を次に示します。
o コンテンツがパーソナライズされていない場合:すべてのユーザーがキャッシュされている同
一項目にアクセスできるようにするため、「基本キャッシング」または「サイト」拡張キャ
ッシュ・タイプを使用する。
o コンテンツがパーソナライズされている場合:
ƒ ユーザー・グループごとにコンテンツが固有である場合:「保護」拡張キャッシュ・
タイプを使用する。これにより、同一グループのユーザーがキャッシュされている
同一項目にアクセスできる。
ƒ パーソナライゼーション・プロファイルごとにコンテンツが固有である場合:「パー
ソナライズ」拡張キャッシュ・タイプを使用する。これにより、同一パーソナライ
ゼーション・プロファイルを共有するユーザーがキャッシュされている同一項目に
アクセスできる。
ƒ ユーザーごとにコンテンツが固有である場合:「ユーザー」拡張キャッシュ・タイプ
を使用する。これにより、すべてのユーザーがキャッシュされている各自の項目に
アクセスできる。
ƒ セッションごとにコンテンツが固有である場合:「セッション」拡張キャッシュ・タ
イプを使用する。これにより、すべてのセッションがキャッシュされている各自の
項目にアクセスできる。
5.8.2
•
•
•
•
サーブレット・キャッシング (Dynacache)
サーブレット・キャッシングでは、WebSphere レイヤーで要求がキャッシュされます。
このキャッシングは事前レンダリングほど高速ではありませんが、Web Content Management キャッシ
ングよりは高速であり、ユーザーのニーズに応じてより柔軟に対応できます。
サーブレット・キャッシングではパーソナライズ・コンテンツはキャッシュされませんが、サーブレ
ット・キャッシングを使用して個別のページを選択してキャッシュする (またはキャッシュしない)
ことができます。
使用するレンダリングのタイプに応じて、ポートレットの結果または Web Content Management サー
ブレットをキャッシュするために、サーブレット・キャッシングを有効にできます。
5.8.2.1 検討事項/制約事項
•
•
•
•
•
フィックスパックまたは累積 iFix を適用する場合は、サーブレット・キャッシングを再度使用可能に
する必要があります。サーブレット・キャッシングの再有効化を容易にするため、cachespec.xml ファ
イルのバックアップを作成しておくことをお勧めします。
cachespec.xml の変更内容を反映するには、サーバーを再始動する必要があります。
cache-id に「pathinfo」コンポーネントを指定する場合は、必ずすべての「non-value」属性と「value」
属性に Web Content Management ライブラリー名を指定し、URL のすべての「+」文字を削除してくだ
さい。
ポートレットおよびサーブレットから戻されるエラー応答 (ファイルが見つからないエラーや例外な
ど) がキャッシュされます。
「non-value」属性または「value」属性にサイトまたはサイト・エリアの URL を指定しても、サイト
またはサイト・エリアの子は指定されません。つまり、選択キャッシュ操作を実行するには、以下の
いずれかを行います。
o A. キャッシュしないすべてのページの URL を指定する (non-value 属性を使用)。
o B. キャッシュするすべてのページの URL を指定する (value 属性を使用)。
レンダリング・ポートレットに関するその他の検討事項/制約事項
• ポートレットのデフォルト・コンテキストはキャッシュできません。
Dec 06
Page 52
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
•
Dynacache は代替ページ設計機能を認識しません (キャッシュ後に代替ページ設計を有効にすると、
キャッシュをクリアするまでは設計が表示されません)。
サーブレット・レンダリングに関するその他の検討事項/制約事項
• Web Content Management v6 では Dynacache と内部統合しているため、サーブレット・レンダリング
で Dynacache を使用する場合は、既存の cachespec.xml ファイルを上書きしないように注意してくだ
さい。代わりに既存の cache-id セクションの後に各自の cache-id セクションを追加してください。
• レンダリング・ポートレットとは対照的に、サーブレット・レンダリング・キャッシングを使用する
ときに、キャッシュ ID に次の引数が指定されていないと、次に示す動作が発生します。
Argument
指定されていない場合の動作
id
pagedesign
version
source
cmpntname
cmpntid
Dynacache が同一オブジェクトのドラフト・コピーと公開コピーを区別しない。
Dynacache が同一コンテンツのデフォルト・ページ設計と代替ページ設計を区別しない。
Dynacache が同一オブジェクトの現行バージョンと以前のバージョンを区別しない。
特定の条件でライブラリーおよびコンテンツ・コンポーネントがレンダリングを実行しない。
特定の条件でライブラリーおよびコンテンツ・コンポーネントがレンダリングを実行しない。
特定の条件でライブラリーおよびコンテンツ・コンポーネントがレンダリングを実行しない。
•
特定の cache-id 項目を追加し、Web Content Management のユーティリティー・モジュールとシンジケ
ーションのサーブレット･キャッシングを使用不可に設定しておくことをお勧めします。ユーティリ
ティー・モジュールとシンジケーションをキャッシュすると、これらの両方のエレメントが破損しま
す。このためには、次に示す cache-id セクションを追加します。
<cache-id>
<component id="MOD" type="parameter">
<required>true</required>
<not-value>Subs</not-value>
<not-value>Synd</not-value>
<not-value>ItemDispatcher</not-value>
<not-value>Syndication</not-value>
<not-value>MemberFixer</not-value>
<not-value>VersioningEnablement</not-value>
<not-value>WorkflowEnablement</not-value>
<not-value>PlutoUploadFile</not-value>
<not-value>PlutoDownloadFile</not-value>
<not-value>AJPECatSelect</not-value>
<not-value>Template</not-value>
</component>
<timeout>7200</timeout>
</cache-id>
5.8.2.2 構成方法
ローカル・レンダリング･キャッシング
1. 最初に WebSphere で Dynacache が使用可能に設定されていることを確認します。
a. 詳しくは、WebSphere Application Server InfoCenter の『サーブレット・キャッシングの構成』
を参照してください。
2. cachespec.xml ファイルを定義します (このファイルは、キャッシュするエレメントとキャッシュしな
いエレメントを記述します)。
a. 詳しくは、WebSphere Application Server InfoCenter の『Cachespec.xml』を参照してください。
3. 次のコマンドを使用して、ローカル・レンダリング・ポートレットをバックアップしてから更新しま
す。
a. コマンド・プロンプトから [WPS_ROOT]\installableApps に移動します。
Dec 06
Page 53
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
ilwwcm-localrendering-portlet.war を ilwwcm-localrendering-portlet.war.backup にコピーします。
「wcm_lrp_war」というディレクトリーを新規に作成し、このディレクトリーに移動します。
次のコマンドを実行します。
[WAS_ROOT]/java/bin/jar –xf ../ilwwcm-localrendering-portlet.war
e. cachespec.xml ファイルを [WPS_ROOT]/installableApps/wcm_lrp_war/WEB-INF にコピーします。
f. 次のコマンドを実行します。
[WAS_ROOT]/java/bin/jar –cf ../ilwwcm-localrendering-portlet.war *
Portal の管理インターフェースを使用して、変更したポートレットを [WPS_ROOT]\installableApps デ
ィレクトリーから再デプロイします。
[オプション] 動的キャッシュ・モニターをインストールします。詳しくは、WebSphere Application
Server InfoCenter の『キャッシュ情報の表示』を参照してください。
b.
c.
d.
4.
5.
リモート・レンダリング･キャッシング
1. 最初に WebSphere で Dynacache が使用可能に設定されていることを確認します。
a. 詳しくは、WebSphere Application Server InfoCenter の『サーブレット・キャッシングの構成』
を参照してください。
2. cachespec.xml ファイルを定義します (このファイルは、キャッシュするエレメントとキャッシュしな
いエレメントを記述します)。
a. 詳しくは、WebSphere Application Server InfoCenter の『Cachespec.xml』を参照してください。
3. 次のコマンドを使用して、リモート・レンダリング・ポートレットをバックアップしてから更新しま
す。
a. コマンド・プロンプトから [WPS_ROOT]\installableApps に移動します。
b. ilwwcm-remoterendering-portlet.war を ilwwcm-remoterendering-portlet.war.backup にコピーしま
す。
c. 「wcm_rrp_war」というディレクトリーを新規に作成し、このディレクトリーに移動します。
d. 次のコマンドを実行します。
[WAS_ROOT]/java/bin/jar –xf ../ilwwcm-remoterendering-portlet.war
e. cachespec.xml ファイルを [WPS_ROOT]/installableApps/wcm_rrp_war/WEB-INF にコピーします。
f. 次のコマンドを実行します。
[WAS_ROOT]/java/bin/jar –cf ../ilwwcm-remoterendering-portlet.war *
4. Portal の管理インターフェースを使用して、変更したポートレットを [WPS_ROOT]\installableApps デ
ィレクトリーから再デプロイします。
5. [オプション] 動的キャッシュ・モニターをインストールします。詳しくは、WebSphere Application
Server InfoCenter の『キャッシュ情報の表示』を参照してください。
サーブレット・レンダリング･キャッシング
1. 最初に WebSphere で Dynacache が使用可能に設定されていることを確認します。
a. 詳しくは、WebSphere Application Server InfoCenter の『サーブレット・キャッシングの構成』
を参照してください。
2. cachespec.xml ファイルを定義します (このファイルは、キャッシュするエレメントとキャッシュしな
いエレメントを記述します)。
a. 詳しくは、WAS InfoCenter の『Cachespec.xml』を参照してください。
3. 次のコマンドを使用して、WCM の ear ファイルをバックアップしてから更新します。
a. コマンド・プロンプトから [WPS_ROOT]\wcm\installableApps に移動します。
b. wcm.ear を wcm.ear.backup に名前変更します。
c. 次のコマンドを実行します。
[WAS_ROOT]/bin/earexpander.bat –ear wcm.ear –operationDir ./wcm_ear –operation expand
d. cachespec.xml ファイルを、./wcm_ear/ilwwcm.war/WEB-INF の既存の同名ファイルにマージし
ます (既存の cachespec ファイルを上書きしないでください)。
e. 次のコマンドを実行します。
[WAS_ROOT]/bin/earexpander.bat –ear wcm.ear –operationDir ./wcm_ear –operation collapse
Dec 06
Page 54
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
次の Portal Config コマンドを実行し、更新された wcm.ear ファイルを再デプロイします。
[WPS_ROOT]/config/WPSconfig.bat update-wcm-ear
[オプション] 動的キャッシュ・モニターをインストールします。詳しくは、WebSphere Application
Server InfoCenter の『キャッシュ情報の表示』を参照してください。
f.
4.
Dec 06
Page 55
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
管理
6
6.1 行うべき作業
1.
バックアップ・ストラテジーを導入する。
•
•
•
重大な障害の発生時にデータを復元できるように、適切なバックアップ・ストラテジーが導入さ
れていることを確認します。Workplace Web Content Management データベースを復元するときに、
既存のシンジケーター/サブスクライバーのペアを手動で削除し、新しいペアを作成します。
バックアップおよび復元の手順をテストし、この手順が機能し、必要なコンポーネントがすべて
バックアップされることを確認します。
Web Content Management データが JCR データベースに格納されるようになったため、管理者は
JCR データベースのバックアップ (または復元) 操作が、このデータベースを使用するすべてのア
プリケーション (PDM、PZN など) に影響する点に注意する必要があります。
2.
次のいずれかの条件に該当する場合は、メンバー・フィクサー・モジュールを実行する。
•
ユーザーまたはグループの DN が変更された。
o この場合、無効/欠落しているユーザーまたはグループへの参照がデータに含まれています。
ユーザーまたはグループを WebSphere Portal から永久的に削除した。
o この場合、欠落しているユーザーまたはグループへの参照がデータに含まれています。
WebSphere Portal セキュリティーを有効または無効にした (または異なる WebSphere Portal セキュリテ
ィー設定の別のサーバーからシンジケートした)。
o この場合、DN 構造が変更され、実際の組織名が追加または削除されたため、すべてのユー
ザー/グループ参照が無効です。
顧客の LDAP 構造が変更された。
o この場合、DN 構造が変更されたため、すべてのユーザー/グループ参照が無効です。
Portal サーバーにデータを移動し、(各ユーザーの LDAP レコードの固有属性ではなく) このサーバー
のデフォルトの自動生成 ID を使用するように WMM を構成した。
o この場合、WMM 外部 ID が一致しないため、すべてのユーザー/グループ参照が無効です。
ユーザーまたはグループが削除された後に WebSphere Portal に再追加され、(各ユーザーの LDAP レ
コードの固有属性ではなく) このサーバーのデフォルトの自動生成 ID を使用するように WMM を構
成した。
o この場合、現在の Portal サーバーと一致しない WWM 外部 ID のユーザー/グループへの参照
がデータに含まれています。
Workplace Web Content Management レベル 3 サポートによりメンバー・フィクサー・モジュールの実
行が要求された。
•
•
•
•
•
•
注 1:MemberFixer についての詳細は、InfoCenter を参照してください。
注 2:プリンシパル情報キャッシュを使用可能にした場合 (PK32457 で入手可能ですが、デフォルトで
は使用可能に設定されていません)、メンバー・フィクサーを実行する前に iFix の README の説明
に従ってメンバー・キャッシュ・マネージャー・モジュールを実行してください。
3.
IBM サポートへ連絡する前に Web Content Management Must-Gather (US)に示されている情報を収集し
ていることを確認する。
4.
「Recommended fixes and updates for WebSphere Portal(US)」サイトで新しい推奨フィックスが公開され
ているかどうかを常に確認する。
Dec 06
Page 56
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
•
•
•
5.
『パフォーマンス』で説明されている推奨事項が実施されていることを確認する。
•
6.
これにより、Web サイトの適切なパフォーマンスを維持できます。
JCR データベース (Web Content Management データが格納されているデータベース) を定期的に再調
整する。
•
•
•
7.
これにより、最新の重要なフィックスを把握できるため、Web サイトを円滑に運営できます。
iFix をインストールするときには、常に最新の Portal Update Installer (US)を使用してください。
これにより、iFix を正しくインストールおよび削除できます。
複数の iFixes をインストールする必要がある場合、通常は一括でインストールし、最後に手動の
手順を実行することができる点に注意してください。不安な場合は IBM サポートに確認してく
ださい。
詳しくは本文書『パフォーマンス』の『データベース・チューニング』を参照してください。
これにより、Web サイトの適切なパフォーマンスを維持できます。
Web サイトが変更されなくなった場合、再調整は不要です。
カスタム JSP ページは、Portal インストール・ディレクトリー外部の別のディレクトリーに保存する。
•
これにより、ポートレットと Web Content Management アプリケーションの更新時に、これらのカ
スタム JSP ページを適切な場所に再度コピーできます。
6.2 行うべきでない作業
1. 最初にテストを行わずにアップグレードまたは iFix の適用を実行しない。
•
変更を実動サーバーに適用する前に、常にテストを実行して変更を文書化してください。
2. トレース機能を有効にしたままにしない。
•
Dec 06
Workplace Web Content Management サポート・チームから詳細トレースが求められた場合は、必
要なログの取得後に必ずトレースをオフにしてください。これは、トレースを有効にしたままに
しておくと、パフォーマンスに影響が出るためです。
Page 57
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
Dec 06
Page 58
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
7
結論
この記事で説明する技術情報を読み理解することで、IBM Workplace Web Content Management を適切に実
装でき、新規 Web コンテンツ・サイトの構築時に選ぶことができる設計の選択肢についてより深く理解
できます。
7.1 参考資料
Creating content with three clicks using IBM Workplace Web Content Management
http://www.ibm.com/developerworks/websphere/library/techarticles/0506_smit/0506_smit.html
Introducing IBM Workplace Web Content Management in WebSphere Portal V6
http://www.ibm.com/developerworks/websphere/library/techarticles/0612_viehweger/0611_viehweger.html
IBM Workplace Web Content Management for WebSphere Portal 5.1 and IBM Workplace Web Content
Management 2.5
http://www.redbooks.ibm.com/abstracts/sg246792.html
Understanding syndication in IBM Workplace Web Content Management
http://www.ibm.com/developerworks/workplace/library/wwcm-syndication/
Using WebSphere Dynamic Cache Service with IBM Workplace Web Content Management
http://www.ibm.com/developerworks/workplace/library/dynamic-cache-wcm/
WebSphere Portal and Workplace Web Content Management product documentation (すべての現行レベル
の InfoCenter を含む)
http://www.ibm.com/developerworks/websphere/zones/portal/proddoc.html
WebSphere Portal zone
http://www.ibm.com/developerworks/websphere/zones/portal/
Web Content Management resources page
http://www.ibm.com/developerworks/workplace/products/webcontentmanagement/
7.2 著者について
David de Vos は、過去 6 年にわたりアプリケーション開発、特に Java による開発に従事しています。
IBM Lotus Workplace Web Content Management 製品の広い知識を有しており、IBM が Aptrix を取得する前
からこのソフトウェア開発に携わっていた最初の開発者の 1 人です。Workplace Content Management レベ
ル 3 国際サポート・チームの元リーダーであり、現在はシドニーの Australian Development Lab を拠点と
する Lab Product Specialist Team のメンバーです。その知識を駆使して、ソフトウェア・デプロイメント
を最大限に活用できるよう顧客を支援し、製品の品質向上に取り組んでいます。David de Vos の連絡先は
[email protected] です。
Melissa Howarth は IBM の Web Content Management Software (以前は Aptrix と呼ばれていた製品) を専門
とする IT コンサルタントです。このソフトウェアの Lotus Domino 対応版を手がけた開発者の 1 人であり、
Dec 06
Page 59
IBM Workplace Web Content Management V6.0 の利用にあたってのベスト・プラクティス
9 年以上にわたる WCM を使用した Web サイトの実装経験を有しています。IBM による Aptrix の取得後
は Software Group Services で Web サイト実装に取り組み、現在はシドニーの Australia Development Lab を
拠点とする Lab Product Specialist Team のメンバーです。その知識を駆使し、クライアント、ビジネス・
パートナー、コンサルタントを対象に、本製品を最大限に活用する方法を教授しています。Melissa
Howarth の連絡先は [email protected] です。
7.3 謝辞
Theresa Smit と Jason Hatch からの本資料へのコメント、貢献、提案に感謝します。
特記事項
IBM、Lotus、Redbook、Workplace Web Content Management、WebSphere、Tivoli、NetView、z/OS、AIX、
および MQSeries は、International Business Machines Corporation の米国およびその他の国における商標で
す。
Microsoft および Windows は、Microsoft Corporation の米国およびその他の国における商標です。
Java およびすべての Java 関連の商標およびロゴは Sun Microsystems, Inc.の米国およびその他の国におけ
る商標です。
Linux は、Linus Torvalds の米国およびその他の国における商標です。
他の会社名、製品名およびサービス名等はそれぞれ各社の商標です。
本書の情報は特定物として現存するままの状態で提供されるものであり、明示もしくは黙示の保証責任
を負わないものとします。また、本書は IBM の現在の製品プランまたは戦略に基づくものです。この製
品プランまたは戦略は予告なく変更されることがあります。IBM は本文書の使用に起因するいかなる損
害についても責任を負いません。本文書は、IBM (または IBM のサプライヤーまたはライセンサー) にい
かなる保証責任を負わせるものではなく、また、IBM ソフトウェアの使用に際し適用される、プログラ
ムのご使用条件の内容も変更するものではありません。
スクリーンショットの River Bend Coffee and Tea Company は架空の企業名であり、例示目的でのみ使用さ
れているものです。
Dec 06
Page 60
Fly UP