WebSphere Portal Express 7

第 1 版

公開日: 2010 年 9 月

この資料について

IBM のアクセシビリティーに関するコミットメントに従い、この資料はアクセシビリティーに対応しています。

印刷

この資料を印刷する場合、最良の印刷出力を得るために、一部の装飾は除去されます。 以下に印刷についてのいくつかのヒントを示します。
  • この資料の長さは、ブラウザーで印刷可能な長さを超えている可能性があります。 Microsoft Internet Explorer では、大きなファイルを正しく印刷できることが実証されています。
  • この資料はボリュームの大きな資料です。 印刷プレビュー機能を利用して、印刷されるページの長さを確認してください。
  • 資料のセクションを強調表示して、その選択部分の内容だけを印刷することもできます。

オフラインでの作業

ブラウザーからこの資料のローカル・コピーを保存することができます。 メニューおよびオプションはブラウザーごとに異なります。 資料をローカルに保存する方法について詳しくは、ブラウザーのヘルプを参照してください。

フィードバックを送る

この資料のフィードバックをお送りになりたい場合は、 「フィードバックを送る」をご覧ください。

製品の概要

IBM® WebSphere® Portal Express は、ミドルウェア・アプリケーション (ポートレットと呼ばれます)、マッシュアップ、およびセキュアな business-to-business (B2B)、business-to-consumer (B2C)、および business-to-employee (B2E) ポータルの作成および管理のための開発ツールで構成されています。 Web ポータルを使用することにより、パートナー、従業員、および顧客は、ユーザー・エクスペリエンスを選択できます。 つまり、役割、コンテキスト、アクション、ロケーション、設定、およびチーム・コラボレーションの要件に基づいて、アプリケーションをパーソナライズできます。 IBM WebSphere Portal Express ソフトウェアでは、複合アプリケーション、つまりビジネス・マッシュアップ・フレームワークと、柔軟な SOA ベースのソリューションを構築するために必要な拡張ツールが提供されます。さらに、あらゆる規模の組織の必要に応える無類のスケーラビリティーも備えています。

Content Accelerator および Enable オファリングでは、 IBM Lotus Web Content Management、文書管理、エンタープライズ・サーチ、および拡張ワークフローといった各機能が追加されます。また、Extend オファリングには、ポータルの効果性を高めるための強力なコラボレーション機能が含まれています。これには、チーム・コラボレーション、電子フォーム、インスタント・メッセージング、および在席認識サービスが含まれます。 追加の IBM アクセラレーター・オファリングでは、WebSphere Portal Express ソフトウェアに簡単にスナップオンする追加のソリューションが提供されるため、評価時間を削減でき、お客様がコンテンツのデプロイ、ビジネス・プロセスの自動化、コラボレーションを行うときにかかるコストを削減できるようにします。

ポータルとは、Web ベースのリソースへのアクセスを 1 つの場所に集約することにより、ユーザーにこれらのリソースへの単一アクセス・ポイントを提供する Web サイトです。ユーザーは使用するそれぞれのポートレットではなく、ポータル自体にログインするだけで済みます。 また WebSphere Portal Express は、WAP 対応デバイス、i モード電話、スマートフォン、および各種 Web ブラウザーに Web コンテンツを配信することもできます。 さらに IBM Mobile Portal Accelerator のマルチ・チャネル・サーバーおよびモバイル・デバイス・リポジトリーを使用することにより、市場のニーズに対応すべく、7000 を超えるモバイル・デバイスにポータル・コンテンツを動的に拡張し、新しい更新やデバイスが追加されています。

アドミニストレーターは、企業、ユーザー、およびユーザー・グループのニーズに合わせて、WebSphere Portal Express をカスタマイズすることができます。 ポータルの「外観と雰囲気」を自分の組織の規格に合わせたり、 ビジネス・ルールやユーザー・プロファイルに従って、ユーザーやグループの ページ・コンテンツをカスタマイズすることができます。 ビジネス・パートナー、カスタマー、従業員などのユーザーは、 さらに、ポータルのビューを独自にカスタマイズすることができます。 ユーザーは、ポートレットをページに追加し、 それらを任意に配置し、ポートレットのカラー・スキームを制御することができます。ポートレットを一か所に集約し、ユーザーに自分のデスクトップをカスタマイズする機能を 提供することにより、WebSphere Portal Express はユーザーに対し、効率的で、高い満足度が得られる業務方法を提供しています。

ポートレットは、WebSphere Portal Express の中心部分です。 ポートレットは、ポータル・ページ上の定義領域として表示される、再使用可能な特殊な Java サーブレットとして、多くの異なるアプリケーション、サービス、および Web コンテンツへのアクセスを提供します。 WebSphere Portal Express には、シンジケート・コンテンツの表示、XML の変換、 検索エンジンおよび Web ページへのアクセスのためのポートレットなど、 多くの標準ポートレットが同梱されています。 Lotus Notes®IBM Lotus® Domino® and Extended Products、IBM Lotus Sametime®IBM Lotus Quickr、IBM Lotus Connections、Microsoft Exchange、インスタント・メッセージングにアクセスするためのポートレットも組み込まれています。第三者のポートレットもいくつかあります。 例えば、エンタープライズ・リソース・プランニング (Enterprise Resource Planning) (ERP) ポートレット、ダッシュボード (Dashboards) ポートレット、ビジネス・インテリジェンス (Business Intelligence) ポートレット、プロセス管理 (Process Management) ポートレット、カスタマー・リレーションシップ・マネージメント (Customer Relationship Management) (CRM) ポートレットなどです。さらに、WebSphere Portal Express には、 ポートレット開発者がカスタム・ポートレットの作成に使用できる API も同梱されています。

また WebSphere Portal Express には Lotus Mashup ランタイムが組み込まれるようになったので、ポータルの内部でウィジェットを実行でき、ポートレットとウィジェットの両方から成るマッシュアップを作成することもできます。ウィジェットは、JavaScript で作成された、高度な対話式ユーザー・インターフェース・コンポーネントです。 これらのウィジェットは一般に、有効範囲が非常に狭く、スクリプト・ベースの言語を使用して簡単に作成できます。 さらにウィジェットは、Java EE ベースのポータル・サーバーや PHP ベースのサーバーのようなさまざまなバックエンド・テクノロジー間のマッシュアップを作成するためのソリューションでもあります。

WebSphere プラットフォーム

WebSphere は IBM の統合ソフトウェア・プラットフォームです。 これには、24x7 の基幹業務用オンデマンド Web アプリケーションや、クロスプラットフォーム、クロス・プロダクトのソリューションを作成、実行、およびモニターするために必要なミドルウェア・インフラストラクチャー全体 (サーバー、サービス、ツールなど) が含まれます。 WebSphere は、信頼できる柔軟で堅固な統合ソフトウェアを提供しています。

WebSphere では、サービス指向アーキテクチャー (SOA) 環境用のソフトウェアが提供され、動的で相互接続されたビジネス・プロセスを使用できるようになり、すべてのビジネス・シチュエーションに対応する非常に効果的なアプリケーション・インフラストラクチャーが提供されます。

IBM WebSphere Application Server によって、サービス指向アーキテクチャー (SOA) アプリケーションおよびサービスを構築、再利用、実行、統合、および管理するためのパフォーマンス・ベースの革新的基盤が、非常に多くの開発者と IT アーキテクトに提供されます。これを活用することで、ビジネスにおける俊敏性が向上します。 ビジネス上不可欠で重要な企業規模のアプリケーションから、最小部門レベルのアプリケーションに至るまで、WebSphere Application Server は、最高レベルの信頼性、可用性、セキュリティー、およびスケーラビリティーを提供します。

新機能、主要コンポーネント、および各コンポーネントがソリューション全体に提供する機能についての追加情報は、このセクションのサブトピックを調べてください。

以下のトピックに、追加の概要情報があります。

新機能

IBM WebSphere Portal Express の新機能について説明します。

IBM WebSphere Portal Express の新機能および改良機能

WebSphere Portal Express には、仮想化、コンテンツのタグ付けおよびレーティングなどの新機能があり、さらにページ・ビルダーの機能拡張や、統一されたテーマ体系、保守容易性、マイグレーション、およびコンテンツ・マネジメントなどにおける機能拡張があります。

ConfigEngine

IBM サポートにより公開された問題報告の自動ログ収集を補助する、新しいタスクが追加されました。 これは、IBM 提供の ISA / ISA-lite サポート・ツールで使用できるログ収集に追加されたものです。 ConfigEngine タスクでログ収集を実行するために追加コードをインストールする必要はありません。

情報ポートレット

現在 2 つの情報ポートレットを使用できるようになりました。 これらのポートレットの機能は同じですが、元のポートレットは IBM API で作成され、新しいポートレットは JSR 286 API で作成されました。 新しいポートレットは、クライアントとサーバーの両サイドで表示できますが、元の情報ポートレットはサーバー・サイドでしか表示できません。

構成ウィザード

構成ウィザードが改良され、LDAP サーバーによる WebSphere Portal Express セキュリティーの構成が簡単になりました。 新しい構成ウィザード機能では、LDAP セキュリティー構成を正常に行うために答える必要のある各種質問に対し、LDAP サーバーの照会を試行することによって、より適切なデフォルトが提供されるようになりました。

構成ウィザードについてさらに調べる

ブログおよび Wiki

ページ・ビルダー・テーマで「コンテンツの追加」ウィジェットを使用して、ブログ、ブログ・ライブラリー、または Wiki をページに簡単に追加できるようになりました。 グローバリゼーション・サポートには、新しい IBM Lotus Web Content Management API を利用する、追加の拡張機能があります。

ブログおよび Wiki についてさらに調べる

エラー報告

ヒープ・メモリー使用に関係する同種の問題に対する WebSphere Portal Express の「First Failure Data Capture」特性を向上させるため、WebSphere Portal Express インストール済み環境のデフォルトでは、WebSphere Portal Express JVM での冗長なガーベッジ・コレクションがアクティブになります。 これは、WebSphere Application Server 内の WebSphere Portal Express JVM の JVM コマンド行引数に適切な設定を追加することによって行います。 これにより、基礎となる JVM で提供される、Java ヒープのガーベッジ・コレクション・アクティビティーに関する統計をログに記録するためのサポートがアクティブになります。

さらに、「ログ・ローリング」機能をサポートするプラットフォームでは、その機能がアクティブになり、ログにより使用される実際のディスク・スペース量を節約しながら、デバッグの際に必要な十分の量のガーベッジ・コレクション履歴を取り込む操作のバランスが取られます。 通常の冗長なガーベッジ・コレクションでは、ログが無制限に拡大する可能性があります。 ログ・ローリング機能を使用すれば、ログの生成は道理にかなった回数に制限され、生成される各ログに含まれるガーベッジ・コレクション・サイクル・レポートの数も制限されます。 WebSphere Portal Express でアクティブになるのは、基礎となる JVM コードで提供されるサポートであるため、このサポートの作動方法の詳細は、該当する Java 診断ガイドに記載されています。

この大量の割り振りロギングは、WebSphere Application Server 内のポータル・サーバー用に登録済みの JVM コマンド行パラメーターによりアクティブになり、WebSphere Application Server 構成内の該当するストリングを編集または削除することにより、調整または非アクティブにできます。 例えば、割り振りが「予定より大きいが 10 MB 未満」であると思われる場合、10 MB のしきい値を小さい値に引き下げることができます。

ロギングおよびトレースについてさらに調べる

Java 診断ガイドについてさらに調べる

メッセージ

メッセージ・カタログが更新されました。追加された新しいメッセージには、 ユーザーおよび IBM サポートの問題判別手順における助けとなるより詳しい説明と、提案されるユーザー処置が記載されます。 新しい項目に加えて、既存の共通エラー・メッセージが問題判別に役立つように改訂されました。

マイグレーション

マイグレーション・パスが改良され、WebSphere Portal Express バージョン 6.1 からのマイグレーションが、ソフトウェア・アップグレードにより近い形になりました。 WebSphere Portal Express バージョン 6.1 と 7.0 の間でのデータベース・スキーマの変更が、自動的に処理されます。 また、同じ場所でもデータベース・アップグレードを実行できます。

マイグレーションについてさらに調べる

ページ・ビルダーおよび統一されたテーマ体系

ページ・ビルダー・テーマが現在のデフォルトのテーマです。 ページ・ビルダー・テーマは、ポートレットとウィジェットに加えて、サーバー・サイドとクライアント・サイド両方のページの集約をサポートする新しく統一された体系に進化しました。 テーマは、WebDAV ファイル・ストアに格納された静的 HTML ファイルを直接介して、編集と管理を完全に行えるようになりました。 スタイルがさらに最適化されました。線形グラデーション、立体の影付け、および角の丸めのために最新の CSS3 機能を活用することにより、パフォーマンスが向上し、カスタマイズが容易になりました。

既存のページ・ビルダー機能が改良されて、新しく機能強化されたクライアント・サイド集約体系をサポートするようになりました。 タブ・ナビゲーション・ウィジェットには、ドロップダウン・メニュー、インライン・ページ作成、およびドラッグ・アンド・ドロップによるページ再順序付けが装備され、 ブラウザーをフルページ最新表示しないでクライアント・サイドのページ切り替えをできるようになりました。 コンテンツ検索では、ページに追加するポートレットおよびウィジェットを検出します。 「スタイルの変更」および「レイアウトの変更」では、WebDAV により格納および構成される静的 CSS およびレイアウト・テンプレートをサポートします。

ページ・ビルダーについてさらに調べる

セキュリティー

偽名の使用 によりユーザー (サポート・スペシャリストなど) は、ユーザーのワークステーションにアクセスして新しいページ、ポートレットなどをテストし、ワークステーションで問題が発生したときにそれを調べることができます。 別のユーザーの偽名を使用する場合は、その前にまず偽名の使用の機能を使用可能にし、該当するユーザーに「ユーザーとして実行可能」の役割を割り当てる必要があります。

偽名の使用とその使用可能化の方法についてさらに調べる

タグ付けおよびレーティング

ユーザーはポータル・コンテンツへのタグ付けまたはレーティング、さらにタグとレーティングの表示を行えるようになりました。 これにより、ポータル・コンテンツ (ポータルにカスタム・コンテンツがある場合にはそれも含む) をより効率的に編成、分類、および検索することができます。 例えば、ユーザーはオンライン・ブック・ストアで本にタグ付けしたり、レーティングしたりすることができます。

ポータル・コンテンツのタグ付けおよびレーティングについてさらに調べる

ワークフロー管理システムとの統合

WebSphere Portal では、統一タスク・リストを使って、IBM WebSphere Process Server などのワークフロー管理システムとの単一の統合点を提供するようになりました。 統一タスク・リストは、視覚に訴える、高度に構成可能なユーザー・インターフェースの中に、複数のシステムからのタスクおよびアクティビティーを集約するポートレットです。 ポータル・ユーザーは、統一タスク・リストにアクセスして、ワークフローを進めるために完了できる保留タスクを表示および要求します。

統一タスク・リストは、WebSphere Portal Business Solutions Catalog から入手することができ、手を加えなくても WebSphere Process Server に統合できます。 しかし、統一タスク・リストはカスタマイズして、ユーザーのビジネス要件に適合させることができます。カスタマイズは、任意のワークフロー管理システムからタスクへのアクセス、検索、フォーマット設定を行う固有のタスク・プロバイダーまたはサービスを作成することによって行います。

統一されたタスク・リスト・ポートレットについてさらに調べる

仮想化

仮想化のテクノロジーを使用して、WebSphere Portal Express と共にインストールされて構成された同一のオペレーティング・システムを一括複製できます。 VMware は、WebSphere Portal Express のこのバージョンにおいて完全にサポートされています。

Linux での仮想化についてさらに調べる

Windows での仮想化についてさらに調べる

ドキュメンテーションの改善と変更

WebSphere Portal 7 では、お客様からのフィードバックに基づいて、ドキュメンテーションをさらに改善しました。 最も注目すべき変更点は、WebSphere Portal Family wiki でドキュメンテーションを発行するように移行していることです。

Wiki

Wiki が提供されたことで、インフォメーション・センターにもメリットがあります。 何か問題に気付いたり、改善の余地があると思ったりした場合、ユーザーはトピックにコメントを加えたり、それを編集したりできます。 以前は、フィードバック・フォームを IBM に送信することができました。 今まで多くのお客様が時間を取ってそれらのフォームを送信してくださり、優れたフィードバックをお寄せくださいました。 その結果として、ドキュメンテーションが更新され、改善されてきました。 新しい Wiki 配信形式では、そのようなフィードバックの効果が今までより早く他のお客様に提供されます。

どなたでも Wiki 上のドキュメンテーションをブラウズできます。 ただし、コンテンツの編集とコメント記入を行うには、Lotus developerWorks ID を使用して Wiki にログオンする必要があります。 既に Lotus developerWorks ID を持っているユーザーは、いつでもログオンしてコメントの追加または編集を行えます。 Lotus developerWorks ID を持っていないユーザーは、すぐに登録して始めることができます。

Lotus Registration

画面取りの中で、ドキュメンテーションを使用するときに知っておくべき機能が強調表示されています。

WebSphere Portal Family wiki ユーザー・インターフェースの画面取り。
画面取りの中で番号の付いた項目の説明については、表を参照してください。
表 1. 画面取りの凡例 - Wiki でドキュメンテーションを使用するときに、以下の主な機能を見逃さないでください。
番号 説明
1 パンくずは、現在の位置を見定めて、どの資料を読んでいるのかを素早く識別するのに役立ちます。
2 「拡張検索 (Advanced Search)」を選択すると、検索範囲を特定のカテゴリーに制限できる新しい画面が開きます。 例えば、検索範囲を IBM WebSphere Portal Express 7 ドキュメンテーションのトピックのみに制限することができます。 複数のカテゴリーでも単一のカテゴリーでも選択可能です。 拡張検索では、完全に一致する句の検出、タイトルのみの検索、単語単位のみでの検索、また検索におけるブール式の利用を行えます。 単一の用語または句を検索した後、選択条件やパラメーターを変更して、検索結果をさらに絞り込むことができます。
3 「ページ変換 (Translate page)」機能は、機械翻訳を使用して、すべてのコンテンツをその場で翻訳します。 多くの機械翻訳サーバーとは異なり、この機械翻訳サーバーはクラウド・ソーシングを使用します。 不正確、不自然、あるいは混乱させるような翻訳を見つけた場合、ユーザーがそれを訂正できます。 ユーザーが加えた修正は翻訳サーバーに追加され、次回そのコンテンツが翻訳されるときに使用されます。
4 IBM は引き続き、高い品質で翻訳されたコンテンツを提供します。 IBM 翻訳センターで翻訳されたドキュメンテーションにアクセスするには、ナビゲーションの「IBM 資料翻訳 (IBM Translated Documentation)」セクションを使用します。
5 これらのリンクを使用すると、参照中のトピックの元のバージョンを素早く表示できます。
6 ナビゲーションで強調表示された部分を見ると、現在のトピックが、コンテンツ内のその他のトピックに対してどのような相対位置にあるのかを知るのに役立ちます。

編成

WebSphere Portal 7 ドキュメンテーションのナビゲーションは、タスク指向に基づくもので、コンテンツをより迅速に検出するのに役立ちます。 この新しいナビゲーション・モデルは、他の IBM 製品とより一層調和しています。 ナビゲーション内の標準セクション (「インストール」、「開発」、「トラブルシューティング」など) に注目してください。 「セキュリティー」、「モニター (Monitoring)」、「ポータル・サイトのセットアップ (Setting up a portal site)」などの追加のナビゲーション・ヘッダーが追加されました。
  • 「セキュリティー」には、認証、SSL、LDAP 構成などについての情報が含まれています。
  • 「モニター (Monitoring)」には、ポータル・サイトの使用パターンについての理解を深めるのに役立つ情報が含まれています。
  • 「ポータル・サイトのセットアップ (Setting up a portal site)」には、サイトのセットアップを一層全体的に捉えられるようにコンテンツがまとめられています。 また、ページの作成、ポートレットのページへの追加、テーマとスキン、およびコンテンツのサイトへの追加に関する情報も含まれています。

WKPLC プロパティー

プロパティーの説明、例、およびデフォルト値が、ドキュメンテーションに復元されました。 プロパティー・ファイルのドキュメンテーションの検出

Lotus Web Content Management

Web Content Management への依存度が高いサイトをセットアップする場合には、IBM Lotus Web Content Management のドキュメンテーションを参照してください。 この新しいドキュメンテーション・セットは、サイトをセットアップするために WebSphere Portal および Lotus Web Content Management について知っておく必要のある事柄をまとめています。

資料リソース

情報の開始点は、製品資料です。 以前は、製品資料は、インフォメーション・センターのフレームワークを使用して配信されていましたが、WebSphere Portal 7.0 では、製品資料は WebSphere Portal Family wiki で配信されます。 WebSphere Portal の操作時に使用できるサイトやリソースが他にもありますが、情報の検索を容易にするためにこの統合が行われました。 また、コンテンツに改善を加え、資料に対してコミュニティー全体で編集およびコメント記入を行えるようにすることも意図しています。 情報の検索場所を知っていると、手間と費用を節約できます。 WebSphere Portal と Lotus Web Content Management の資料および補足コンテンツに関する 1 次リソースと 2 次リソースについて詳しく説明します。

コンテンツの 1 次ソースには、WebSphere Portal Family wiki および WebSphere Portal サポート・サイトの 2 つがあります。 優れた 2 次ソースとして developerWorks があります。ここには、例およびチュートリアル・ベースの記事があります。

コンテンツの 2 つの 1 次ソースである WebSphere Portal Family wiki およびサポート・ページを図示した概念的なグラフィック。さらにそれらに接続するハイパーリンク。
リソース間のナビゲートに役立つように、各コンテンツ・ソースは他のソースにリンクしています。 各コンテンツ・ソースには特定の目的があり、他のソースと併用することを意図しています。

Wiki で配信される製品資料 (「製品マニュアル (Product Documentation)」タブにある) は、予期される使用パターンに基づいて機能を活用できるように、IBM により開発されています。 ユーザーは製品を使用した経験を反映させることにより、コンテンツに貢献できます。 「ホーム」タブからアクセスする Wiki コンテンツは、IBM 内外のコミュニティーによって作成されます。 製品を使用した経験から得た、実際の使用パターンとユース・ケースに基づく知識を共有することを意図しています。 サポート・コンテンツは、IBM サポートによって、問題を避けたり診断したりするのに役立つように開発されており、可能な限り即応性があるよう意図されています。

WebSphere Portal Wiki

Wiki には、次の内容が含まれます。
  • 「製品マニュアル (Product Documentation)」タブには、次のものが含まれます。
    • 新しいフィーチャーのハイライト、製品フィーチャー、およびユーザー補助を含む製品の概説
    • デプロイメントの計画情報
    • 概念検証または開発サーバー用の単一サーバー、スタンドアロン実稼働、およびクラスター実稼働の各環境を対象にしたインストール指示
    • 通常 1 回、またはまれにしか指定されない、ポータル全体に影響する構成オプション
    • 毎日使用する管理タスク
    • 統合に関する指示
    • ポートレットや複合アプリケーションの開発に役立つ開発情報
    • トラブルシューティング情報と、ロギングおよびトレースの情報
    • 問題の診断やトラブルシューティングに役立つメッセージ
  • パフォーマンスおよびチューニング・ガイドなどの補足的な手引き
  • IBM Redbooks
  • ベスト・プラクティス
  • デプロイメント・シナリオ
  • タスク・ベースのデモンストレーションやビデオなどのマルチメディア・オファリング
  • 参照カード
Wiki に関して覚えておく必要があるキーポイントは以下のとおりです。
  • 以前はインフォメーション・センターで配信された情報は、現在 Wiki の「製品マニュアル (Product Documentation)」タブで配信されています。
  • コンテンツは体験主導型です。
  • ユーザーは記事を編集したり、コメントを追加したり、ユーザー独自の記事を作成したりできます。
  • IBM が Wiki をモニターします。
  • 新しい記事、コメント、および最新の編集に関して RSS フィードにサブスクライブできます。

WebSphere Portal Support ページ

Support ページには、次の内容が含まれます。
  • 製品か資料に伴う問題に対応して書き込まれた技術情報
  • フィックスの適用に関する指示を含む、フィックスパックのダウンロード
  • トラブルシューティング情報
  • 優先順位が高い問題に関するフラッシュ
Support ページに関して覚えておく必要があるキーポイントは以下のとおりです。
  • MyNotifications を使用して、更新や新規サポート・コンテンツにサブスクライブできます。
  • IBM Support Assistant などのツールをダウンロードできます。

多機能なフレームワーク

IBM WebSphere Portal Express により、ポータル・アプリケーション上で一貫したビューがユーザーに提供され、 ユーザーは、単一のコンテキストで提供される、特定のアプリケーションのセットを定義できるようになります。 要求を行うデバイスにより、そのデバイスの要件を満たすためのアプリケーション・セットの レンダリングは異なります。

デバイスから要求を受けるたびに、次の集約タスクを実行する必要があります。

  • ユーザー、デバイス、および選択言語に関する情報を収集する。
  • ユーザーにアクセス権があるアプリケーション・セットからアクティブなポートレットを選択する。
  • アクティブ・ポートレットの出力を一貫性があり使用可能な表示内容に集約する。

WebSphere Portal Express には、以下のフィーチャーを含む、カスタム・ナビゲーション・モデルを作成する機能も 用意されています。

  • 複数レベル・ナビゲーション
  • カスタマイズ済みテーマとスキン
  • カスタム・ナビゲーション - ナビゲーション・ツリーはポートレット自体によって提供される
  • ページ上でのポートレット (およびコンテンツ) のカスタム配置

多機能なフレームワークのもう 1 つの特徴として、 ポータルでユーザーおよびユーザーの役割に基づいて登録されているコンテンツを提供する「コンテンツ・スポット」を使用して、ユーザーのポータル環境をパーソナライズする機能があります。

カスタマイズ

ポータルをカスタマイズすることは、IBM WebSphere Portal Express の主な目的の 1 つです。 ページのコンテンツやレイアウトをカスタマイズするためのユーザー向けのポートレットやアドミニストレーター向けのポートレットが用意されています。

ページのカスタマイズ

ユーザーは 1 つ以上のカスタム・ページを作成して、ほかのページからそれぞれのページにアクセスできます。1 つのページには、特定の目的のために編成された、ページのグループを含むことができます。 各ページには、さまざまなポートレットのセットを作成できます。 ユーザーは、それぞれの権限に基づいて、 スキンとページ・レイアウトを使用して、自分のページの外観と雰囲気を変更できます。 また、ページのナビゲーション階層はツリー・ベースであり、ページのネストがいかに深くとも対応できます。

ユーザーまたはアドミニストレーターは、各ページのコンテンツをセットアップすることができます。 アドミニストレーターは、特定のポートレットを必須ポートレットとして指定できます。 ユーザーはこれらの必須ポートレットをページ上で移動したり削除したりすることはできません。 それぞれのページに独自の色体系と列レイアウトを設定できます。

権限のカスケード

アドミニストレーターは、他のアドミニストレーターまたはユーザーに対して、 ページまたはページの一部をカスタマイズする権限を付与したり、取り消したりすることができます。 アドミニストレーターは、ユーザーのページ編集権限を決定できます。 アドミニストレーターは、他のアドミニストレーターがページおよびそのコンテンツに持っている編集権限をコントロールできます。 これは、 組織がポリシーを適用し、整合性を確保して、中央で管理されたコンテンツで地域固有のポータルを作成できるようにすることを目的としています。 例を用いて、このコントロールを分かりやすく説明します。

1 人目のアドミニストレーターが、ページを 3 つの列から構成することを指定し、 他のアドミニストレーターがこの列のレイアウトを変更することを認めないことにするとします。 1 人目のアドミニストレーターよりも持っている権限が少ない 2 人目のアドミニストレーターは、 列のレイアウトを変更することはできませんが、ポートレットを列に追加することはできます。 以下の図に、3 列に分割されたページを示します。 アドミニストレーターは、これらの列にポートレットを追加することができます。

ページの領域を示すこのグラフィックの説明が、このトピックで提供されています。

2 人目のアドミニストレーターは、列 1 に株式ポートレットを追加し、 列 2 に社内ニュース・ポートレットを追加します。 このアドミニストレーターは、誰でもこれらのポートレットを使用できるが、 ポートレットを除去することはできないようにする必要があります。 ただし、アドミニストレーターは列にポートレットを追加することができます。 したがって、ポートレットはロックされ、権限の少ない他のアドミニストレーターは、 このポートレットを除去することができません。 以下の図に、アドミニストレーター間での権限のカスケードの様子を示します。

ページのカスケードを示すこのグラフィックの説明が、このトピックで提供されています。

スキンとテーマ

WebSphere Portal Express は、HTML、カスケード・スタイルシート、イメージ、およびその他の標準 Web 設計成果物を使用して、ページの「外観」を定義します。 Java Server Pages (JSP) および他のサーバー・サイドの動的技法を使用してサイトの「外観」を定義に役立てることもできます。 エレメントを追加または変更すると、WebSphere Portal Express の外観を制御することができます。例えば、会社固有のブランド・エレメントを追加したり、カラー・スキームや表示スタイルを変更したりできます。 色体系やスキンの定義では、各テーマに複数のスキン、ブランド・エレメントを追加したり、ナビゲーション・スタイル、 ブラウザーから独立した動的カスケード・スタイルシートなどを利用できます。

スキンとテーマは、製品全体だけではなく、ページにも適用できます。 ポートレットにも個別に異なるスキンを適用できるため、 ユーザーのニーズに応じてポータルの外観を微調整できます。 ページごとに異なるテーマを使用すると、単一のインストールで多数の仮想ポータルを表示できます。

テーマとスキンを示すこのグラフィックの説明が、このトピックで定義されています。

ブランド・エレメント

マストヘッド、ナビゲーション領域、グラフィックス、ポートレットのタイトル領域、 スタイルシートなどの WebSphere Portal Express の表示エレメントをすべて変更して、 WebSphere Portal Express の外観をカスタマイズできます。 JPEG、GIF、CSS、JSP ファイルなどの標準ファイル・フォーマットを使用して、 外観とレイアウトを定義できます。

コンポーネントのインストール・フォルダーの構造に、「skin」フォルダーと「theme」フォルダーが含まれています。 各フォルダーには、「html」、「wml」、および「chtml」というフォルダーが含まれています。 これらのフォルダーには、ホーム・ページの基本構造、カラー・スキーム、およびポートレットの装飾などを定義するためのほとんどのファイルが含まれています。 ポータル・デザイナーは、これらのフォルダーをコピーして、そのコンテンツを変更すると「 外観と雰囲気」をカスタマイズできます。 テーマ管理ポートレットに、新しいファイルが登録されます。

ポートレット・レイアウトの変更

ドラッグ・アンド・ドロップ機能を使用して、ページ上の個々のポートレットの配置を変更できます。 ページ上のポートレットを再配置するには、ポートレットのタイトル・バーをクリックしてから、そのポートレットをページ上の新しい場所にドラッグします。 「ポートレット・パレット」からページにポートレットをドラッグして、 ポートレットをページに追加し、短時間で簡単にカスタマイズを行うことも可能です。

ユニバーサル・アクセス

ページ・テンプレート、テーマ、スキン、およびポートレット・レンダリングなどのシステムは、 国際化および障害者対応のユーザー補助について完全対応しています。 国際的なアクセスを受けるポータルについては、対象となるブラウザーとその言語および国設定をもとに、WebSphere Portal Express が適当な JSP ページを検索および選択します。

合理化されたサイト作成

IBM WebSphere Portal Express には事前構築済みのサンプル・インターネットおよびイントラネット Web サイトが付属しており、これらのサイトを探索して、さまざまなタイプのコンテンツのオーサリングや管理について学習したり、独自のポータルの開発を合理化するためのテンプレートとして使用したりできます。新規サイト・ウィザードを使用して、独自のポータル・サイトを生成することもできます。

サンプル・サイト

サンプルのイントラネットおよびインターネット・サイトは、WebSphere Portal Express のインストール時に自動的にデプロイされます。

サンプルのイントラネットおよびインターネット・サイトにアクセスするには、メイン・ポータル・バナーの「詳細表示」メニューを使用するか、ブラウザーで該当する URL を開きます。
  • イントラネット・サンプル・サイト: http://hostname.example.com:10039/wps/portal/intranet
  • インターネット・サンプル・サイト: http://hostname.example.com:10039/wps/portal/internet

独自の従業員サイトを作成する開始点として、イントラネット・サイト・テンプレートを使用します。「ホーム」、「作業 (Work)」、および「リソース (Resources)」ページは、現状のまま使用したりカスタマイズしたりできるプレースホルダー・コンテンツでシードされます。 使いやすいリスト・ポートレットにより、アナウンス、ニュース、イベント、FAQ、およびリンクを編成して管理できます。

イントラネット・サイト・グラフィックの説明が、このトピックで提供されます。

インターネット・サイト・テンプレートを使用して、カスタマーが製品のオファリング、マーケティング・プロモーション、および会社ニュースについて学習できる Web サイトの構築を迅速に開始できます。

インターネット・サイト・グラフィックの説明が、このトピックで提供されます。

さらにその他のコンテンツ・サンプルが IBM WebSphere Portal Express Business Solutions Catalog で入手できます。

ポータル・サイトのオンデマンド作成

「新規サイト・ウィザード」を使用して、独自のサイトを生成します。ポータル開発のスキルや管理者からの支援は必要ありません。使用可能なサンプルからサイト・テンプレートを選択し、ご希望の外観を選択してから、残りの作業をウィザードに行わせるだけです。

このウィザードは、新しいサイトを仮想ポータルとして自動的に作成します。しかし、管理者および開発者は、このウィザードを拡張して不特定型のポータル・サイトを作成できます。ポータル開発者は、カスタム・サイト・テンプレートを作成してからウィザードに追加することにより、「新規サイト・ウィザード」を拡張することもできます。

「新規サイト・ウィザード」は、IBM WebSphere Portal Express Business Solutions Catalog からダウンロードします。パッケージのコンテンツにはポートレット .war (Web Application Archive) ファイル、サポート・ファイルとディレクトリー、および .pdf ファイル形式の詳細な指示が含まれています。ウィザードのデプロイ後に、ユーザーがアクセスできるページにポートレットを追加する必要があります。詳しくは、ウィザードに付属の .pdf ファイルを参照してください。

「新規サイト・ウィザード」画面。この図について詳しくは、このトピックのテキストを参照してください。

ポートレット

ポートレットは、IBM WebSphere Portal Express の中心的なパーツです。 ポートレットは、 個別に開発、デプロイ、管理、および表示される小さいアプリケーションです。 アドミニストレーターとユーザーは、ポートレットを選択および配列して、個別設定されたページを作成し、Web ページをカスタマイズできます。

WebSphere Portal Express には、多数の標準ポートレットが付属しています。 ダウンロード可能な最新のポートレットなどのポートレットの最新情報については、「IBM WebSphere Portal Business Solutions Catalog」を参照してください。 また、カスタム・ポートレットの作成について詳しくは、『ポートレットの開発』を参照してください。

ポートレット・アプリケーション

ポートレットは、既存の単純な Web コンテンツとは異なります。 ポートレットは、標準のモデル表示コントローラー設計を 使用した 1 つの完全なアプリケーションです。 ポートレットには複数の状態と表示モードのほか、イベント機能やメッセージング機能があります。

ポートレットは、Application Server 上でサーブレットが動作するのと同じように、Application Server 内で動作しますが、WebSphere Portal サーバーによって複数のポートレットが集約され、1 つの完全な Web ページにまとめられます。 ポートレット・コンテナーは ランタイム環境を提供し、ここでポートレットのインスタンス化、使用、そして最後に破棄が行われます。 ポートレットは、ユーザー・プロファイル情報へのアクセス、ウィンドウおよびアクション・イベントへの参加、 他のポートレットとの通信、リモート・コンテンツへのアクセス、クリデンシャルの検索、および永続データの保管などにおいて、WebSphere Portal Express インフラストラクチャーに依存します。

一般的に、ポートレットはサーブレットよりも動的に管理します。 例えば、WebSphere Portal コンポーネントを実行中に、いくつ かのポートレットからなるポートレット・アプリケーションをインストールしたり削除したりできます。 実稼働環境の場合でも、WebSphere Portal を実行中に、アドミニストレーターはポートレットの設定値やアクセス権を変更できます。

ポートレットの各モードでは、ポートレットが必要とするタスクに応じて、異なるユーザー・インターフェースを表示できます。 ポートレットにはいくつかの表示モードがあり、ポートレット・タイトル・バー上のアイコン (「表示」、「ヘルプ」、「編集」、「構成」、「共用設定の編集」) を使用して呼び出すことができます。

ポートレットは、最初は表示モードで表示されます。ユーザーがポートレットを使用すると、フォームと応答、エラー・メッセージ、その他のアプリケーション固有の状態など、一連のビュー状態をポートレットに表示できます。「ヘルプ」モードでは、ユーザーにヘルプが提供されます。 ユーザーは「編集」モードでポートレットの設定を変更できます。例えば、Weather ポートレットでは、ユーザーが場所を指定するための「編集」ページが表示されます。 「編集」モードにアクセスするには、ユーザーは WebSphere Portal Express にログインする必要があります。「構成」モードではすべてのポートレット・インスタンスに関するポートレットのデフォルトの外観が変更され、「共用設定の編集」では特定のページ上のポートレットの外観が変更されます。

それぞれのポートレット・モードの表示には、標準、最大、最小を選択できます。 ポートレットを最大化すると、ポートレットはページ全体に表示されるので、その他のポートレットは表示されません。 ポートレットを最小化すると、デフォルトでは、ページ上にポートレット・タイトル・バーだけが表示されます。

ポートレット API

Java Portlet Specification は、ポータル環境で実行されるポートレットの集約、Personalization、 プレゼンテーション、およびセキュリティーの要件を指定したものです。 WebSphere Portal Express は、ポートレット規格 JSR 168 および JSR 286 を両方ともサポートしています。 標準ポートレット API について詳しくは、標準ポートレット API に関するトピックを参照してください。

ポートレット通信

WebSphere Portal Express を使用すると、ポートレットが互いに通信できます。 ポートレット通信を使用して、ポートレット間でデータを交換できます。 したがって、ポータルが使いやすくなります。

ポータルは、JSR 286 仕様の定義どおりにイベントをサポートします。 管理者は、ポータル・ユーザー・インターフェースを使用してポートレットをワイヤリングできます。

例えば、1 つのポートレットでアカウントに関する情報を表示し、2 番目のポートレットでは、そのうちの 1 つのアカウントについて過去 30 日分のトランザクションに関する情報を表示することができます。これをするには、トランザクション・ポートレットがトランザクション詳細を表示するときに、該当のアカウント情報を取得する必要があります。この操作は、JSR 286 仕様の記述どおりにイベントを使用して、2 つのポートレットがお互いに通信することで達成されます。 この例では、アカウント・ポートレットがポートレット記述子内で公開イベントを定義します。 トランザクション・ポートレットは、ポートレット記述子内で処理イベントとしてこのイベントを定義します。 ポータル・ユーザー・インターフェースを使用すると、これらの 2 つのポートレットを一緒にワイヤリングできるようになります。 ワイヤリング後、アカウント・ポートレットがイベントをスローすると、トランザクション・ポートレットはこのイベントを受け取り、このアカウントのトランザクションに関する情報を表示できます。

ポートレット・サービス

ポートレット・サービスは、各ポートレットに共通機能を提供する場合に使用します。 各ポートレット・サービスには、提供する機能用の独自のサービス固有のインターフェースがあります。WebSphere Portal Express では、標準ポートレット用のポートレット・サービスがサポートされています。 標準ポートレットでは、JNDI 検索を使用して PortletServiceHome オブジェクトを検索します。このオブジェクトは、ポートレット・サービス実装を検索する場合に使用します。 ポートレット・サービスは、ポートレット内部のコードによってのみ起動されます。 ポータル内のポートレット・サービスについて詳しくは、ポートレット・サービスに関するトピックを参照してください。

ポータル・コンテンツのタグ付けおよびレーティング

ユーザーはポータル・コンテンツにタグ付けやレーティングを行うことができ、そのタグやレーティングを表示できます。 タグ付けやレーティングにより、ユーザーはポータル・コンテンツをより効率的に編成、分類、および検索することができます。 これには Web Content Management コンテンツやカスタム・コンテンツなど含まれます。 例えば、ユーザーはオンライン・ブック・ストアで本にタグ付けしたり、レーティングしたりすることができます。

注: デフォルトのポータル・インストール環境では、ページ・ビルダー のテーマのページのタグ付けおよびレーティングのみをサポートしています。 したがって、Portal テーマをデフォルトのサイト・テーマとして選択する場合は、タグ・センターが予期したように表示されない場合があります。
Portal ユーザーはポータルのコンテンツをタグ付けまたはレーティングすることができます。これには次のタイプのリソースが含まれます。
  • ページおよびポートレットなどのポータルのリソース
  • 記事や画像などの Web Content Management のリソース
  • カスタム・リソース。例えば、オンライン・ストアの品目やポートレット内のピクチャーなどが可能です。 管理者はこれらのカスタム・リソースにユーザーがタグ付けしたり、レーティングしたりすることができるように、これらをポータルに追加できます。
一般に、ポータル内で一意的に識別できるすべてのコンテンツに対してはタグ付けやレーティングができます。
ユーザーは次の目的のために、タグおよびレーティングを公開で、および私用で適用できます。
  • 公開のタグ付けおよびレーティングは、他のユーザーによるタグ付けおよびレーティングに基づいて、ユーザーがポータル・コンテンツを分類、評価、検索するのに役立ちます。
  • 私用のタグ付けおよびレーティングは、ユーザーが自身の個人的な方法を作成してポータル・コンテンツの分類、評価、検索を行うのに役立ちます。
ポータルではタグ付けおよびレーティングのために、2 つのユーザー・インターフェースが用意されています。
  • デフォルトのユーザー・インターフェース。これにより、ユーザーはリソースのタグ付けおよびレーティングを行い、複数のリソースのタグおよびレーティングを表示できます。
  • デフォルトのインターフェースの代わりに、インライン・ウィジェットを処理するユーザー・インターフェースも使用できます。 これは、各リソースのコンテキストで、個々のリソースのタグ付けおよびレーティングを表示します。 このユーザー・インターフェースはデフォルトで、ブログおよび Wiki で使用可能です。 管理者はこのユーザー・インターフェースを他のタイプのリソースに追加することもできます。
詳細として、ポータル・ユーザーは次のタスクを実行することができます。
  • タグの処理。
    • ポータル・コンテンツのタグ付け。ユーザーはポータル・コンテンツにタグを追加できます。例えば、タグ websphere を、IBM WebSphere 製品に関する情報を提供するページに適用することができます。ユーザーは、自分が付けたタグを削除できます。
    • タグおよび関連したポータル・コンテンツの表示。ユーザーは個々のポータル・リソースに付けたタグを、例えばデフォルトのタグ・ウィジェットおよびレーティング・ウィジェットを呼び出すことにより、表示できます。 また、ユーザーは選択されたタグの集約セットを処理することもできます。
      • ユーザーはタグ・クラウドを使用することにより、あるリソース・セットに付けたタグを表示できます。タグ・クラウドはタグをアルファベット順にリストします。異なるフォント・サイズは、タグがどれだけ頻繁に付けられたかを示します。 管理者がタグ・クラウドを構成した方法に応じて、リストはポータル全体にわたることも、特定の項目に限定することも可能です。例えば、ポータル・ページのリストや、ユーザーがタグをクリックしたページで入手可能な本のリストにすることができます。
      • タグ・クラウドはさまざまなビューをサポートしており、ユーザーはこれらのビューを切り替えることができます。 例えば、すべてのタグの表示、自分が付けたタグのみの表示、自分の私用タグの表示、一番新しく追加されたタグの表示、などを切り替えられます。
      • ユーザーは異なる表示モードを切り替えることができます。例えば、前述のようにクラウドでタグを表示したり、単純なリストで表示したりすることができます。
      • ユーザーはタグ・クラウドで表示されたタグを使用してコンテンツを検索できます。 ユーザーがタグをクリックすると、そのタグの付いたリソースのリストがポータルに表示されます。 そのようなリソースをクリックすると、ユーザーはそのリソースそのものにリダイレクトされます。 複数のタグをクリックすることもできます。その場合、リストには選択したすべてのタグが付いたリソースのみが表示されます。
      • ユーザーがリソースのリストを操作する場合に、タイトル、日付、レーティングなど、さまざまな基準でリストをソートできます。 この結果のリスト・ポートレットでも 2 つの表示モード、要約ビューと詳細ビューがサポートされています。
  • レーティングの処理。
    • ポータル・コンテンツのレーティング。
      • ユーザーは個々のリソースにレーティングを付けて、そのリソースを「好む」程度を示すことができます。 例えば、ユーザーが良い本に 4 のレーティングを与える場合があります。
      • ユーザーは自分が付けたレーティングを変更したり削除したりすることができます。 例えば、あるユーザーが前回付けたレーティングの 45 に更新することができます。
    • ユーザー自身や他のユーザーがポータル・コンテンツに付けたレーティングの表示。
管理者は次のタスクを実行できます。
  • 上記にリストした、ポータル・ユーザーが実行できるすべてのタスク。
  • ユーザーがタグ付けやレーティングをできるコンテンツの追加 (ブック・ストアの本など)。
  • ユーザーがコンテンツのタグ付けやレーティングを行うためのアクセス権限の割り当て。
  • タグ・クラウドの構成。デフォルトで、タグ・クラウドはポータル全体のリソースに付けられたすべてのタグを表示します。 管理者は必要に応じてタグ・クラウドをポータル・ページやポータル・テーマに追加して、それらを構成することができます。 例えば、タグ・クラウドを制限して、あるカテゴリー (ポートレットなど) のリソースに割り当てられたタグのみを表示するようにできます。 ユーザーがそのタグ・クラウドからタグをクリックすると、結果リストにはリソースのみ (この場合はポートレット) が表示されます。
  • タグを別のポータル・システムに移動 (例えばステージングのためや、マイグレーション時)。
  • タグ付けおよびレーティングについての基本的な統計の取得。例えば、特定のポータル・ページのタグおよびタグ数を入手したり、特定のユーザーが付けたすべてのタグを取得できます。 さらに詳細な統計を取得するために照会を作成したり、それらを視覚化するためのユーザー・インターフェースを作成したりすることができます。
開発者は次のタスクを実行できます。
  • Java Model API や REST API を使用するカスタム・ユーザー・インターフェースを作成することにより、ポータルのタグ付けおよびレーティング機能を拡張。
  • タグ付けおよびレーティングに関する統計を取得するための照会の作成、およびそれらの統計を視覚化するためのユーザー・インターフェースの作成。
  • フィルターの使用可能化または使用不可化。例えば、ユーザーがタグとして望ましくない単語を使用しないようにします。 デフォルトで、ポータルにはブラックリスト・フィルターおよびホワイトリスト・フィルターが用意されています。
注: ポータルおよびユーザー・グループによっては、管理者または開発者がポータル・ユーザーに対して、タグ付けおよびレーティングに関するエンド・ユーザー向け資料の作成を検討する場合があります。

ブログおよび Wiki

ブログおよび Wiki 機能を Web サイトに追加するために、プリインストールされた Web コンテンツ・ライブラリーのセットが提供されています。 ブログ、ブログ・ライブラリー、および Wiki を使用して、コミュニティーの能力を活用し、作業する方法を変更します。

ブログは、単一のトピックに関するアイデアを生み出したい場合に使用できる優れたツールです。 ブログは、自分個人の作業に使用したり、より大きなチームから単一の概念に関するフィードバックを得るために使用したりできます。 ブログ・ライブラリーは、ブログを次のレベルに引き上げます。ブログ・ライブラリーを使用することにより、トピックごとにブログを作成する代わりに、一元化された場所で複数のトピックを追跡することができます。 さらに、Wiki は、コンテンツをオーサリングするためのもう 1 つの代替方法を提供します。 イメージおよびリンクの挿入を含む、単純なインライン編集によって、Wiki のオーサリングは迅速かつ簡単になります。また、ブログおよび Wiki のコンテンツにタグ付けおよびレーティングを行うこともできます。

ブログ、ブログ・ライブラリー、および Wiki は、IBM Lotus Web Content Management で提供されるテンプレート・ライブラリーを使用します。各ブログ、ブログ・ライブラリー、および Wiki には独自のライブラリーが存在します。 これらのコンポーネントで提供されるページ階層は、Web Content Management テンプレート・ライブラリーで定義される一般的なページ階層です。

アプリケーションの統合

ポータルを使用すると、企業内に存在するコンテンツ、データ、サービスなどにアクセスできます。 これらのサービスには、 所定の、あらかじめ定義されたコネクターおよびポートレットと、 コネクターおよびポートレットを追加作成するためのツールが含まれます。

エンタープライズ・リソース・プランニング (ERP) およびカスタマー・リレーションシップ・マネージメント (CRM) の 2 つのシステムはポートレットとして最適の対策となります。 効率の良い、個別のアクセスを使用してさまざまな機能にアクセスできますので、ポータルでは納得のいく投資回収を見込めます。IBM では、Java Connector Architecture (JCA) を使用して、エンタープライズ・アプリケーションへのコネクターを提供しています。

標準 Java コネクター

JCA は、Java 2 Enterprise Edition (J2EE) アプリケーションをリレーショナル・データベース以外のエンタープライズ情報システムに統合するための標準アーキテクチャーです。 呼び出す機能の識別、入力データの指定、および出力データの処理について、それぞれのシステムがネイティブの API を提供します。 JCA の目的は、こうした機能をコード化するための独立した API を提供することです。

さらに JCA は、標準的な Service Provider Interface (SPI) を定義して、 アプリケーション・サーバーとトランザクション・リソース・マネージャーのトランザクション、セキュリティー、および接続管理機能を統合します。このため、JCA では、エンタープライズ・アプリケーション・システムへの接続管理、トランザクション、およびセキュア・アクセスについて、規格をベースにしたアプローチを利用しています。 IBM JCA コネクターは、 SAP、PeopleSoft、J.D. Edwards、Oracle Enterprise Edition CICS、 IMS、および Host-on-Demand などのシステムへのアクセスを提供します。 IBM は CrossWorlds の買収により、さらに多くのシステムに対応する JCA コネクターの開発および統合を計画しています。

Rational Application Developer は、JCA コネクター、Web サービス、 およびマイクロフローを使用するアプリケーション用の完全な開発および単体テスト環境を提供します。Rational Application Developer ツールには、Web Service Definition Language (WSDL)、 開発者バージョンのコネクター、Web Services Invocation Framework (WSIF)、 およびマイクロフロー・エンジンに対するサポートが含まれています。

コラボレーション

IBM WebSphere Portal Express のコラボレーション機能は、Lotus Domino および Extended Products ポートレット を介して提供されます。 Lotus Domino and Extended Products には、Lotus Domino Enterprise Server と IBM Lotus Sametime があります。

ポートレットは、Lotus Domino Server 製品を WebSphere Portal Express に完全に統合する際に使用するメカニズムです。Lotus Lotus Domino および Extended Products ポートレット は、ユーザー認識を用いるオンライン・ディレクトリーと、オンライン会議を管理するための統合ツールを提供します。これらすべてのコラボレーション機能は、ビジネス目的達成のために組織の社員が協働し、情報をオンラインで共用しやすくします。コラボレーション・ポータルにより、 組織の反応性、革新性、能力、および作業効率を改善できます。

IBM Lotus Domino および IBM Lotus Sametime のサポートされるバージョンについては、WebSphere Portal Express の詳細なシステム要件を参照してください。

コラボレーション・ポートレット

Lotus Domino および Extended Products ポートレットのすべての事例が、「コラボレーション」ページおよび「メッセージング」ページに提供されています。ポートレットは、WebSphere Portal Express ととも にインストールされ、自動的にデプロイされるため、アドミニストレーターが、サーバーの数やその他の構成タスクを行うだけで、 ユーザーは一連の統合されたコラボレーション・アプリケーションを使用することができます。

Lotus Domino および Extended Products ポートレット には以下が含まれます。

  • iNotes®
  • Sametime コンタクト・リスト
  • Lotus Notes ビュー
  • ピープル・ファインダー
  • 在席リスト

在籍確認

ユーザーは、ユーザー・カードを表示することにより、登録ユーザーの一般的な名刺情報 (連絡先など) を見ることができます。ユーザー・カードは、Lotus Domino および Sametime 統合、複合アプリケーション、パーソナライゼーション、Web コンテンツ・オーサリングなどを含む幅広いポータル・コンポーネントを通じて使用可能です。 ユーザー・カードを表示するには、アクティブな (下線付きの) ユーザー名の上にカーソルを移動し、「クリックしてユーザー・カードを表示」を選択します。

ポータル構成でLotus Sametime を使用可能にすると、ユーザーは、 インスタント・メッセージングおよび e ミーティングによるアプリケーション共用を含め、 ユーザー認識機能の完全なセットを使用して作業することができます。 ユーザー名は、動的オンライン状況標識とともに認識 されます。「プロファイル」をクリックすると、ユーザーに関する完全な情報が表示されます。追加のアクションには以下のようなものがあります。

  • メールの送信
  • チャット
  • Sametime コンタクトとして追加

ポータル構成で Lotus Sametime を使用可能にしないことを選択すると、ユーザー認識機能が制限されます。個人の名前はハイパーリンクとして表示されますが、それぞれの名前の横にユーザー認識アイコンは付きません。また、ユーザー・カード上で実行可能なアクションは、WebSphere Portal Express にネイティブなもののみに限定されます。

ユーザー補助機能

ユーザー補助機能は、運動障害または視覚障害など身体に障害を持つユーザーがソフトウェア・プロダクトを快適に使用できるように サポートします。

このバージョンの IBM WebSphere Portal Express は、以下をサポートしています。

  • コンソール・モード というコマンド行インターフェースによるインストールをサポート。このインストールは、グラフィカル・ユーザー・インターフェースを使用したインストールと同等のユーザー補助です。
  • スクリーン・リーダーおよび画面拡大機能で一般的に使用されるインターフェースをサポート (Windows のみ)
  • 画面の表示内容を聞き取るために、スクリーン・リーダー・ソフトウェアおよびディジタル音声シンセサイザーの使用をサポート
  • キーボードのみを使用して操作可能
  • 時刻指定応答を完了する時間をさらに要求することが可能
  • カラー、コントラスト、フォント・サイズなどの表示属性のカスタマイズをサポート
  • カラーとは関係なく、すべての情報を伝達
  • 代替入出力デバイスの接続をサポート
  • 音声情報の代替手段をサポート
  • 調整可能なボリューム制御をサポート
  • てんかん発作を誘発する可能性のあるレートで画面が明滅しない
  • 利用できるフォーマットでドキュメンテーションを提供
注: スクリーン・リーダーを使用して WebSphere Portal Express を表示する際に最善の結果を得るには、Freedom Scientific JAWS 11 以上と Firefox 3.5 以上を併用してください。
ユーザー補助を強化するため、資料に、次のような機能が含まれています。
  • すべての資料は、スクリーン・リーダー・ソフトウェア・テクノロジーの適用の可能性が最大となる HTML 形式で入手可能。
  • 資料内のすべてのイメージは、視覚障害のあるユーザーがイメージの内容を理解できるように、代替テキストと共に提供される。

該当する場合は、特定の製品機能のドキュメンテーションに、ユーザー補助に関する追加情報が含まれています。

ユーザー補助に対する IBM のコミットメントについて詳しくは、IBM Human Ability and Accessibility Centerを参照してください。

非推奨の機能

IBM WebSphere Portal Express の旧バージョンで使用できたものの、このバージョンまたは今後のバージョンでは使用できない機能についての注記です。

準備が整い次第、非推奨の機能からの移行に役立つ、追加の情報へのリンクが提供されます。

Exchange、Lotus Domino、および POP3 が、Common Mail Portlet でサポートされるプロトコルではなくなりました。

これまで Exchange で CPP を使用していた場合は、Exchange のポートレットを使用できるようになりました。

これまで Lotus Domino で CPP を使用していた場合は、iNotes ポートレットを使用できるようになりました。

RSS ポートレットおよび IBM フィード・リーダー・ポートレットは出荷されなくなりました。

これまで RSS ポートレットまたは IBM フィード・リーダー・ポートレットを使用していた場合は、IBM Syndicated Feed Portlet for WebSphere Portal Express を使用できます。代わりに、RSS ポートレットおよび IBM フィード・リーダー・ポートレットを IBM WebSphere Portal Express Business Solutions Catalog からダウンロードできます。

Common Calendar ポートレットが、同梱されなくなりました。

これまで Exchange で CPP を使用していた場合は、Exchange のポートレットを使用できるようになりました。

これまで Lotus Domino で CPP を使用していた場合は、iNotes ポートレットを使用できるようになりました。

Document Manager
WebSphere Portal Express のこのバージョンでは、Document Manager を使用できなくなりました。 文書ライブラリーを引き続き使用する必要がある場合は、その文書ライブラリーを IBM Lotus Quickr サーバーに移動する必要があります。詳しくは、WebSphere Portal Express Best Practices Wiki を参照してください。
複合アプリケーションのワークフロー
このバージョンでは、複合アプリケーションのワークフローを使用できなくなりました。
コラボレーション・ポートレット
以下のコラボレーション・ポートレットは、WebSphere Portal Express に含まれなくなりました。
  • My Lotus QuickPlaces
  • インライン QuickPlace
  • Lotus Domino Document Manager
  • Lotus Web Conferencing
注: Lotus QuickPlaces は、IBM WebSphere Portal Business Solutions Catalog からダウンロードできます。
レガシー・サンプル・ポートレット
以下のレガシー・サンプル・ポートレットは提供されなくなりました。
  • SPFLegacyBlank.war
  • SPFLegacyClock.war
  • SPFLegacyCommandManager.war
  • SPFLegacyEditMode.war
  • SPFLegacyFileUpload.war
  • SPFLegacyLookupAction.war
  • SPFLegacyMailReader.war
  • SPFLegacyMultipleServletContexts.war
  • SPFLegacyStockQuote.war
  • SPFLegacyTiles.war
  • SPFLegacyTransformation.war
Microsoft Exchange 2000 ポートレット・アプリケーション
Microsoft Exchange 2000 ポートレット・アプリケーションは含まれなくなりました。 このポートレット・アプリケーションは、次のポートレットを含んでいます。
  • MS Exchange 2000 Mail ポートレット
  • MS Exchange 2000 Calendar ポートレット
  • MS Exchange 2000 Tasks ポートレット
  • MS Exchange 2000 Contacts ポートレット
  • MS Exchange 2000 Notes ポートレット
トランスコーディング・テクノロジー
今まで WebSphere Portal Express に提供されていたトランスコーディング・テクノロジーは、このバージョンでは廃止されています。
ブラウザー・サポート
このバージョンでは、以下のブラウザーはサポートされなくなっています。
  • Mozilla
  • Netscape
ポータル・スクリプト・インターフェース用の JACL 構文
ポータル・スクリプト・インターフェース用の JACL 構文は、WebSphere Portal Express バージョン 6.1 で Jython 構文に置き換えられています。 JACL 構文は引き続きサポートされますが、このサポートは今後、廃止される予定です。
専用ワイヤー API
専用ワイヤーを参照する WireModel 成果物は、WebSphere Portal Express バージョン 6.1.0.1 以降推奨されなくなりました。
IBM ポートレット API の Web コンテンツ・ビューアー・ポートレット
バージョン 7.0 では、IBM ポートレット API に基づく Web コンテンツ・ビューアー・ポートレットは使用されなくなり、JSR 286 Web コンテンツ・ビューアー・ポートレットに置換されました。
IBM ポートレット API のリモート Web コンテンツ・ビューアー・ポートレット
バージョン 7.0 では、IBM ポートレット API に基づくリモート Web コンテンツ・ビューアー・ポートレットは使用されなくなりました。 Web Content Management がインストールされていないポータル上に Web コンテンツを表示する場合は、WSRP および JSR 286 Web コンテンツ・ビューアーを使用します。Web コンテンツをバージョン 7.0 より前のリモート Web Content Management システムから表示する必要がある場合、引き続きリモート・サーバーから IBM API のリモート Web コンテンツ・ビューアー・ポートレットを使用できます。

インストール

IBM WebSphere Portal Express は、機能の検査とテストができる PoC (概念検証) から使い勝手がよく拡張が容易な実稼働環境まで、柔軟なデプロイメント・オプションを提供します。ハードウェアおよびソフトウェア要件、高可用性、拡張容易性、サポートされているトポロジーなどについてさらに知るため、計画情報をレビューしてください。オペレーティング・システムを選択してから、業務上の必要を最もよく反映できるインストール・パターンを選択してください。

重要: WebSphere Portal Express のインストール後に、マッシュアップ統合の使用を計画している場合は、「マッシュアップ統合」 > 「ポータルおよびマッシュアップの構成」 > 「ポータルでのマッシュアップ統合の使用可能化」のトピックにリストされている deploy-portal-mashup-ui タスクを実行する必要があります。

WebSphere Portal Express をインストールするための計画

実稼働環境で IBM WebSphere Portal Express をインストールする前に、ハードウェアおよびソフトウェアの要件、可能なデータベース構成、セキュリティー・オプション、および LDAP サーバー・オプションを考慮する必要があります。 この重要なステップを省略すると、予期しない結果とコストの高い遅延が発生する可能性があります。

このタスクについて

システム要件

IBM WebSphere Portal Express をインストールする前に、ハードウェアとソフトウェアの要件を確認して、サポートされているバージョンの前提条件ソフトウェアと相互に必要なソフトウェア、および必須ハードウェアがあることを確認します。

システム要件の詳しい資料については、以下の URL を参照してください。
http://www.ibm.com/support/docview.wss?uid=swg27007791

リリース・ノート

既知の問題は、まとめてサポート・ページで説明されています。 サポート知識ベースへのリンクがインフォメーション・センター全体に組み込まれており、最新の情報を確実に得られるようにしています。 インストール・プロセスを開始する前に、IBM サポート・サイトを調べて、既知の制限事項または問題に関する最新情報を確認してください。 このリリースに関する最新の情報を検索するには、以下の動的照会を使用してください。

以下のリンクは、識別されている領域に関する技術情報の最新リストを返します。 所定のトピックの領域に関する技術情報が公開されていない場合は、リンクは技術情報を返さず、検索を詳細化するよう指示されます。

インストールおよび構成の問題に関する技術情報
http://www.ibm.com/support/search.wss?amp;atrn=SWVersion&atrv=7.0&tc=SSCPKQ9+SSC3QNP
マイグレーションの問題に関する技術情報
http://www.ibm.com/support/search.wss?amp;atrn=SWVersion&atrv=7.0&tc=SSCPKQB
データベース接続の問題に関する技術情報
http://www.ibm.com/support/search.wss?amp;atrn=SWVersion&atrv=7.0&tc=SSC3QNK
このリリースに関するすべての技術情報
http://www.ibm.com/support/search.wss?amp;atrn=SWVersion&atrv=7.0

また、インフォメーション・センターから直接、サポート・サイトを検索できます。 IBM Support Web サイトにおける解決策の検索 のトピックを参照してください。

WebSphere Portal Express サポート・ステートメント

このサポート・ステートメントでは、IBM WebSphere Portal Express が正常に動作するために依存している各種製品に関して、「サポート」および「非サポート」の定義の改訂を提案しています。

概要

WebSphere Portal Express には、それが正常に動作するためのいくつかの付随製品が必須です。特に、Portal は WebSphere Application Server、データベース、ユーザー情報用のリポジトリー (一般には LDAP)、および特定のカスタマー要件に応じたその他の製品を必要とします。

新規リリースのテスト時には、開発は一般に、 これらの付随製品の所定のリストを使用して WebSphere Portal Express をテストします。これらの製品は、そのリリース用のハードウェア要件およびソフトウェア要件に関する文書で「サポート製品」として指定されています。

「サポート製品」のリストには、お客様が使用する必要があると考えられる構成をすべて記載できるわけではないので、一部のお客様からは、具体的に「サポートされる」として示されていない構成に対して提供されるサポートのレベルについて不安の声が寄せられています。本書は、依存製品をさまざまに組み合わせて使用している現在のリリースに対して一般的に期待できるサポート・レベルを説明することを目的としています。

注: この文書のステートメントは、WebSphere Portal Express に対して期待できる一般的なサポート・レベルを反映していますが、実際に提供される製品のサポートは、特定のサポート・オファリング、ライセンス、または IBM と交わされるその他の契約の条件によって決まります。ここでの内容を、WebSphere Portal Express に関する IBM ご使用条件または IBM と交わされるその他の契約の補足、変更、または置き換えと解釈しないでください。また、ここでの内容によって、そのような契約で発生すると考えられるサポートとは異なるレベルのサポートを提供する義務を IBM が負うものでもありません。

サポートのカテゴリー

WebSphere Portal Express に付随する製品のサポートには、3 つのカテゴリーがあります。 それは、「サポート製品」、「サポート製品の最新バージョンおよびリリース」、「非サポート製品」の 3 つです。 カテゴリーごとの定義およびサポート・ステートメントは以下のとおりです。

サポート製品
「サポート製品」とは、開発によってテストされ、WebSphere Portal Express で動作することが判明している (指定されたバージョン、リリース、および修正レベルにある) 製品です。

このカテゴリーの製品は、WebSphere Portal Express のご使用条件の条項ごとにサポートされます。PMR (問題管理レコード) は、WebSphere Portal Express ご使用条件の条件に従って IBM サポートによって受け入れられます。

サポート製品の最新バージョンおよびリリース
「サポート」バージョンの特定のバージョン、リリース、またはフィックスパック以外の多くの製品 (ハードウェア要件およびソフトウェア要件に関する文書で解説しています) は、IBM WebSphere 開発によって明示的にテストされていない場合がありますが、お客様の信頼性、機能、およびパフォーマンスの許容範囲内で動作するとお考えください。

このカテゴリーに該当するのは、通常、すでに「サポート製品」のカテゴリーに分類されている比較的新しいリリースまたは修正レベルの製品か、 WebSphere Portal Express がサポートする標準 API に準拠する製品 (LDAP サーバーなど) です。 例えば、オペレーティング・システムの最近の修正レベル、最初に「サポートされている」フィックスパック・レベルよりも新しい WebSphere Application Server (WAS) のフィックスパック、IBM Java (JVM) フィックスパック、DB2 の新規のフィックスパックまたはリリース、更新済みの LDAP サーバーなどがあります。

このカテゴリーに当てはまる製品には以下のサポートがあります。

IBM Directory Server または Lotus Domino LDAP、IBM DB2、IBM JDK (JVM)、および WebSphere Application Server などの IBM 製品の場合、WebSphere Portal Express は、WebSphere Portal Express がその機能を得るために依存しているインターフェースまたはその他の基本サポートからわずかしか変更されていないフィックスパック、リリース、およびバージョンの更新をフルサポートします。WebSphere Portal Express が対応できない、これらの製品の 1 つの最新リリースが出荷された場合は、『非サポート製品』というタイトルの次のセクションで説明しているように、そのことが示されます。 WebSphere Portal Express がデータベース製品または LDAP 製品への更新をサポートするためには、WebSphere Application Server もその更新をサポートする必要があります。

IBM 以外の製品の場合、サポート・チームは、商業的に妥当と思われる作業でこのカテゴリーの製品をサポートします。サポートは、これらの未テスト製品を使用している、該当するリリースの問題報告 (PMR) を受け入れます。 サポートが、報告された問題を「サポート」バージョンの製品を使用して再現できる場合は、その問題を修正します。

サポートは、問題の生じている「サポート」バージョンの製品を使用して問題を再現できず、 未テスト・バージョンの該当する製品の問題を解決できない場合、その製品のサポート組織に依頼して解決を図ります。 IBM 以外の製品に対してこのプロセスを処理するには、程度はさまざまですが、お客様に何らかの形で協力していただく必要があります。

当該の未テスト製品のサポート組織が問題を解決できない場合、サポートは、当該の未テスト製品のそのバージョン、リリース、またはフィックスパック・レベルを「非サポート製品」とみなします。

非サポート製品
「非サポート製品」とは、WebSphere Portal Express では動作せず、そのためサポートされないことが判明している (指定されたバージョン、リリース、および修正レベルにある) 製品です。 製品がこのカテゴリーに含まれるのは、開発によって明示的にテストされた結果、または前のカスタマーの問題からそのことが発見された場合です。WebSphere Portal Express サポート・チームは、判明しているすべての「非サポート製品」のリストを WebSphere Portal Express リリースごとに管理しています。 このリストは、すべてのお客様が入手可能な techdoc として、Web で公開されています。

WebSphere Application Server には Web 上で参照できる類似のサポート・ステートメントがあります。

注: WebSphere Application Server は、特定のプラットフォームに関する IBM Java SDK の特別にカスタマイズされたビルドを使用しています。これらに対する更新は、WebSphere Application Server サポートから入手できます。

WebSphere Portal Express は、 基礎となる WebSphere Application Server の変更に左右されやすくなる可能性があります。 WebSphere Application Server のすべての必要な修正が、新しいフィックスパックに統合されるか、特にその保守レベルの暫定修正を適用することによって入手可能である限り、アプリケーション・サーバーの新しいフィックスパック・レベルへのアップグレードは耐用性が良好であり、推奨されています (WebSphere Application Server バージョン 7.0 から 7.0.x など)。ただし、WebSphere Application Server の 1 つのバージョンから次のバージョンへのアップグレード (例えば 6.1 から 7.0 へ) は、それがバージョンのマイグレーション作業の一部として実行されるのでない場合、大いに問題があり、「現場の」システムでは決して実行するべきではありません。

LDAP サーバーのサポート

LDAP サポートには以下の 2 つのカテゴリーがあります。

完全にテストされサポートされている LDAP サーバーの場合:
WebSphere Portal Express の各リリースの 完全にテストされている LDAP サーバーのリストは、リリース毎に詳細なシステム要件内で文書化されています。システム要件について詳しくは、下記のリンクを参照してください。 WebSphere Portal Express サポートでは、テスト済みのディレクトリー・サーバーを使用して、該当する WebSphere Portal Express リリースの 問題の報告に応じます。これらの問題報告は、高い優先順位で処理されます。これらのディレクトリーでテストされる機能は、 ユーザーおよびグループ・オブジェクトの比較的単純な検索と取得機能などです。この範囲外の機能 (Active Directory の「グローバル・カタログ」機能など) は拡張機能と考えられ、WebSphere Portal Express ではテストされていません。WebSphere Portal Express サポートでは、お客様が LDAP プロバイダーと連絡を取り、これらの拡張機能に対する追加サポートを受けることができるよう支援します。
テスト済みでない、また部分的にサポートされている LDAP サーバーの場合:
一般的に、WebSphere Portal Express サポートでは、WebSphere Portal Express でテストされていないディレクトリー・サーバーのサポートに最善を尽くしています。 WebSphere Portal Express サポートでは、テストされていないディレクトリー・サーバーを使用して、該当する WebSphere Portal Express リリースの 問題の報告に応じます。 WebSphere Portal Express サポートが、テスト済み LDAP サーバーを使用して、報告された問題を再現できる場合は、スタッフが問題の修正を試みます。 サポート・チームがテスト済み LDAP サーバーで問題を再現できない場合は、 LDAP プロバイダーまでお問い合わせください。

外部セキュリティー・マネージャー (ESM) のサポート

ESM サポートには以下の 2 つのカテゴリーがあります。
完全にテストされサポートされている ESM ソフトウェアの場合:
WebSphere Portal Express の各リリースの 完全にテストされている ESM ソフトウェアのリストは、リリース毎に詳細なシステム要件内で文書化されています。システム要件について詳しくは、下記のリンクを参照してください。 WebSphere Portal Express サポートでは、テスト済みの ESM サーバーを使用して、該当する WebSphere Portal Express リリースの 問題の報告に応じます。これらの問題報告は、高い優先順位で処理されます。これらのソフトウェア製品でテストされる機能は、認証および許可などです。 この範囲外の機能 (ログインのカスタマイズ、参照、偽名の使用、ステップアップ認証機能など) は拡張機能と見なされ、WebSphere Portal Express ではテストされていません。 WebSphere Portal Express サポートでは、お客様が ESM プロバイダーと連絡を取り、これらの拡張機能に対する追加サポートを受けることができるよう支援します。
テスト済みでない、また部分的にサポートされている ESM サーバーの場合:
一般的に、WebSphere Portal Express サポートでは、認証でのみ ESM に依存する場合に、WebSphere Portal Express でテストされていない ESM サーバーのサポートに最善を尽くしています。 WebSphere Portal Express サポートでは、テストされていない ESM Trust Association Interceptor (TAI) 実装を使用して、該当する WebSphere Portal Express リリースの問題の報告に応じます。 WebSphere Portal Express サポートが、テスト済み ESM を使用して、報告された問題を再現できる場合は、スタッフが問題の修正を試みます。 サポート・チームがテスト済み ESM で問題を再現できない場合は、 ESM プロバイダーまでお問い合わせください。

ユーザー ID とパスワード

ユーザー ID とパスワードは、アクセスおよびセキュア・コンテンツを提供するためシステム全体で使用されるため、これらの文字制限について理解することは重要です。 ここで示す文字制限は、IBM WebSphere Portal Express アドミニストレーター、IBM WebSphere Application Server アドミニストレーター、データベース・アドミニストレーター、LDAP サーバー・アドミニストレーター、およびユーザー ID に適用されます。 データベースおよび LDAP サーバーには、ここに示す制限より厳密な制限を指定できます。 このため、制限についてはデータベースおよび LDAP サーバーの製品資料を確認する必要があります。 インストール・プロセス時にユーザー ID およびパスワードを正常に定義できなかった場合、インストールが失敗する可能性があります。 さらに、より厳密なユーザー ID およびパスワード要件を企業が指定している場合は、その要件にもに従う場合があります。

ユーザーがユーザーとしてサインアップする場合、あるいはアドミニストレーターにユーザー登録をしてもらう場合、ユーザー情報フォームに記入する必要があります。このフォームでは、サポートされていない可能性がある文字を入力しないでください。ユーザー情報フォームに入力可能な文字でも、ユーザー ID とパスワードは、ここで記述されている有効文字に制限されます。 「名と姓 (氏名)」フィールドには、その他の文字も指定できます。 企業のポリシーがより厳密な場合、登録フォーム・ヘルプで、あるいはフォーム上の直接のインライン・ヘルプとして、その情報をユーザーに提供できます。

通常の環境では、有効なユーザー ID およびパスワードに以下の文字を含めることができます。
注: IBM i でサポートされる文字は、小文字、大文字、数値、および下線のみです。
  • 小文字の {a から z}
  • 大文字の {A から Z}
  • 数値 {0 から 9}
  • 感嘆符 {!}
  • 左括弧 {(}
  • 右括弧 {)}
  • ダッシュ {-}
  • ピリオド {.}
  • 疑問符 {?}
  • 下線 {_}。これは i でサポートされる唯一の特殊文字です。
  • アクサングラーブ {`}
  • ティルド {~}
  • アットマーク {@}。この文字は、インストール時に WebSphere Portal Express および WebSphere Application Server アドミニストレーターを作成するときにはサポートされません。
重要: これらはすべて ASCII 文字です。 非 ASCII 文字はユーザー名にもパスワードにも使用できません。
注: (Linux のみ) 一部のタスクでは、完全修飾のユーザー ID の入力が必要な場合があります。 完全修飾のユーザー ID にスペースが含まれている場合 (例: cn=wpsadmin,cn=users,l=SharedLDAP,c=US,ou=Lotus,o=Software Group,dc=ibm,dc=com) は、 完全修飾のユーザー ID をコマンド行のフラグとしてではなく、プロパティー・ファイルに配置するか、または親のプロパティー・ファイルに配置する必要があります。 例えば、mysecurity.properties という親のプロパティー・ファイルを作成して完全修飾のユーザー ID を入力し、 次にタスク ./ConfigEngine.sh task_name -DparentProperties=/opt/mysecurity.properties を実行します。
注: (Windows のみ) 一部のタスクでは、完全修飾のユーザー ID の入力が必要な場合があります。 完全修飾のユーザー ID にスペースが含まれている場合 (例: cn=wpsadmin,cn=users,l=SharedLDAP,c=US,ou=Lotus,o=Software Group,dc=ibm,dc=com) は、タスクを実行する前に、完全修飾ユーザー ID の前後を引用符で囲む必要があります (例: "cn=wpsadmin,cn=users,l=SharedLDAP,c=US,ou=Lotus,o=Software Group,dc=ibm,dc=com")。

下表は、ユーザー情報フォームおよびサポート文字に関する必須フィールドの説明です。

表 2. ユーザー情報で有効な文字および非サポート文字
ユーザー情報 有効文字 非サポート文字
ユーザー ID
注: IBM i でサポートされる文字は、小文字、大文字、数値、および下線のみです。
  • 小文字の {a から z}
  • 大文字の {A から Z}
  • 数値 {0 から 9}
  • 感嘆符 {!}
  • 左括弧 {(}
  • 右括弧 {)}
  • ダッシュ {-}
  • ピリオド {.}
  • 疑問符 {?}
  • 下線 {_}。これは i でサポートされる唯一の特殊文字です。
  • アクサングラーブ {`}
  • ティルド {~}
  • アットマーク {@}。この文字は、インストール時に WebSphere Portal Express および WebSphere Application Server アドミニストレーターを作成するときにはサポートされません。

ASCII 文字のみが許可されています。

その他の制限事項: ユーザー ID には、user name のように、スペースを使用できません。ユーザー ID の長さは 200 文字を超えてはなりません。
インストール中にサポートされない文字を入力すると、どの文字が無効であるかを示すエラー・メッセージを受け取ります。 例えば、「管理ユーザー ID フィールドに特殊文字 [@] が見つかりました。 管理ユーザー ID を再入力してください。」などです。
重要: ユーザーおよびグループの管理ポートレットを使用してユーザーを作成するときに、サポートされない文字を入力すると、別のエラー・メッセージを受け取ります。
パスワード / パスワードの確認
注: IBM i でサポートされる文字は、小文字、大文字、数値、および下線のみです。
  • 小文字の {a から z}
  • 大文字の {A から Z}
  • 数値 {0 から 9}
  • 感嘆符 {!}
  • 左括弧 {(}
  • 右括弧 {)}
  • ダッシュ {-}
  • ピリオド {.}
  • 疑問符 {?}
  • 下線 {_}。これは i でサポートされる唯一の特殊文字です。
  • アクサングラーブ {`}
  • ティルド {~}
  • アットマーク {@}。この文字は、インストール時に WebSphere Portal Express および WebSphere Application Server アドミニストレーターを作成するときにはサポートされません。

ウムラウトなどの発音記号および DBCS 文字は使用できません。

その他の制限事項: パスワードには、pass word のように、スペースを使用できません。パスワードの長さは 128 文字以内でなければなりません。
重要: パスワードに DBCS を含むサポートされない文字が使用されていると、ログインに失敗します。DBCS を含むパスワードを使用してユーザーが正常に登録されても、ログインには失敗します。

インストール中にサポートされない文字を入力すると、どの文字が無効であるかを示すエラー・メッセージを受け取ります。 例えば、「パスワード・フィールドに特殊文字 [@] が見つかりました。 パスワードを再入力してください。」などです。

すべての文字 該当なし
すべての文字 該当なし
注: user.UNIQUEID.charset パラメーターが ascii に設定されている場合、 上記の文字が該当します。unicode に設定されている場合は、標準 Java 文字定義が使用され、Java で文字または数字として認識されるすべての文字がデフォルトで許可されます。Portal のユーザー、グループ、およびパスワードの検証動作に影響するように変更できるパラメーターについて詳しくは、『ポータル構成サービス』リンクにある 「Puma 検証サービス 」セクションを参照してください。

オペレーティング・システムの準備

インストールが正常に完了するように、各操作には固有の準備が必要です。 インストール・ウィザードを続行する前に、ご使用のオペレーティング・システムが適切に準備され、すべての必要なハードウェアおよびソフトウェアの前提条件と相互前提条件が揃っていることを確認してください。

サーバー・トポロジー

トポロジー・ダイアグラムは、さまざまなユーザーとシステム負荷の要件をサポートするためにセットアップできるさまざまな構成を視覚化するのに役立ちます。 トポロジー・ダイアグラムは、基本的な構成の代表です。

単一サーバー・トポロジーでは、デモンストレーション、製品のお試し、または開発環境の目的で、単純なインストール済み環境が例示されています。 スタンドアロン・トポロジーでは、分散した構成が例示さています。 クラスター化トポロジーで例示されているハードウェア構成の方が堅固で負荷が集中しており、Web Content Management トポロジーではさまざまなハードウェア構成がさまざまなオーサリングやシステム負荷の要件をサポートする方法が例示されています。 容量および可用性を増大させるために、IBM WebSphere Application Server Network Deployment を使用して、複数のポータル・サーバーをクラスター化できます。IBM WebSphere Application Server Network Deployment では、ポータルは共通の構成を共有し、また負荷がすべてのクラスター・インスタンスに均等に配分されます。高可用性およびフェイルオーバー・トポロジーでは、複雑な実稼働環境での WebSphere Portal Express が例示されています。

単一サーバー・トポロジー

IBM WebSphere Portal Express の単一インスタンスは、十分な機能を持つアプリケーション・サーバー、および中規模から小規模のユーザー・コミュニティーにサービスを提供することのできる Web サイトを提供します。最初に、単一インスタンスは データ・ストレージ用の DB2 に置き換える必要があります。

単一サーバー・デプロイメントは、開発、テスト、デモンストレーション、および教育用、また上述のようなある種の小規模の実動サイトには理想的です。ただし、単一サーバーは Single Point of Failure があり、その容量、可用性、および能力を改善して障害状態から復旧するために、クラスターまたはサーバー・ファームに変換する必要があります。

下の図では説明されていないオプションの構成として、IBM WebSphere Application Server の HTTP プラグインを使用して Web サーバーを、テストまたは実動用の一般的なサーバー・デプロイメントの前面に構成できます。 Web サーバーは、WebSphere Portal Express がグローバル SSO ドメインに参加する場合、静的リソース (画像やスタイルシートなど) を供給する機能、および企業のシングル・サインオン (SSO) エージェント用のプラグイン・ポイントを提供します。

以下の図には、単一サーバー環境での一般的なトポロジーが示されています。 必要なサーバーは 1 つのみです。 WebSphere Portal ExpressWebSphere Application Server、およびデータベースはすべての同一のサーバー上にインストールされます。

単一サーバー・インストールの図。WebSphere Portal、WebSphere Application Server、およびデフォルト Derby データベースが 1 つのサーバー上にあります。

スタンドアロン・サーバー・トポロジー

スタンドアロンのシナリオでは、データベース・サーバー、LDAP サーバー、および Web サーバー・ソフトウェアが IBM WebSphere Portal Express とは別の物理サーバーにインストールされるので、 シングル・サーバーとは異なります。 この構成を使用すると、ネットワーク内でソフトウェアを分散できるので、処理の負荷を分散できます。

スタンドアロン構成の場合、ネットワーク内で既存のサポートされるデータベースを使用でき、既存のサポートされる LDAP ディレクトリーを使用できます。 LDAP サーバーで認証を行うように IBM WebSphere Portal Express を構成できます。 以下の図には、スタンドアロン・サーバーでの一般的なトポロジーが示されています。 HTTP サーバー (Web サーバーとも呼ばれる) は保護されているネットワーク内でサーバーにインストールされます。 LDAP サーバーとデータベース・サーバーも別々のサーバーにインストールされます。 WebSphere Portal ExpressWebSphere Application Server は同じサーバーにインストールされます。

スタンドアロン・サーバー構成の図。
WebSphere Portal、Web サーバー、およびデータベースは別々のサーバーにインストールされます。

アイドル・スタンバイ・トポロジー

WebSphere Portal Express においてクローン作成やクラスター化はサポートされていないので、アイドル・スタンバイ・トポロジーによってフェイルオーバー構成が提供されています。 アイドル・スタンバイ構成では、2 つの WebSphere Portal Express ノードが構成されます。1 次ノードで障害が起こると、スタンバイ・ノードに着信要求が経路指定されます。

以下のトポロジー・ダイアグラムは、修理イントラネットの構成を示しています。ご覧になると分かるように、IP スプレイヤーを使用して、着信トラフィックが 2 つの WebSphere Portal Express サーバー、つまりノード A とノード B に送信されます。ノード A が応答しない場合に限り、ノード B にトラフィックは送信されます。これらの WebSphere Portal Express サーバーは、クラスター内での 1 次ノードと 2 次ノードとなります。どちらも同じクラスター・セルのメンバーです。これらの WebSphere Portal Express ノードに加えて、LDAP サーバーとデータベース・サーバーもあります。

以下の図は、アイドル・スタンバイ構成における一般的なトポロジーを示しています。 それぞれのサーバー上に 2 つの WebSphere Portal Express ノードがあります。 どちらのノードも同じクラスター・セルのメンバーです。また、それぞれすべてのサーバー上にはデータベースと LDAP サーバー・ソフトウェアがインストールされています。

アイドル・スタンバイ・インストールを示す図。この図について詳しくは、このトピックのテキストを参照してください。

このトポロジーでは、IP スプレイヤーが着信要求を 1 次ノードのノード A に経路指定します。ノード A が応答しない場合、IP スプレイヤーは着信要求をノード B に経路指定します。どちらの WebSphere Portal Express ノードも、同じデータベース・サーバーと LDAP サーバーを使用するように構成されています。

このトポロジーでは、LDAP サーバーとデータベース・サーバーはクラスター化されていないので、これらは Single Point of Failure となります。このデータベース・サーバーと LDAP サーバーは、Single Point of Failure を除去するためにクラスター化することもできます。

Web Content Management の単一サーバー・トポロジー

小規模な Web サイトまたはイントラネット・サイトのみを必要とする組織では、Web Content Management の単一サーバー・トポロジーを実装できるでしょう。 単一サーバー構成では、オーサリングと配信は同じサーバー上で行われます。 大規模な Web サイトまたはイントラネット・サイトを必要とする組織の場合、この構成は推奨されていません。

以下のトポロジー図は、Web Content Management の単一サーバー構成を示しています。 Web サーバーは、ブラウザー・クライアントからの着信要求を転送します。 Web Content Management、WebSphere Portal、および WebSphere Application Server は、同一のサーバーにインストールされています。 許可ユーザー情報を保管する LDAP サーバーは、専用のサーバーにインストールされています。 コンテンツを保管するデータベースも、専用のサーバーにインストールされています。 この図ではクラスター構成は示されていませんが、Web Content Management サーバーをクラスター化することもできます。 同様に、LDAP サーバーおよびデータベース・サーバーをフェイルオーバー用にクラスター化することもできます。

Web Content Management の単一サーバー構成の図。この図について詳しくは、このトピックのテキストを参照してください。

以下のアクションが単一サーバーで実行されます。
  • ドラフトの作成
  • ドラフトの承認
  • 変更内容の検査
  • 変更内容の公開
  • コンテンツのホスト
ハードウェアおよびリソースに関する考慮事項
  • 同じ環境内でコンテンツをオーサリングおよび配信するとリソースが集約されるので、 デプロイする環境のタイプはオーサリングと配信の同時発生を許容できる堅固なものでなければなりません。 クラスター化サーバーの使用は、単一サーバー構成における一般的なソリューションとなります。
  • コンテンツは、Web コンテンツ・ビューアー・ポートレット、Web コンテンツ・サーブレット、または事前レンダリングされたサイトのいずれかを使用して配信できます。

Web Content Management トポロジー

Web Content Management システムを使用するには、一連の Web Content Management 環境を WebSphere Portal システム全体にデプロイする必要があります。 Web Content Management 環境を検討することは、各環境で何が行われるか、および物理サーバーをどのようにセットアップするかを理解するために役立ちます。 Web Content Management は、WebSphere Portal インストール・ユーザー・インターフェースを使用してインストールされます。

Web コンテンツ・システム内のサーバーまたはクラスターは、それぞれに個別のデータ・リポジトリーを必要としますが、通常は同じ LDAP を共用します。Web Content Management システムは、分離してデプロイすることも、WebSphere Portal システムと並列させてデプロイすることもできます。

Web コンテンツ・システムの概要

デプロイする Web コンテンツ・システムのタイプは、 Web コンテンツ・システムのサイズ、配信される Web サイトのタイプ、および Web コンテンツを作成および表示するユーザーの数によって決まります。

Web コンテンツ・システムのタイプ
Web コンテンツ・システムには、以下の 3 つの主なタイプがあります。
単一環境システム
ここでは、オーサリングおよび配信が単一環境内で生じます。 このタイプの環境は、イントラネットなどの小さな Web サイトを配信する小さな組織によってデプロイされます。同じ環境内でコンテンツをオーサリングおよび配信するとリソースが集約されるので、 デプロイする環境のタイプはオーサリングと配信の同時発生を許容できる堅固なものでなければなりません。 例えば、クラスター化サーバーの使用は、単一インスタンス・システムの一般的なソリューションとなります。

単一環境システムは、Web コンテンツのオーサリングおよび配信の両方で使用される単一サーバーまたはクラスターで構成されます。

二重環境システム
ここでは、オーサリングおよび配信が異なる環境に分割されます。 このモデルにより、オーサリングおよびデリバリーの両方の負荷が軽減され、 またオーサリング環境をファイアウォールの背後に配置できるようになります。 このタイプのシステムは、外部に向けた Web サイトを配信するとき、 または多数のユーザーがコンテンツをオーサリングするか多数のユーザーが Web サイトを表示する場合に使用されます。

二重環境システムは、オーサリング環境および配信環境で構成されます。

ステージ・システム
ここでは、ステージング環境がオーサリング環境と配信環境との間に追加されます。 ステージング環境は、ユーザー受け入れテスト (UAT) のために、 または単一のバッチで変更を配信環境にシンジケートする前にオーサリング環境からの変更を累積できるようにするために使用できます。このシステムは、多数のコンテンツ作成者が存在する大きく複雑なサイトを配信するために、 配信される Web サイトが正確でエラーがなく負荷の下でも実行可能なものであることを確認する必要がある場合にデプロイされます。

ステージング・システムは、オーサリング環境、ステージング環境 (ユーザー受け入れテストが実行される場合があります)、および配信環境で構成されます。

環境のタイプ
オーサリング環境
オーサリング環境は Web コンテンツの作成と管理に使用されます。 これはコンテンツ作成者および Web サイト設計者によって使用される環境です。オーサリング・システムは、以下のものから構成できます。
  • オーサリング・サーバーまたはクラスター。
  • 配信環境にシンジケートする前にサイトおよびコンテンツの更新をテストできる、個別の UAT サーバー。
ステージング環境
ステージング環境は、以下のものから構成できます。
  • 単一のバッチで変更を配信環境にシンジケートする前にオーサリング環境からの変更を累積できる、個別の保存用サーバー。保存用サーバーを対にして使用すると、環境に冗長性を組み込むことができます。
  • サイトおよびコンテンツの更新を確認するため、および配信環境のパフォーマンスをテストするために UAT を実行できる、配信環境の完全なレプリカ。
配信環境
この環境は、Web サイト・ビューアーによって使用されます。配信環境は、以下のものから構成できます。
  • Web コンテンツ・サイトが HTML ファイルのセットとして事前レンダリングされていて、 その後に静的 Web サイトを配信するために使用される、事前レンダリングされたサイト。
  • コンテンツがサーブレットを使用して配信される、WebSphere Portal サーバーまたはクラスター。サーブレット配信は、動的コンテンツを含み WebSphere Portal コンテンツまたはアプリケーションを含まない Web サイトの配信に使用されます。
  • コンテンツがローカルまたはリモートの Web コンテンツ・ビューアー・ポートレットを使用して配信される、WebSphere Portal サーバーまたはクラスター。Web コンテンツ・ビューアー・ポートレットは、動的 Web コンテンツを他のポートレットまたはアプリケーションと共に含む Web サイトの配信に使用されます。
  • 上記のすべての組み合わせ。

Web コンテンツのオーサリング環境

オーサリング環境は Web コンテンツの作成と管理に使用され、コンテンツ作成者および Web サイト設計者によって使用されます。

サーバー・タイプ
ほとんどの Web Content Management サイトでは、数多くのコンテンツ作成者をサポートする必要があります。 クラスター化サーバーのソリューションが、このシナリオにおける最良のソリューションです。
標準的なオーサリング環境

標準的なオーサリング環境は、ステージング環境または配信環境と直接シンジケートする単一のオーサリング・クラスターで構成されます。 例:

標準的なオーサリング環境。この例では、標準的なオーサリング環境は、ステージング環境または配信環境と直接シンジケートする単一のオーサリング・クラスターで構成されます。オーサリング環境は、ドラフトの作成、ドラフトの承認、変更のテスト、変更の公開、および配信環境へのシンジケートを行うために使用できます。

テストを行うオーサリング環境

テスト環境をオーサリング環境に追加すると、コンテンツ管理システムおよび Web サイトでユーザー受け入れテストを実行できるようになります。 例:

テストを行うオーサリング環境。この例では、ドラフトの作成、変更の承認、変更のテスト、およびオーサリング環境からステージングへのシンジケートを行うことができます。
サイト UAT 環境では、変更の公開、システムによる変更のテスト、およびオーサリング環境へのシンジケートが可能です。
オーサリング環境から、配信環境にシンジケートできます。

非集中オーサリング環境
コンテンツ作成者が別の場所に存在する場合、またはコンテンツ作成者のさまざまなグループが存在する場合には、 一連の非集中オーサリング・クラスターをデプロイすることを検討できます。 このシナリオは、非集中コンテンツ作成者がさまざまなコンテンツ・ライブラリーに保管された別個のコンテンツを処理する場合に最適です。

例えば、ユーザーが複数の場所に分散している場合は、それぞれの場所に 1 つのローカル・オーサリング環境をインストールする方が効率的でしょう。集中オーサリング環境のあるすべてのオーサリング環境の間で、両方向シンジケーションが使用されます。これにより、すべてのリモート・ロケーションで加えられた変更内容を、すべてのユーザーに表示できるようになります。

非集中オーサリング・ダイアグラム。この図について詳しくは、このトピックのテキストを参照してください。

非集中オーサリングでは、オーサリング環境の間で更新内容が矛盾するというリスクが生じます。 矛盾のリスクを減らすには、各オーサリング環境に、異なるサイトまたは異なるサイトのセクションを割り振ることができます。 また、ユーザーの役割ごとに別々のオーサリング環境を使用することもできます。例えば、コンテンツ作成者は、プレゼンテーション・テンプレート設計者とは異なるオーサリング環境を使用できます。

各非集中オーサリング環境へのアクセスは、オーサリング・ポートレット・アクセス制御と項目のセキュリティーの設定を組み合わせて制御します。 例えば、ローカル・オーサリング環境へのアクセスが必要なユーザーのみが、 ローカル・オーサリング・ポートレットへのアクセスを許可されるようにします。 ユーザーには、すべての項目に対する「読み取り」アクセス権が付与されますが、更新する必要がある項目に対しては「編集」アクセス権のみが付与されます。

Web コンテンツのテスト環境

この環境は UAT テスターによって使用され、サイトおよびコンテンツの更新を配信環境にシンジケートする前にテストできる個々の UAT サーバーのような単純なものである場合もありますし、 サイトおよびコンテンツの更新の検討と配信環境のパフォーマンスのテストの両方で UAT が行われる可能性がある、配信環境の完全なレプリカのような複雑なものである場合もあります。 さらに、単一のバッチで変更を配信環境にシンジケートする前に、オーサリング環境での変更を累積するためにも使用できます。

オーサリング環境内でのサイト・テスト

テスト環境をオーサリング環境に追加すると、コンテンツ管理システムおよび Web サイトでユーザー受け入れテストを実行できるようになります。

オーサリング環境内でテストする場合、UAT サーバーはオーサリング・サーバーとペアになります。
UAT サーバーは配信環境をシミュレートし、Web サイトへの大きな変更をテストするために使用されます。

ステージング環境内でのシステム・テスト

変更を稼働中の配信環境にシンジケートする前に、配信環境のレプリカでシステム・テストを実行できます。

ステージング環境内でテストする場合、オーサリング環境からのデータは、ユーザー受け入れテストが実行されるステージング・サーバーにシンジケートされます。
すべてのテストにパスすると、データはステージング・サーバーから配信環境にシンジケートされます。

Web コンテンツの配信環境

配信環境は、コンテンツを Web サイト・ビューアーに配信するために使用します。

事前レンダリングされた配信

Web サイト全体を HTML に事前レンダリングし、ディスクに保存することができます。 事前レンダリングされたサイトは、その後、表示サイトとして使用でき、Web Content Management または Web サーバーのいずれかを使用してユーザー向けに表示することができます。ポートレットなどの使用している WebSphere Portal の機能が 1 つもなく、コンテンツが静的で、定期的にしか更新されない場合には、事前レンダリングされたサイトをデプロイします。

事前レンダリングされた配信環境では、コンテンツはオーサリング・サーバーから配信サーバーにシンジケートされます。ここで、コンテンツは静的 HTML ファイルのセットに変換されます。
HTML ファイルは、Web サーバー経由でユーザーに表示されます。

サーブレット配信

ユーザーは、Web Content Management サーブレットを使用して表示されるコンテンツにアクセスできます。 オーサリング・ツールなど、ポートレット・ベースの機能を使用する必要がない場合は、サーブレットが配信する Web サイトが使用されます。

サーブレット配信環境では、コンテンツはオーサリング・サーバーから配信サーバーにシンジケートされます。ここで、コンテンツは、Web Content Management サーブレットによって表示され、Web サーバー経由でユーザーが使用できるようになります。

ローカル Web コンテンツ・ビューアー配信

Web コンテンツ・ビューアーは、Web コンテンツ・ライブラリーからのコンテンツをポータル・ページの一部として表示するポートレットです。表示が単純な場合は単一の Web コンテンツ・ビューアーで十分である場合もありますが、 複数の Web コンテンツ・ビューアーを使用してさまざまなライブラリーからのコンテンツを集約することにより、 より豊富な情報をユーザーに提供することもできます。 ローカル Web コンテンツ・ビュー・ポートレットを使用して、Web コンテンツ配信環境に含まれるコンテンツを表示します。

ローカル Web コンテンツ・ビューアーを使用する配信環境では、コンテンツはオーサリング・サーバーから配信サーバーにシンジケートされます。ここで、コンテンツは、ポータル内の Web コンテンツ・ビューアー・ポートレットによってユーザーに表示されます。
ローカル Web コンテンツ・ビューアーを使用する場合、Web コンテンツ・ビューアーは Web Content Management と同じサーバーにインストールされます。

リモート Web コンテンツ・ビューアー配信

JSR 286 Web コンテンツ・ビューアーの WSRP サポートは、リモート WebSphere Portal サーバーまたはクラスター上のコンテンツを表示するために使用されます。

リモート Web コンテンツ・ビューアーを使用する配信環境では、コンテンツはオーサリング・サーバーから配信環境の Web Content Management サーバーにシンジケートされます。JSR 286 Web コンテンツ・ビューアーは Web Content Management サーバーにインストールされ、配信環境の別のポータル・サーバーにインストールされた WSRP プロキシー・ポートレットと通信するように構成されます。
ユーザーは、通常は Web サーバー経由でリモート・ポータル・サーバー上のプロキシー・ポートレットにアクセスすることによって、Web コンテンツを表示します。

評価ライセンス

IBM WebSphere Portal Express には、60 日間の評価用に無料で製品をインストールしてデプロイできる、特別なライセンスが付属しています。 後で WebSphere Portal Express を購入する場合は、 簡単なユーティリティーを使用して評価ライセンスを完全なプロダクション・ライセンスに変換できます。 評価ライセンスなしで、直接 WebSphere Portal Express を購入してインストールするユーザーは、評価ライセンスをインストールして変換することなく製品を使用できます。

注: このバージョンは、以前に WebSphere Portal Express をインストールしていない新規のユーザーを対象にしています。 WebSphere Portal Express のメディア、またはダウンロードしたインストール・イメージを使用して、既存のインストール済み環境をアップグレードすることはできません。

評価ライセンスの使用

60 日間の評価ライセンスの条件で WebSphere Portal Express をインストールした場合は、各個人およびチームでそのサイトをすぐに検討および使用できます。

このサイトを立ち上げるごとに、SystemOut ログ・ファイルに評価ライセンスの残り日数が記録されます。 このログ・ファイルは、wp_profile_root/logs/WebSphere_Portalにあります。

評価ライセンスの期限切れ後に使用を継続するには、WebSphere Portal Express を購入する必要があります。 購入したプロダクション・ソフトウェアには、前にインストールした評価ライセンスの完全なプロダクション・ライセンスへの変換に必要なファイルが含まれています。 評価期間中にユーザーが作成したカスタムのテンプレートおよびデータ・ファイルは、プロダクション・ライセンスと完全に互換性があるため、追加のマイグレーションは必要ありません。

ご購入の情報については、地域の IBM 担当員、または認可された IBM ビジネス・パートナーにお問い合わせください。

Web サーバー

デフォルトでは、IBM WebSphere Portal ExpressIBM WebSphere Application Server 内の内部 HTTP トランスポートを使用して、リクエストを処理します。 ただし、WebSphere Application Server では外部 Web サーバーの使用もサポートされているため、ご使用の Web サーバーから WebSphere Portal Express にアクセスすることができます。 WebSphere Portal Express と同じマシン上のローカル Web サーバーを使用することも、別のマシン上のリモート Web サーバーを使用することもできます。 リモート Web サーバーは通常、実稼働環境または他の高トラフィック構成のために使用します。また通常は、ポータル・ポートを保護するファイアウォールの外部の非武装地帯 (DMZ) に配置されます。

Web サーバーとWebSphere Application Server 間の通信を使用可能にするには、Web サーバー・プラグインが必要です。 Web サーバー・プラグインによって、リクエストが Web サーバーまたはアプリケーション・サーバーのいずれで処理されるかが決定されます。 このプラグインは、WebSphere Application Server と同じマシンまたは、別のマシンにある Web サーバーにインストールできます。 Web サーバー・プラグインは、プラグインを介してアクセス可能になった WebSphere Application Server への リクエストを処理したり、渡したりする方法を記述した設定を含む XML 構成ファイル (plugin-cfg.xml) を使用します。

WebSphere Application Server の管理コンソールでは、Web サーバーが固有のサーバー・タイプとして表示されるため、Web サーバー・プラグインの plugin-cfg.xml ファイルで使用されているすべての構成プロパティーを管理コンソールから表示して変更できます。

注: 一部のポータル機能が作動するためには、HTTP 操作の POST、PUT、および DELETE が使用可能になるように、Web サーバーで書き込み操作と削除操作が許可されていることを確認する必要があります。 例えば、マッシュアップ統合の場合にそれが必要になります。

i ユーザー: i システムでの外部 Web サーバーの使用について詳しくは、このページにリストされているステップに加えて、Web サーバーのトポロジー・ダイアグラムおよびロードマップの選択も参照してください。

スタンドアロンまたはクラスター環境における別の HTTP ポートを経由した WebSphere Portal Express へのアクセス

デフォルトでは、WebSphere Portal Express は、WebSphere Application Server 内の内部の HTTP ポートを経由してアクセスするように構成されています。例えば、http://hostname.example.com:10039/wps/portal。ここで、hostname.example.com は WebSphere Portal が稼働しているマシンの完全修飾ホスト名、10039 は WebSphere Application Server が作成したデフォルトのトランスポート・ポートです。ポート番号はご使用の環境によっては違うことがあります。WebSphere Portal Express が使用するデフォルトのホスト名およびポートは、wkplc.properties ファイル内の WpsHostName および WpsHostPort プロパティーで指定されます。

外部 Web サーバーを使用するように WebSphere Portal Express を構成すると、ポータルにアクセスする際には、Web サーバーのホスト名およびポート (例えば 80) を使用します。 スタンドアロン・サーバーまたは垂直クラスター・メンバーの場合、WebSphere Application Server 構成に、ポート 10039 に対応する仮想ホスト定義が存在していなければ、WebSphere Portal Express のホスト名およびポート (例えば 10039) を使用してポータルにアクセスすることはできません。

WebSphere Portal Express 構成タスクの多くは、wkplc.properties ファイルの WpsHostName および WpsHostPort プロパティーを使用します。これらのプロパティー値によって指定されるホスト名およびポートを使用して、WebSphere Portal Express にアクセスできることを保証する必要があります。 これは、以下の 2 つの方法のいずれかを使用して実行できます。
  • WpsHostName および WpsHostPort プロパティー値を変更して、Web サーバーのホスト名およびポートを指定する。
  • 以下で説明しているように、適切な仮想ホスト定義を追加する。
Web サーバーとは異なるホスト名およびポートを使用して WebSphere Portal Express にアクセスする場合は、WebSphere Application Server 管理コンソールを使用して、必要な仮想ホスト定義を追加します。クラスター環境で Web サーバーを使用している場合は、デプロイメント・マネージャーの管理コンソールを使用して、以下のステップを実行します。
  1. 「環境」 > 「仮想ホスト」を選択する。
  2. default_host の項目または WebSphere Portal Express アプリケーションへのアクセスに使用されている仮想ホストの項目を選択する。
  3. 「ホスト別名」を選択し、WebSphere Portal Express へのアクセスに使用される値に対応するホスト名およびポートの項目が存在しているかどうかを確認する (例えば、*:10039)。 その項目が存在していない場合は、「新規作成」を選択して、使用するホスト名およびポートの情報を入力する。
  4. 変更内容を保管する。
  5. Web サーバー・プラグインを再生成する。
  6. リモート Web サーバーを使用している場合は、更新済みの plugin-cfg.xml ファイルを Web サーバー・マシンにコピーする。
  7. 負荷の下でシステムを実行しており、要求が「ServerIOTimeout」のデフォルト値よりも時間が長くかかると予期される場合、この値を増やして要求が 2 回送信されるのを防ぐ。
  8. Web サーバーおよびポータルをリサイクルする。
  9. クラスター環境でノードを再同期し、クラスターを再始動する。

クラスター環境の Web サーバーに関する考慮事項

クラスター環境で Web サーバーと WebSphere Portal Express を連動させる場合に該当する考慮事項は、以下のとおりです。
  • デプロイメント・マネージャー・システムで configureweb_server_name スクリプトを実行する場合は、Web サーバーとクラスター・メンバーとの間の通信を正しく行うために、クラスターを同期化して再始動する必要があります。
  • スタンドアロン WebSphere Portal Express ノードが以前に Web サーバー用に構成されていて、その後デプロイメント・マネージャーによって管理されるセルに統合された場合、そのノード上の Web サーバー定義が削除されます。 クラスターで Web サーバーを使用する場合は、ノードを統合してから、デプロイメント・マネージャーの管理コンソールで Web サーバー定義を再作成する必要があります。

データベースに関する考慮事項

デフォルトで、IBM WebSphere Portal Express では IBM DB2 Universal Database™ Workgroup Server Edition がインストールされ、使用されます。DB2 と共にインストールすると、WebSphere Portal Express を実稼働レベルの環境に素早くインストールして稼働させることができます。

適切なチューニングによって、他のデータベースでのパフォーマンス向上が可能です。 他のデータベースでは、垂直方向および水平方向のクラスターおよびクローン作成がサポートされています。パフォーマンスおよび可用性を向上させるために、複数のデータベースを使用してください。

サポートされている他のデータベースにデータを転送する場合は、ポータルを広範囲に使用する前にデータベース転送を実行します。Java ヒープ・サイズが十分な大きさでない場合、データベース内のデータが大量であると、データベース転送が失敗する場合があります。 ポータルを使用するにつれて情報がデータベースに追加されるため、大容量データを保管する必要があり、フェイルオーバーが必要であることに気付いたなら、直ちにデータベース転送を実行してください。 データベースの転送を後回しにせず直ちに実行すれば、後の段階で大容量データを、サポートされる他のデータベースに転送することにより生じる一般的な問題 (例えば、Java ヒープ・サイズの不足など) を回避できます。

デフォルト・データベース以外のデータベースから転送する場合は、データベース転送機能を試行する前に追加のステップとして、wkplc_sourceDb.properties、wkplc_dbdomain、および wkplc_dbtype.properties ファイルを編集して、ソース・データベース情報を更新する必要があります。

データベース・ユーザー

データベース・ユーザーには、データベース構成ユーザーとデータベース・ランタイム・ユーザー という 2 つのタイプがあります。各ユーザー・タイプが IBM WebSphere Portal Express の データベース・ドメインで作業するために必要な特権、およびデータベース構成ユーザーを作成して特権を付与するためのコマンドを 理解します。

データベース構成ユーザー

通常、データベース管理システム (DBMS) のインストール時に作成される データベース管理ユーザーは、データベース・インストール・ユーザー またはデータベース構成ユーザー です。データベース構成ユーザーは、 データベース管理システムのインストール時にデフォルトで作成されるユーザーとは限りません。 デフォルト・ユーザーが、データベース構成ユーザーとして使用される場合もあります。 データベース構成ユーザーは、 WebSphere Portal Express により構成タスクのために使用され、 WebSphere Portal Express で必要なデータベース構成を作成します。例えば、 データベース構成ユーザーはデータベース表や索引を作成したり、データベース転送を実行したりすることができ、 さらに、データベース管理システムによっては、オペレーティング・システムの特権を保持していることもよくあります。

データベース・ランタイム・ユーザー

データベース・ランタイム・ユーザー の持つ特権は、データベース構成ユーザーに比べて限られています。 ランタイム・ユーザーはデータベースのデータ・ソースに対するランタイム・アクセス権を持ち、 データ上で基本的な読み取りおよび書き込み操作を実行できます。 WebSphere Portal Express のデータベース・ドメインごとに、 専用のランタイム・ユーザーを作成することを検討してください。ランタイム・ユーザーを作成しない場合は、 WebSphere Portal Express は構成ユーザーを使用して、ランタイムでデータベースに 接続します。

データベース・ユーザーの特権

以下の表に、 2 つのタイプのデータベース・ユーザー (構成ユーザーとランタイム・ユーザー) が機能を修正するために 必要とする最小限の特権を示します。 リストされた特権は、すべての WebSphere Portal Express データベース・ドメインに当てはまります。

表 4. データベース・ランタイム・ユーザーがすべてのデータベース・ドメインに対して保持する 最小限の特権リスト
データベース・ドメイン内のアクセス権 Release Community Customization JCR Feedback Likeminds
データベースへのアクセス権 はい はい はい はい はい はい
すべての表での読み取り はい はい はい はい はい はい
すべての表での書き込み はい はい はい はい はい はい
すべての表でのアップデート はい はい はい はい はい はい
すべての表での削除 はい はい はい はい はい はい
表の作成 いいえ いいえ いいえ はい いいえ いいえ
索引の作成 いいえ いいえ いいえ はい いいえ いいえ
シーケンスの使用 いいえ いいえ いいえ はい はい いいえ
表 5. データベース構成ユーザーがすべてのデータベース・ドメインに対して保持する 特権のリスト
データベース・ドメイン内のアクセス権 Release Community Customization JCR Feedback Likeminds
データベースへのアクセス権 はい はい はい はい はい はい
すべての表での読み取り はい はい はい はい はい はい
すべての表での書き込み はい はい はい はい はい はい
すべての表でのアップデート はい はい はい はい はい はい
すべての表での削除 はい はい はい はい はい はい
新規オブジェクト作成用のディスク上の割り当て量 はい はい はい はい はい はい
表スペースの作成 はい はい はい はい はい はい
表スペースの除去 はい はい はい はい はい はい
表の作成 はい はい はい はい はい はい
表の変更 はい はい はい はい はい はい
表の除去 はい はい はい はい はい はい
索引の作成 はい はい はい はい はい はい
索引の除去 はい はい はい はい はい はい
トリガーの作成 はい はい はい はい はい はい
トリガーの除去 はい はい はい はい はい はい
シーケンスの作成 いいえ いいえ いいえ はい はい いいえ
シーケンスの使用 いいえ いいえ いいえ はい はい いいえ
タイプの作成 いいえ いいえ いいえ はい いいえ いいえ
タイプの除去 いいえ いいえ いいえ はい いいえ いいえ
ビューの作成 いいえ いいえ いいえ はい いいえ いいえ
ビューの除去 いいえ いいえ いいえ はい いいえ いいえ

データベース・トポロジー

データベース構成オプションを、ご使用の IBM WebSphere Portal Express デプロイメント・シナリオと関連させて検討します。 IBM DB2 Universal Database Workgroup Server Edition を使用した PoC (概念検証) 環境から、垂直方向および水平方向のクローン作成技法を使用したシステムへ拡大するにつれて、ネットワーク・トポロジーがより複雑になります。

WebSphere Portal Express データは、PoC (概念検証) および実稼働環境用のデプロイメント・シナリオに応じて、さまざまな可用性の要件を満たすために、単一ストアで構成することも、複数のデータベース・ドメインに編成することもできます。 WebSphere Portal Express により提供されるデータベース・ドメインにより、ポータル・データを分類して分散させることができます。 効率的な保守のため、各データベース・ドメインを個別のデータベースに配置できます。 さらに、各ドメインを個別のデータベース・サーバー・システムに配置すると、パフォーマンスを最大にできます。

図 1. データベースをセットアップするためのオプション
データベース構成オプションのトポロジー図
ご使用のポータル・デプロイメントでは、PoC (概念検証) 環境用のローカル・データベースが必要か、通常のロード・バランシングをサポートするためにデータベース・ドメインを共有するリモート・データベースが必要か、データを分離する大容量で重いロード・バランシング用のリモート・データベースが必要か、またはこれらデータベース構成を組み合わせることが必要かを検討します。
ローカル・データベースを使用した PoC (概念検証) デプロイメント
データベース・サーバーを WebSphere Portal Express と同じサーバー・マシンにインストールできます。 これは一般にローカル・データベースと呼ばれます。 ローカル・データベースを使用すると、環境の管理がより容易になります。ただし、このセットアップは PoC デプロイメントの場合にのみ使用するのが最善です。 なぜなら、ローカル・データベースは、サーバー・リソースの使用でポータルと競合し、ポータル環境全体における Single Point of Failure となってしまうからです。
1 つ以上のリモート・データベースを使用した、通常のロード・バランシング
データベース・サーバーを WebSphere Portal Express とは異なるサーバー・マシンにインストールできます。 これは一般にリモート・データベースと呼ばれます。 リモート・データベースを使用すると、ネットワークの速度に応じて、パフォーマンス上の利点が生じる可能性があります。 複数の生産ラインが関与し、各生産ラインがサーバーのクラスターとして 実装されている場合は、データベース・ドメインを共用することにより、生産ライン全体で、データが確実に自動的 に同期されるようになります。 効率的な保守のため、各データベース・ドメインを個別のデータベースに配置できます。
1 つ以上のリモート・データベースを使用した、大容量のロード・バランシング
大規模でハイ・デマンドの環境にポータルをデプロイする場合は、1 つのサーバーをデータベース・トランザクション専用に指定できます。 ポータルにアクセスするユーザーが増加すると、ポータル・アプリケーションは、データベースを頻繁に使用するようになります。 データベース・アクティビティーによって、CPU 使用率やディスク入出力時間が増大する可能性があります。 データベースをポータルが実行されるサーバーから分離することによって、サーバーの能力が向上します。 各ドメインを個別のデータベース・サーバー・システムに配置すると、パフォーマンスを最大にできます。
要確認: リモート・システムにデータベース・サーバーをインストールする場合は、ポータルがリモート・データベース・サーバーと通信できるようにするために、WebSphere Portal Express システムにデータベース・クライアント・ソフトウェアをインストールする必要があります。

共用データベース・ドメイン

データベース・ドメインは、ポータル・データの配布方法を分類して判別するのに役立ちます。データの可用性を最大化するには、複数のデータベースにわたってポータル・データを配布することができます。またドメインによっては、複数の実動ライン間でデータを共用することができます。単一データベース・ドメインを転送するか、または複数ドメインを転送するかを選択できます。

データを分離することにより、各カテゴリーのデータを専用のデータベース・テーブル・セットまたはファイル・システムに保管できます。ポータル・リソースのデータベース・テーブルとスキーマのセットをデータベース・ドメインと言います。 データベース・ドメインは、カテゴリーごとのストレージとデータ転送をサポートしています (例えば、Configuration、Release、Customization、Community、IBM Java Content Repository (JCR) など)。 データを分離することによって、複数のポータルでドメインを共有できるようになります。 さらに、さまざまなデータベース・タイプにさまざまなドメインを分散させることもできます。 例えば、LikeMinds のデータをデフォルト・データベースに残し、 他のすべてのデータを別のデータベースに移動することが可能です。このようなドメインの分離に基づいて、実動ノードを別々のクラスターに分割する実動環境をサポートできます。 例えば、各クラスターは独立して稼働可能ですが、同じ Community データベース・ドメインと Customization データベース・ドメインを共有します。これらのクラスターのそれぞれを実動ラインと言います。

データベース・ドメインでは、ポータル・データが以下のカテゴリーとサブカテゴリーに分類されており、さまざまなデータベースにポータル・データを配布する方法を決定しやすくしています。
Configuration データ
このデータで、データベース接続、オブジェクト・ファクトリー、デプロイメント記述子などの Portal Server セットアップを定義します。このタイプのデータは、通常、サーバー・ノードが動作している間は一定です。 構成データは通常、プロパティー・ファイルに保存され、ファイル・システムのセキ ュリティーまたはアプリケーション・サーバーの管理権限によって保護されます。
Release データ
このデータの内容は、外部で設計後、ステージング・プロセスによってポータルに取り込んだ、ポータル・コンテンツのすべての定義、ルール、および権限です。ページ階層、使用可能なポートレットおよびテーマ、テンプレート、クリデンシャル・スロット、Personalization ルール、ポリシーなどがあります。 これらのリソースは通常、実動 システムでは変更されません。変更には管理権限が必要です。アドミニストレーターは通常、統合サーバーで Release データを作成し、実動システムにステージングします。Release データは アクセス制御によって保護されており、データのみでコードは含みません。 複数の実動系統からなる環境では、クラスターごとに Release データのコピーが 1 つずつ存在します。Release データには、以下の 2 つの個別のドメインが含まれます。
  • Release: アクセス制御、ページ、ポートレットなど、ポータルの静的サイト構成が含まれます。
  • JCR: オーサリングされたコンテンツ、Personalization ルール、およびテーマ・ポリシー定義が含まれます。
これらはリリース・データと見なされ、個別に実動ラインへプロモートする必要があります。
Customization データ
このデータは、特定ユーザーだけに関連したデータであり、ユーザー間またはユーザー・グループ間で共有することはできません。典型的な例としては、ポートレット・データやカスタマイズされたページ (暗黙派生ページ) などがあります。このデータの有効範囲は単一ユーザーのみに限定 されているので、アクセス制御による保護も簡略化されています。
複数の実動系統からなる環境では、それらの実動系統間で共用されるデータベースに Customization データが保管されます。したがって、それらの実動ラインの間では、データが自動的に同期します。
Community データ
このデータには、複合アプリケーション・インスタンスなどの、通常、実稼働時に変更されるリソースがすべて含まれています。通常、ユーザーやグループは、共用リソースの変更や削除を行うことができます。コミュニティー・リソースはアクセス制御によって保護されます。
以下の表に、サポートされるデータベース・ドメイン、ドメインが共用可能かどうか、およびその保管方法をリストします。
表 6. サポートされるデータベース・ドメイン
データベース・ドメイン 共用可能 ストレージ方式
Release 不可 データベース
Customization データベース
Community データベース
JCR 不可 データベース
Feedback データベース
LikeMinds データベース

保守とステージングのために、1 つの実動ラインをサービス休止状態にしながら、他のラインでは、古いデータに基づいて要求への対応を続けることも可能です。最初の実動ラインを更新してサービス中の状態に戻したら、2 番目のラインを同じ方法で更新します。 共用ドメイン内のデータの更新は、他の実動ラインに影響を 与えるので、重大な意味を持ちます。

アプリケーションのアベイラビリティーに影響を与えずに、個々のサーバーを実稼働から切り離すことができるように、 環境全体のキャパシティーは想定される使用率よりも大きくしておく必要があります。 ポータルがすべてのシステム・リソースを確実に使用できるようにするには、実動システムはポータル専用にして 、ポータルには関係のないその他のサーバー・ソフトウェアを実行しないようにする必要があります。

メンテナンスの目的で、以下のデータベース・ドメインをオフラインにすることができます。
  • Community
  • Customization
  • Feedback
  • LikeMinds
WebSphere Portal Express を始動する際はいつでも、以下のデータベースをオフラインにしないでください。
  • Release
  • JCR
オフラインのデータベース・ドメインがある間は、その該当するデータに WebSphere Portal Express がアクセスできないため、エラー・メッセージが表示される可能性があります。WebSphere Portal Express 自体は、反応できる状態にあります。データベース・ドメインが再び使用可能になると WebSphere Portal Express は、この使用可能状態を検知し、再接続し、該当するデータの処理を続行します。共用データベースのデータは、常時その時点で使用中の実動ラインから使用可能であることが必須のため、共用データベースが定期保守の影響を受けてはなりません。
VMM データベースの共用

リポジトリー全体およびプロパティー拡張のための VMM データベースは、複数の生産ラインで共用できます。 VMM データベースがサービス休止している場合、WebSphere Portal Express は機能しません。

データベースの互換性に関する考慮事項

データベース管理者である場合は、IBM WebSphere Portal Express のデータベース要件について考慮する必要があります。

始める前に
IBM i オペレーティング・システムで稼働する IBM WebSphere Portal Express でのデータベース互換性は、以下のように相互に排他的であることに注意してください。
  • IBM DB2 Universal Database for iSeries® データベースは、WebSphere Portal Express for i でのみサポートされています。
  • WebSphere Portal Express でサポートされているその他のデータベース管理システムは、任意のポータル・プラットフォームで動作するよう構成できます。
このタスクについて

Windows での DB2 の計画

IBM DB2 Universal Database Enterprise Server Edition へのデータ転送を計画する場合は、 データベース名、格納するデータ、および必要なデータベースのスペースなど、データベースおよびユーザーの情報について検討する必要があります。 一部のフィックスパックでは、転送タスクを正常に実行するために、転送タスクの前にいくつかの手順を行うことが必要です。

始める前に
始める前に
  • DB2 は、WebSphere Portal Express のインストール時にインストールされます。 このセクションは、構成を変更し、別のローカル DB2 データベースに移動する 場合にのみ必要です。
  • WebSphere Portal Express では、DB2 JDBC タイプ 2 (CLI ベース) およびタイプ 4 (JCC) の各ドライバーがサポートされています。
  • データベースに関する考慮事項を確認してください。
  • 使用予定のデータベースが、このバージョンの WebSphere Portal Express でサポートされているかどうかを確認します。 WebSphere Portal Express の詳細なシステム要件にある、サポート対象データベースのリストを参照してください。
このタスクについて

このページのデータベース名およびユーザーは推奨値であり、文書全体で一貫して使用します。 これらの値をご使用の環境に応じた値に置き換えてください。データベース名が 8 文字を超えないようにしてください。また、使用できるのは文字と数字のみです。

  • 同一のデータベース・ユーザー ID を使用する場合は、データベース名、データベース・サーバー・ノード、またはスキーマ名を固有にする必要があります。
  • DB2 Universal JDBC ドライバー (タイプ 4 モード) を使用する場合、データベースに直接接続してください。 別名データベース (ゲートウェイ) に接続するのではなく、JDBC 接続 URL (dbdomain.DbUrl) およびデータベース名プロパティー (dbdomain.DbName) には実際のデータベース名を指定してください。

ローカル・データベース環境では、WebSphere Portal ExpressDB2 は同じシステムにインストールします。

図 2. ローカル・データベース環境
ローカル・データベース。この図について詳しくは、このトピックのテキストを参照してください。

図 2 に示すように、JDBC タイプ 2 接続を使用する場合、WebSphere Portal Express および DB2 Connect は 1 つのシステム (ローカル・システム) にインストールします。 DB2 サーバーは別のシステム (リモート・システム) にインストールします。

図 3. リモート・データベース環境 (JDBC タイプ 2 接続)
リモート・データベース。この図について詳しくは、このトピックのテキストを参照してください。

JDBC タイプ 4 接続の場合、WebSphere Portal Express を実行する システムに DB2 Connect をインストールする必要はありません。 図 3 に示すように、DB2 に付属している DB2 Universal JDBC ドライバーは、このシステムにコピーされます。 これは、WebSphere Portal Express の Java 仮想マシン内で使用され、 リモートの DB2 サーバーに直接接続します。

図 4. リモート・データベース環境 (JDBC タイプ 4 接続)
タイプ 4 接続を行うリモート・データベース。この図について詳しくは、このトピックのテキストを参照してください。
手順
  1. 以下の表に示すさまざまなデータベースを検討し、これらの値をご使用の環境の値に置き換えます。データベースを共用している場合は、スキーマ名を異なるものにする必要があります。 1 つのデータベースを使用するように WebSphere Portal Express を構成することは技術的には可能ですが、独立した複数のデータベースを使用すると、スケーラビリティーおよびパフォーマンスを向上させることができます。 アーキテクチャーによって、これらのデータベースはそれぞれ、1 つまたは 複数のインスタンスに存在することができます。 ただし、推奨されるアーキテクチャーは、インストール・プログラムによって作成されたデフォルト・インスタンス (db2inst1) を使用します。
    表 7. さまざまなデータベースに必要なスペース
    アプリケーション データベース名 必要なスペース
    WebSphere Portal Express

    ポータルの最低限、またはすべてのデータを保持するために使用する。ページなど のユーザー・カスタマイズに関する情報と、ユーザー・プロファイルおよびログイン情報を保管する。

    • reldb
    • commdb
    • custdb
    ユーザー数、およびページおよびポートレットなどのポータル・オブジェクトの数によって異なる。
    Personalization,Web Content Management

    文書、Personalization ルール、Personalization キャンペーン、および文書ライブラリーの構成情報を含む。

    • jcrdb
    Personalization ルールおよびキャンペーンの数およびサイズ、Web Content Management で作成された項目およびエレメントの数およびサイズによって異なる。
    Feedback

    サイト活動の分析やレポートの生成のために Web サイトによって記録される情報が格納されます。

    • fdbkdb
    サイトに対するトラフィック量によって異なります。ログイン可能なページごとにログに記録されるデータの量は、異なる可能性があります。
    LikeMinds

    Web サイトとの対話が分析され、予測が生成されたときにユーザーに対して表示されるレコメンデーションが含まれています。

    • lmdb
    サイトに対するトラフィック量によって異なります。
  2. 各ユーザーが所有するテーブル数およびオブジェクトのタイプを検討します。 アーキテクチャーによって、以下の各ユーザーを同じデータベースに配置できます。 すべてのテーブル・スペースは、デフォルトでは約 2.8GB です。サイズは、Java Content Repository を使用して増加できます。
    表 8. データベース・ユーザーが所有するテーブルおよびオブジェクト
    アプリケーション データベース・ユーザー・プレースホルダー 機能
    WebSphere Portal Express
    • releaseusr
    • communityusr
    • customizationusr
    約 230 のテーブルを所有するコア・ユーザー。これらのテーブルは WebSphere Portal Express コア・オブジェクト用に使用され、ページに対して行われたユーザーのカスタマイズ情報を保管するテーブルを含みます。
    Java Content Repository
    • jcr
    Java Content Repository ユーザーは、少なくとも 1130 のテー ブルを所有します。数値は、使用量に応じて増える場合があります。
    Feedback
    • feedback
    ロギング・サイトおよび Personalization で使用する約 50 のテーブルを所有する Feedback ユーザー。
    LikeMinds
    • likeminds
    Web サイト使用分析ルーチンおよび推奨テキストを保持するために使用する約 15 のテーブルを所有する LikeMinds ユーザー。

Linux での DB2 の計画

IBM DB2 Universal Database Enterprise Server Edition へのデータ転送を計画する場合は、 データベース名、格納するデータ、および必要なデータベースのスペースなど、データベースおよびユーザーの情報について検討する必要があります。 一部のフィックスパックでは、転送タスクを正常に実行するために、転送タスクの前にいくつかの手順を行うことが必要です。

始める前に
始める前に
  • DB2 は、WebSphere Portal Express のインストール時にインストールされます。 このセクションは、構成を変更し、別のローカル DB2 データベースに移動する 場合にのみ必要です。
  • WebSphere Portal Express では、DB2 JDBC タイプ 2 (CLI ベース) およびタイプ 4 (JCC) の各ドライバーがサポートされています。
  • データベースに関する考慮事項を確認してください。
  • 使用予定のデータベースが、このバージョンの WebSphere Portal Express でサポートされているかどうかを確認します。 WebSphere Portal Express の詳細なシステム要件にある、サポート対象データベースのリストを参照してください。
このタスクについて

このページのデータベース名およびユーザーは推奨値であり、文書全体で一貫して使用します。 これらの値をご使用の環境に応じた値に置き換えてください。データベース名が 8 文字を超えないようにしてください。また、使用できるのは文字と数字のみです。

  • 同一のデータベース・ユーザー ID を使用する場合は、データベース名、データベース・サーバー・ノード、またはスキーマ名を固有にする必要があります。
  • ローカルな DB2 データベースにアクセスすると、共用メモリーの問題が発生する場合があります。この問題を解決するには、ローカル・システム上のリモート・データベースとしてローカル・データベースを扱う必要があります。 手動でデータベースを作成する場合は、『リモート・データベースの作成』セクションの指示に従ってください。
  • DB2 Universal JDBC ドライバー (タイプ 4 モード) を使用する場合、データベースに直接接続してください。 別名データベース (ゲートウェイ) に接続するのではなく、JDBC 接続 URL (dbdomain.DbUrl) およびデータベース名プロパティー (dbdomain.DbName) には実際のデータベース名を指定してください。

ローカル・データベース環境では、WebSphere Portal ExpressDB2 は同じシステムにインストールします。

図 5. ローカル・データベース環境
ローカル・データベース。この図について詳しくは、このトピックのテキストを参照してください。

図 2 に示すように、JDBC タイプ 2 接続を使用する場合、WebSphere Portal Express および DB2 Connect は 1 つのシステム (ローカル・システム) にインストールします。 DB2 サーバーは別のシステム (リモート・システム) にインストールします。

図 6. リモート・データベース環境 (JDBC タイプ 2 接続)
リモート・データベース。この図について詳しくは、このトピックのテキストを参照してください。

JDBC タイプ 4 接続の場合、WebSphere Portal Express を実行する システムに DB2 Connect をインストールする必要はありません。 図 3 に示すように、DB2 に付属している DB2 Universal JDBC ドライバーは、このシステムにコピーされます。 これは、WebSphere Portal Express の Java 仮想マシン内で使用され、 リモートの DB2 サーバーに直接接続します。

図 7. リモート・データベース環境 (JDBC タイプ 4 接続)
タイプ 4 接続を行うリモート・データベース。この図について詳しくは、このトピックのテキストを参照してください。
手順
  1. 以下の表に示すさまざまなデータベースを検討し、これらの値をご使用の環境の値に置き換えます。データベースを共用している場合は、スキーマ名を異なるものにする必要があります。 1 つのデータベースを使用するように WebSphere Portal Express を構成することは技術的には可能ですが、独立した複数のデータベースを使用すると、スケーラビリティーおよびパフォーマンスを向上させることができます。 アーキテクチャーによって、これらのデータベースはそれぞれ、1 つまたは 複数のインスタンスに存在することができます。 ただし、推奨されるアーキテクチャーは、インストール・プログラムによって作成されたデフォルト・インスタンス (db2inst1) を使用します。
    表 9. さまざまなデータベースに必要なスペース
    アプリケーション データベース名 必要なスペース
    WebSphere Portal Express

    ポータルの最低限、またはすべてのデータを保持するために使用する。ページなど のユーザー・カスタマイズに関する情報と、ユーザー・プロファイルおよびログイン情報を保管する。

    • reldb
    • commdb
    • custdb
    ユーザー数、およびページおよびポートレットなどのポータル・オブジェクトの数によって異なる。
    Personalization,Web Content Management

    文書、Personalization ルール、Personalization キャンペーン、および文書ライブラリーの構成情報を含む。

    • jcrdb
    Personalization ルールおよびキャンペーンの数およびサイズ、Web Content Management で作成された項目およびエレメントの数およびサイズによって異なる。
    Feedback

    サイト活動の分析やレポートの生成のために Web サイトによって記録される情報が格納されます。

    • fdbkdb
    サイトに対するトラフィック量によって異なります。ログイン可能なページごとにログに記録されるデータの量は、異なる可能性があります。
    LikeMinds

    Web サイトとの対話が分析され、予測が生成されたときにユーザーに対して表示されるレコメンデーションが含まれています。

    • lmdb
    サイトに対するトラフィック量によって異なります。
  2. 各ユーザーが所有するテーブル数およびオブジェクトのタイプを検討します。 アーキテクチャーによって、以下の各ユーザーを同じデータベースに配置できます。 すべてのテーブル・スペースは、デフォルトでは約 2.8GB です。サイズは、Java Content Repository を使用して増加できます。
    表 10. データベース・ユーザーが所有するテーブルおよびオブジェクト
    アプリケーション データベース・ユーザー・プレースホルダー 機能
    WebSphere Portal Express
    • releaseusr
    • communityusr
    • customizationusr
    約 230 のテーブルを所有するコア・ユーザー。これらのテーブルは WebSphere Portal Express コア・オブジェクト用に使用され、ページに対して行われたユーザーのカスタマイズ情報を保管するテーブルを含みます。
    Java Content Repository
    • jcr
    Java Content Repository ユーザーは、少なくとも 1130 のテー ブルを所有します。数値は、使用量に応じて増える場合があります。
    Feedback
    • feedback
    ロギング・サイトおよび Personalization で使用する約 50 のテーブルを所有する Feedback ユーザー。
    LikeMinds
    • likeminds
    Web サイト使用分析ルーチンおよび推奨テキストを保持するために使用する約 15 のテーブルを所有する LikeMinds ユーザー。

IBM DB2 for i の計画

IBM DB2 for i へのデータ転送を計画する場合は、 データベース名、格納するデータ、および必要なデータベースのスペースなど、データベースおよびユーザーの情報について検討する必要があります。 一部のフィックスパックでは、転送タスクを正常に実行するために、転送タスクの前にいくつかの手順を行うことが必要です。

始める前に
始める前に
  • データベースに関する考慮事項を確認してください。
  • デフォルトのデータベース接続はタイプ 4 接続であるため、IBM i コマンド WRKRDBDIRE を使用して、ローカル・データベース環境のデータベース項目、またはリモート環境でのリモート・データベースのデータベース項目があることを確認します。
  • 使用予定のデータベースが、このバージョンの WebSphere Portal Express でサポートされているかどうかを確認します。 WebSphere Portal Express の詳細なシステム要件にある、サポート対象データベースのリストを参照してください。
このタスクについて

DB2i に統合されていますが、必要なデータベースとユーザ ーを作成し、そのユーザーに適切な権限を付与することは必要です。 WebSphere Portal Express によってデータベースを作成することも可能です。

このトピックのデータベース名およびユーザーは推奨値であり、文書全体で一貫して使用します。 これらの値をご使用の環境に応じた値に置き換えてください。

WebSphere Portal Express はインストール時に DB2 を使用します。また、 IBM System i5 システム用の DB2 の構成をサポートしています。

IBM DB2 for i データベースを使用す れば、アプリケーションまたはユーザー・インターフェースを使用して、サーバー・データへのアクセスと管理を実行で きます。IBM DB2 Universal Database for i は、データへのアクセスと保護の機能を提供するだけでなく、参照保全性や並列データベース処理などの拡張機能も提供 しています。

IBM DB2 for i は、 i システムに完全に統合されたリレーショナル・データベース・マネージャーです。IBM DB2 for i には、広範囲のアプリケーション・タイプに対応する、トリガー、ストアード・プロシージャー、動的ビットマップ索引付けなどの機能も用意されています。 対応するアプリケーションの範囲は、クライアント/サーバー・ソリューションに対する従来の ホスト・ベースのアプリケーションから、ビジネス・インテリジェンス・アプリケーションまでの 広い範囲にわたります。

DB2 Query Manager および SQL (構造化照会言語) Development Kit for System i5 は、IBM DB2 for i に対するインターフェースとして、対話式の照会とレポート作成のインターフェース、および高水準プログラム言語で SQL アプリケーション・プログラムを作成する際に役立つプリコンパイラーとツールを追加します。OS/400 用の SQL インプリメンテーションは、 i データの定義、操作、照会、およびアクセス制御を実行できます。このインプリメンテーションでは、 i ファイルでも SQL テーブルでも同じように操作できます。

1 つのデータベースを使用して、WebSphere Portal ExpressMember Manager、 および content publishing のすべての情報を保持するようにする場合、必要なユーザー・プロファイルは 1 つだけです。 複数の i システムを使用する場合や、個別のデータベースが必要な場合にのみ、追加のユーザー・プロファイルが必要になります。

WebSphere Portal Express は、データベースを作成するときに、UserData ディレクトリー wp_profile_root/ConfigEngine/properties にある wkplc_dbdomain.properties ファイルに指定されているデータベース名を使用します。 wkplc_dbdomain.properties ファイルに異なる値を設定することで、異なるデータベースを最大 6 つまで作成できます。

ポータルを 1 つのデータベースを使用するように構成することは技術的に可能ですが、 スケーラビリティーとパフォーマンスの調整上の理由から、別々のデータベースを使用します。 単一の共用データベースを使用するには、各データベースとユーザー変数を、 それぞれ、ご使用のデータベース名とデータベース・ユーザーで置き換えます。
注: データベース名のフォーマットは、タイプ 2 データベース接続の場合は *LOCAL/database_name となり、タイプ 4 データベース接続の場合は myserver.mycompany.com/database_name などの完全修飾サーバー名になります。

ローカル・データベース環境では、WebSphere Portal Express および IBM DB2 for i に、タイプ 4 接続またはタイプ 2 接続でアクセスできます。 タイプ 4 がデフォルトで、推奨の接続です。

リモート・データベース環境では、WebSphere Portal Express は、DB2 サーバーに直接接続されます (JDBC タイプ 4 接続)。

手順
  1. 以下の表に示すさまざまなデータベースを検討し、これらの値をご使用の環境の値に置き換えます。データベースを共用している場合は、スキーマ名を異なるものにする必要があります。
    表 11. さまざまなデータベースに必要なスペース
    アプリケーション データベース名 必要なスペース
    WebSphere Portal Express

    ポータルの最低限、またはすべてのデータを保持するために使用する。ページなど のユーザー・カスタマイズに関する情報と、ユーザー・プロファイルおよびログイン情報を保管する。

    • reldb
    • commdb
    • custdb
    ユーザー数、およびページおよびポートレットなどのポータル・オブジェクトの数によって異なる。
    Personalization,Web Content Management

    文書、Personalization ルール、Personalization キャンペーン、および文書ライブラリーの構成情報を含む。

    • jcrdb
    Personalization ルールおよびキャンペーンの数およびサイズ、Web Content Management で作成された項目およびエレメントの数およびサイズによって異なる。
    Feedback

    サイト活動の分析やレポートの生成のために Web サイトによって記録される情報が格納されます。

    • fdbkdb
    サイトに対するトラフィック量によって異なります。ログイン可能なページごとにログに記録されるデータの量は、異なる可能性があります。
    LikeMinds

    Web サイトとの対話が分析され、予測が生成されたときにユーザーに対して表示されるレコメンデーションが含まれています。

    • lmdb
    サイトに対するトラフィック量によって異なります。
  2. 各ユーザーが所有するテーブル数およびオブジェクトのタイプを検討します。 アーキテクチャーによって、以下の各ユーザーを同じデータベースに配置できます。 すべてのテーブル・スペースは、デフォルトでは約 2.8GB です。サイズは、Java Content Repository を使用して増加できます。
    表 12. データベース・ユーザーが所有するテーブルおよびオブジェクト
    アプリケーション データベース・ユーザー・プレースホルダー 機能
    WebSphere Portal Express
    • releaseusr
    • communityusr
    • customizationusr
    約 230 のテーブルを所有するコア・ユーザー。これらのテーブルは WebSphere Portal Express コア・オブジェクト用に使用され、ページに対して行われたユーザーのカスタマイズ情報を保管するテーブルを含みます。
    Java Content Repository
    • jcr
    Java Content Repository ユーザーは、少なくとも 1130 のテー ブルを所有します。数値は、使用量に応じて増える場合があります。
    Feedback
    • feedback
    ロギング・サイトおよび Personalization で使用する約 50 のテーブルを所有する Feedback ユーザー。
    LikeMinds
    • likeminds
    Web サイト使用分析ルーチンおよび推奨テキストを保持するために使用する約 15 のテーブルを所有する LikeMinds ユーザー。

DB2 for z/OS の計画

IBM DB2 Universal Database for z/OS® へのデータ転送を計画する場合は、 データベース名、格納するデータ、および必要なデータベースのスペースなど、データベースおよびユーザーの情報について検討する必要があります。 一部のフィックスパックでは、転送タスクを正常に実行するために、転送タスクの前にいくつかの手順を行うことが必要です。

始める前に

WebSphere Portal Express 用のデータベースとして使用するために DB2 for z/OS のインストールを計画しているときは、以下を検討してください。

  • データベースに関する考慮事項を確認してください。
  • 使用予定のデータベースが、このバージョンの WebSphere Portal Express でサポートされているかどうかを確認します。 WebSphere Portal Express の詳細なシステム要件にある、サポート対象データベースのリストを参照してください。
  • Java Database Connectivity の要件を満たしていることを確認します。以下のリファレンスを参照してください。
  • IBM DB2 Universal Database for z/OS を、データベース・ユーザー・レジストリーまたはプロパティー拡張 (索引) データベースとして使用してデータベース転送を行う予定である場合は、共通サービス域 (CSA) 設定を 3500,350000 に変更します。CSA の計算および設定について詳しくは、該当する以下の DB2 for z/OS Information Center のトピックを参照してください。
  • DB2 for z/OS バージョン 9.1.2 と共にタイプ 2 ドライバーを使用する予定である場合は、DB2 for z/OS APAR PK58105 がインストール済みであることを確認してください。
  • 以下のガイドラインを検討してください。
    • 現行バージョンと旧バージョンの WebSphere Portal Express が混在して同じ DB2 for z/OS サブシステムを使用している場合は、現行バージョンの WebSphere Portal Express のデータベース・ユーザー ID を旧バージョンの ID とは異なるように設定し、インストール時の競合を避ける必要があります。 2 つのバージョンの WebSphere Portal Express が 2 つの異なる DB2 for z/OS サブシステムに接続する場合は、同じユーザー ID を使用しても競合は発生しません。
    • システムのバッファー・プール割り振りを確認し、ご使用のインストールに応じて適切にバッファー・プールを定義し、十分な大きさのサイズを定義してください。例えば、以下のようにします。
      -db2 display bufferpool(bp2) 
      -db2 alter bufferpool(bp2) vpsize(15000)
      • 必要に応じて、以下のような追加のバッファー・プールで操作を繰り返します。
        • bp3
        • bp4
        • bp5
        • bp32k1
        • bp32k2
      • データベース転送を実行する前に、BP8K0 カタログ・バッファー・プールを 35,000 に更新します。SYSIBM.SYSDATABASE テーブルはこのバッファー・プール内に存在し、データベース転送時に DB2 for z/OS によって広範囲に使用されます。
    • Derby から DB2 for z/OS へのデータ転送時には、文書を保管するデータベース・テーブル用に、サポートしている下位バイト・テーブル・スペースが作成されます。テーブル・スペースの PRIQTY および SECQTY は、 デフォルト値を使用して割り当てられます。多数の文書を保管する場合は、自動クラス選択 (ACS) ルーチンを使用して、 少なくとも 10 シリンダーの 1 次および 2 次スペース割り振りで、DB2 for z/OS データ・セットを割り振るか、または DB2 DSNTIJUZ メンバーの PRIQTY と SEQTY にとって十分に大きな値を指定してください。 テーブル・スペースは、名前 (JCRDB.Sxxxxxxx のような構造) で識別できます。 xxxxxxx は、システムが割り当てる 7 個の数字と文字の組み合わせです。
    • また、メンバー DSNTIJUZ で次のパラメーターを更新してから、DSNTIJUZ が正常に実行されていることを確認します。
      • edmdbdc = 204800
      • edmpool=409600
      • edmstmtc=204800
      • rrulock=no
      • cachedyn=yes (作成済みの動的 SQL ステートメントがキャッシュされる)
      • dbacrvw=yes (データベース管理者によるビューの作成を許可する)
    • LikeMinds サンプルを実行する予定である場合は、NUMLKTS パラメーターおよび NUMLKUS パラメーターを引き上げます。デフォルトの 10 倍で十分ですが、サンプルの使用法によってはさらに引き上げます。例えば、NUMLKTS=1000 および NUMLKUS=10000 がインストールでのデフォルト値である場合は、これらの値を NUMLKTS=10000 および NUMLKUS=100000 に更新します。
    • DB2 JDBC および ODBC メタデータ・メソッドで必要なオブジェクトを作成するために、ジョブ DSNTIJSG が実行されていることを確認します。「DB2 インストール・ガイド」の『JDBC および ODBC サポート用のストアード・プロシージャーとテーブルを使用可能にする』を参照してください。
    • ジョブ DSNTIJMS が正常に実行されていることを確認します (バインドの再実行)。
    • ジョブ DSNTIJEX が正常に実行されていることを確認します。
    • ラージ・オブジェクトが格納されて列が非常に大規模になる可能性があるため、これらの列に対する変更をロギングするには、大容量のログ・スペースが必要になります。したがって、そのようなデータを格納するテーブル・スペースでは、ラージ・オブジェクト (LOB) ロギングはデフォルトで無効になっています。LOB ロギングが無効の場合、フルバックアップのリカバリーは可能ですが、ポイント・イン・タイム・リカバリーに使用できる増分バックアップのリカバリーは不可能です。ポイント・イン・タイム・バックアップをリカバリーするには、LOB ロギングを有効にする必要があります。詳しくは、技術情報 1306637「Managing LOB logging in DB2 for z/OS」を参照してください。
このタスクについて

このページのデータベース名およびユーザーは推奨値であり、文書全体で一貫して使用します。 これらの値をご使用の環境に応じた値に置き換えてください。データベース名が 8 文字を超えないようにしてください。また、使用できるのは文字と数字のみです。

手順
  1. 以下の表に示すさまざまなデータベースを検討し、これらの値をご使用の環境の値に置き換えます。データベース・サブシステムを共用している場合は、スキーマ名を異なるものにする必要があります。 WebSphere Portal Express は、1 つのデータベースを使用するように構成できます。しかし、複数の異なるデータベースを使用するなら、スケーラビリティーとパフォーマンスが向上します。
  2. ご使用の Java Content Repository が Declared Global Temporary Table (DGTT) を使用する場合は、使用前に適切な TEMP データベースおよび TEMP テーブル・スペースを構成する必要があります。TEMP データベースには、 割り振られた追加スペースが必要である場合があります。以下の情報をガイドラインとして使用して、 宣言された一時テーブルを含めるための TEMP データベースおよび TEMP テーブル・スペースを作成します。
    表 13. TEMP データベースおよび TEMP テーブル・スペースの作成方法の例 (データベース・バージョン別)
    データベース・バージョン
    DB2 for z/OS バージョン 8 TEMP データベースおよびテーブル・スペースが存在しない場合は作成する。 以下は、TEMP データベース定義の代表例です。
    CREATE DATABASE TEMP AS TEMP STOGROUP SYSDEFLT;
    CREATE TABLESPACE TEMP IN TEMP  
    USING STOGROUP SYSDEFLT  
    BUFFERPOOL BP8  
    SEGSIZE 32; 
    このバージョンでは、ソートなどの作業用ストレージを必要とする SQL ステートメント用の 作業ファイル・データベース・ストレージも必要です。 This requires the addition of a table space to support sorting operations in addition to the TEMP database.
    非データ共用環境での DB2 for z/OS バージョン 9 TEMP データベースは DSNDB07 で、データベースのインストール時に作成されます。 一時テーブル・スペースが既存の TEMP データベースに追加されます。 以下は、一時テーブル・スペースの代表例です。
    CREATE TABLESPACE ICMTEMP IN DSNDB07  
    USING STOGROUP SYSDEFLT  
    BUFFERPOOL BP8  
    SEGSIZE 32; 

    このバージョンでは、作業ファイル・データベース および TEMP データベースが結合されます。作業ファイル・データベースの作成の手順およびサイズ設定の推奨については、 DB2 for z/OS インフォメーション・センターを参照してください。

    データ共用環境での DB2 for z/OS バージョン 9 WORKFILE データベースを作成します。1 つのサブシステムに作成できる WORKFILE データベースは 1 つだけです。 以下は、 WORKFILE データベースおよび一時テーブル・スペースの作成の代表例です。
    CREATE DATABASE WORKTEMP AS WORKFILE STOGROUP SYSDEFLT;  
    CREATE TABLESPACE ICMTEMP IN WORKTEMP  
    USING STOGROUP SYSDEFLT  
    BUFFERPOOL BP8  
    SEGSIZE 32;  

    このバージョンでは、作業ファイル・データベース および TEMP データベースが結合されます。作業ファイル・データベースの作成の手順およびサイズ設定の推奨については、 DB2 for z/OS インフォメーション・センターを参照してください。

    TEMP データベースおよび TEMP テーブル・スペースのセットアップに関する追加情報については、DB2 for z/OS の資料を参照してください。

Oracle の計画

Oracle へのデータ転送を計画する場合は、 データベース名、格納するデータ、および必要なデータベースのスペースなど、データベースおよびユーザーの情報について検討する必要があります。

始める前に
始める前に
  • データベースに関する考慮事項を確認してください。
  • 使用予定のデータベースが、このバージョンの WebSphere Portal Express でサポートされているかどうかを確認します。 WebSphere Portal Express の詳細なシステム要件にある、サポート対象データベースのリストを参照してください。
このタスクについて

このトピックのデータベース名およびユーザーは推奨値であり、文書全体で一貫して使用します。 これらの値をご使用の環境に応じた値に置き換えてください。

手順
  1. 以下の表に示すさまざまなデータベースを検討し、これらの値をご使用の環境の値に置き換えます。データベースを共用している場合は、スキーマ名を異なるものにする必要があります。 WebSphere Portal Express は、 下記の各データベースに別々のデータベース・ユーザーを選択した場合に 単一の共用データベースを使用するように 構成できます。。Oracle では、 単一のデータベース構成により、データベース管理システムが使用する システム・リソースの消費量を大幅に削減できます。 以下に示すすべてのデータベースについて独立したテーブル・スペースを使用すると、スケーラビリティーおよびパフォーマンスを向上できます。
    表 14. さまざまなデータベースに必要なスペース
    アプリケーション データベース名 必要なスペース
    WebSphere Portal Express

    ポータルの最低限、またはすべてのデータを保持するために使用する。ページなど のユーザー・カスタマイズに関する情報と、ユーザー・プロファイルおよびログイン情報を保管する。

    • reldb
    • commdb
    • custdb
    ユーザー数、およびページおよびポートレットなどのポータル・オブジェクトの数によって異なる。
    Personalization,Web Content Management

    文書、Personalization ルール、Personalization キャンペーン、および文書ライブラリーの構成情報を含む。

    • jcrdb
    Personalization ルールおよびキャンペーンの数およびサイズ、Web Content Management で作成された項目およびエレメントの数およびサイズによって異なる。
    Feedback

    サイト活動の分析やレポートの生成のために Web サイトによって記録される情報が格納されます。

    • fdbkdb
    サイトに対するトラフィック量によって異なります。ログイン可能なページごとにログに記録されるデータの量は、異なる可能性があります。
    LikeMinds

    Web サイトとの対話が分析され、予測が生成されたときにユーザーに対して表示されるレコメンデーションが含まれています。

    • lmdb
    サイトに対するトラフィック量によって異なります。
  2. 各ユーザーが所有するテーブル数およびオブジェクトのタイプを検討します。 アーキテクチャーによって、以下の各ユーザーを同じデータベースに配置できます。 すべてのテーブル・スペースは、デフォルトでは約 2.8GB です。サイズは、Java Content Repository を使用して増加できます。
    表 15. データベース・ユーザーが所有するテーブルおよびオブジェクト
    アプリケーション データベース・ユーザー・プレースホルダー 機能
    WebSphere Portal Express
    • releaseusr
    • communityusr
    • customizationusr
    約 230 のテーブルを所有するコア・ユーザー。これらのテーブルは WebSphere Portal Express コア・オブジェクト用に使用され、ページに対して行われたユーザーのカスタマイズ情報を保管するテーブルを含みます。
    Java Content Repository
    • jcr
    Java Content Repository ユーザーは、少なくとも 1130 のテー ブルを所有します。数値は、使用量に応じて増える場合があります。
    Feedback
    • feedback
    ロギング・サイトおよび Personalization で使用する約 50 のテーブルを所有する Feedback ユーザー。
    LikeMinds
    • likeminds
    Web サイト使用分析ルーチンおよび推奨テキストを保持するために使用する約 15 のテーブルを所有する LikeMinds ユーザー。

Oracle RAC の計画

Oracle RAC へのデータ転送を計画する場合は、 データベース名、格納するデータ、および必要なデータベースのスペースなど、データベースおよびユーザーの情報について検討する必要があります。

始める前に
始める前に
  • データベースに関する考慮事項を確認してください。
  • 使用予定のデータベースが、このバージョンの WebSphere Portal Express でサポートされているかどうかを確認します。 WebSphere Portal Express の詳細なシステム要件にある、サポート対象データベースのリストを参照してください。
このタスクについて

このトピックのデータベース名およびユーザーは推奨値であり、文書全体で一貫して使用します。 これらの値をご使用の環境に応じた値に置き換えてください。

Oracle RAC の デフォルトのテーブル・スペース・サイズは、データベース転送を正常に実行するために、 autoextend をオンにして 1024MB に設定する必要があります。

手順
  1. 以下の表に示すさまざまなデータベースを検討し、これらの値をご使用の環境の値に置き換えます。データベースを共用している場合は、スキーマ名を異なるものにする必要があります。 WebSphere Portal Express は、 下記の各データベースに別々のデータベース・ユーザーを選択した場合に 単一の共用データベースを使用するように 構成できます。Oracle では、 単一のデータベース構成により、データベース管理システムが使用する システム・リソースの消費量を大幅に削減できます。 以下に示すすべてのデータベースについて独立したテーブル・スペースを使用すると、スケーラビリティーおよびパフォーマンスを向上できます。
    表 16. さまざまなデータベースに必要なスペース
    アプリケーション データベース名 必要なスペース
    WebSphere Portal Express

    ポータルの最低限、またはすべてのデータを保持するために使用する。ページなど のユーザー・カスタマイズに関する情報と、ユーザー・プロファイルおよびログイン情報を保管する。

    • reldb
    • commdb
    • custdb
    ユーザー数、およびページおよびポートレットなどのポータル・オブジェクトの数によって異なる。
    Personalization,Web Content Management

    文書、Personalization ルール、Personalization キャンペーン、および文書ライブラリーの構成情報を含む。

    • jcrdb
    Personalization ルールおよびキャンペーンの数およびサイズ、Web Content Management で作成された項目およびエレメントの数およびサイズによって異なる。
    Feedback

    サイト活動の分析やレポートの生成のために Web サイトによって記録される情報が格納されます。

    • fdbkdb
    サイトに対するトラフィック量によって異なります。ログイン可能なページごとにログに記録されるデータの量は、異なる可能性があります。
    LikeMinds

    Web サイトとの対話が分析され、予測が生成されたときにユーザーに対して表示されるレコメンデーションが含まれています。

    • lmdb
    サイトに対するトラフィック量によって異なります。
  2. 各ユーザーが所有するテーブル数およびオブジェクトのタイプを検討します。 アーキテクチャーによって、以下の各ユーザーを同じデータベースに配置できます。 すべてのテーブル・スペースは、デフォルトでは約 2.8GB です。サイズは、Java Content Repository を使用して増加できます。
    表 17. データベース・ユーザーが所有するテーブルおよびオブジェクト
    アプリケーション データベース・ユーザー・プレースホルダー 機能
    WebSphere Portal Express
    • releaseusr
    • communityusr
    • customizationusr
    約 230 のテーブルを所有するコア・ユーザー。これらのテーブルは WebSphere Portal Express コア・オブジェクト用に使用され、ページに対して行われたユーザーのカスタマイズ情報を保管するテーブルを含みます。
    Java Content Repository
    • jcr
    Java Content Repository ユーザーは、少なくとも 1130 のテー ブルを所有します。数値は、使用量に応じて増える場合があります。
    Feedback
    • feedback
    ロギング・サイトおよび Personalization で使用する約 50 のテーブルを所有する Feedback ユーザー。
    LikeMinds
    • likeminds
    Web サイト使用分析ルーチンおよび推奨テキストを保持するために使用する約 15 のテーブルを所有する LikeMinds ユーザー。

SQL Server の計画

SQL Server へのデータ転送を計画する場合は、 データベース名、格納するデータ、および必要なデータベースのスペースなど、データベースおよびユーザーの情報について検討する必要があります。

始める前に
始める前に
  • データベースに関する考慮事項を確認してください。
  • 使用予定のデータベースが、このバージョンの WebSphere Portal Express でサポートされているかどうかを確認します。 WebSphere Portal Express の詳細なシステム要件にある、サポート対象データベースのリストを参照してください。
このタスクについて

このトピックのデータベース名およびユーザーは推奨値であり、文書全体で一貫して使用します。 これらの値をご使用の環境に応じた値に置き換えてください。

手順
  1. 以下の表に示すさまざまなデータベースを検討し、これらの値をご使用の環境の値に置き換えます。データベースを共用している場合は、スキーマ名を異なるものにする必要があります。 1 つのデータベースを使用するように WebSphere Portal Express を構成することは技術的には可能ですが、独立した複数のデータベースを使用すると、スケーラビリティーおよびパフォーマンスを向上させることができます。
    表 18. さまざまなデータベースに必要なスペース
    アプリケーション データベース名 必要なスペース
    WebSphere Portal Express

    ポータルの最低限、またはすべてのデータを保持するために使用する。ページなど のユーザー・カスタマイズに関する情報と、ユーザー・プロファイルおよびログイン情報を保管する。

    • reldb
    • commdb
    • custdb
    ユーザー数、およびページおよびポートレットなどのポータル・オブジェクトの数によって異なる。
    Personalization,Web Content Management

    文書、Personalization ルール、Personalization キャンペーン、および文書ライブラリーの構成情報を含む。

    • jcrdb
    Personalization ルールおよびキャンペーンの数およびサイズ、Web Content Management で作成された項目およびエレメントの数およびサイズによって異なる。
    Feedback

    サイト活動の分析やレポートの生成のために Web サイトによって記録される情報が格納されます。

    • fdbkdb
    サイトに対するトラフィック量によって異なります。ログイン可能なページごとにログに記録されるデータの量は、異なる可能性があります。
    LikeMinds

    Web サイトとの対話が分析され、予測が生成されたときにユーザーに対して表示されるレコメンデーションが含まれています。

    • lmdb
    サイトに対するトラフィック量によって異なります。
  2. 1 名以上のユーザーを SQL Server インスタンスに接続します。 ユーザーには複数のスキーマ名を使用する権限を付与できるため、各インスタンスに 1 名のユーザーで十分です。
  3. 各スキーマが所有するテーブル数およびオブジェクトのタイプを検討します。 WebSphere Portal Express アーキテクチャーでは、以下の各スキーマを同じデータベース内に配置できます。 すべてのテーブル・スペースは、デフォルトでは約 2.8GB です。 サイズは、Java Content Repository 関数を使用して増加できます。
    表 19. アプリケーション、データベース・スキーマ・プレースホルダー、推奨される名前、および機能別の情報
    アプリケーション データベース・スキーマ・プレースホルダー 推奨される名前 機能
    WebSphere Portal Express
    • releaseusr
    • communityusr
    • customizationusr
    <なし> コア・スキーマ。ドメインごとに、約 130 のテーブルを所有します。ページに対して行われたユーザー・カスタマイズを保管するテーブルを含む、WebSphere Portal Express コア・オブジェクトを所有しています。
    Java Content Repository icmadmin <なし> Java Content Repository スキーマ。少なくとも 1130 のテー ブルを所有します。数値は、使用量に応じて増える場合があります。
    Feedback feedback <なし> Feedback スキーマ。ロギング・サイトおよび Personalization で使用する約 50 のテーブルを所有します。
    Likeminds LIKEMINDS <なし> LikeMinds スキーマ。Web サイト使用分析ルーチンおよび推奨テキストを保持するために使用する、約 15 のテーブ ルを所有します。

ユーザー・レジストリーに関する考慮事項

ユーザー・レジストリーまたはユーザー・リポジトリーでは、認証と許可を含むセキュリティー関連の機能を実行するために、ユーザーが認証され、ユーザーとグループに関する情報が取得されます。

ユーザー・レジストリーには、ユーザー ID やパスワードなどのユーザー・アカウント情報が保管され、認証時にアクセスすることができます。 ユーザー・リポジトリーには、ユーザー・プロファイルとユーザー設定の情報が保管されます。 ユーザー・レジストリーまたはユーザー・リポジトリーは、以下のことを行うために使用されます。
  • 基本認証、ID アサーション、またはクライアント証明書を使用して、ユーザーを認証する
  • ユーザーとグループの情報を取得して、セキュリティー役割へのユーザーとグループのマップなどのセキュリティー関連の管理機能を実行する
IBM WebSphere Portal Express は、デフォルトでは、組み込みのファイル・リポジトリーが備わった統合リポジトリーと共にインストールされます。 この統合リポジトリーにより、各種ユーザー・レジストリー、仮想ポータルのレルム・サポート、または単一の作業単位を作成するためのプロパティーの拡張を追加することができます。 統合リポジトリーに追加できる使用可能なユーザー・レジストリーは、LDAP ユーザー・レジストリー、データベース・ユーザー・レジストリー、およびカスタム・ユーザー・レジストリーです。
要確認: 組み込みファイル・リポジトリーの使用は、実稼働環境では推奨されません。 別のリポジトリーを追加してそのリポジトリーから管理ユーザーを選択した後、そのファイル・リポジトリーを除去する必要があります。

統合リポジトリーに基づいて、WebSphere Portal Express は複数のリポジトリー (LDAP、DB、およびカスタム・ユーザー・レジストリーまたはそのいずれか) において統合できるユーザー・ベースを作成できます。 また、企業 LDAP ディレクトリーが読み取り専用になっている場合は、別個のストアで追加属性を定義できます。

統合リポジトリーを使用している場合は、新規ユーザーおよびグループの保管場所を計画する必要があります。 デフォルトで、新規ユーザーおよびグループは、デフォルトのファイル・リポジトリーに保管されます。 複数の LDAP ユーザー・レジストリーおよび (または) データベース・ユーザー・レジストリーを使用している場合は、 新規ユーザーおよびグループの保管場所となるデフォルトのユーザー・レジストリーとして、どのユーザー・レジストリーを定義するかを判別する必要があります。 すべてのユーザー・レジストリーを統合リポジトリーに追加した後、wp-set-entitytypes タスクを実行して、特定のユーザー・レジストリーをデフォルトの場所として設定できます。

要確認: 複数のユーザー・レジストリーを結合する前に、レジストリーで以下の制限事項を確認し、問題があれば訂正してください。
  • レルムにおける識別名は、すべてのレジストリーで固有でなければなりません。例えば、uid=wpsadmin,o=yourco が LDAP1 内に存在する場合は、このユーザーが LDAP2、LDAP3、または DB1 内に存在することはできません。
  • レルムにおける短縮名 (例えば wpsadmin) は、すべてのレジストリーで固有でなければなりません。
  • レルム内で使用されるすべてのレジストリーの基本識別名は重複してはなりません。例えば、LDAP1 が c=us,o=yourco の場合、LDAP2 を o=yourco にしてはなりません。
  • レルム内で使用されるどのレジストリーでも、基本エントリーを空白にしてはなりません。
  • IBM Lotus Domino が複数のレジストリー構成内のユーザー・レジストリーの 1 つになり、別のユーザー・レジストリーとレルムを共有する場合には、グループが必ず、デフォルトのフラット・ネーミング構造ではなく階層フォーマットで Domino Directory に保管されるようにしてください。 例えば、フラット・ネーミング規則は cn=groupName ですが、 階層フォーマットは cn=groupName,o=root です。
  • このユーザーは、プロパティー拡張構成内ではなく、特定のユーザー・レジストリー内に存在している必要があります。 存在していない場合、このユーザーは、レルムのメンバーになることができません。

統合リポジトリーをサポートしないアプリケーションが存在する場合は、スタンドアロンの LDAP ユーザー・レジストリーまたはスタンドアロンのカスタム・ユーザー・レジストリーに切り替えることができます。

ユーザー・レジストリー・オプションの概要

IBM WebSphere Portal Express には、さまざまなセキュリティー構成タスクがあります。 以前は、タスクは 1 つだけであり、エラーからリカバリーしたり、増大するビジネス要件にユーザー・レジストリーを適合させたりすることはできませんでした。 現在は、複数のタスクがあり、ご使用のシステムを微調整してビジネス要件を満たすことができます。

以下の汎用セキュリティー・オプションを選択できます。
表 20. セキュリティー・オプションとその説明
セキュリティー・オプション 説明
スタンドアロン LDAP セキュリティー このオプションは、単純な単一の LDAP セキュリティー・オプションです。過去に提供されていた LDAP セキュリティー・オプションと類似したものです。 このオプションにより、単一レルムを持つ仮想ポータルを作成して、ユーザーおよびグループを単一の LDAP サーバーに保管できます。
統合セキュリティー このオプションは、単一レルム・サポート・オプションを持つスタンドアロン LDAP ユーザー・レジストリーに対する拡張オプションです。 このオプションにより、複数のレルムを持つ仮想ポータルを作成したり、複数のリポジトリー (LDAP、データベース、カスタム) を使用したり、アプリケーション・グループをシステムに追加したりできます。 このオプションは、複数の LDAP サーバーを 1 つのまとまった構造にマージする必要がある場合に有用です。
重要: 各種リポジトリー間で名前の重複がないよう、特に注意する必要があります。 例えば、「wpsadmin」という名前のポータル管理者が製品をインストールした場合には、「wpsadmin」という名前のユーザーは 企業の LDAP サーバーに存在してはなりません。
カスタム・セキュリティー このオプションによって、Virtual Member Manager (VMM) 用のカスタム・ユーザー・レジストリーおよびカスタム・メンバー・アダプターを提供することにより、完全に制御された WebSphere セキュリティー環境を作成できます。 このオプションの機能は、ご使用の実装環境によって異なります。
スタンドアロン LDAP セキュリティー

出荷時の WebSphere Portal Express は、組み込みのファイル・リポジトリーが備わったデフォルトの統合リポジトリーで構成されます。 したがって、wp-modify-ldap-securityタスクを実行して、スタンドアロン LDAP ユーザー・レジストリーに切り替える必要があります。 LDAP ユーザー・レジストリーを WebSphere Portal で適正に作動させるため、構成された LDAP サーバーおよびビジネス要件に合うように、属性構成を適応させる必要があります。 これらのタスクのステップが完了すると、セキュリティーは実動の準備ができています。

スタンドアロン LDAP ユーザー・レジストリーを使用後、ユーザー・レジストリーを管理する必要があるかもしれません。以下の任意のオプション・タスクを実行して、スタンドアロン LDAP ユーザー・レジストリーを微調整できます。
表 21. スタンドアロン・ユーザー・レジストリーを管理するオプション・タスク
タスク 説明
スタンドアロン LDAP ユーザー・レジストリーを更新する バインド ID およびパスワードなどの特定のパラメーターを更新して、LDAP ユーザー・レジストリー関連の問題を修正できます。
プロパティー拡張データベース (以前は索引データベースと呼ばれました) このオプションを選択すると、追加属性を LDAP ユーザー・レジストリーではなく、VMM プロパティー拡張内に保管します。 Common Mail ポートレットや IBM Lotus Web Content Management などのアプリケーションは、プロパティー拡張データベースを使用して追加属性を保管します。 プロパティー拡張データベースを使用可能にした後、属性を追加してユーザーのビジネス要件に合わせることができます。
エンティティー・タイプを作成する LDAP ユーザー・レジストリー内ではなく WebSphere Portal Express 内に存在するエンティティー・タイプを使用する場合は、このオプションを選択します。 このオプションは、ユーザー・レジストリー内でエンティティー・タイプを作成し、WebSphere Portal Express とユーザー・レジストリー間でエンティティー・タイプをマップする相対識別名 (RDN) を追加します。
既存のエンティティー・タイプを更新する このオプションを選択すると、既存の単一エンティティー・タイプのデフォルトの親を更新します。 例えば、あるリポジトリーを削除したものの、エンティティー・タイプがその削除されたリポジトリーを指している場合、情報を更新して新規リポジトリーを指すようにする必要があります。
統合セキュリティー
出荷時の WebSphere Portal Express は、組み込みのファイル・リポジトリーが備わったデフォルトの統合リポジトリーで構成されます。 統合リポジトリーは、ユーザーのビジネス要件に適合させ、また要件が増大するにつれてビジネスを容易に拡張できるようにする、最も豊富なオプションを提供します。 例えば、ユーザーの会社が既存 LDAP ユーザー・レジストリーを持つ新規ビジネスを獲得した場合、その LDAP サーバーを統合リポジトリーに追加するだけですみます。 以下のタスクの 1 つを選択して、実動リポジトリーを使用可能にします。
表 22. 実動リポジトリーを使用可能にするタスク
タスク 説明
統合 LDAP リポジトリーを VMM 構成に追加する このオプションを選択すると、LDAP サーバーを統合リポジトリーに追加します。 このタスクは現行のセキュリティー割り当てを変更しません。したがって、インストール中に定義された管理ユーザーは引き続きアクティブです。
統合データベース・リポジトリーを VMM 構成に追加する このオプションを選択すると、データベースを統合リポジトリーに追加します。 このタスクは現行のセキュリティー割り当てを変更しません。したがって、インストール中に定義された管理ユーザーは引き続きアクティブです。
統合カスタム・ユーザー・レジストリーを追加する このオプションを選択すると、貴社が作成したカスタム・ユーザー・レジストリーを統合リポジトリーに追加します。 このタスクは現行のセキュリティー割り当てを変更しません。したがって、インストール中に定義された管理ユーザーは引き続きアクティブです。
初期 LDAP ユーザー・レジストリー、データベース・ユーザー・レジストリー、またはカスタム・ユーザー・レジストリーを追加した後で、追加のユーザー・レジストリーをリポジトリーに追加して、複数のユーザー・レジストリー構成を作成できます。 リポジトリーの構成後、これが開発環境でない限り、デフォルトのファイル・ベース・リポジトリーを除去する必要があります。 以下のタスクは、デフォルトのファイル・ベース・リポジトリーを除去するために必要です。
表 23. デフォルトのファイル・ベース・リポジトリーを除去するために必要なタスク
タスク 説明
ユーザーおよびグループの保管場所となるユーザー・レジストリーを変更する このタスクは、新規ユーザーおよびグループの保管場所であるデフォルトのリポジトリーを変更します。
WebSphere Application Server 管理ユーザーを変更する このタスクは WebSphere Application Server アドミニストレーター・ユーザー ID およびパスワードを、インストール中に定義されたものから、クラスターまたはスタンドアロン実稼働環境に必要な新規ユーザー ID およびパスワードに変更します。
WebSphere Portal Server アドミニストレーターを変更する このタスクは WebSphere Portal Express アドミニストレーター・ユーザー ID およびパスワードを、インストール中に定義されたものから、クラスターまたはスタンドアロン実稼働環境に必要な新規ユーザー ID およびパスワードに変更します。
統合リポジトリーを VMM 構成から削除する このタスクは、デフォルトのファイル・ベース・リポジトリーを構成から削除します。
統合リポジトリーを使用した後、ユーザー・レジストリーを管理する必要があるかもしれません。以下の任意のオプション・タスクを実行して、スタンドアロン LDAP ユーザー・レジストリーを微調整できます。
表 24. 統合リポジトリーを管理するオプション・タスク
タスク 説明
統合 LDAP ユーザー・レジストリーを更新する このオプションを選択すると、バインド ID およびパスワードなどの特定のパラメーターを更新して、LDAP ユーザー・レジストリー関連の問題を修正します。
統合データベース・ユーザー・レジストリーを更新する このオプションを選択すると、データ・ソース名、データベース URL、およびデータベース・タイプなどの特定のパラメーターを更新して、データベース・ユーザー・レジストリー関連の問題を修正します。
新規レルムを作成する このオプションを選択すると、レルムを作成します。レルムとは、WebSphere Portal Express 内で一貫性のあるグループを形成する、1 つ以上のユーザー・レジストリーから抽出したユーザーのグループです。 レルムにより、さまざまな構成オプションでの、柔軟なユーザー管理を行うことができます。 レルムは、仮想ポータルにマップして、定義済みユーザーがその仮想ポータルにログインできるようにする必要があります。統合リポジトリーでは、複数のレルムを作成できます。
プロパティー拡張データベース (以前は索引データベースと呼ばれました) このオプションを選択すると、追加属性を LDAP ユーザー・レジストリーではなく、VMM プロパティー拡張内に保管します。 Common Mail ポートレットや IBM Lotus Web Content Management などのアプリケーションは、プロパティー拡張データベースを使用して追加属性を保管します。 プロパティー拡張データベースを使用可能にした後、属性を追加してユーザーのビジネス要件に合わせることができます。
エンティティー・タイプを作成する LDAP ユーザー・レジストリー内ではなく WebSphere Portal Express 内に存在するエンティティー・タイプを使用する場合は、このオプションを選択します。 このオプションは、ユーザー・レジストリー内でエンティティー・タイプを作成し、WebSphere Portal Express とユーザー・レジストリー間でエンティティー・タイプをマップする相対識別名 (RDN) を追加します。
既存のエンティティー・タイプを更新する このオプションを選択すると、既存の単一エンティティー・タイプのデフォルトの親を更新します。 例えば、あるリポジトリーを削除したものの、エンティティー・タイプがその削除されたリポジトリーを指している場合、情報を更新して新規リポジトリーを指すようにする必要があります。

Virtual Member Manager の統合

IBM WebSphere Application Server には、 IBM WebSphere Portal Express がユーザーおよびグループの情報にアクセスするために使用する Virtual Member Manager (VMM) が組み込まれています。 VMM は、WebSphere Portal Express と任意のリポジトリー (統合リポジトリー、スタンドアロン・リポジトリー、または独自のカスタム・ユーザー・レジストリーなど) との間の通信を使用可能にするインターフェースです。

Virtual Member Manager (VMM) は、WebSphere Application Server インフラストラクチャー内の抽象コンポーネントです。 下図に示すように、WebSphere Portal Express は、ポータル・ユーザー管理アーキテクチャー (PUMA) システム・プログラミング・インターフェース (SPI) を使用して、ユーザー・オブジェクトで属性を検索および設定します。PUMA は、これらの要求を VMM に渡します。次に VMM は、VMM をリポジトリーに接続する、対応するレジストリー・アダプターに要求を渡します。

WebSphere Portal と Virtual Member Manager との相互作用の図。この図について詳しくは、このトピックのテキストを参照してください。

前述の図には以下のコンポーネントが組み込まれています。
統合リポジトリー

複数のリポジトリーをサポートする、すぐに使用可能な UserRegistry インターフェースの実装。 統合リポジトリーと通信する場合、WebSphere Application ServerWebSphere Portal Express の両方がすべての操作を VMM にディスパッチします。

スタンドアロン LDAP

単一の LDAP ディレクトリーをリポジトリーにする、すぐに使用可能な UserRegistry インターフェースの実装。 WebSphere Application Server は、スタンドアロン LDAP と直接通信します。 WebSphere Portal Express は、VMM を介してスタンドアロン LDAP と通信します。

VMM SPI

VMM は、リポジトリーとの通信を使用可能にするサービス・プロバイダー・インターフェース (SPI) wim.Repository を提供します。 WebSphere Application Server は、この SPI を使用して統合リポジトリーに接続します。 WebSphere Portal Express は、この SPI を使用して、統合またはスタンドアロンなど、すべてのリポジトリーに接続します。

ユーザー・レジストリー・アダプター

VMM が特定のリポジトリー (LDAP ディレクトリー、データベース、ファイル、または他のリポジトリーなど) に接続することを可能にする VMM SPI の実装。 レジストリー・アダプターは、WebSphere Portal Express および任意のリポジトリーの間の通信を使用可能にします。

重要: カスタム・ユーザー・リポジトリーまたは WebSphere Portal Express がすぐにサポートできないリポジトリーの使用を予定している場合、ユーザー・レジストリー・アダプターを作成する必要があります。 ユーザー・レジストリー・アダプターを作成するには、wim.Repository インターフェースを実装します。 詳細および手順については、WebSphere Application Server インフォメーション・センター内の以下のトピックを参照してください。
  • Repository SPI (仮想メンバー・マネージャー・アダプター用のシステム・プログラミング・インターフェース)
  • フェデレーテッド・リポジトリーのサンプル・カスタム・アダプターの例

レルムのサポート

レルムとは、リポジトリー・ツリーの 1 つ以上のブランチから取得したユーザーまたはグループの集合です。 それらのブランチは、例えば LDAP ユーザー・レジストリーのような単一リポジトリーの一部であっても、複数のユーザー・レジストリーの組み合わせであってもかまいません。 レルムのユーザー集団が仮想ポータルにログインできるようにするには、その仮想ポータルにレルムをマップします。この機能により、WebSphere Portal Express 内で、制限されたユーザー集団のみがアクセスできる領域を定義できます。

例えば、アジア、ヨーロッパ、米国、およびカナダに従業員を持つ国際的な企業の場合、これらの従業員のサブセットにのみ適用されるアプリケーションや情報が存在することがあります。 従業員のあるサブセットを作成して、このレルム用のアプリケーションまたは情報が含まれた仮想ポータルを作成することができます。 あるレルムのユーザーが別のレルムにアクセスすることは、そのレルムのメンバーでない限りできません。 例えば、wpsadmin ユーザーが 仮想ポータルにログインすることは、wpsadmin ユーザーが対応するレルムのメンバーでない限りできません。

さまざまなユーザー・レジストリーからのユーザーを結合するレルムを作成できます。例えば、レルムは 3 つの LDAP ユーザー・レジストリーと 1 つのデータベース・ユーザー・レジストリー (LDAP1、LDAP2、LDAP3、および DB1) にわたって作成できます。
要確認: 複数のユーザー・レジストリーを結合する前に、レジストリーで以下の制限事項を確認し、問題があれば訂正してください。
  • レルムにおける識別名は、すべてのレジストリーで固有でなければなりません。例えば、uid=wpsadmin,o=yourco が LDAP1 内に存在する場合は、このユーザーが LDAP2、LDAP3、または DB1 内に存在することはできません。
  • レルムにおける短縮名 (例えば wpsadmin) は、すべてのレジストリーで固有でなければなりません。
  • レルム内で使用されるすべてのレジストリーの基本識別名は重複してはなりません。例えば、LDAP1 が c=us,o=yourco の場合、LDAP2 を o=yourco にしてはなりません。
  • レルム内で使用されるどのレジストリーでも、基本エントリーを空白にしてはなりません。
  • IBM Lotus Domino が複数のレジストリー構成内のユーザー・レジストリーの 1 つになり、別のユーザー・レジストリーとレルムを共有する場合には、グループが必ず、デフォルトのフラット・ネーミング構造ではなく階層フォーマットで Domino Directory に保管されるようにしてください。 例えば、フラット・ネーミング規則は cn=groupName ですが、 階層フォーマットは cn=groupName,o=root です。
  • このユーザーは、プロパティー拡張構成内ではなく、特定のユーザー・レジストリー内に存在している必要があります。 存在していない場合、このユーザーは、レルムのメンバーになることができません。

プロパティー拡張

以前に索引データベースとして知られていたプロパティー拡張により、バックエンド・ユーザー・レジストリーに影響を与えないで、追加のユーザー属性をデータベース・ストアに保管できます。LDAP が読み取り専用であるが、ユーザーが時間帯などの追加属性を指定できるという要件がある場合には、プロパティー拡張を使用できます。 この追加属性はデータベース・ストアに保管できます。 また、リポジトリー・スキーマを変更できない場合には、アプリケーションの追加属性を追加することもできます。 プロパティー拡張は、統合リポジトリー、スタンドアロン LDAP ユーザー・レジストリー、またはカスタム・ユーザー・レジストリーで使用できます。

IBM Lotus Web Content Management は、以下の機能についての追加情報を格納しています。
  • Web コンテンツ・ユーザー・プロファイル
  • カテゴリー選択ツリー
この情報をメイン・リポジトリーに格納できない場合 (例えば、メイン・リポジトリーが読み取り専用の場合) は、プロパティー拡張構成が必要です。

WebSphere Portal Express 高可用性

IBM WebSphere Portal Express は、単一サーバー構成での使用でライセンス交付を受けているため、フェイルオーバーの目的でアイドル・スタンバイを実装する場合を除き、複製構成またはクラスター構成のいずれでも使用できません。

アイドル・スタンバイ構成のサーバーは、管理上の必要性およびフェイルオーバーの状態の支援に限定して使用される場合は、アイドルであるとみなされます。 WebSphere Portal Express は、アイドルのスタンバイ・サーバーにインストールされますが、ユーザー・トランザクションへのサービス提供またはワークロードの要求に対しては運用されません。

アイドル・スタンバイの実装には、1 次サーバーのライセンスに加えて、個別の WebSphere Portal Express Idle Standby の部品番号の購入が必要です。 これは、1 次サーバーがユーザー・ライセンス・オプション、またはプロセッサー値単位ライセンス・オプションで現在ライセンス交付を受けているかどうかには関係ありません。

アイドル・スタンバイのライセンス・オプションを取得すると、WebSphere Portal Express をアイドル・スタンバイ構成で使用できるようになります。 フェイルオーバーを実現するには、1 次ノードおよび 2 次ノードを実装します。 1 次ノードは、すべての時間でアクティブになるように構成可能であり、2 次ノードは 1 次ノードに障害が発生した場合にのみアクティブになるように構成します。
要確認: デプロイメント・マネージャーおよびクラスター内の各 WebSphere Portal Express ノードについて、各システム・クロック設定の差が互いに 5 分以内に収まっていることを確認してください。そうでない場合は、addNode コマンドは失敗します。

WebSphere Portal Express wiki にあるデプロイメントのシナリオ、『アイドル・スタンバイを使用した高可用性の WebSphere Portal Express のデプロイメント (Deploying WebSphere Portal Express for high availability using idle standby)』では、アイドル・スタンバイ構成のセットアップに関する情報が提供されています。

インストール方法およびソース

複数のインストール方法 (サイレント、グラフィカル・ユーザー・インターフェース、およびコンソール)、およびソース (CD または CD イメージ) があります。

インストール方法

ご使用の環境に該当するインストール方法を選択してください。 グラフィカル・インターフェース・プログラム、コンソール・モード、または応答ファイル (サイレント・インストールの場合) のいずれかを使用できます。

グラフィカル・ユーザー・インターフェース
グラフィカル・ユーザー・インターフェース・プログラムでは、ホスト名やノードなどの必須の情報が収集された後、インストールが実行されます。オペレーティング・システムによっては、グラフィカル・ユーザー・インターフェースをサポートしないものがあります。
コンソール・モード
コンソール・モードは、グラフィカル・ユーザー・インターフェース・プログラムのテキストによる表示です。 選択肢に対応する数字を入力した後、Enter キーを押してインストールを進めます。
サイレント・インストール
サイレント・インストールでは、ユーザーとの対話なしでインストール・オプションを提供するための応答ファイルが使用されます。 このオプションは、IBM WebSphere Portal Express を複数のマシンに対して同様の設定でインストールまたはアンインストールする場合に使用します。 インストールを構成するには、インストール・タスクを実行する前に応答ファイル内のオプションを変更します。
インストールに関する注意: インストール前に、以下の情報をお読みください。
  • すべてのインストール方法に対して以下を適用してください。
    • インストールまたはアンインストールを開始する前に、マシン上で稼働しているスクリーン・セーバー・ソフトウェアを 使用不可またはオフにしてください。このソフトウェアは、マシンのネットワークへの接続能力に影響し、インストール・プログラムの動作を妨害することがあります。
    • インストール前にインストール・プログラムで、オペレーティング・システムとその前提条件、 使用できるディスク空き容量、および必須ソフトウェア前提条件が検証されます。
    • 異なる複数のディレクトリーにインストールするのであっても、サーバーの 2 つのインスタンスを同時にインストールすることはできません。 次のサーバーをインストールする前に、それぞれのサーバーのインストールを完了しなければなりません。
    • インストール・ディレクトリーには、ファイルが含まれていないディレクトリーを指定してください。
    • インストール・ディレクトリーには、以下の文字が含まれていないディレクトリーを指定してください。
      • ~
      • !
      • @
      • #
      • $
      • %
      • ^
      • &
      • *
      • (
      • )
      • _
      • +
      • {
      • }
      • |
      • <
      • >
      • ?
      • `
      • =
      • [
      • ]
      • ;
      • '
      • ,
      • .
      • "
  • グラフィカル・ユーザー・インターフェースとコンソール・モードの両方の方法に対して 以下を適用してください。
    ホスト名が間違って表示されている場合 (例えば serve1.server1.rtp.raleigh.ibm.com など)、 正しい情報に訂正する必要があります (例えば、serve1.server1.rtp.raleigh.ibm.comserver1.rtp.raleigh.ibm.com に変更するなど)。
    注: この動作が見られるのは、Microsoft Exchange サーバーのインスタンスが既にインストールされている Windows サーバーで、インストールが実行されるときのみです。
  • グラフィカル・ユーザー・インターフェースの使用時にのみ以下を適用してください。
    • ダイアログが表示され、テキストの入力が必要な場合は、入力フィールド間を移動するのに、 ポインティング・デバイスを使用するか、または TAB キーを押す必要があります。

インストール・ソースの場所

IBM WebSphere Portal Express のインストールの前に、ご使用の環境に最適なインストール・ソースの場所と方法を選択します。例えば、DVD-ROM またはファイル・システムからインストールすることができ、グラフィカル・インターフェース・プログラムを使用したインストールや、サイレント・インストールを実行することもできます。

注: ディスク・イメージがサポートしている同じプラットフォーム上で、そのイメージをダウンロードし、抽出し、インストールする必要があります。例えば、Linux プラットフォームにインストールする準備をしている場合には、Linux システム上で Linux イメージをダウンロードし、抽出し、インストールする必要があります。
インストール・ソースの選択時には、インストール時間が異なる可能性があるため、ローカルの環境を考慮に入れる必要があります。以下のソースの場所のいずれかを選択します。
DVD からインストールする
このオプションには以下の利点があり、インストールを限られた回数で実行する場合に最適です。
  • インストール前に前提条件ステップは必要ない。
  • ファイル・サーバーが使用できない、もしくは使用できるが DVD よりも遅い場合、インストール・パスを提供する。
Linux での注: セキュリティー上の理由で、Red Hat Enterprise Linux バージョン 5 などの一部の Linux バージョンでは、 自動マウントの DVD からはプログラムを実行できません。 ユーザーのシステムがこれに該当する場合、DVD からはインストーラーを実行できません。 この問題を修正するには、/etc/fstab ファイルの最後に /dev/hdc /media/ auto pamconsole,fscontext=system_u:object_r:removable_t,exec,noauto,managed 0 0 行を追加して、システムのファイル・システム・テーブルを更新します。
DVD のコンテンツをローカル・マシンにコピーする
このオプションはネットワークあるいは DVD-ROM の速度に依存せず、同じ製品を同じマシンに繰り返しインストールする場合に最適です。
DVD のコンテンツをローカル・マシンにコピーするには、次のステップを実行します。
  1. その製品用のディレクトリーを作成する。例えば version_number
  2. DVD を独自のディレクトリーにコピーする。例えば /wpversion_number/OS_code-Setup
オペレーティング・システムのコードは、以下のとおりです。
  • IBM i = I
  • Intel Linux (32 ビット) = IL
  • Windows (32 ビット) = W
注: (Linux のみ) コンテンツのコピー後に、インストールを実行するユーザーに読み取り権限と実行権限を設定してください。
DVD のコンテンツをファイル・サーバーにコピーする
ネットワーク・ドライブからのインストールは、DVD-ROM ドライブからのインストールよりも速い場合がある。
DVD のコンテンツをファイル・サーバーにコピーするには、次のステップを実行します。
注: この 方式を使用して WebSphere Portal ExpressWindows クライアントにインストールする際には、ファイル・サーバーをドライブ名にマウントしなければなりません。UNC リソース (//servername/mountpoint) にはドライブ名が割り当てられていないので、このリソースからはインストールできません。 インストールの間にセキュリティー関係のプロンプトが出されるのを抑制するため、Windows の信頼できるサイトのリストにネットワーク・ファイル・サーバーを追加することが必要になることもあります。
  1. その製品用のディレクトリーを作成する。例えば version_number
  2. DVD を独自のディレクトリーにコピーする。例えば /wpversion_number/OS_code-Setup
オペレーティング・システムのコードは、以下のとおりです。
  • IBM i = I
  • Intel Linux (32 ビット) = IL
  • Windows (32 ビット) = W
注: (Linux のみ) コンテンツのコピー後に、インストールを実行するユーザーに読み取り権限と実行権限を設定してください。

拡張インストール・パラメーター

インストール・コマンドに以下のパラメーターを追加して、ビジネス要件に合うようインストールをカスタマイズできます。

「ポート構成」パネルの表示

-W adminPortBlock.active=false -W portalPortBlock.active=false
GUI またはコンソール・モード・インストール・コマンドに以下のパラメーターを追加して、GUI またはコンソール・モード・インストール・プログラムで「ポート構成」パネルを表示する。

WebSphere Application Server ポート範囲の指定

-W adminPortBlockInput.startingPortToScan=port number -W adminPortBlockInput.endingPortToScan=port number -W adminPortBlockInput.portBlockSize=block size
このパラメーターをサイレント・インストール・コマンドに追加して、スキャンする WebSphere Application Server ポートの範囲、およびポート・ブロック・サイズを指定する。
注: デフォルトでは、インストール・プログラムは、WebSphere Application Server について、アクティブ・ポートのスキャンを 10000 から開始して 65000 で終了します。
注: WebSphere Application Server のポート・ブロック・サイズを 25 個より少なくすることはできません。

IBM WebSphere Portal Express ポート範囲の指定

-W portalPortBlockInput.startingPortToScan=port number -W portalPortBlockInput.endingPortToScan=port number -W portalPortBlockInput.portBlockSize=block size
このパラメーターをサイレント・インストール・コマンドに追加して、スキャンする IBM WebSphere Portal Express ポートの範囲、およびポート・ブロック・サイズを指定する。
注: デフォルトでは、インストール・プログラムは、WebSphere Portal Express について、アクティブ・ポートのスキャンを 10000 から開始して 65000 で終了します。
注: WebSphere Portal Express のポート・ブロック・サイズを 25 個より少なくすることはできません。

特定の PortalServer と AppServer のインストール場所の指定

-W was.location="/proj/WebSphere/portal/AppServer" -W portal.location="/proj/WebSphere/portal/PortalServer" -W setNewWasInstallLocationValue.active="false"
これらのパラメーターをインストール・コマンドに追加して、PortalServer と AppServer のインストール・ディレクトリーをカスタマイズする。

ポート・ファイルの変更

-W adminPortBlockInput.portsFilePath=full path to ports file
このパラメーターをインストール・コマンドまたは応答ファイルに追加して、ポート・ファイル WASDefaultPortsFile.props を変更する。このファイルは、セットアップ・ディスクにあり、 WebSphere Application Server ポート範囲を持ちます。
注: WebSphere Application Server の有効なポート範囲は、1 から 65535 です。
-W portalPortBlockInput.portsFilePath=full path to ports file
このパラメーターをインストール・コマンドまたは応答ファイルに追加してポート・ファイル WPDefaultPortsFile.props を変更する。このファイルは、セットアップ・ディスクにあり、WebSphere Portal Express ポート範囲を持ちます。
注: WebSphere Portal Express の有効なポート範囲は、1 から 65535 です。

プロファイルをデフォルト・プロファイルとして設定

-W detectProfileAction.isDefault="True"
共存インストールをインストールする場合は、インストール・コマンドにこのパラメーターを追加して、プロファイルをデフォルト・プロファイルとして設定する。
-W detectProfileAction.isDefault="False"
共存インストールをインストールする場合は、インストール・コマンドにこのパラメーターを追加して、プロファイルを非デフォルト・プロファイルとして設定する。
-W detectProfileAction.isDefault="True" -W detectProfileAction.profileName="your_profile_name" -W detectProfileAction.profilePath="C:¥full¥path¥your_profile_name"
共存インストールをインストールする場合は、インストール・コマンドに次の 3 つのパラメーターを追加して、デフォルトのプロファイル名とプロファイル・パスを変更する。

cellName の設定

-W setCellName.active=false -W defaults.cellName=cellName
デフォルトで、インストールは CellNameNodeName に設定する。 このパラメーターを使用して、デフォルトを、ユーザーのビジネス要件に適合するものに変更します。

IBM i ポート構成およびプロファイル名

-W setWASHome.startingPort=20000
i の場合: このパラメーターを追加して、ポート構成を指定する。
-W setWASHome.wasProfile=my_profile
i の場合: このパラメーターを追加して、デフォルトを使用する代わりにプロファイル名を設定する。

IBM i でのインストール

IBM WebSphere Portal Express は、機能の検査とテストができる PoC (概念検証) から使い勝手がよく拡張が容易な実稼働環境まで、柔軟なデプロイメント・オプションを提供します。

このタスクについて

重要: WebSphere Portal Express のインストール後に、マッシュアップ統合の使用を計画している場合は、「マッシュアップ統合」 > 「ポータルおよびマッシュアップの構成」 > 「ポータルでのマッシュアップ統合の使用可能化」のトピックにリストされている deploy-portal-mashup-ui タスクを実行する必要があります。
オプションのリストから必要なセットアップのタイプを選択します。 シナリオに従い WebSphere Portal Express をインストールして構成します。

IBM i でのスタンドアロン・サーバーのセットアップ

単一のサーバー環境をテストし終えて、実稼働環境を作成する準備ができた後で、スタンドアロン実稼働環境をセットアップします。リモート・データベースとさまざまなセキュリティー・オプションをサポートするように、この環境を変更できます。

このタスクについて

以下の図は、このシナリオの指示に従った結果のスタンドアロン・サーバー構成を説明しています。
リモート・データベース、LDAP サーバー、および HTTP サーバーのあるスタンドアロン構成の図
ベスト・プラクティス パフォーマンスを改善するために、インストールの完了後に、ポータル環境でサーバーを調整することを忘れないでください。 「IBM WebSphere Portal Express and IBM Lotus Web Content Management Performance Tuning Guide」の「Base Portal Tuning」のシナリオには、IBM WebSphere Application ServerWebSphere Portal Express サービス、データベース、ディレクトリー・サーバーなどのチューニングに関する情報が記載されています。

IBM i スタンドアロン: System IBM i の準備

IBM WebSphere Portal Express 用のオペレーティング・システムのセットアップに関する情報を示します。 他のコンポーネントを使用する場合は、追加のステップが必要になる場合があります。 詳しくは、インストールする特定のコンポーネントの製品資料を参照してください。

このタスクについて

WebSphere Portal Express のインストールは、Windows ワークステーションを使用してローカルまたはリモートで行うことができます。

リモートにインストールするには、以下の情報が必要です。
  • Microsoft® Windows® のサポートされているバージョン
  • マシンの CD-ROM ドライブ
  • WebSphere Portal Express をインストールする IBM i システムへの TCP/IP 接続
  • IBM i サーバーが制限なしの状態になっていること
  • IBM i システムの有効なユーザー ID とパスワード
  • WebSphere Portal Express のインストールと構成を行うためのユーザー・タイプ (ユーザー・クラス) *SECOFR (QSECOFR 以外) のユーザー・プロファイル
ローカルにインストールするには、以下の情報が必要です。
  • IBM i の CD-ROM ドライブ
  • IBM i サーバーが制限なしの状態になっていること
  • IBM i の有効なユーザー ID とパスワード
  • WebSphere Portal Express のインストールと構成を行うためのユーザー・タイプ (ユーザー・クラス) *SECOFR (QSECOFR 以外) のユーザー・プロファイル

IBM i スタンドアロン: WebSphere Portal のインストール

IBM WebSphere Portal Express は、情報を保管するための統合データベースを完備した、単一のコンポーネントとしてインストールされます。したがって、WebSphere Portal Express を素早く稼働状態にし、PoC (概念検証) フェーズに入り、すぐに作成と処理を開始することができます。また、ご使用の環境を拡張して、アイドル・スタンバイ、管理が容易で分散処理の負荷が軽いリモート・データベース、および LDAP ベースの認証を組み込むこともできます。

始める前に
使用しているオペレーティング・システムに関する WebSphere Portal Express の詳細なシステム要件を検討し、WebSphere Portal Express をインストールする前に、すべてのハードウェアおよびソフトウェアが最小の製品レベルを満たしていることを確認してください。 インストール方法およびソースを検討します。
このタスクについて
WebSphere Portal Express をインストールするには、以下のステップを実行します。
手順
  1. コマンド行で ping yourserver.yourcompany.com と入力し、完全修飾ホスト名が適切に構成されていることを確認してください。
  2. コマンド行で ping localhost と入力し、ネットワークが適切に構成されていることを確認してください。
  3. WebSphere Portal Express をインストールするサーバーに、固定 IP アドレスをセットアップしてください。
  4. WebSphere Portal Express のインストールに使用するインストール方法に基づいて、以下のいずれかのインストール・コマンドを選択します。詳しくは、『インストール方法』を参照してください。
    拡張インストール・パラメーター: インストールをカスタマイズするには、インストール・コマンドにさまざまなパラメーターを追加できます。例えば、ポート情報を指定できます。詳しくは、この文書の最後にある関連参照の『拡張インストール・パラメーター』を参照してください。
    制約事項: インストール・パスの定義時にサポートされる文字は、ASCII 文字 [A から Z および a から z]、数値 [0 から 9]、スラッシュ [オペレーティング・システムに応じて / または ¥]、およびダッシュ [-] のみです。
    表 25. インストール・タスク・オプション
    インストール・タイプ タスク
    グラフィカル・ユーザー・インターフェース install400.bat (PortalExpress サブディレクトリーにあります)
    オプション属性: WebSphere Application Server のプロファイルと構成は J9 32 ビット JVM を使用して実行されます。 これを使用すると、より高速のインストールが可能になりますが、ランタイム・パフォーマンスは低下します。 パフォーマンスを向上させるには、インストール・コマンドに -W enableClassicJVM.active=false 属性を追加し、Classic 64 ビット JVM を使用してインストールしてください。
    コンソール・モード (リモート) install400.bat -console
    コンソール・モード (ローカル) install.sh
    オプション属性: WebSphere Application Server のプロファイルと構成は J9 32 ビット JVM を使用して実行されます。 これを使用すると、より高速のインストールが可能になりますが、ランタイム・パフォーマンスは低下します。 パフォーマンスを向上させるには、インストール・コマンドに -W enableClassicJVM.active=false 属性を追加し、Classic 64 ビット JVM を使用してインストールしてください。
    サイレント・インストール (リモート) install400.bat -options "path_to_file¥response_filename" (PortalExpress サブディレクトリーにあります) (ここで、path_to_file は応答ファイルへの絶対パス、response_filename はファイルの名前です)。 サンプルのインストール応答ファイル (installresponse.txt) と サンプルのアンインストール応答ファイル (uninstallresponse.txt) は、 セットアップ CD のルート・ディレクトリーにあります。
    重要: 応答ファイルのパスにスペースが含まれないようにしてください。 また、そのファイル名の中にスペースを含めないようにしてください。
    サイレント・インストール (ローカル) install.sh -options "path_to_file/response_filename" (PortalExpress サブディレクトリーにあります) (ここで、path_to_file は応答ファイルへの絶対パス、response_filename はファイルの名前です)。 サンプルのインストール応答ファイル (installresponse.txt) と サンプルのアンインストール応答ファイル (uninstallresponse.txt) は、 セットアップ CD のルート・ディレクトリーにあります。
    重要: 応答ファイルのパスにスペースが含まれないようにしてください。 また、そのファイル名の中にスペースを含めないようにしてください。
  5. インストールが成功したことを確認する。 http://yourserver:yourport/wps/portal フォーマットを使用して WebSphere Portal Express にアクセスする。 wp_profile_root/ConfigEngine ディレクトリーから以下のいずれかのタスクを実行して、server1_PortMatrix.txt ファイルと WebSphere_Portal_PortMatrix.txt ファイルを生成します。
    注: ポート・ファイルは wp_profile_root/ConfigEngine/log/ ディレクトリーにあり、このファイルには、インストールの対象となる WebSphere Application Server (server1) と WebSphere Portal Express (WebSphere_Portal) のポートがリストされています。
    • ConfigEngine.sh list-server-ports -DWasPassword=password
    • ConfigEngine.sh list-server-ports-by-name -DServerName=server1 -DWasPassword=password
    • ConfigEngine.sh list-server-ports-by-name -DServerName=WebSphere_Portal -DWasPassword=password
  6. 以下のステップを実行して、データベースに JMS リソースを作成する。
    1. wp_profile_root¥ConfigEngine ディレクトリーから ConfigEngine.sh create-jcr-jms-resources-post-dbxfer -DWasPassword=password タスクを実行する。
    2. WebSphere_Portal サーバーを再起動する。
次のタスク
WebSphere Portal Expressi バージョン 6.1 システムにインストールした場合は、MF45016 フィックスをインストールします。このフィックスを入手するには、Fix Central を参照してください。
WebSphere Application Server の管理コンソールで、WP_CacheManagerService リソース環境プロバイダーの下の以下の 2 つのキャッシュ・プロパティーを設定します。詳しくは サービス構成プロパティーの設定を参照してください。
  • cacheglobal.softref=true
  • cacheglobal.lifetime=1200

WebSphere Application Server サーバーを開始する前に、ソフトウェア・ライセンス契約を構成して、ライセンス証書 (POE) または送り状から使用制限を設定する必要があります。詳しくは、ソフトウェア・ライセンス情報の構成を参照してください。

IBM i スタンドアロン: 評価ライセンスの変換

最初に評価ライセンスを使用して IBM WebSphere Portal Express をインストールした後に製品を購入した場合は、インストールした評価ライセンスを製品ライセンスに変換できます。 これは、評価ライセンスの期限切れの前後に関係なく、任意の時点に実行できます。

始める前に
評価ライセンスを確認します。
このタスクについて
評価ライセンスの変換では、プログラム・ファイルを再インストールする必要はありません。 ただし、ライセンス変換ユーティリティーにおいて、購入したプロダクション・ソフトウェアにアクセスできる必要があります。 物理メディア (クイック・スタート・サーバー・インストール CD) またはサーバーのハード・ディスクにダウンロードした新規のインストール・イメージのいずれも使用可能です。 評価ライセンスの変換に評価ソフトウェアを使用することはできません。
手順
評価ライセンスをプロダクション・ライセンスに変換するには、以下のようにしてセットアップ CD または構成タスクのいずれかを選択します。
表 26. 評価ライセンスをプロダクション・ライセンスに変換する方法
メソッド ステップ
セットアップ CD セットアップ CD を使用して評価ライセンスを変換するには、以下のステップを実行します。
  1. 購入した製品セットアップ CD から install.sh タスクを実行します。
  2. インストール・ディレクトリーについて尋ねるプロンプトが出されたら、評価バージョンのインストール・ディレクトリーを指します。

    インストール・プログラムは、評価バージョンを検出し、ライセンスを全製品ライセンスに変換するかどうか尋ねます。

  3. 「アップグレード」を選択して全ライセンス・ファイルの場所を入力します。このファイルは WebSphere Portal Express の CD またはダウンロードしたインストール・イメージ上の PortalExpress サブディレクトリー内にあり、例えば、QOPT がディスク・マウント・ポイントの場合は /QOPT/disk_volume_label/PortalExpress であり、インストール・イメージの場合は /wpdownload/PortalExpress などです。

    インストール時にライセンス・ファイルがアップグレードされます。他のファイルは変更されず、60 日の時間制限は除去されます。

構成タスク 構成タスクを使用して評価ライセンスを変換するには、以下のステップを実行します。
  1. wp_profile_root/bin ディレクトリーから stopServer WebSphere_Portal -username admin_userid -password admin_password タスクを実行します。
  2. ディレクトリー wp_profile_root/ConfigEngine でタスク ConfigEngine.sh install-license -Dlicense=media_filepath を実行します。 ここで、media_filepathWebSphere Portal Express の CD またはダウンロードしたインストール・イメージ上の PortalExpress サブディレクトリーの場所であり、例えば、QOPT がディスク・マウント・ポイントの場合は /QOPT/disk_volume_label/PortalExpress であり、インストール・イメージの場合は /wpdownload/PortalExpress などです。

    タスクが完了すると、製品が使用に対するライセンス交付を受けたことを確認するメッセージが表示されます。

  3. startServer WebSphere_Portalタスクを実行します。

IBM i スタンドアロン: DB2 for IBM i の準備

リモート IBM DB2 for i データベースをセットアップするには、リモート・サーバー上でユーザー ID およびデータベースを作成します。 ユーザー ID およびデータベースの作成に役立つタスクが提供されています。 そのタスクを使用する前に、プロパティー・ファイルを変更する必要があります。

IBM i スタンドアロン: DB2 for IBM i のプロパティーの変更

ここでは、データベースで使用する wkplc.properties、wkplc_dbdomain.properties、および wkplc_dbtype.properties ファイルの変更方法を説明します。これらのプロパティー・ファイルは、データベースの作成、ユーザーの作成、またはデータの転送タスクを実行する前に変更してください。

このタスクについて
プロパティー・ファイルに関する作業:
  • WebSphere Portal Express データベースを使用して、Personalization (Feedback)、LikeMinds などのアプリケーションの情報を格納できます。 データベースでそれらのアプリケーション情報を格納する準備として、release.DbName などのプロパティー値に同じような命名規則を使用してください。 いくつかの例を示します。
    • release.DbName=hostname/WP70REL
    • community.DbName=hostname/WP70COM
    • customization.DbName=hostname/WP70CUS
    • jcr.DbName=hostname/WP70JCR
    • feedback.DbName=hostname/WP70FBK
    • likeminds.DbName=hostname/WP70LKM
  • リモート・データベースを使用している場合は、 リモート・サーバーに対応した値を入力してください。
  • プロパティー・ファイル中のファイル・システム・パスでは、使用するオペレーティング・システムとは無関係に、円記号 (¥) ではなく、スラッシュ (/) を使用してください。
  • 以下に示すプロパティーの他に、追加のデータベース・プロパティーがある場合があります。 このタスク内のプロパティーのみ変更し、他のプロパティーはすべてスキップしてください。
  • 以下にイタリックで表示されている値は、特定の環境に対して変更が必要な場合があります。
  • パスワードに関する考慮事項: セキュリティー上の理由により、wkplc.propertieswkplc_dbdomain.propertieswkplc_dbtype.properties の各ファイルにパスワードを保管しないでください。構成タスクの実行前に各プロパティー・ファイルを編集して、そのタスクに必要なパスワードを挿入することをお勧めします。タスクの実行後に、各ファイルからパスワードをすべて削除する必要があります。
  • プロパティーごとのリストに記載されている推奨値は、ターゲット・データベースに対して WebSphere Portal Express を構成するために必要な固有の情報を表しています。
  • どのデータベース・ドメインを構成する必要があるかに応じて、dbdomain を以下の値に置き換えます。
    • release
    • customization
    • community
    • jcr
    • feedback
    • likeminds
  • release、customization、community、および JCR の各ドメインに対して、次のプロパティーの少なくとも 1 つが固有の値である必要があります。
    • dbdomain.DbName
    • dbdomain.DbUrl
    • dbdomain.DbSchema
    release、customization、community、および jcr の各ドメインにわたって、この 3 つのプロパティーすべてに同じ値を使用すると、データベース・オブジェクト名があいまいになるため、データベース転送タスクは失敗します。
  • DbUserDbUrl、 および DbPassword がドメイン間にわたって同じではない場合は、DataSourceName の値をその他のドメインの DataSourceName とは異なる値にする必要があります。 つまり、この値はデータベース・ドメインでは固有でなければなりません。
  • スキーマを作成する際は、 IBM i システムで以下のスキーマ命名規則を使用する必要があります。
    注: この製品のデフォルトのスキーマ名を使用できます。
    • 長さは 10 文字を超えてはならない
    • すべての英数字を使用可能 (「A」-「Z」および「1」-「0」)
    • 以下の文字は無効です。
      • スペース
      • ヌル値
      • アスタリスク (*)
      • 引用符 (")
      • コロン (:)
      • より大記号 (>)
      • より小記号 (<)
      • 垂直バー (|)
      • 正符号 (+)
      • セミコロン (;)
      • 単一引用符 (')
      • 疑問符 (?)
      注:
      • 有効なスキーマ名がわかっていることを確認し、ローカル・システムまたはリモート・システムに既に存在するスキーマ名は使用しないでください。 制限が適用されるため、有効なスキーマ名を定義するために、ターゲット・データベース管理システムの資料を参照してください。 WebSphere Portal Express 作成ウィザードは、スキーマ名を自動的に検査します。
      • データベースおよびスキーマの命名規則の詳細については、System i5 インフォメーション・センターで、DB2 Universal Database for System i5 のコンテンツを参照してください。
手順
  1. 次のファイルを見つけ、それぞれのバックアップ・コピーを作成してから、値の変更を行う。

    デフォルト値は、これらのファイル内にリストされています。特に注がない限り、すべての値のタイプは英数字のテキスト・ストリングです。 プロパティー・ファイルを変更する前に、参照用に以下の手順を印刷してください。 各プロパティーのインスタンスごとに、必ず適切な値を入力してください。 wkplc_dbdomain.properties では、ほとんどのプロパティーがドメインごとに繰り返されています。

  2. テキスト・エディターを使用してプロパティー・ファイルを開き、それぞれの環境に適した値を入力する。また、5250 セッションで OS/400 コマンド行に 以下を入力して、System i5 システムで 各プロパティー・ファイルをローカルに変更することもできます。
    注: このステップは、WebSphere Portal ExpressIBM i 上にインストールされていて、IBM DB2 for i に転送する場合にのみ適用されます。
    EDTF 'wp_profile_root/ConfigEngine/properties/property filename.properties'

    ここで、property filenamewkplc_dbdomainwkplc、または wkplc_dbtype のいずれかです。

    注: プロパティー・ファイルを編集するには、 IBM i サーバーにユーザー・プロファイルを持ち、少なくとも *USE 特殊権限を持っていなければなりません。
    ヒント: 『サポートされる別のデータベースにデータを転送するステップ』セクションでは、データを手動で転送する方法について説明しています。以下のステップを実行する代わりに、グラフィカル・ユーザー・インターフェースである構成ウィザードを使用して、 サポートされている別のデータベースへのデータ転送を行うこともできます。

    ローカルまたはリモートの IBM i サーバーにデータベース名およびスキーマを作成する前に、プロパティーを変更する必要があります。

  3. テキスト・エディターを使用してプロパティー・ファイル wkplc_dbdomain.properties を開き、ご使用の環境に対応するように値を変更します。
    1. dbdomain.DbType の場合は、db2_iseries と入力します。
    2. dbdomain.DbName の場合は、WebSphere Portal Express ドメイン・データベースの名前を入力します。
      注: この値は、dbdomain.DbUrl プロパティー内のデータベース・エレメントでもあります。
    3. dbdomain.DbSchema の場合は、データベース・ドメインのスキーマ名を入力します。
      注: ターゲット・データベース管理システムの文書を参照して、有効なスキーマ名を定義します。 いくつかのデータベース管理システムでは、知っておく必要のあるスキーマ名の制約があります。
    4. dbdomain.DataSourceName の場合は、WebSphere Portal Express がデータベースとの通信に使用するデータ・ソースの名前を入力します。 以下の予約語を使用しないでください。
      • releaseDS
      • communityDS
      • customizationDS
      • jcrDS
      • lmdbDS
      • feedback
    5. dbdomain.DbUrl の場合、JDBC を使用してWebSphere Portal Express データベースにアクセスするときに使用するデータベースの URL を入力します。この値は、データベースで指定された JDBC URL 構文規則に準拠する必要があります。 IBM i V7R1 より前のシステムで稼働しているデータベースには、接続プロパティー metadata source=1 を指定する必要があります。WebSphere Portal ExpressIBM i にインストール済みで、 データをリモートまたはローカルで IBM DB2 for i に転送する場合は、次の例を参照してください。dbdomain.DbUrl="jdbc:as400:daisy.mycorp.com/WPDBREL;metadata source=1" WebSphere Portal Express が Windows にインストール済みで、データをリモートで IBM DB2 for i に転送する場合は、次の例を参照してください。dbdomain.DbUrl="jdbc:as400:daisy.mycorp.com/WPDBREL;metadata source=1" WebSphere Portal Express が UNIX プラットフォームにインストール済みで、 データを IBM DB2 for i に転送する場合は、次の例を参照してください。dbdomain.DbUrl="jdbc:as400:daisy.mycorp.com/WPDBREL;metadata source=1;prompt=false"。X11 DISPLAY が設定済みで、アクティブになっている場合は、 ;prompt=false を URL に追加しないでください。
      注: この値のデータベース・エレメントは、DbName の値と一致する必要があります。
    6. dbdomain.DbUser には、データベース構成ユーザーの ユーザー ID を入力します。
    7. dbdomain.DbPassword には、 データベース構成ユーザーのパスワードを入力します。
    8. dbdomain.DbConfigRoleName には、 データベース構成ユーザーのグループの名前を入力します。データベースの権限は、 個人ではなく、このグループに付与されます。dbdomain.DbUser に指定されているユーザーを、 このグループに割り当てる必要があります。
    9. オプション: dbdomain.DbRuntimeUser の場合は、WebSphere Portal Express によってランタイムのデータベースへの接続に使用される、データベース・ユーザーのユーザー ID を入力します。この設定に値を指定しない場合は、 ランタイムでデータベースに接続するためにデータベース構成ユーザーが使用されます。
    10. dbdomain.DbRuntimeUser を指定している場合、dbdomain.DbRuntimePassword を、ランタイム・データベース・ユーザーのパスワードとなるように設定する必要があります。
    11. dbdomain.DbRuntimeRoleName には、 データベース・ランタイム・ユーザーの名前を入力します。データベースの権限は、 個人ではなく、このグループに付与されます。dbdomain.DbRuntimeUser に指定されているユーザーを、 このグループに割り当てる必要があります。
    12. オプション: dbdomain.DBA.DbUser には、 データベース作成時の特権アクセス操作のためのデータベース管理者ユーザー ID を 入力します。このパラメーターが不要の場合は、デフォルト値を受け入れるか、 空白のままにします。
    13. オプション: dbdomain.DBA.DbPassword には、 データベース作成時の特権アクセス操作のためのデータベース管理者パスワードを 入力します。このパラメーターが不要の場合は、デフォルト値を受け入れるか、 空白のままにします。
  4. ファイルを保管して閉じる。
  5. wkplc_dbtype.properties ファイルの以下のプロパティーを更新します。
    注: データベースを転送する前に、jt400.jar ファイルをダウンロードする 必要があります。jt400.jar ファイルのダウンロードについて詳しくは、wkplc_dbtype.properties を 参照してください。
    1. db2_iseries.DbDriver の場合は、JDBC ドライバー・クラスの名前を入力します。
    2. db2_iseries.DbLibrary の場合は、JDBC ドライバー・クラスを含む .zip、または .jar ファイルのディレクトリーと名前を入力します。
    3. db2_iseries.JdbcProviderName の場合は、WebSphere Portal Express がそのデータベースとの通信に使用する JDBC プロバイダーの名前を入力します。
    4. db2_iseries.DbDriverType の場合は、データベースのドライバー・タイプを表す数値を入力します。
  6. ファイルを保管して閉じる。
  7. wkplc.properties ファイルの WasPassword 値を 更新します。この値は、ご使用の環境で使用される WebSphere Application Server セキュリティー認証のパスワードです。
  8. ファイルを保管して閉じる。
  9. テキスト・エディターを使用して wkplc_sourceDb.properties ファイルを開き、 ご使用の環境に対応するようにすべてのドメインで source.domain.DbPassword パラメーターを 変更します。この値は構成ユーザーのパスワードです。
  10. ファイルを保管して閉じる。
IBM i スタンドアロン: DB2 for IBM i のユーザー・プロファイルの作成

ここでは、IBM DB2 for iWebSphere Portal Express と連動させるためのユーザー・プロファイルの設定について説明します。

始める前に
始める前に
  • データベース 所有者のユーザー・プロファイルは、インストールの 実行に使用されるアドミニストレーター・ユーザー・プロファイルとは異なるもの でなければなりません。 アドミニストレーター・ユーザー・プロファイルは必要なもの以外の権 限を持つことができ、通常は個人に属します。データベース・ユーザー・プロファイルは最低限の権限しか持たず、共用することができます。
  • 一定の期間パスワードを変更する必要のないデータベース・ユーザー・プロファイルを作成します。データベース・ユーザー・プロファイルに対するパスワードを変更した場合は、新しいパスワードを使用するように WebSphere Portal Express を再構成する必要があります。
  • 実際の実行時環境と同じ設定になっている環境でユーザーを作成してください。 例えば、トルコ語環境でユーザーを使用するつもりである場合、そのユーザーを英語環境で作成するのは避けてください。
このタスクについて
手順
ユーザー・プロファイルを作成するには、IBM DB2 for i の資料の手順に従います。
IBM i スタンドアロン: DB2 for IBM i でのデータベースの作成

リモート・データベースは、WebSphere Portal Express とは異なるシステム上にあります。 リモート・サーバーを使用する場合は、WebSphere Portal Express で必要なデータベースを手動で作成する必要があります。

始める前に
始める前に
  • 使用するユーザー ID とパスワードには、リモート System i5 マシンでデータベース・ライブラリーを作成するための権限がなければなりません。
  • *LOCAL/schema を使用するデータベースの各プロパティー・インスタンスを、 それぞれ HostName/schema に置き換えます。

    例えば、WebSphere Portal Express の release ドメインのデフォルトのデータベース名とデータベース・ライブラリー名は、release.DbName=wpsdb です。このデータベース・ライブラリーをリモート・データベースで作成したかった場合、デフォルトの値を release.DbName=hostname/wpsdb に変更してください。

このタスクについて
すべてのドメイン・データベース・ライブラリーを作成するには、以下の手順を実行します。
手順
  1. リモート・データベース・マシンで、5250 セッションを開始する。
  2. i コマンド WRKRDBDIRE を入力し、 リモート・ロケーション *LOCAL のリレーショナル・データベース・ディレクトリー項目を表示させ、 表示される値をメモに書き留める。
  3. 5250 セッションからサインオフする。
  4. WebSphere Portal Express がインストールされているローカル・マシンで、5250 セッションを開始する。
  5. i コマンド WRKRDBDIRE を使用して、ローカル・システム上にリモート・システム用のリレーショナル・データベース・ディレクトリー項目を作成する。
  6. 以下の値を持つ項目を追加する。
    リレーショナル・データベース
    リモートのリレーショナル・データベース。 前のステップでメモした値を使用。
    リレーショナル・データベース別名
    ホスト名。リモート・システムの TCP/IP 短縮ホスト名を使用。
    リモート・ロケーション
    ドメイン修飾ホスト名。 リモート・システムの TCP/IP 完全ホスト名を使用。
    タイプ
    IP
    ポート番号またはサービス名
    DRDA
    リモート認証方式
    • 優先される方式: ENCRYPTED
    • 簡易認証を許可: ALWLOWER
  7. ローカル・マシンから次のコマンドを実行して、リモート・データベース・マシンで必要な DB2 パッケージを作成する。 JAVA CLASS(com.ibm.db2.jdbc.app.DB2PackageCreator) PARM('rdb_alias' 'userid' 'password') PROP((jdbc.drivers 'com.ibm.as400.access.AS400JDBCDriver')) ここで、rdb_alias は、ステップ 2 で作成したリレーショナル・データベース項目の名前に一致し、userid は、リモート・マシンのデータベース・アドミニストレーターのユーザー ID を表し、password は、リモート・マシンのデータベース・アドミニストレーターのパスワードを表します。 出力は次のようになります。Java program completed
  8. F3 を押して、Java Shell Display を終了する。
  9. 5250 セッションからサインオフする。
  10. リモート・データベース・マシンで、5250 セッションを開始する。
  11. コマンド WRKOBJ OBJ(QGPL/QSQCL*) OBJTYPE(*SQLPKG) を実行して、必要な DB2 パッケージが作成されたことを確認する。 すると、次のように出力されます。
    Opt  Object      Type      Library     Attribute   Text                        
         QSQCLIPKGA  *SQLPKG   QGPL        PACKAGE                                 
         QSQCLIPKGC  *SQLPKG   QGPL        PACKAGE                                 
         QSQCLIPKGL  *SQLPKG   QGPL        PACKAGE                                 
         QSQCLIPKGN  *SQLPKG   QGPL        PACKAGE                                 
         QSQCLIPKGS  *SQLPKG   QGPL        PACKAGE
  12. WebSphere Portal Express がインストールされているローカル・マシンで、5250 セッションを開始する。
  13. コマンド行で、cd wp_profile_root/ConfigEngineと入力してディレクトリーを変更する。
  14. Enter を押す。
  15. コマンド行に以下のコマンドを入力する前に、構成プロパティー・ファイル内のプロパティー値を変更する。 ConfigEngine.sh create-database
  16. Enter を押す。
IBM i スタンドアロン: DB2 for IBM i を使用するためのポータルの構成

ここでは、セットアップ済みの IBM DB2 Universal Database for i データベースに、データを手動で転送するステップを示します。ここで説明する手動のデータベース転送手順の代わりに、構成ウィザードを使用してデータベース転送タスクを実行することもできます。ただし、構成ウィザードでは、すべての設定を指定することはできません。例えば、データ転送に使用するメソッドに関わらず、このトピックで説明するように、JMS リソースを作成するために構成タスクを実行する必要があります。

始める前に

始める前に
以下の前提条件に適合していることを確認します。

  • サポートされるデータベース・ソフトウェアがインストール済み。
  • データベースとユーザーがセットアップ済み。
このタスクについて
手順
  1. server1 および WebSphere_Portal サーバーの両方を停止する。
    • stopServer server1 -username admin_userid -password admin_password
    • stopServer WebSphere_Portal -username admin_userid -password admin_password
  2. ConfigEngine.sh validate-database -DWasPassword=password コマンドを使用して、構成プロパティーを検証する。
    ヒント: 検証するドメインを指定するには、上記の検証タスクに -DTransferDomainList パラメーターを追加します。例えば、-DTransferDomainList=jcr とします。 すべてのドメインを検証する場合、コマンド行でこのパラメーターを指定する必要はありません。
  3. 以下の手順でデータベースを転送する。
    1. 以下のコマンドを入力する。
      ConfigEngine.sh database-transfer -DWasPassword=password
      注:
      • 特定のデータベース・ドメインを転送対象に選択するには、コマンドで指定する -DTransferDomainList に、転送するドメインのみが含まれるように変更します。例えば、JCR ドメインのみを転送する場合は、コマンド ./ConfigEngine.sh database-transfer -DTransferDomainList=jcr -DWasPassword=password を入力します。
      • この注記は、IBM DB2 for i のデータベースを、IBM DB2 for i のある別のサーバーへ転送する場合にのみ適用されます。IBM DB2 for i 以外のデータベースから転送する場合は、この注記をスキップできます。*INTERACT プールに 1GB 以上のメモリーが 割り振られていない場合は、SBMJOB を使用して、*BASE プールで実行する バッチ・ジョブとして Qshell スクリプトを実行依頼します。例: SBMJOB CMD(STRQSH CMD(ConfigEngine.sh database-transfer -DWasPassword=password))
    2. このタスクを実行すると、タスクが正常に実行されたことが確認可能なメッセージが、以下のログ・ファイルに追加されます。wp_profile_root/ConfigEngine/log/ConfigTrace.log 構成が失敗した場合は、wkplc.propertieswkplc_dbdomain.propertieswkplc_dbtype.properties の各ファイルの値を確認してから、このステップを繰り返してください。
  4. ConfigEngine.sh create-jcr-jms-resources-post-dbxfer -DWasPassword=password コマンドを実行して、新規データベース内に JMS リソースを作成する。
    注: データ転送に使用した方法 (構成ウィザード、またはこのトピックのステップ) に関わらず、JMS リソースを作成するためにこのタスクを実行する必要があります。
  5. WebSphere Portal Express サーバーを開始する。 手順については、「サーバー、デプロイメント・マネージャー、およびノード・エージェントの始動と停止」を参照してください。
次のタスク
すべてのノード上の以下のファイルを、1 次ノードのファイルと比較します。wp_profile_root/PortalServer/jcr/lib/com/ibm/icm/icm.properties ファイルのすべてのインスタンスが同一であることを確認します。 ファイルが同一でない場合、database-transfer タスクを実行した 1 次ノードからそのノードに icm.properties をコピーします。
  1. 2 次ノードでポータル・サーバーを停止する。
  2. wp_profile_root/PortalServer/jcr/lib/com/ibm/icm/icm.properties を 1 次ノードからコピーし、2 次ノード上の icm.properties を置換する。
  3. 2 次ノードでポータル・サーバーを始動する。
IBM i スタンドアロン: DB2 for IBM i 構成の検証

ユーザーのデータベースと連動するように WebSphere Portal Express を構成した後に、データベース接続を検査して、接続が正しく動作することを確認する必要があります。

このタスクについて
接続は、ブラウザーまたはコマンド行から検査できます。

WebSphere Portal Express が稼働していることをブラウザーで検査するには、Web ブラウザーに http://hostname.yourco.com:port_number/wps/portal という URL を入力して、ポータルを開きます。ここで、hostname.yourco.com は、 WebSphere Portal Express が稼働しているマシンの完全修飾ホスト名であり、port_number は、IBM WebSphere Application Server によって作成されるトランスポート・ポートです。

以下のいずれかの条件が発生した場合、エラーの可能性があります。
  • ポータルにアクセスしようとすると、503 エラーを受け取る。
  • データベースで何らかのロケール問題が発生した後にログインすると 、???? などの無効文字が表示される。 これは、データベースの文字セットが UTF-8 対応でない場合に、発生することがあります。
  • 転送されたデータに問題があった場合、ログインできないことがある。 ユーザーが有効なユーザー ID およびパスワードを入力しても、WebSphere Portal Express により 無効であると示されます。

以下のステップを実行して、コマンド行から接続を検査します。

手順
  1. WebSphere Portal Express がインストールされているローカル・マシンでコマンド行を開く。
  2. WebSphere Application Server 上の WebSphere Portal Express の場合 (UserData パス) は、コマンド行で cd wp_profile_root/ConfigEngineと入力する。
  3. 以下のコマンドを入力する。

    ConfigEngine.sh validate-database-connection -DTransferDomainList=release,community,customization,jcr,feedback,likeminds -DWasPassword=password

次のタスク

セキュリティー上の理由により、wkplc_dbdomain.properties ファイルにパスワードを残さないでください。構成タスクを実行する前にファイルを編集して、そのタスクに必要なパスワードを挿入します。 タスクの実行後に、ファイルからすべてのパスワードを削除します。

あるいは、wkplc_dbdomain.properties ファイルを更新する代わりに、コマンド行にそのパスワードを指定することもできます。例: ConfigEngine.sh -DPortalAdminPwd=password -DWasPassword=password validate-database

WebSphere Portal Express のインストール時、構成後に wkplc_dbdomain.properties ファイル内のパスワードが自動的に除去されます。

IBM i スタンドアロン: リモート Web サーバーの準備

IBM WebSphere Application Server に付属する Web サーバー・プラグインをインストールして構成し、IBM WebSphere Portal Express と通信できるように Web サーバーをセットアップします。

このタスクについて
Web サーバーをインストールして構成するには、以下のステップを実行します。
手順
  1. Web サーバーをインストールして構成する (詳しくは、Web サーバーの資料を参照してください)。
  2. IBM Lotus Domino を使用している場合は、Web サーバーの NOTES.INI ファイルを編集する。HTTPEnableConnectorHeaders パラメーターを 1 に設定する。
  3. IBM HTTP Server または Apache Server を使用している場合は、Web サーバー上の httpd.conf ファイルを編集する。AllowEncodedSlashes ディレクティブを On に設定する。 このディレクティブは、グローバル・ディレクティブとして、ルート・レベルで追加する必要があります。
    表 27. HTTP Server および Apache Server の資料へのリンク
    HTTP Server のタイプ 資料リンク
    該当の HTTP Server の資料を参照してください。 IBM HTTP Server
    該当の Apache Server の資料を参照してください。 AllowEncodedSlashes ディレクティブ
  4. Web サーバーを停止する。
  5. WebSphere Application Server に用意されているプラグイン・インストール・ウィザードを使用して、Web サーバーが配置されているシステムに Web サーバー・プラグインをインストールして構成する。 情報については、Web サーバーのトポロジー・ダイアグラムおよびロードマップの選択を参照してください。
    WebDAV を使用する場合: Web サーバー・プラグインを正常にインストールした後に、plugin-cfg.xml ファイルを見つけて開き、AcceptAllContenttrue に設定してください。
    重要: Web サーバーの使用法に応じて、ServerIOTimeout 値を調整する必要が生じることがあります。この値は、アプリケーションからの応答をプラグインが待機する時間の長さを定義します。推奨されている最小値は 60 ですが、データベースからデータを取り出す場合はこの値を調整して大きくする必要が生じることがあります。この値を更新するには、plugin-cfg.xml ファイルを見つけて開き、ServerIOTimeout を業務上の必要に合う適切な値に設定してください。 追加情報については、Web サーバー・プラグインに関する共通の質問を参照してください。
  6. Sun Java System Web Server を使用している場合、一部のポートレットでは、正しく作動するために unix-uri-clean または nt-uri-clean ディレクティブを使用不可にする必要があります。 これらのディレクティブは、obj.conf ファイルを編集することにより、使用不可/使用可能にすることができます。 ご使用の環境に対する適切な設定を決定するには、Sun Java System Web Server 資料を参照してください。
  7. ポータル・マッシュアップなど一部の機能では、PUT メソッドと DELETE メソッドが使用可能になっていることが必要です。 ご使用の Web サーバーでこれらのメソッドが使用不可になっている場合は、以下のいずれかのオプションを実行してください。
    • HTTP トンネリングを使用可能にして、PUT 要求と DELETE 要求をシミュレートする。 これは、POST 要求が代わりに使用されることを意味します。 詳しくは、以下の『HTTP メソッドのトンネリングへの切り替え』のリンクを参照してください。
    • 使用する Web サーバーの手順に従って、PUT 要求と DELETE 要求を使用可能にする。
  8. Web サーバーを始動する。

IBM i スタンドアロン: ユーザー・レジストリーを使用するための WebSphere Portal の構成

無許可ユーザーからサーバーを保護するため、IBM WebSphere Portal Express でユーザー・レジストリー・セキュリティーを構成してください。 スタンドアロン LDAP ユーザー・レジストリーを構成することも、LDAP ユーザー・レジストリーまたはデータベース・ユーザー・レジストリー (あるいはその両方) を、デフォルトの統合リポジトリーに追加することもできます。ユーザー・レジストリーを構成した後に、仮想ポータルまたは索引データベース用のレルムを追加して、LDAP ユーザー・レジストリーに保管できない属性を保管することができます。

始める前に
セキュリティーを構成する前に、IBM WebSphere Application Server backupConfig タスクを使用して、IBM WebSphere Portal Express 構成のバックアップを作成して保管する必要があります。詳細については、backupConfig コマンドを参照してください。
このタスクについて
ユーザー・レジストリーを使用するように WebSphere Portal Express を構成するには、以下のタスクを実行します。
IBM i スタンドアロン: Tivoli Directory Server の準備

Tivoli Directory Server を LDAP ユーザー・レジストリーとして使用する予定の場合は、このサーバーをインストールし、IBM WebSphere Portal Express と通信できるようにセットアップする必要があります。

このタスクについて
Tivoli Directory Server の準備を行うには、以下のステップを実行します。
手順
  1. ディレクトリー・サービス構成ウィザードを使用して、LDAP ディレクトリー・サーバーの設定をカスタマイズします。 このウィザードを使用するには、特殊権限 *ALLOBJ および *IOSYSCFG が必要です。詳しくは、IBM System i and IBM i Information Center に移動し、適切なバージョンのインフォメーション・センターを選択して、「e-business および Web サービス」 > 「セキュリティーおよび IBM Tivoli Directory Server for i5/OS (LDAP)」 > 「IBM Tivoli Directory Server for i5/OS (LDAP)」を選択してください。
    注: Tivoli Directory Server の制限のために、ユーザーまたはグループは、トルコ語の大文字のドット付き I または小文字のドット付き i を DN に含めることはできません。含めると、そのユーザーまたはグループの検索を正しく実行することができなくなります。
  2. WebSphere Portal Express 管理ユーザーを作成するには、以下のステップを実行します。
    1. オプション: 新規ディレクトリー・サフィックスを作成するには、以下のステップを実行します。
      1. 詳しくは、IBM System i and IBM i Information Center に移動し、適切なバージョンのインフォメーション・センターを選択して、「ネットワーキング」 > 「TCP/IP アプリケーション、プロトコル、およびサービス」 > 「IBM Directory Server for iSeries (LDAP)」 > 「Directory Server の管理」 > 「一般管理タスク (General administration tasks)」 > 「Directory Server サフィックスの追加と除去 (Adding and Removing Directory Server suffixes)」を選択してください。
      2. LDAP サーバーをいったん停止してから再起動する。
    2. CD セットアップのルート・ディレクトリーにある適切な LDIF ファイルを、テキスト・エディターで開く。
      • PortalUsers.ldif ファイルを実施例として使用して、ご使用の LDAP サーバーに合わせて適宜変更してください。
      • DB2 Content Manager を構成した場合は、IBM DB2® Content Manager グループおよびユーザー ID については ContentUsers.ldif ファイルを使用します。
    3. すべての dc=yourco,dc=com を、ご使用のサフィックスで置き換える。
    4. 使用している LDAP サーバーに固有のプレフィックスとサフィックスをすべて置換する。
    5. wpsadmin および wpsbind 以外のユーザー名を指定することもできます。 セキュリティー上の理由で、これらの管理者アカウントには簡単に推測されないパスワードを指定してください。
    6. オプション: IBM Tivoli® Access Manager バージョン 5.1 を使用している場合は、objectclassesaccessGroup に設定します。 Tivoli Access Manager バージョン 6 を使用している場合は、objectclassesgroupOfNames に設定します。
    7. 変更内容を保管する。
    8. ご使用のディレクトリー・サーバーで規定されている手順に従って、LDIF ファイルをインポートする。
    9. LDAP サーバーをいったん停止してから再起動する。
IBM i スタンドアロン: ユーザー・レジストリー・モデルの選択

IBM WebSphere Portal Express を保護するために、スタンドアロンの LDAP ユーザー・レジストリーを使用するか、LDAP ユーザー・レジストリーまたはデータベース・ユーザー・レジストリー、あるいはその両方をデフォルトの統合リポジトリーに追加するかを選択します。

このタスクについて
以下のユーザー・レジストリー・モデルのいずれか 1 つを選択します。
IBM i スタンドアロン: スタンドアロン LDAP ユーザー・レジストリーの構成

IBM WebSphere Application ServerIBM WebSphere Portal Express、および LDAP サーバーとの間で交換されるデータのタイプに応じて、LDAP サーバーを SSL で構成するか、または IBM WebSphere Application Server および IBM WebSphere Portal Express に直接アクセスできるよう LDAP サーバーを構成できます。

このタスクについて
以下のいずれかのオプションを使用して、LDAP サーバーを構成します。
IBM i スタンドアロン: SSL を使用しないスタンドアロン LDAP ユーザー・レジストリーの構成

スタンドアロンの LDAP ユーザー・レジストリーを使用して、許可のためのすべてのユーザー・アカウント情報を保管するよう IBM WebSphere Portal Express を構成します。

始める前に
単一サーバー環境では、以下のステップを実行するために WebSphere_Portal サーバーと server1 サーバーを開始したり停止したりする必要はありません。 クラスター環境では、以下のタスクを開始する前に、システム上で WebSphere_Portal を含むすべてのアプリケーション・サーバーを停止してから、ノード・エージェントおよびデプロイメント・マネージャー・サーバーを開始する必要があります。

wp-modify-ldap-security タスクを再実行して LDAP リポジトリーを変更する必要がある場合か、そのタスクが失敗した場合は、タスクを再実行する前に、standalone.ldap.realm パラメーターを使用してレルムの新しい名前を選択する必要があるか、または wklpc.properties ファイル内で ignoreDuplicateIDs=true を設定できます。

このタスクについて
スタンドアロン LDAP ユーザー・レジストリーを構成するには、以下のステップを実行します。
注: このタスクの実行時には、wp_profile_root/ConfigEngine/config/helpers ディレクトリー内にある wp_security_xxx.properties ヘルパー・ファイルを使用して、正しいプロパティーが入力されていることを確認してください。以下の指示で、wkplc.properties ファイルがステップで参照されている場合は、wp_security_xxx.properties ヘルパー・ファイルを使用します。
手順
  1. テキスト・エディターを使用して、wp_profile_root/ConfigEngine/properties ディレクトリーにある wkplc.properties ファイルを開く。
  2. 必須: wkplc.properties ファイルの VMM スタンドアロン LDAP 構成見出しの下に、以下の必須パラメーターの値を入力します。
    注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
    • standalone.ldap.id
    • standalone.ldap.host
    • standalone.ldap.port
    • standalone.ldap.bindDN
    • standalone.ldap.bindPassword
    • standalone.ldap.ldapServerType
    • standalone.ldap.userIdMap
    • standalone.ldap.groupIdMap
    • standalone.ldap.groupMemberIdMap
    • standalone.ldap.userFilter
    • standalone.ldap.groupFilter
    • standalone.ldap.serverId
    • standalone.ldap.serverPassword
    • standalone.ldap.realm
    • standalone.ldap.primaryAdminId
    • standalone.ldap.primaryAdminPassword
    • standalone.ldap.primaryPortalAdminId
    • standalone.ldap.primaryPortalAdminPassword
    • standalone.ldap.primaryPortalAdminGroup
    • standalone.ldap.baseDN
  3. 必須: wkplc.properties ファイルの LDAP エンティティー・タイプ見出しの下に、以下の必須エンティティー・タイプ・パラメーターの値を入力します。
    注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
    • standalone.ldap.et.group.objectClasses
    • standalone.ldap.et.group.objectClassesForCreate
    • standalone.ldap.et.group.searchBases
    • standalone.ldap.et.personaccount.objectClasses
    • standalone.ldap.et.personaccount.objectClassesForCreate
    • standalone.ldap.et.personaccount.searchBases
  4. 必須: wkplc.properties ファイルのグループ・メンバー属性見出しの下に、以下の必須グループ・メンバー・パラメーターの値を入力します。
    注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
    • standalone.ldap.gm.groupMemberName
    • standalone.ldap.gm.objectClass
    • standalone.ldap.gm.scope
    • standalone.ldap.gm.dummyMember
  5. 必須: wkplc.properties ファイルのデフォルトの親と相対識別名 (RDN®) 属性見出しの下に、以下の必須 RDN パラメーターの値を入力します。
    注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
    • standalone.ldap.personAccountParent
    • standalone.ldap.groupParent
    • standalone.ldap.personAccountRdnProperties
    • standalone.ldap.groupRdnProperties
  6. 変更内容を wkplc.properties ファイルに保管します。
  7. ConfigEngine.sh validate-standalone-ldap -DWasPassword=password タスクを実行して、LDAP サーバーの設定を検証します。
    重要: デフォルトのファイル・リポジトリーを削除していない場合は、WasPassword は LDAP ユーザー・レジストリー内にある値ではなく、インストール時に入力された値になります。
    注: 検証タスクの間は、ここでトラスト・ストアに署名者を追加しますか?というプロンプトが表示される場合があります。y を押してから、Enter を押してください。
  8. wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-modify-ldap-security -DWasPassword=password タスクを実行して、スタンドアロンの LDAP ユーザー・レジストリーを設定します。
  9. 該当するサーバーを停止してから再始動し、変更を伝搬させます。 具体的な手順については、関連タスクの以下のリンクを参照してください。 『サーバー、デプロイメント・マネージャー、およびノード・エージェントの始動と停止
  10. wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-validate-standalone-ldap-attribute-config -DWasPassword=password タスクを実行して、定義済みのすべての属性が構成済みの LDAP ユーザー・レジストリーで使用可能であることを確認します。
    重要: LDAP ユーザー・レジストリーの構成が完了したら、属性の追加とマッピングを行って WebSphere Portal Express と LDAP サーバーとの間の適切な通信を保証する方法について『属性の構成の調整』を参照してください。
  11. 必須: メンバー・フィクサー・タスクを実行して、Web Content Management が使用するメンバー名を LDAP ディレクトリーの対応するメンバーによって更新します。このステップにより、contentAuthors グループのイントラネットおよびインターネットのサイト・テンプレート用 Web コンテンツ・ライブラリーへのアクセスが、LDAP ディレクトリー内の適切なグループに正しくマップされるようにします。
    1. wp_profile_root/PortalServer/wcm/shared/app/config/wcmservices/MemberFixerModule.properties ファイルを編集する。
    2. 以下の行をファイルに追加する。
      uid=xyzadmin,o=defaultWIMFileBasedRealm -> portal_admin_DN
      cn=contentauthors,o=defaultWIMFileBasedRealm -> content_authors_group_DN
      portal_admin_DN は、ポータル・アドミニストレーターの識別名で、content_authors_group_DN は、LDAP 構成中に使用されるコンテンツ作成者グループの識別名です。
      重要:
      • portal_admin_DN に指定するポータル・アドミニストレーターは、必ず content_authors_group_DN に指定するグループのメンバーであるようにしてください。 そうでない場合、ポータル・アドミニストレーターは、イントラネットおよびインターネット・サイトのテンプレートの Web コンテンツ・ライブラリーにアクセスできません。
      • 複数のレルムがある環境で express-memberfixer タスクを実行する場合は、cn=contentauthors,o=defaultWIMFileBasedRealm グループを削除します (存在する場合)。 複数のレルムがある環境にこのグループが存在すると、メンバー・フィクサー・タスクは無効になります。
    3. 変更を保管してファイルを閉じる。
    4. wp_profile_root/ConfigEngine ディレクトリーにある ConfigEngine.sh express-memberfixer -DmemberfixerRealm=realm_name -DPortalAdminPwd=password -DWasPassword=password タスクを実行する。
      ポータル・アドミニストレーター ID に関する注意事項: ポータル・アドミニストレーター ID がご使用の環境に固有でない場合は、wkplc.properties ファイル内の PortalAdminID パラメーターの値として完全修飾 ID を指定するか、コマンドの一部として完全修飾 ID を指定します。 例えば、ポータル・アドミニストレーター ID が wpsadmin であり、ご使用の LDAP ディレクトリーに別のユーザーの ID として wpsadmin が含まれている場合、このタスクは正常に実行されません。 したがって、uid=wpsadmin,cn=users,ou=test,o=retail,o=ibm などの完全修飾ポータル・アドミニストレーター ID を指定する必要があります。
      注: 構成した LDAP ユーザー・レジストリーのタイプに応じて、入力する realm_name の該当値を選択します。
      表 28. メンバー・フィクサー・タスクを実行して、Web Content Management が使用するメンバー名を更新する際の realm_name の値
      LDAP のタイプ
      スタンドアロン LDAP realm_name の指定値は、wkplc.properties ファイル内の standalone.ldap.realm の値と一致している必要があります。
      統合 LDAP realm_name の指定値は、wkplc.properties ファイル内の federated.realm の値と一致している必要があります。federated.realm の値が空の場合は、デフォルト値として defaultWIMFileBasedRealm を使用します。
  12. オプション: Web コンテンツ・ライブラリーへのアクセス権を割り当てる。
    1. ポータル・アドミニストレーターとしてログインする。
    2. 「管理」 > 「ポータル・コンテンツ」 > 「Web コンテンツ・ライブラリー」にナビゲートします。
    3. Web ライブラリーの「アクセス権の設定」アイコンをクリックする。
    4. 「編集者」の「役割の編集」アイコンをクリックする。
    5. content_authors_group_DN に指定したグループを、イントラネットおよびインターネット・ライブラリーの「編集者」として追加する。
    6. 「適用」をクリックしてから、「完了」をクリックする。
  13. 追加の Web Content Management ライブラリーを作成している場合は、Web コンテンツ・メンバー・フィクサー・タスクを実行して、ライブラリーで使用されるメンバー名を更新します。
IBM i スタンドアロン: SSL を介したスタンドアロン LDAP ユーザー・レジストリーの構成

スタンドアロンの LDAP ユーザー・レジストリーを SSL を介して使用して、セキュアな許可のためのすべてのユーザー・アカウント情報を保管するよう IBM WebSphere Portal Express を構成します。

始める前に
単一サーバー環境では、以下のステップを実行するために WebSphere_Portal サーバーと server1 サーバーを開始したり停止したりする必要はありません。 クラスター環境では、以下のタスクを開始する前に、システム上で WebSphere_Portal を含むすべてのアプリケーション・サーバーを停止してから、ノード・エージェントおよびデプロイメント・マネージャー・サーバーを開始する必要があります。
このタスクについて
SSL を介したスタンドアロン LDAP ユーザー・レジストリーを構成するには、以下のステップを実行します。
注: このタスクの実行時には、wp_profile_root/ConfigEngine/config/helpers ディレクトリー内にある wp_security_xxx.properties ヘルパー・ファイルを使用して、正しいプロパティーが入力されていることを確認してください。以下の指示で、wkplc.properties ファイルがステップで参照されている場合は、wp_security_xxx.properties ヘルパー・ファイルを使用します。
手順
  1. LDAP サーバーに対する SSL 証明書をサーバー・トラストストアおよびクライアント・トラストストアに追加するには、以下の手順を完了します。
    1. サーバー・トラストストアに証明書を追加するには、以下のうちの 1 つを選択します。
      表 29. サーバー・トラストストアに SSL 証明書を追加する際のオプション
      オプション ステップ
      サーバー・トラストストアに証明書を追加する
      1. WebSphere Application Server 管理コンソールにログインする。
      2. 「セキュリティー」 > 「SSL 証明書および鍵管理」 > 「SSL 構成」にナビゲートする。
      3. リストから適切な SSL 構成をクリックします。以下に例を示します。
        • スタンドアロン環境: NodeDefaultSSLSettings
        • クラスター環境: CellDefaultSSLSettings
      4. 「鍵ストアおよび証明書」をクリックする。
      5. リストから適切なトラストストアをクリックします。以下に例を示します。
        • スタンドアロン環境: NodeDefaultTrustStore
        • クラスター環境: CellDefaultTrustStore
      6. 「署名者証明書」をクリックし、「追加」をクリックして、次の情報を入力する。
        • 署名者証明書で鍵ストアが使用する「別名」を入力する。
        • 署名者証明書を保管する「ファイル名」を入力する。
      7. 「OK」をクリックし、「保管」をクリックしてマスター構成に対する変更内容を保管する。
      ポートから証明書を取得する
      1. WebSphere Application Server 管理コンソールにログインする。
      2. 「セキュリティー」 > 「SSL 証明書および鍵管理」 > 「SSL 構成」にナビゲートする。
      3. リストから適切な SSL 構成をクリックします。以下に例を示します。
        • スタンドアロン環境: NodeDefaultSSLSettings
        • クラスター環境: CellDefaultSSLSettings
      4. 「鍵ストアおよび証明書」をクリックする。
      5. リストから適切なトラストストアをクリックします。以下に例を示します。
        • スタンドアロン環境: NodeDefaultTrustStore
        • クラスター環境: CellDefaultTrustStore
      6. 「署名者証明書」をクリックし、「ポートから取得」をクリックして、以下の情報を入力する。
        • SSL ポートから署名者証明書を取得するときに使用する「ホスト」の名前を入力する。
        • 署名者証明書を取得するときに使用する SSL の「ポート」を入力する。
        • 署名者証明書で鍵ストアが使用する「別名」を入力する。クラスター環境: 「アウトバウンド接続の SSL 構成」の設定が SSL 設定と一致していることを確認する。
      7. 「署名者情報の取得」をクリックして、ポートから証明書を取得する。
      8. 「OK」をクリックし、「保管」をクリックしてマスター構成に対する変更内容を保管する。
    2. クライアント・トラストストアに証明書を追加します。
      1. クライアント署名者を取得するためのセキュア・インストールを参照してください。
      2. wp_profile_root/bin ディレクトリーから retrieveSigners タスクを実行します。詳しくは、retrieveSigners コマンドを参照してください。デプロイ済み環境では、デプロイメント・マネージャーに対して、統合ノードに関する retrieveSigners タスクを実行する必要があります。
        注: このタスクはエラーを報告する場合がありますが、トラストストアのアップデートには成功します。エラー・メッセージは無視できます。
        タスクの例:
        スタンドアロン環境
        retrieveSigners.sh NodeDefaultTrustStore ClientDefaultTrustStore -autoAcceptBootstrapSigner -conntype SOAP -port port_number
        クラスター環境
        retrieveSigners.sh CellDefaultTrustStore ClientDefaultTrustStore -autoAcceptBootstrapSigner -conntype SOAP -port port_number
        プロンプトが出たら、以下を入力します。
        • レルム/セル名: name
        • ユーザー名: user_ID
        • パスワード: password
        次のメッセージが表示されます: CWPKI0308I: 署名者の別名 "alias_name" をローカルの鍵ストア "ClientDefaultTrustStore" に次の SHA ダイジェストと共に追加しました: ssl_certificate_fingerprint
      3. トラストストアのプロパティー・ファイルを更新します。
        クラスター環境:
        • 1 次ノードで以下の手順を実行してから、デプロイメント・マネージャーを通して再同期し、変更点を伝搬させます。
        • 各ノードで、ssl.client.props が 1 次ノードと同じ値を含んでいることを確認してください。ssl.client.props の値が特定のノードと同一でない場合は、サーバーを再始動して変更点を同期してください。
        1. wp_profile_root/properties ディレクトリーにある ssl.client.props を任意のテキスト・エディターで開きます。
        2. com.ibm.ssl.trustStore パラメーターと関連するトラストストアのパラメーターを、SSL 構成で指定されているトラスト・ファイルに一致するように変更する。以下に例を示します。
          • スタンドアロン環境: デフォルトのトラストストアを使用する場合、以下を入力します。 com.ibm.ssl.trustStore=wp_profile_root¥config¥cells¥cell_name¥nodes¥node_name¥trust.p12
          • クラスター環境: デフォルトのトラストストアを使用する場合、以下を入力します。com.ibm.ssl.trustStore=wp_profile_root/config/cells/cell_name/trust.p12
        3. 変更内容を保管する。
  2. テキスト・エディターを使用して、wp_profile_root/ConfigEngine/properties ディレクトリーにある wkplc.properties ファイルを開く。
  3. 必須: wkplc.properties ファイルの VMM スタンドアロン LDAP 構成見出しの下に、以下の必須パラメーターの値を入力します。
    注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
    • standalone.ldap.id
    • standalone.ldap.host
    • standalone.ldap.port
    • standalone.ldap.bindDN
    • standalone.ldap.bindPassword
    • standalone.ldap.ldapServerType
    • standalone.ldap.userIdMap
    • standalone.ldap.groupIdMap
    • standalone.ldap.groupMemberIdMap
    • standalone.ldap.userFilter
    • standalone.ldap.groupFilter
    • standalone.ldap.serverId
    • standalone.ldap.serverPassword
    • standalone.ldap.realm
    • standalone.ldap.primaryAdminId
    • standalone.ldap.primaryAdminPassword
    • standalone.ldap.primaryPortalAdminId
    • standalone.ldap.primaryPortalAdminPassword
    • standalone.ldap.primaryPortalAdminGroup
    • standalone.ldap.baseDN
  4. 必須: wkplc.properties ファイルの LDAP エンティティー・タイプ見出しの下に、以下の必須エンティティー・タイプ・パラメーターの値を入力します。
    注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
    • standalone.ldap.et.group.objectClasses
    • standalone.ldap.et.group.objectClassesForCreate
    • standalone.ldap.et.group.searchBases
    • standalone.ldap.et.personaccount.objectClasses
    • standalone.ldap.et.personaccount.objectClassesForCreate
    • standalone.ldap.et.personaccount.searchBases
  5. 必須: wkplc.properties ファイルのグループ・メンバー属性見出しの下に、以下の必須グループ・メンバー・パラメーターの値を入力します。
    注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
    • standalone.ldap.gm.groupMemberName
    • standalone.ldap.gm.objectClass
    • standalone.ldap.gm.scope
    • standalone.ldap.gm.dummyMember
  6. 必須: wkplc.properties ファイルのデフォルトの親と相対識別名 (RDN) 属性見出しの下に、以下の必須 RDN パラメーターの値を入力します。
    注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
    • standalone.ldap.personAccountParent
    • standalone.ldap.groupParent
    • standalone.ldap.personAccountRdnProperties
    • standalone.ldap.groupRdnProperties
  7. Secure Socket Layers (SSL) を使用可能にするために、以下のパラメーターの値を入力します。
    注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
    必須パラメーター:
    • standalone.ldap.sslEnabled
    • standalone.ldap.sslConfiguration
    オプション・パラメーター:
    • standalone.ldap.certificateMapMode
    • standalone.ldap.certificateFilter
  8. 変更内容を wkplc.properties ファイルに保管します。
  9. ConfigEngine.sh validate-standalone-ldap -DWasPassword=password タスクを実行して、LDAP サーバーの設定を検証します。
    重要: デフォルトのファイル・リポジトリーを削除していない場合は、WasPassword は LDAP ユーザー・レジストリー内にある値ではなく、インストール時に入力された値になります。
    注: 検証タスクの間は、ここでトラスト・ストアに署名者を追加しますか?というプロンプトが表示される場合があります。y を押してから、Enter を押してください。
  10. wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-modify-ldap-security -DWasPassword=password タスクを実行して、スタンドアロンの LDAP ユーザー・レジストリーを設定します。
  11. 該当するサーバーを停止してから再始動し、変更を伝搬させます。 具体的な手順については、関連タスクの以下のリンクを参照してください。 『サーバー、デプロイメント・マネージャー、およびノード・エージェントの始動と停止
  12. wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-validate-standalone-ldap-attribute-config -DWasPassword=password タスクを実行して、定義済みのすべての属性が構成済みの LDAP ユーザー・レジストリーで使用可能であることを確認します。
    重要: LDAP ユーザー・レジストリーの構成が完了したら、属性の追加とマッピングを行って WebSphere Portal Express と LDAP サーバーとの間の適切な通信を保証する方法について『属性の構成の調整』を参照してください。
IBM i スタンドアロン: デフォルトの統合リポジトリーの構成

LDAP ユーザー・レジストリーまたはデータベース・ユーザー・レジストリー、あるいはその両方をデフォルトの統合リポジトリーに追加して、そのリポジトリー内にシームレスな認証を作成します。

このタスクについて
ユーザー・レジストリーをデフォルトの統合リポジトリーに追加するには、以下のタスクを実行します。
IBM i スタンドアロン: 統合 LDAP ユーザー・レジストリーの構成

IBM WebSphere Application ServerIBM WebSphere Portal Express、および LDAP サーバーとの間で交換されるデータのタイプに応じて、LDAP サーバーを SSL で構成するか、または IBM WebSphere Application Server および IBM WebSphere Portal Express に直接アクセスできるよう LDAP サーバーを構成できます。

このタスクについて
以下のいずれかのオプションを使用して、LDAP サーバーを構成します。
IBM i スタンドアロン: SSL を使用しない LDAP ユーザー・レジストリーの追加

許可のためのユーザー・アカウント情報を保管するためのデフォルトの統合リポジトリーに、LDAP ユーザー・レジストリーを追加します。 複数の LDAP ユーザー・レジストリーをデフォルトの統合リポジトリーに追加できますが、一度に追加できる LDAP サーバーは 1 つのみです。IBM Lotus Domino が複数のレジストリー構成内のユーザー・レジストリーの 1 つになり、別のユーザー・レジストリーとレルムを共有する場合には、グループが必ず、デフォルトのフラット・ネーミング構造ではなく階層フォーマットで Domino Directory に保管されるようにしてください。 例えば、フラット・ネーミング規則は cn=groupName ですが、 階層フォーマットは cn=groupName,o=root です。 デフォルトの統合リポジトリーと追加している LDAP の間で ID が固有であることも確認する必要があります。例えば、デフォルトの統合リポジトリーに wpsadmin のような ID が含まれている場合、この ID は追加している LDAP に存在することはできません。

始める前に
単一サーバー環境では、以下のステップを実行するために WebSphere_Portal サーバーと server1 サーバーを開始したり停止したりする必要はありません。 クラスター環境では、以下のタスクを開始する前に、システム上で WebSphere_Portal を含むすべてのアプリケーション・サーバーを停止してから、ノード・エージェントおよびデプロイメント・マネージャー・サーバーを開始する必要があります。
このタスクについて
LDAP ユーザー・レジストリーをデフォルトの統合リポジトリーに追加するには、1 次ノードでのみ以下のステップを実行します。追加する計画の LDAP ユーザー・レジストリーごとにこれらのステップを繰り返さなければなりません。
注: このタスクの実行時には、wp_profile_root/ConfigEngine/config/helpers ディレクトリー内にある wp_add_federated_xxx.properties ヘルパー・ファイルを使用して、正しいプロパティーが入力されていることを確認してください。以下の指示で、wkplc.properties ファイルがステップで参照されている場合は、wp_add_federated_xxx.properties ヘルパー・ファイルを使用します。
手順
  1. テキスト・エディターを使用して、wp_profile_root/ConfigEngine/properties ディレクトリーにある wkplc.properties ファイルを開く。
  2. 必須: wkplc.properties ファイルの VMM 統合 LDAP プロパティー見出しの下に、以下の必須パラメーターの値を入力します。
    注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
    • federated.ldap.id
    • federated.ldap.host
    • federated.ldap.port
    • federated.ldap.bindDN
    • federated.ldap.bindPassword
    • federated.ldap.ldapServerType
    • federated.ldap.baseDN
  3. 必須: wkplc.properties ファイルの LDAP エンティティー・タイプ見出しの下に、以下の必須エンティティー・タイプ・パラメーターの値を入力します。
    注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
    • federated.ldap.et.group.objectClasses
    • federated.ldap.et.group.objectClassesForCreate
    • federated.ldap.et.group.searchBases
    • federated.ldap.et.personaccount.objectClasses
    • federated.ldap.et.personaccount.objectClassesForCreate
    • federated.ldap.et.personaccount.searchBases
  4. 必須: wkplc.properties ファイルのグループ・メンバー属性見出しの下に、以下の必須グループ・メンバー・パラメーターの値を入力します。
    注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
    • federated.ldap.gm.groupMemberName
    • federated.ldap.gm.objectClass
    • federated.ldap.gm.scope
    • federated.ldap.gm.dummyMember
  5. 変更内容を wkplc.properties ファイルに保管します。
  6. ConfigEngine.sh validate-federated-ldap -DWasPassword=password タスクを実行して、LDAP サーバーの設定を検証します。
    重要: デフォルトのファイル・リポジトリーを削除していない場合は、WasPassword は LDAP ユーザー・レジストリー内にある値ではなく、インストール時に入力された値になります。
    注: 検証タスクの間は、ここでトラスト・ストアに署名者を追加しますか?というプロンプトが表示される場合があります。y を押してから、Enter を押してください。
  7. wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-create-ldap -DWasPassword=password タスクを実行して、LDAP ユーザー・レジストリーをデフォルトの統合リポジトリーに追加します。
    注: LDAP を使用していないユーザーは、認識機能を利用できず、ほかのユーザーがオンラインかどうかを知ることはできません。この状況は、WebSphere Portal Express をインストールしてから、そのユーザーが含まれていない統合 LDAP または統合データベースのユーザー・リポジトリーを使用可能にする場合に発生します。セルフケア・ポートレットを使用してサインアップしたユーザーも、認識機能を使用できません。
  8. 該当するサーバーを停止してから再始動し、変更を伝搬させます。 具体的な手順については、関連タスクの以下のリンクを参照してください。 『サーバー、デプロイメント・マネージャー、およびノード・エージェントの始動と停止
  9. オプション: LDAP ユーザー・レジストリー内に追加の基本項目を作成するには、以下のステップを実行します。複数レルム・サポートのために作成する基本項目ごとに、これらのステップを繰り返し行ってください。
    1. テキスト・エディターを使用して、wp_profile_root/ConfigEngine/properties ディレクトリーにある wkplc.properties ファイルを開く。
    2. レルムの作成時に使用する追加基本項目を LDAP ユーザー・レジストリー内部に作成するには、wkplc.properties ファイルの VMM リポジトリー基本項目構成見出しの下に、以下の必須パラメーターの値を入力します。
      注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
      • id
      • baseDN
      • nameInRepository
    3. 変更内容を wkplc.properties ファイルに保管します。
    4. wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-create-base-entry -DWasPassword=password タスクを実行して、リポジトリー内に基本項目を作成します。
    5. 必要なサーバーをすべて停止して再始動し、変更を伝搬する。
  10. オプション: wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-query-repository -DWasPassword=password タスクを実行して、構成済みリポジトリーの名前とタイプをリストします。
  11. wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-validate-federated-ldap-attribute-config -DWasPassword=password タスクを実行して、定義済みのすべての属性が構成済みの LDAP ユーザー・レジストリーで使用可能であることを確認します。
    重要: LDAP ユーザー・レジストリーの構成が完了したら、属性の追加とマッピングを行って WebSphere Portal Express と LDAP サーバーとの間の適切な通信を保証する方法について『属性の構成の調整』を参照してください。
  12. 新規ユーザーとグループが保管されるユーザー・レジストリーを更新するには、以下のステップを実行します。
    注: 複数の LDAP ユーザー・レジストリーおよび (または) データベース・ユーザー・レジストリーを使用している場合は、新規ユーザーおよびグループの保管場所となるデフォルトのユーザー・レジストリーとして定義するユーザー・レジストリーのみにこのタスクを実行してください。
    重要: インストール中に、デフォルトのファイル・リポジトリーは、personAccountRdnProperties および groupRdnProperties パラメーターのデフォルト値を作成します。 デフォルト値を変更するには、このタスクを 2 回実行しなければなりません。1 回目でデフォルト値をクリアし、2 回目で新しい値を追加します。
    1. テキスト・エディターを使用して、wp_profile_root/ConfigEngine/properties ディレクトリーにある wkplc.properties ファイルを開く。
    2. wkplc.properties ファイルの VMM サポートのエンティティー・タイプ構成見出しの下に、以下の必須パラメーターの値を入力します。
      注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
      • personAccountParent
      • groupParent
      • personAccountRdnProperties
      • groupRdnProperties
    3. 変更内容を wkplc.properties ファイルに保管します。
    4. wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-set-entitytypes -DWasPassword=password タスクを実行して、古い属性を削除してから新しい属性を追加します。
    5. 必要なサーバーをすべて停止して再始動し、変更を伝搬する。
  13. オプション: 短縮名がそのレルムで固有ではない場合に完全識別名によるログインを使用可能にするには、以下のステップを実行します。
    1. テキスト・エディターを使用して、wp_profile_root/ConfigEngine/properties ディレクトリーにある wkplc.properties ファイルを開く。
    2. realmName に値を入力するか、ブランクのままにしてデフォルト・レルムを更新する。
    3. 変更内容を wkplc.properties ファイルに保管します。
    4. wp_profile_root/ConfigEngine ディレクトリーにある ConfigEngine.sh wp-modify-realm-enable-dn-login -DWasPassword=password タスクを実行して、識別名ログインを使用可能にする。
      注: このタスクを実行して完全識別名によるログインを使用可能にした後に、ConfigEngine.sh wp-modify-realm-disable-dn-login -DWasPassword=password タスクを実行してこの機能を使用不可にすることができます。
    5. 必要なサーバーをすべて停止して再始動し、変更を伝搬する。
  14. 必須: メンバー・フィクサー・タスクを実行して、Web Content Management が使用するメンバー名を LDAP ディレクトリーの対応するメンバーによって更新します。このステップにより、contentAuthors グループのイントラネットおよびインターネットのサイト・テンプレート用 Web コンテンツ・ライブラリーへのアクセスが、LDAP ディレクトリー内の適切なグループに正しくマップされるようにします。
    1. wp_profile_root/PortalServer/wcm/shared/app/config/wcmservices/MemberFixerModule.properties ファイルを編集する。
    2. 以下の行をファイルに追加する。
      uid=xyzadmin,o=defaultWIMFileBasedRealm -> portal_admin_DN
      cn=contentauthors,o=defaultWIMFileBasedRealm -> content_authors_group_DN
      portal_admin_DN は、ポータル・アドミニストレーターの識別名で、content_authors_group_DN は、LDAP 構成中に使用されるコンテンツ作成者グループの識別名です。
      重要:
      • portal_admin_DN に指定するポータル・アドミニストレーターは、必ず content_authors_group_DN に指定するグループのメンバーであるようにしてください。 そうでない場合、ポータル・アドミニストレーターは、イントラネットおよびインターネット・サイトのテンプレートの Web コンテンツ・ライブラリーにアクセスできません。
      • 複数のレルムがある環境で express-memberfixer タスクを実行する場合は、cn=contentauthors,o=defaultWIMFileBasedRealm グループを削除します (存在する場合)。 複数のレルムがある環境にこのグループが存在すると、メンバー・フィクサー・タスクは無効になります。
    3. 変更を保管してファイルを閉じる。
    4. wp_profile_root/ConfigEngine ディレクトリーにある ConfigEngine.sh express-memberfixer -DmemberfixerRealm=realm_name -DPortalAdminPwd=password -DWasPassword=password タスクを実行する。
      ポータル・アドミニストレーター ID に関する注意事項: ポータル・アドミニストレーター ID がご使用の環境に固有でない場合は、wkplc.properties ファイル内の PortalAdminID パラメーターの値として完全修飾 ID を指定するか、コマンドの一部として完全修飾 ID を指定します。 例えば、ポータル・アドミニストレーター ID が wpsadmin であり、ご使用の LDAP ディレクトリーに別のユーザーの ID として wpsadmin が含まれている場合、このタスクは正常に実行されません。 したがって、uid=wpsadmin,cn=users,ou=test,o=retail,o=ibm などの完全修飾ポータル・アドミニストレーター ID を指定する必要があります。
      注: 構成した LDAP ユーザー・レジストリーのタイプに応じて、入力する realm_name の該当値を選択します。
      表 30. メンバー・フィクサー・タスクを実行して、Web Content Management が使用するメンバー名を更新する際の realm_name の値
      LDAP のタイプ
      スタンドアロン LDAP realm_name の指定値は、wkplc.properties ファイル内の standalone.ldap.realm の値と一致している必要があります。
      統合 LDAP realm_name の指定値は、wkplc.properties ファイル内の federated.realm の値と一致している必要があります。federated.realm の値が空の場合は、デフォルト値として defaultWIMFileBasedRealm を使用します。
  15. オプション: Web コンテンツ・ライブラリーへのアクセス権を割り当てる。
    1. ポータル・アドミニストレーターとしてログインする。
    2. 「管理」 > 「ポータル・コンテンツ」 > 「Web コンテンツ・ライブラリー」にナビゲートします。
    3. Web ライブラリーの「アクセス権の設定」アイコンをクリックする。
    4. 「編集者」の「役割の編集」アイコンをクリックする。
    5. content_authors_group_DN に指定したグループを、イントラネットおよびインターネット・ライブラリーの「編集者」として追加する。
    6. 「適用」をクリックしてから、「完了」をクリックする。
  16. 追加の Web Content Management ライブラリーを作成している場合は、Web コンテンツ・メンバー・フィクサー・タスクを実行して、ライブラリーで使用されるメンバー名を更新します。
  17. オプション: このステップは、実稼働環境で必須です。ファイル・システム・リポジトリーを削除する前に、以下のステップを実行して、WebSphere Application ServerWebSphere Portal Express のアドミニストレーター・ユーザー ID と管理グループ ID を、LDAP ユーザー・レジストリーに存在するユーザーとグループに置き換えます。
    重要:
    • ユーザー ID とパスワードを変更する前に、『WebSphere Portal Express の計画』の中の『ユーザー ID とパスワードの特殊文字』を検討してください。
    • WebSphere Application Server アドミニストレーターの新規ユーザー ID が、置換対象の ID と同一でないことを確認してください。 ユーザー ID が重複していると、管理コンソールで認証の問題が発生します。
    注: クラスターの作成後にこれらのタスクを実行する場合は、クラスター内のすべてのノード上でこれらのタスクを実行しなければなりません。
    1. wp_profile_root/ConfigEngine ディレクトリーから以下のタスクを実行する。 ConfigEngine.sh wp-change-was-admin-user -DWasPassword=password -DnewAdminId=newadminid -DnewAdminPw=newpassword
      重要: newAdminId パラメーターには、完全識別名 (DN) を入力する必要があります。
    2. タスクが正常に完了したことを確認する。 クラスター環境では、デプロイメント・マネージャー、ノード・エージェント、および WebSphere_Portal サーバーを再始動します。 スタンドアロン環境では、server1 と WebSphere_Portal サーバーを再起動します。
    3. wp_profile_root/ConfigEngine ディレクトリーから以下のタスクを実行する。 ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=password -DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid
      重要: newAdminId および newAdminGroupId パラメーターに完全識別名 (DN) を入力しなければなりません。
      停止したサーバーの追加パラメーター: このタスクでは、実行サーバー・インスタンスに照合してユーザーを検証します。サーバーが停止する場合は、-Dskip.ldap.validation=true パラメーターをタスクに追加して、検証動作をスキップしてください。
    4. タスクが正常に完了したことを確認する。 クラスター環境では、デプロイメント・マネージャー、ノード・エージェント、および WebSphere_Portal サーバーを再始動します。 スタンドアロン環境では、server1 と WebSphere_Portal サーバーを再起動します。
  18. オプション: このステップは、実稼働環境で必須です。ファイルシステム・リポジトリーを使用しない場合は、削除します。 デフォルトのセキュリティー設定だった統合ファイルシステムのユーザー・リポジトリーは、ユーザー・リポジトリーの統合後は必要なくなる場合があります。ファイルシステム・リポジトリーが不要になった場合、そのリポジトリーを削除すると、複数のリポジトリーに存在する重複ユーザー ID が原因で起こる競合を避けるのに役立ちます。手順については、オペレーティング・システム別に編成されている『リポジトリーの削除』のトピックを参照してください。
IBM i スタンドアロン: SSL を介した LDAP ユーザー・レジストリーの追加

セキュアな許可のためのユーザー・アカウント情報を保管するためのデフォルトの統合リポジトリーに、LDAP ユーザー・レジストリーを SSL を介して追加します。複数の LDAP ユーザー・レジストリーをデフォルトの統合リポジトリーに追加できますが、一度に追加できる LDAP サーバーは 1 つのみです。

始める前に
単一サーバー環境では、以下のステップを実行するために WebSphere_Portal サーバーと server1 サーバーを開始したり停止したりする必要はありません。 クラスター環境では、以下のタスクを開始する前に、システム上で WebSphere_Portal を含むすべてのアプリケーション・サーバーを停止してから、ノード・エージェントおよびデプロイメント・マネージャー・サーバーを開始する必要があります。
このタスクについて
LDAP ユーザー・レジストリーを SSL を介してデフォルトの統合リポジトリーに追加するには、1 次ノードでのみ以下のステップを実行します。追加する計画の LDAP ユーザー・レジストリーごとにこれらのステップを繰り返さなければなりません。
注: このタスクの実行時には、wp_profile_root/ConfigEngine/config/helpers ディレクトリー内にある wp_add_federated_xxx.properties ヘルパー・ファイルを使用して、正しいプロパティーが入力されていることを確認してください。以下の指示で、wkplc.properties ファイルがステップで参照されている場合は、wp_add_federated_xxx.properties ヘルパー・ファイルを使用します。
手順
  1. LDAP サーバーに対する SSL 証明書をサーバー・トラストストアおよびクライアント・トラストストアに追加するには、以下の手順を完了します。
    1. サーバー・トラストストアに証明書を追加するには、以下のうちの 1 つを選択します。
      表 31. サーバー・トラストストアに SSL 証明書を追加する際のオプション
      オプション ステップ
      サーバー・トラストストアに証明書を追加する
      1. WebSphere Application Server 管理コンソールにログインする。
      2. 「セキュリティー」 > 「SSL 証明書および鍵管理」 > 「SSL 構成」にナビゲートする。
      3. リストから適切な SSL 構成をクリックします。以下に例を示します。
        • スタンドアロン環境: NodeDefaultSSLSettings
        • クラスター環境: CellDefaultSSLSettings
      4. 「鍵ストアおよび証明書」をクリックする。
      5. リストから適切なトラストストアをクリックします。以下に例を示します。
        • スタンドアロン環境: NodeDefaultTrustStore
        • クラスター環境: CellDefaultTrustStore
      6. 「署名者証明書」をクリックし、「追加」をクリックして、次の情報を入力する。
        • 署名者証明書で鍵ストアが使用する「別名」を入力する。
        • 署名者証明書を保管する「ファイル名」を入力する。
      7. 「OK」をクリックし、「保管」をクリックしてマスター構成に対する変更内容を保管する。
      ポートから証明書を取得する
      1. WebSphere Application Server 管理コンソールにログインする。
      2. 「セキュリティー」 > 「SSL 証明書および鍵管理」 > 「SSL 構成」にナビゲートする。
      3. リストから適切な SSL 構成をクリックします。以下に例を示します。
        • スタンドアロン環境: NodeDefaultSSLSettings
        • クラスター環境: CellDefaultSSLSettings
      4. 「鍵ストアおよび証明書」をクリックする。
      5. リストから適切なトラストストアをクリックします。以下に例を示します。
        • スタンドアロン環境: NodeDefaultTrustStore
        • クラスター環境: CellDefaultTrustStore
      6. 「署名者証明書」をクリックし、「ポートから取得」をクリックして、以下の情報を入力する。
        • SSL ポートから署名者証明書を取得するときに使用する「ホスト」の名前を入力する。
        • 署名者証明書を取得するときに使用する SSL の「ポート」を入力する。
        • 署名者証明書で鍵ストアが使用する「別名」を入力する。クラスター環境: 「アウトバウンド接続の SSL 構成」の設定が SSL 設定と一致していることを確認する。
      7. 「署名者情報の取得」をクリックして、ポートから証明書を取得する。
      8. 「OK」をクリックし、「保管」をクリックしてマスター構成に対する変更内容を保管する。
    2. クライアント・トラストストアに証明書を追加します。
      1. クライアント署名者を取得するためのセキュア・インストールを参照してください。
      2. wp_profile_root/bin ディレクトリーから retrieveSigners タスクを実行します。詳しくは、retrieveSigners コマンドを参照してください。デプロイ済み環境では、デプロイメント・マネージャーに対して、統合ノードに関する retrieveSigners タスクを実行する必要があります。
        注: このタスクはエラーを報告する場合がありますが、トラストストアのアップデートには成功します。エラー・メッセージは無視できます。
        タスクの例:
        スタンドアロン環境
        retrieveSigners.sh NodeDefaultTrustStore ClientDefaultTrustStore -autoAcceptBootstrapSigner -conntype SOAP -port port_number
        クラスター環境
        retrieveSigners.sh CellDefaultTrustStore ClientDefaultTrustStore -autoAcceptBootstrapSigner -conntype SOAP -port port_number
        プロンプトが出たら、以下を入力します。
        • レルム/セル名: name
        • ユーザー名: user_ID
        • パスワード: password
        次のメッセージが表示されます: CWPKI0308I: 署名者の別名 "alias_name" をローカルの鍵ストア "ClientDefaultTrustStore" に次の SHA ダイジェストと共に追加しました: ssl_certificate_fingerprint
      3. トラストストアのプロパティー・ファイルを更新します。
        クラスター環境:
        • 1 次ノードで以下の手順を実行してから、デプロイメント・マネージャーを通して再同期し、変更点を伝搬させます。
        • 各ノードで、ssl.client.props が 1 次ノードと同じ値を含んでいることを確認してください。ssl.client.props の値が特定のノードと同一でない場合は、サーバーを再始動して変更点を同期してください。
        1. wp_profile_root/properties ディレクトリーにある ssl.client.props を任意のテキスト・エディターで開きます。
        2. com.ibm.ssl.trustStore パラメーターと関連するトラストストアのパラメーターを、SSL 構成で指定されているトラスト・ファイルに一致するように変更する。以下に例を示します。
          • スタンドアロン環境: デフォルトのトラストストアを使用する場合、以下を入力します。 com.ibm.ssl.trustStore=wp_profile_root¥config¥cells¥cell_name¥nodes¥node_name¥trust.p12
          • クラスター環境: デフォルトのトラストストアを使用する場合、以下を入力します。com.ibm.ssl.trustStore=wp_profile_root/config/cells/cell_name/trust.p12
        3. 変更内容を保管する。
  2. テキスト・エディターを使用して、wp_profile_root/ConfigEngine/properties ディレクトリーにある wkplc.properties ファイルを開く。
  3. 必須: wkplc.properties ファイルの VMM 統合 LDAP プロパティー見出しの下に、以下の必須パラメーターの値を入力します。
    注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
    • federated.ldap.id
    • federated.ldap.host
    • federated.ldap.port
    • federated.ldap.bindDN
    • federated.ldap.bindPassword
    • federated.ldap.ldapServerType
    • federated.ldap.baseDN
  4. 必須: wkplc.properties ファイルの LDAP エンティティー・タイプ見出しの下に、以下の必須エンティティー・タイプ・パラメーターの値を入力します。
    注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
    • federated.ldap.et.group.objectClasses
    • federated.ldap.et.group.objectClassesForCreate
    • federated.ldap.et.group.searchBases
    • federated.ldap.et.personaccount.objectClasses
    • federated.ldap.et.personaccount.objectClassesForCreate
    • federated.ldap.et.personaccount.searchBases
  5. 必須: wkplc.properties ファイルのグループ・メンバー属性見出しの下に、以下の必須グループ・メンバー・パラメーターの値を入力します。
    注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
    • federated.ldap.gm.groupMemberName
    • federated.ldap.gm.objectClass
    • federated.ldap.gm.scope
    • federated.ldap.gm.dummyMember
  6. Secure Socket Layers (SSL) を使用可能にするために、以下のパラメーターの値を入力します。
    注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
    必須パラメーター:
    • federated.ldap.sslEnabled
    • federated.ldap.sslConfiguration
    オプション・パラメーター:
    • federated.ldap.certificateMapMode
    • federated.ldap.certificateFilter
  7. 変更内容を wkplc.properties ファイルに保管します。
  8. ConfigEngine.sh validate-federated-ldap -DWasPassword=password タスクを実行して、LDAP サーバーの設定を検証します。
    重要: デフォルトのファイル・リポジトリーを削除していない場合は、WasPassword は LDAP ユーザー・レジストリー内にある値ではなく、インストール時に入力された値になります。
    注: 検証タスクの間は、ここでトラスト・ストアに署名者を追加しますか?というプロンプトが表示される場合があります。y を押してから、Enter を押してください。
  9. wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-create-ldap -DWasPassword=password タスクを実行して、LDAP ユーザー・レジストリーをデフォルトの統合リポジトリーに追加します。
    注: LDAP を使用していないユーザーは、認識機能を利用できず、ほかのユーザーがオンラインかどうかを知ることはできません。この状況は、WebSphere Portal Express をインストールしてから、そのユーザーが含まれていない統合 LDAP または統合データベースのユーザー・リポジトリーを使用可能にする場合に発生します。セルフケア・ポートレットを使用してサインアップしたユーザーも、認識機能を使用できません。
  10. 該当するサーバーを停止してから再始動し、変更を伝搬させます。 具体的な手順については、関連タスクの以下のリンクを参照してください。 『サーバー、デプロイメント・マネージャー、およびノード・エージェントの始動と停止
  11. オプション: LDAP ユーザー・レジストリー内に追加の基本項目を作成するには、以下のステップを実行します。複数レルム・サポートのために作成する基本項目ごとに、これらのステップを繰り返し行ってください。
    1. テキスト・エディターを使用して、wp_profile_root/ConfigEngine/properties ディレクトリーにある wkplc.properties ファイルを開く。
    2. レルムの作成時に使用する追加基本項目を LDAP ユーザー・レジストリー内部に作成するには、wkplc.properties ファイルの VMM リポジトリー基本項目構成見出しの下に、以下の必須パラメーターの値を入力します。
      注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
      • id
      • baseDN
      • nameInRepository
    3. 変更内容を wkplc.properties ファイルに保管します。
    4. wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-create-base-entry -DWasPassword=password タスクを実行して、リポジトリー内に基本項目を作成します。
    5. 必要なサーバーをすべて停止して再始動し、変更を伝搬する。
  12. オプション: wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-query-repository -DWasPassword=password タスクを実行して、構成済みリポジトリーの名前とタイプをリストします。
  13. wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-validate-federated-ldap-attribute-config -DWasPassword=password タスクを実行して、定義済みのすべての属性が構成済みの LDAP ユーザー・レジストリーで使用可能であることを確認します。
    重要: LDAP ユーザー・レジストリーの構成が完了したら、属性の追加とマッピングを行って WebSphere Portal Express と LDAP サーバーとの間の適切な通信を保証する方法について『属性の構成の調整』を参照してください。
  14. 新規ユーザーとグループが保管されるユーザー・レジストリーを更新するには、以下のステップを実行します。
    注: 複数の LDAP ユーザー・レジストリーおよび (または) データベース・ユーザー・レジストリーを使用している場合は、新規ユーザーおよびグループの保管場所となるデフォルトのユーザー・レジストリーとして定義するユーザー・レジストリーのみにこのタスクを実行してください。
    重要: インストール中に、デフォルトのファイル・リポジトリーは、personAccountRdnProperties および groupRdnProperties パラメーターのデフォルト値を作成します。 デフォルト値を変更するには、このタスクを 2 回実行しなければなりません。1 回目でデフォルト値をクリアし、2 回目で新しい値を追加します。
    1. テキスト・エディターを使用して、wp_profile_root/ConfigEngine/properties ディレクトリーにある wkplc.properties ファイルを開く。
    2. wkplc.properties ファイルの VMM サポートのエンティティー・タイプ構成見出しの下に、以下の必須パラメーターの値を入力します。
      注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
      • personAccountParent
      • groupParent
      • personAccountRdnProperties
      • groupRdnProperties
    3. 変更内容を wkplc.properties ファイルに保管します。
    4. wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-set-entitytypes -DWasPassword=password タスクを実行して、古い属性を削除してから新しい属性を追加します。
    5. 必要なサーバーをすべて停止して再始動し、変更を伝搬する。
  15. オプション: 短縮名がそのレルムで固有ではない場合に完全識別名によるログインを使用可能にするには、以下のステップを実行します。
    1. テキスト・エディターを使用して、wp_profile_root/ConfigEngine/properties ディレクトリーにある wkplc.properties ファイルを開く。
    2. realmName に値を入力するか、ブランクのままにしてデフォルト・レルムを更新する。
    3. 変更内容を wkplc.properties ファイルに保管します。
    4. wp_profile_root/ConfigEngine ディレクトリーにある ConfigEngine.sh wp-modify-realm-enable-dn-login -DWasPassword=password タスクを実行して、識別名ログインを使用可能にする。
      注: このタスクを実行して完全識別名によるログインを使用可能にした後に、ConfigEngine.sh wp-modify-realm-disable-dn-login -DWasPassword=password タスクを実行してこの機能を使用不可にすることができます。
    5. 必要なサーバーをすべて停止して再始動し、変更を伝搬する。
  16. 必須: メンバー・フィクサー・タスクを実行して、Web Content Management が使用するメンバー名を LDAP ディレクトリーの対応するメンバーによって更新します。このステップにより、contentAuthors グループのイントラネットおよびインターネットのサイト・テンプレート用 Web コンテンツ・ライブラリーへのアクセスが、LDAP ディレクトリー内の適切なグループに正しくマップされるようにします。
    1. wp_profile_root/PortalServer/wcm/shared/app/config/wcmservices/MemberFixerModule.properties ファイルを編集する。
    2. 以下の行をファイルに追加する。
      uid=xyzadmin,o=defaultWIMFileBasedRealm -> portal_admin_DN
      cn=contentauthors,o=defaultWIMFileBasedRealm -> content_authors_group_DN
      portal_admin_DN は、ポータル・アドミニストレーターの識別名で、content_authors_group_DN は、LDAP 構成中に使用されるコンテンツ作成者グループの識別名です。
      重要:
      • portal_admin_DN に指定するポータル・アドミニストレーターは、必ず content_authors_group_DN に指定するグループのメンバーであるようにしてください。 そうでない場合、ポータル・アドミニストレーターは、イントラネットおよびインターネット・サイトのテンプレートの Web コンテンツ・ライブラリーにアクセスできません。
      • 複数のレルムがある環境で express-memberfixer タスクを実行する場合は、cn=contentauthors,o=defaultWIMFileBasedRealm グループを削除します (存在する場合)。 複数のレルムがある環境にこのグループが存在すると、メンバー・フィクサー・タスクは無効になります。
    3. 変更を保管してファイルを閉じる。
    4. wp_profile_root/ConfigEngine ディレクトリーにある ConfigEngine.sh express-memberfixer -DmemberfixerRealm=realm_name -DPortalAdminPwd=password -DWasPassword=password タスクを実行する。
      ポータル・アドミニストレーター ID に関する注意事項: ポータル・アドミニストレーター ID がご使用の環境に固有でない場合は、wkplc.properties ファイル内の PortalAdminID パラメーターの値として完全修飾 ID を指定するか、コマンドの一部として完全修飾 ID を指定します。 例えば、ポータル・アドミニストレーター ID が wpsadmin であり、ご使用の LDAP ディレクトリーに別のユーザーの ID として wpsadmin が含まれている場合、このタスクは正常に実行されません。 したがって、uid=wpsadmin,cn=users,ou=test,o=retail,o=ibm などの完全修飾ポータル・アドミニストレーター ID を指定する必要があります。
      注: 構成した LDAP ユーザー・レジストリーのタイプに応じて、入力する realm_name の該当値を選択します。
      表 32. メンバー・フィクサー・タスクを実行して、Web Content Management が使用するメンバー名を更新する際の realm_name の値
      LDAP のタイプ
      スタンドアロン LDAP realm_name の指定値は、wkplc.properties ファイル内の standalone.ldap.realm の値と一致している必要があります。
      統合 LDAP realm_name の指定値は、wkplc.properties ファイル内の federated.realm の値と一致している必要があります。federated.realm の値が空の場合は、デフォルト値として defaultWIMFileBasedRealm を使用します。
  17. オプション: Web コンテンツ・ライブラリーへのアクセス権を割り当てる。
    1. ポータル・アドミニストレーターとしてログインする。
    2. 「管理」 > 「ポータル・コンテンツ」 > 「Web コンテンツ・ライブラリー」にナビゲートします。
    3. Web ライブラリーの「アクセス権の設定」アイコンをクリックする。
    4. 「編集者」の「役割の編集」アイコンをクリックする。
    5. content_authors_group_DN に指定したグループを、イントラネットおよびインターネット・ライブラリーの「編集者」として追加する。
    6. 「適用」をクリックしてから、「完了」をクリックする。
  18. 追加の Web Content Management ライブラリーを作成している場合は、Web コンテンツ・メンバー・フィクサー・タスクを実行して、ライブラリーで使用されるメンバー名を更新します。
  19. オプション: このステップは、実稼働環境で必須です。ファイル・システム・リポジトリーを削除する前に、以下のステップを実行して、WebSphere Application ServerWebSphere Portal Express のアドミニストレーター・ユーザー ID と管理グループ ID を、LDAP ユーザー・レジストリーに存在するユーザーとグループに置き換えます。
    重要:
    • ユーザー ID とパスワードを変更する前に、『WebSphere Portal Express の計画』の中の『ユーザー ID とパスワードの特殊文字』を検討してください。
    • WebSphere Application Server アドミニストレーターの新規ユーザー ID が、置換対象の ID と同一でないことを確認してください。 ユーザー ID が重複していると、管理コンソールで認証の問題が発生します。
    注: クラスターの作成後にこれらのタスクを実行する場合は、クラスター内のすべてのノード上でこれらのタスクを実行しなければなりません。
    1. wp_profile_root/ConfigEngine ディレクトリーから以下のタスクを実行する。 ConfigEngine.sh wp-change-was-admin-user -DWasPassword=password -DnewAdminId=newadminid -DnewAdminPw=newpassword
      重要: newAdminId パラメーターには、完全識別名 (DN) を入力する必要があります。
    2. タスクが正常に完了したことを確認する。 クラスター環境では、デプロイメント・マネージャー、ノード・エージェント、および WebSphere_Portal サーバーを再始動します。 スタンドアロン環境では、server1 と WebSphere_Portal サーバーを再起動します。
    3. wp_profile_root/ConfigEngine ディレクトリーから以下のタスクを実行する。 ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=password -DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid
      重要: newAdminId および newAdminGroupId パラメーターに完全識別名 (DN) を入力しなければなりません。
      停止したサーバーの追加パラメーター: このタスクでは、実行サーバー・インスタンスに照合してユーザーを検証します。サーバーが停止する場合は、-Dskip.ldap.validation=true パラメーターをタスクに追加して、検証動作をスキップしてください。
    4. タスクが正常に完了したことを確認する。 クラスター環境では、デプロイメント・マネージャー、ノード・エージェント、および WebSphere_Portal サーバーを再始動します。 スタンドアロン環境では、server1 と WebSphere_Portal サーバーを再起動します。
  20. オプション: このステップは、実稼働環境で必須です。ファイルシステム・リポジトリーを使用しない場合は、削除します。 デフォルトのセキュリティー設定だった統合ファイルシステムのユーザー・リポジトリーは、ユーザー・リポジトリーの統合後は必要なくなる場合があります。ファイルシステム・リポジトリーが不要になった場合、そのリポジトリーを削除すると、複数のリポジトリーに存在する重複ユーザー ID が原因で起こる競合を避けるのに役立ちます。手順については、オペレーティング・システム別に編成されている『リポジトリーの削除』のトピックを参照してください。
IBM i スタンドアロン: データベース・ユーザー・レジストリーの追加

認証および許可のためのユーザー・アカウント情報を保管するためのデフォルトの統合リポジトリーに、データベース・ユーザー・レジストリーを追加します。 複数のデータベース・ユーザー・レジストリーをデフォルトの統合リポジトリーに追加できますが、一度に追加できるデータベース・ユーザー・レジストリーは 1 つのみです。

始める前に
単一サーバー環境では、以下のステップを実行するために WebSphere_Portal サーバーと server1 サーバーを開始したり停止したりする必要はありません。 クラスター環境では、以下のタスクを開始する前に、システム上で WebSphere_Portal を含むすべてのアプリケーション・サーバーを停止してから、ノード・エージェントおよびデプロイメント・マネージャー・サーバーを開始する必要があります。
このタスクについて
データベース・ユーザー・レジストリーをデフォルトの統合リポジトリーに追加するには、1 次ノードでのみ以下のステップを実行します。追加する計画のデータベース・ユーザー・レジストリーごとにこれらのステップを繰り返さなければなりません。
注: このタスクの実行時には、wp_profile_root/ConfigEngine/config/helpers ディレクトリー内にある wp_add_DB.properties ヘルパー・ファイルを使用して、正しいプロパティーが入力されていることを確認してください。以下の指示で、wkplc.properties ファイルがステップで参照されている場合は、wp_add_DB.properties ヘルパー・ファイルを使用します。
手順
  1. IBM DB2 for i データベースを作成するには、以下のステップを実行します。
    データベースのセットアップの手順: セットアップするデータベースのタイプに該当するドキュメンテーションを参照してください。
    データベース管理者への相談: 新規のデータベースをセットアップするタスクを実行するのは、一般にはデータベース管理者です。しかし、テストまたはデモンストレーションといった目的のためにスタンドアロンのデータベースを作成している場合には、以下の手順を参照してください。実稼働環境のデータベースを作成しようとしている場合は、以下の手順を続行する前にデータベース管理者に相談してください。
    1. リモート i セッションにログインする。
    2. strsql コマンドを入力してインタラクティブ SQL セッションを開始する。
    3. create schema database_name コマンドを入力する。ここで database_name は、データベースで使用する名前です。
  2. DbDriver パラメーターと DbLibrary パラメーターの値を指定する。
    1. 以下のディレクトリーにナビゲートする。 wp_profile_root/ConfigEngine/properties ディレクトリー。
    2. wkplc_dbtype.properties を見つけて、テキスト・エディターで開きます。
    3. 構成しているデータベースのタイプに関する適切な見出しを見つけて、以下のパラメーターの値を指定する。
      注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
      • db_type.DbDriver
      • db_type.DbLibrary
    4. wkplc_dbtype.properties を保管して閉じる。
  3. テキスト・エディターを使用して、wp_profile_root/ConfigEngine/properties ディレクトリーにある wkplc.properties ファイルを開く。
  4. wkplc.properties ファイルの VMM 統合データベース・プロパティー見出しの下に、以下の必須パラメーターの値を入力します。
    注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
    • federated.db.DataSourceName
    • federated.db.DbType
    • federated.db.DbUrl
    • federated.db.id
    • federated.db.baseDN
    • federated.db.DbUser
    • federated.db.DbPassword
    • federated.db.DbName
  5. com.ibm.SOAP.requestTimeout パラメーターの値を 1000 に変更する。
    1. 以下のディレクトリーにナビゲートする。wp_profile_root/properties
    2. soap.client.props を見つけて、テキスト・エディターで開きます。
    3. com.ibm.SOAP.requestTimeout パラメーターを見つけて、その値が 1000 より大きいことを確認します。
    4. soap.client.props を保管して閉じる。
  6. クラスター環境では以下のステップを実行します。
    1. ConfigEngine.sh wp-prep-vmm-db-secured-environment -DWasPassword=password -DDbDomain=federated.db -Ddb_type.DmgrDbLibrary=local path of the database jars on the Deployment Manager -DDmgrNodeName=dmgr_node_name タスクを wp_profile_root/ConfigEngine ディレクトリーから実行して、データベース jar へのアクセスに使用するローカル・デプロイメント・マネージャー WebSphere 変数を作成します。
      注: db_type.DmgrDbLibrarydb_type は、使用しているデータベースのタイプに設定する必要があります (db2_iseries など)。 デプロイメント・マネージャー上のデータベース jar のローカル・パスは、以下のいずれかのオプションを使用する必要があります。
      • IBM DB2 for i タイプ 2 ドライバー: /QIBM/ProdData/Java400/ext/db2_classes.jar
      • IBM DB2 for i タイプ 4 ドライバー: /QIBM/ProdData/HTTP/Public/jt400/lib/jt400.jar
    2. 以下のタスクを実行します。次のコマンドに、各ノード名をコンマ区切りリストとして含めます。
      タスクの実行: このタスクは、複数回実行する必要はありません。 このタスクは、クラスター内のいずれのノードからも実行できます。
      1. データベース・ユーザー・レジストリーを使用している場合、またはセルが前のバージョンからマイグレーションされている場合は、federated.db.DbType のプロパティー値を設定し、wkplc.properties ファイルのプロパティー拡張データベースを使用している場合は la.DbType のプロパティー値を設定します。
      2. 各ノードの wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-node-prep-vmm-db-secured-environment -DWasPassword=password -DDbDomain=federated.db -DVmmNodeName=node_name -Ddb_type.NodeDbLibrary=データベース jar のローカルの絶対パス タスクを実行し、VMM データベース jar にアクセスするために使用する変数を作成します。
        注: VmmNodeName は、同じデータベース・ドライバー・パスを共有している、セル内の 1 つ以上の WebSphere Portal Express ノード名です。db_type.NodeDbLibrarydb_type は、使用しているデータベースのタイプに設定する必要があります (db2 など)。
        • IBM DB2 for i タイプ 2 ドライバー: /QIBM/ProdData/Java400/ext/db2_classes.jar
        • IBM DB2 for i タイプ 4 ドライバー: /QIBM/ProdData/HTTP/Public/jt400/lib/jt400.jar
    3. 必要なサーバーをすべて停止して再始動し、変更を伝搬する。
  7. wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-create-db -DWasPassword=password タスクを実行して、データベース・ユーザー・レジストリーをデフォルトの統合リポジトリーに追加します。
    注: LDAP を使用していないユーザーは、認識機能を利用できず、ほかのユーザーがオンラインかどうかを知ることはできません。この状況は、WebSphere Portal Express をインストールしてから、そのユーザーが含まれていない統合 LDAP または統合データベースのユーザー・リポジトリーを使用可能にする場合に発生します。セルフケア・ポートレットを使用してサインアップしたユーザーも、認識機能を使用できません。
  8. 該当するサーバーを停止してから再始動し、変更を伝搬させます。 具体的な手順については、関連タスクの以下のリンクを参照してください。 『サーバー、デプロイメント・マネージャー、およびノード・エージェントの始動と停止
  9. 新規ユーザーとグループが保管されるユーザー・レジストリーを更新するには、以下のステップを実行します。
    注: 複数の LDAP ユーザー・レジストリーおよび (または) データベース・ユーザー・レジストリーを使用している場合は、新規ユーザーおよびグループの保管場所となるデフォルトのユーザー・レジストリーとして定義するユーザー・レジストリーのみにこのタスクを実行してください。
    重要: インストール中に、デフォルトのファイル・リポジトリーは、personAccountRdnProperties および groupRdnProperties パラメーターのデフォルト値を作成します。 デフォルト値を変更するには、このタスクを 2 回実行しなければなりません。1 回目でデフォルト値をクリアし、2 回目で新しい値を追加します。
    1. テキスト・エディターを使用して、wp_profile_root/ConfigEngine/properties ディレクトリーにある wkplc.properties ファイルを開く。
    2. wkplc.properties ファイルの VMM サポートのエンティティー・タイプ構成見出しの下に、以下の必須パラメーターの値を入力します。
      注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
      • personAccountParent
      • groupParent
      • personAccountRdnProperties
      • groupRdnProperties
    3. 変更内容を wkplc.properties ファイルに保管します。
    4. wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-set-entitytypes -DWasPassword=password タスクを実行して、古い属性を削除してから新しい属性を追加します。
    5. 必要なサーバーをすべて停止して再始動し、変更を伝搬する。
  10. オプション: wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-query-repository -DWasPassword=password タスクを実行して、構成済みリポジトリーの名前とタイプをリストします。
IBM i スタンドアロン: レルム・サポートの追加

レルムは、IBM WebSphere Portal Express 内で整合性のあるグループを形成する、1 つ以上のユーザー・レジストリーからのユーザーのグループです。レルムにより、さまざまな構成オプションでの、柔軟なユーザー管理を行うことができます。 レルムは、仮想ポータルにマップして、定義済みユーザーがその仮想ポータルにログインできるようにする必要があります。レルム・サポートを構成しているときに、LDAP ユーザー・レジストリーまたはデータベース・ユーザー・レジストリー、あるいはその両方に存在する基本項目ごとに以下の手順を実行して、複数のレルム・サポートを作成できます。

始める前に
レルム・サポートを構成する前に、単一レルムまたは複数レルムを作成するために使用するすべての LDAP ユーザー・レジストリーまたはデータベース・ユーザー・レジストリー (あるいはその両方) を、統合リポジトリーに追加しておく必要があります。 複数のレルムを作成しようとしている場合は、必要なすべての基本項目を LDAP ユーザー・レジストリーまたはデータベース・ユーザー・レジストリー (あるいはその両方) の内部に作成する必要があります。すべての基本項目名は、統合リポジトリー内では固有である必要があります。

単一サーバー環境では、以下のステップを実行するために WebSphere_Portal サーバーと server1 サーバーを開始したり停止したりする必要はありません。 クラスター環境では、以下のタスクを開始する前に、システム上で WebSphere_Portal を含むすべてのアプリケーション・サーバーを停止してから、ノード・エージェントおよびデプロイメント・マネージャー・サーバーを開始する必要があります。

このタスクについて
ユーザー・レジストリー・モデルにレルム・サポートを追加するには、以下のステップを実行します。
手順
  1. テキスト・エディターを使用して、wp_profile_root/ConfigEngine/properties ディレクトリーにある wkplc.properties ファイルを開く。
  2. 必須: wkplc.properties ファイルの VMM レルム構成見出しの下に、以下の必須パラメーターの値を入力します。
    注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
    • realmName
    • securityUse
    • delimiter
    • addBaseEntry
  3. 変更内容を wkplc.properties ファイルに保管します。
  4. wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-create-realm -DWasPassword=password タスクを実行して、新規レルムを仮想メンバー・マネージャー構成に追加します。
    重要: 複数のレルムを作成するには、統合リポジトリーに必須固有基本項目が含まれていることを確認してください。インストール済み環境の適切なサーバーを停止して再起動し、基本項目情報に従って wkplc.properties ファイルを更新して、wp-create-realm タスクを再実行します。 これらのステップを、すべてのレルムが作成されるまで繰り返してください。
  5. 該当するサーバーを停止してから再始動し、変更を伝搬させます。 具体的な手順については、関連タスクの以下のリンクを参照してください。 『サーバー、デプロイメント・マネージャー、およびノード・エージェントの始動と停止
  6. VMM レルム構成見出しの下にある wkplc.properties ファイルに以下の必須パラメーターの値を入力し、変更内容を保管します。
    注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
    • realmName
    • realm.personAccountParent
    • realm.groupParent
    • realm.orgContainerParent
  7. wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-modify-realm-defaultparents -DWasPassword=password タスクを実行して、エンティティー・タイプおよびレルムごとにデフォルトの親を更新します。
    重要: どの追加エンティティー・タイプおよびレルムに対しても、このタスクを実行する前に、インストール済み環境の適切なサーバーを停止して再起動します。
  8. 該当するサーバーを停止してから再始動し、変更を伝搬させます。 具体的な手順については、関連タスクの以下のリンクを参照してください。 『サーバー、デプロイメント・マネージャー、およびノード・エージェントの始動と停止
  9. オプション: 追加基本項目をレルム構成に追加するには、以下のステップを実行します。例えば、作成したばかりのレルムに追加する 2 つの追加基本項目 (基本項目 1 と基本項目 2) がある場合、基本項目 1 の情報を使用して wkplc.properties ファイルを更新してから、このタスクを実行します。 次に、基本項目 2 の情報を使用して同じプロパティー・ファイルを更新し、その後、このタスクを実行します。
    1. テキスト・エディターを使用して、wp_profile_root/ConfigEngine/properties ディレクトリーにある wkplc.properties ファイルを開く。
    2. wkplc.properties ファイルの VMM レルム構成見出しの下に、以下の必須パラメーターの値を入力します。
      注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
      • realmName
      • addBaseEntry
    3. 変更内容を wkplc.properties ファイルに保管します。
    4. wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-add-realm-baseentry -DWasPassword=password タスクを実行して、レルム構成にさらに LDAP 基本項目を追加します。
    5. 必要なサーバーをすべて停止して再始動し、変更を伝搬する。
  10. オプション: WebSphere Application Server および WebSphere Portal Express アドミニストレーター・ユーザー ID を置き換えるには、以下のステップを実行します。このステップは、デフォルト・レルムを変更する場合に必要になります。
    1. ユーザーおよびグループの管理ポートレットで新規ユーザーを作成して、現在の WebSphere Application Server 管理ユーザーを置き換える。
    2. ユーザーおよびグループの管理ポートレットで新規ユーザーを作成して、現在の WebSphere Portal Express 管理ユーザーを置き換える。
    3. ユーザーおよびグループの管理ポートレットで新規グループを作成して、現在のグループを置き換える。
    4. wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-change-was-admin-user -DWasPassword=password -DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid タスクを実行して、古い WebSphere Application Server 管理ユーザー ID とグループ ID を新規ユーザーとグループで置き換える。
      重要: newAdminId および newAdminGroupId パラメーターに完全識別名 (DN) を入力しなければなりません。
      停止したサーバーの追加パラメーター: このタスクでは、実行サーバー・インスタンスに照合してユーザーを検証します。サーバーが停止する場合は、-Dskip.ldap.validation=true パラメーターをタスクに追加して、検証動作をスキップしてください。
    5. タスクが正常に完了したことを確認する。 クラスター環境では、デプロイメント・マネージャー、ノード・エージェント、および WebSphere_Portal サーバーを再始動します。 スタンドアロン環境では、server1 と WebSphere_Portal サーバーを再起動します。
    6. ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=password -DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid タスクを実行して、古い WebSphere Portal Express 管理ユーザー ID とグループ ID を新規ユーザーとグループで置き換える。
      重要: newAdminId および newAdminGroupId パラメーターに完全識別名 (DN) を入力しなければなりません。
      停止したサーバーの追加パラメーター: このタスクでは、実行サーバー・インスタンスに照合してユーザーを検証します。サーバーが停止する場合は、-Dskip.ldap.validation=true パラメーターをタスクに追加して、検証動作をスキップしてください。
    7. タスクが正常に完了したことを確認する。 クラスター環境では、デプロイメント・マネージャー、ノード・エージェント、および WebSphere_Portal サーバーを再始動します。 スタンドアロン環境では、server1 と WebSphere_Portal サーバーを再起動します。
  11. オプション: 作成したレルムをデフォルト・レルムとして設定するには、以下のステップを実行します。
    要確認: デフォルト・レルム内に存在する基本エントリーで定義されているユーザーのみ、WebSphere Portal Express にログインできます。 ユーザーが WebSphere Portal Express にログインできないことが分かった場合は、そのユーザーを含む基本エントリーがデフォルト・レルム内に存在することを確認してください。 wp-query-realm-baseentry タスクを実行して、どの基本エントリーがデフォルト・レルムの一部か参照できます。デフォルト・レルムに基本エントリーがない場合は、wp-add-realm-baseentry タスクを実行して、デフォルト・レルムに基本エントリーを追加します。
    1. テキスト・エディターを使用して、wp_profile_root/ConfigEngine/properties ディレクトリーにある wkplc.properties ファイルを開く。
    2. defaultRealmName には、デフォルト・レルムとして使用する realmName プロパティー値を入力します。
    3. 変更内容を wkplc.properties ファイルに保管します。
    4. wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-default-realm -DWasPassword=password タスクを実行して、このレルムをデフォルト・レルムとして設定します。
    5. 必要なサーバーをすべて停止して再始動し、変更を伝搬する。
  12. オプション: レルムの基本項目のリストを照会するには、以下のステップを実行します。
    1. テキスト・エディターを使用して、wp_profile_root/ConfigEngine/properties ディレクトリーにある wkplc.properties ファイルを開く。
    2. realmName には、照会するレルムの名前を入力します。
    3. 変更内容を wkplc.properties ファイルに保管します。
    4. wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-query-realm-baseentry -DWasPassword=password タスクを実行して、特定のレルムの基本項目をリストします。
  13. オプション: 短縮名がそのレルムで固有ではない場合に完全識別名によるログインを使用可能にするには、以下のステップを実行します。
    1. テキスト・エディターを使用して、wp_profile_root/ConfigEngine/properties ディレクトリーにある wkplc.properties ファイルを開く。
    2. realmName に値を入力するか、ブランクのままにしてデフォルト・レルムを更新する。
    3. 変更内容を wkplc.properties ファイルに保管します。
    4. wp_profile_root/ConfigEngine ディレクトリーにある ConfigEngine.sh wp-modify-realm-enable-dn-login -DWasPassword=password タスクを実行して、識別名ログインを使用可能にする。
      注: このタスクを実行して完全識別名によるログインを使用可能にした後に、ConfigEngine.sh wp-modify-realm-disable-dn-login -DWasPassword=password タスクを実行してこの機能を使用不可にすることができます。
    5. 必要なサーバーをすべて停止して再始動し、変更を伝搬する。
IBM i スタンドアロン: 属性の構成の調整

IBM WebSphere Portal Express をインストールして LDAP ユーザー・レジストリーを構成した後には、構成された LDAP サーバーおよびビジネス要件に合うよう属性構成を調整する必要があります。しかし、初期状態のインストール済み環境に対して、データベース・ユーザー・レジストリーあるいはデフォルトの統合ファイル・ベース・リポジトリーのいずれかを使用している場合は、これらのステップを実行する必要はありません。

このタスクについて

インストールされると、IBM WebSphere Portal Express には各ユーザーおよびグループ用の属性が事前定義されています。 ご使用の LDAP サーバーには、異なる事前定義のユーザーおよびグループ属性が設定されている場合があります。 WebSphere Portal Express とご使用の LDAP サーバー間で正しく通信するできるように、各リポジトリーごとに、またはすべての構成リポジトリーに対して、追加の属性の構成、および既存の属性の必須または非サポートへのフラグ付けが可能です。

LDAP サーバーでは、そのスキーマで明示的に定義されている属性のみを処理できます。 LDAP サーバーのスキーマは WebSphere Portal Express スキーマと異なりますが、 この 2 つのスキーマは WebSphere Portal Express と LDAP サーバー間の正しい通信のために一致する必要があります。 LDAP ユーザー・レジストリーを追加するタスクでは、選択した LDAP サーバーのタイプに応じて基本的な属性を構成します。 ただし、LDAP のスキーマに合わせて WebSphere Portal Express 構成を調整する必要もあります。例えば、ある属性が WebSphere Portal Express に定義されていて LDAP サーバーにはない場合は、以下のいずれかのタスクを実行してこの不一致を解決する必要があります。
  • その属性を LDAP サーバーでは非サポートにフラグ付けする
  • 属性マッピングを導入して、WebSphere Portal Express 属性を LDAP スキーマに定義された属性にマッピングする
構成された LDAP サーバーおよびビジネス要件に合致するよう属性構成を調整するには、以下の手順を実行します。
IBM i スタンドアロン: 定義属性の照会

IBM WebSphere Portal Express をインストールしして LDAP ユーザー・レジストリーを構成した後に、定義済みの属性を照会して、どの属性が非サポートにフラグ付けされているかや、属性が別の LDAP 属性にマップされているかどうかを参照できます。

このタスクについて
wp_profile_root/ConfigEngine ディレクトリーから、タスク ConfigEngine.sh wp-query-attribute-config -DWasPassword=password を構成処理時またはランタイムにいつでも実行して、現在定義されている各属性の概要を照会します。このタスクでは、レポート availableAttributes.html を作成し、ディレクトリー wp_profile_root/ConfigEngine/log に配置します。 このレポートには、各ユーザー (PersonAccount) の使用可能な属性をリストした表、および各グループの使用可能な属性をリストした表が含まれています。 それぞれの構成済みリポジトリーごとに列があり、その属性が非サポートにフラグ付けされているかどうか、またはその属性が別の LDAP 属性にマップされているかどうかが示されます。
注: このタスクでは、LDAP スキーマでの属性の存在は検証しません。
IBM i スタンドアロン: 属性の追加

VMM はデフォルト属性スキーマを使用して構成されますが、このスキーマにはご使用の LDAP サーバーとの互換性がない場合があります。 このような場合は、IBM WebSphere Portal Express とユーザー・レジストリーの間にマップできる新規属性を追加して、VMM 属性スキーマを拡張してください。

このタスクについて
以下のステップを実行して、新規属性をユーザー・レジストリーに追加します。
手順
  1. 必要なエンタープライズ・アーカイブ (.ear) ファイルを WebSphere Application Server にインストールします。 以下のようにして、該当するタスクを選択して .ear ファイルをインストールします。
    表 33. 環境別の .ear ファイルをインストールするためのステップ
    環境 ステップ
    スタンドアロン環境 スタンドアロン環境で .ear ファイルをインストールするには、以下のステップを実行します。
    1. コマンド・プロンプトを開く。
    2. wp_profile_root/ConfigEngine ディレクトリーにナビゲートする。
    3. ConfigEngine.sh wp-la-install-ear -DWasPassword=password タスクを実行します。
    クラスター環境 クラスター環境で .ear ファイルをインストールするには、以下のステップを実行します。
    1. コマンド・プロンプトを開く。
    2. 1 次ノード上の wp_profile_root/ConfigEngine ディレクトリーにナビゲートする。
    3. ConfigEngine.sh wp-la-install-ear -DWasPassword=dmgr_password -DServerName=dmgr_server_name -DNodeName=node_name タスクを実行します。

    dmgr_server_name のデフォルト値は dmgr です。dmgr_server_name 値は、WebSphere Application Server 管理コンソール内の 「システム管理者」 > 「デプロイメント・マネージャー」 > 「構成」タブ > 「汎用プロパティー」 > 「名前」の下にあります。

    node_name はデプロイメント・マネージャーがあるノードの名前です。node_name 値は、WebSphere Application Server 管理コンソール内の 「システム管理者」 > 「デプロイメント・マネージャー」 > 「実行時間」タブ > 「汎用プロパティー」 > 「ノード名」の下にあります。

  2. 該当するサーバーを停止してから再始動し、変更を伝搬させます。 具体的な手順については、関連タスクの以下のリンクを参照してください。 『サーバー、デプロイメント・マネージャー、およびノード・エージェントの始動と停止
  3. テキスト・エディターを使用して、wp_profile_root/ConfigEngine/properties ディレクトリーにある wkplc.properties ファイルを開く。
  4. wkplc.properties ファイルの VMM プロパティー拡張プロパティー見出しの下に、以下の必須パラメーターの値を入力します。
    注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
    • la.providerURL
    • la.propertyName
    • la.entityTypes
    • la.dataType
    • la.multiValued
  5. 変更内容を wkplc.properties ファイルに保管します。
  6. ConfigEngine.sh wp-add-property -DWasPassword=password タスクを実行して、ユーザー・レジストリーに属性を追加します。
    注: このタスクは WebSphere Application Server への EJB 呼び出しを実行します。この呼び出しは、WebSphere Application Server に対して認証されている必要があります。 sas.client.props ファイル内の構成によっては、ポップアップ・ウィンドウが開いたり、コマンド行プロンプトでユーザー ID とパスワードを要求されることがあります。WebSphere Application Server のユーザー ID およびパスワードを入力します。
    要確認: 複数のプロパティーを追加する場合は、新規属性をすべて追加するまで wp-la-install-ear タスク以外のすべてのステップを繰り返します。
  7. 該当するサーバーを停止してから再始動し、変更を伝搬させます。 具体的な手順については、関連タスクの以下のリンクを参照してください。 『サーバー、デプロイメント・マネージャー、およびノード・エージェントの始動と停止
IBM i スタンドアロン: 属性のマッピング

LDAP ユーザー・レジストリーをインストールして構成し、定義済みの属性を照会した後に、構成済みの LDAP サーバーおよび業務上の必要と一致するように属性をマップできます。

このタスクについて
以下の手順を実行して、WebSphere Portal Express と LDAP サーバーの間で属性をマップします。LDAP サーバーが複数ある場合は、LDAP サーバーごとにこれらのステップを実行する必要があります。
手順
  1. テキスト・エディターを使用して、wp_profile_root/ConfigEngine/properties ディレクトリーにある wkplc.properties ファイルを開く。
  2. wkplc.properties ファイル内の以下の一連のパラメーターの 1 つに値を入力して、LDAP サーバーを識別します。
    注: LDAP サーバーの構成に使用した値と同じ値を使用していることを確認してください。
    表 34. wkplc.properties ファイル内の LDAP サーバーの識別
    リポジトリー・タイプ パラメーター
    スタンドアロン 以下のパラメーターは、LDAP 属性構成見出しの下にあります。
    注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
    • standalone.ldap.id
    • standalone.ldap.host
    • standalone.ldap.port
    • standalone.ldap.sslEnabled
    • standalone.ldap.bindDN
    • standalone.ldap.bindPassword
    • standalone.ldap.baseDN
    統合 以下のパラメーターは、VMM 統合リポジトリー・プロパティー見出しの下にあります。
    注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
    • federated.ldap.id
    • federated.ldap.host
    • federated.ldap.port
    • federated.ldap.sslEnabled
    • federated.ldap.bindDN
    • federated.ldap.bindPassword
    • federated.ldap.baseDN
  3. 以下のいずれかのタスクを実行して、定義済みのすべての属性が構成済みの LDAP ユーザー・レジストリーで使用可能であることを確認します。
    表 35. 定義済みのすべての属性が構成済みの LDAP ユーザー・レジストリーで使用可能であることを確認するためのタスク
    リポジトリー・タイプ タスク
    スタンドアロン wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-validate-standalone-ldap-attribute-config -DWasPassword=password タスク。
    統合 wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-validate-federated-ldap-attribute-config -DWasPassword=password タスク。
  4. wp_profile_root¥ConfigEngine¥log ディレクトリーにある ConfigTrace.log ファイルを開き、PersonAccount および Group エンティティー・タイプについて、以下の出力を確認します。
    以下の属性は、WebSphere Portal Express には定義されていますが、LDAP サーバーには定義されていません。
    このリストには、WebSphere Portal Express で定義されているが、 LDAP では使用不可である属性がすべて含まれています。WebSphere Portal Express で使用する予定のない属性には、非サポートとしてフラグを立てます。使用する予定の属性を LDAP に存在する属性にマップします。他に、uidcnfirstNamesnpreferredLanguage、および ibm-primaryEmail 属性もリストに含まれている場合はマップする必要があります。
    以下の属性は LDAP サーバーでは必須のフラグが立てられていますが、WebSphere Portal Express では立てられていません。
    このリストには、LDAP サーバーで「MUST」と定義されているが、WebSphere Portal Express で必須とは定義されていない属性がすべて含まれています。必要に応じ、WebSphere Portal Express 内でこれらの属性にフラグを立ててください。属性に非サポートまたは必須のフラグを立てることについては、以下のステップを参照してください。
    以下の属性のタイプは、WebSphere Portal Express と LDAP サーバーとで異なります。
    このリストには、WebSphere Portal Express 内のデータ型と LDAP サーバー内のデータ型が一致しないために、WebSphere Portal Express が無視する可能性がある属性すべてが含まれています。
  5. テキスト・エディターを使用して、wp_profile_root/ConfigEngine/properties ディレクトリーにある wkplc.properties ファイルを開く。
  6. wkplc.properties ファイル内の以下の一連のパラメーターの 1 つに値を入力して、config トレース・ファイルで見つかった問題を訂正します。
    表 36. config トレース・ファイルで見つかった問題を訂正するために wkplc.properties ファイルに定義するパラメーター
    リポジトリー・タイプ パラメーター
    スタンドアロン 以下のパラメーターは、LDAP 属性構成見出しの下にあります。
    注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
    • standalone.ldap.id
    • standalone.ldap.attributes.nonSupported
    • standalone.ldap.attributes.nonSupported.delete
    • standalone.ldap.attributes.mapping.ldapName
    • standalone.ldap.attributes.mapping.portalName
    • standalone.ldap.attributes.mapping.entityTypes
    例えば、以下の値では、certificate および members に非サポート属性のフラグを立て、PersonAccountGroup の両方の entityTypes の場合に、ibm-primaryEmailmail にマップし、ibm-jobTitletitle にマップします。
    standalone.ldap.attributes.nonSupported=certificate, members
    standalone.ldap.attributes.nonSupported.delete=
    
    standalone.ldap.attributes.mapping.ldapName=mail, title
    standalone.ldap.attributes.mapping.portalName=ibm-primaryEmail, ibm-jobTitle
    standalone.ldap.attributes.mapping.entityTypes=PersonAccount, Group
    統合 以下のパラメーターは、VMM 統合リポジトリー・プロパティー見出しの下にあります。
    注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
    • federated.ldap.attributes.nonSupported
    • federated.ldap.attributes.nonSupported.delete
    • federated.ldap.attributes.mapping.ldapName
    • federated.ldap.attributes.mapping.portalName
    • federated.ldap.attributes.mapping.entityTypes
    例えば、以下の値では、certificate および members に非サポート属性のフラグを立て、PersonAccountGroup の両方の entityTypes の場合に、ibm-primaryEmailmail にマップし、ibm-jobTitletitle にマップします。
    federated.ldap.attributes.nonSupported=certificate, members
    federated.ldap.attributes.nonSupported.delete=
    
    federated.ldap.attributes.mapping.ldapName=mail, title
    federated.ldap.attributes.mapping.portalName=ibm-primaryEmail, ibm-jobTitle
    federated.ldap.attributes.mapping.entityTypes=PersonAccount, Group
  7. 変更内容を wkplc.properties ファイルに保管します。
  8. 以下のいずれかのタスクを実行して、非サポート属性のリスト、およびWebSphere Portal Express と LDAP ユーザー・レジストリーの間の適切なマッピングで LDAP ユーザー・レジストリー構成を更新します。
    表 37. 非サポート属性のリスト、および Portal と LDAP ユーザー・レジストリーの間の適切なマッピングによって、LDAP ユーザー・レジストリー構成を更新するためのタスク
    リポジトリー・タイプ タスク
    スタンドアロン wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-update-standalone-ldap-attribute-config -DWasPassword=password タスク
    統合 wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-update-federated-ldap-attribute-config -DWasPassword=password タスク
  9. 該当するサーバーを停止してから再始動し、変更を伝搬させます。 具体的な手順については、関連タスクの以下のリンクを参照してください。 『サーバー、デプロイメント・マネージャー、およびノード・エージェントの始動と停止
  10. オプション: 指定された LDAP に対してだけでなく、WebSphere Portal Express 環境全体で属性に非サポートまたは必須のフラグを立てるには、以下のステップを実行します。
    1. wkplc.properties ファイルに、以下の必須パラメーターの値を入力します。
      注: 必須パラメーターと詳細設定パラメーターについての具体的な情報は、プロパティー・ファイルを参照してください。
      • user.attributes.required
      • user.attributes.nonsupported
    2. 変更内容を wkplc.properties ファイルに保管します。
    3. wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-update-attribute-config -DWasPassword=password タスクを実行します。
    4. 必要なサーバーをすべて停止して再始動し、変更を伝搬する。
IBM i スタンドアロン: 属性の除去

Virtual Member Manager (VMM) の制限のため、現時点では属性を更新するタスクはありません。そのため、プロパティー拡張データベースに属性を追加した場合や、間違ってスペルされた属性を LDAP サーバーと照合して調整する際、あるいはマイグレーションのために属性が既に追加されている場合に、データベースから属性を削除する必要があります。これらのステップを実行する際には注意してください。

このタスクについて
属性をデータベースから除去するには、以下のステップを実行します。
重要: データベースの不整合が発生する可能性があるので、既にユーザー値を追加した属性を除去しないでください。
クラスターに関する注意事項: クラスター環境では、デプロイメント・マネージャー上で以下のステップを実行してから、ノードを再同期してください。
手順
  1. データベースの編集に使用するツールを開く。
  2. LAPROP 表内で属性名が使用可能か検証する。
  3. LAPROP 表から必須属性を削除する。
  4. wp_profile_root/config/cells/cellname/wim/model ディレクトリーにある wimxmlextension.xml ファイルを開く。
  5. LAPROP 表から削除した属性に関する propertySchema 定義を見つけて削除する。例えば、
        <wim:propertySchema nsURI="http://www.ibm.com/websphere/wim" dataType="String"
            multiValued="true" propertyName="attribute_name">
          <wim:applicableEntityTypeNames>PersonAccount</wim:applicableEntityTypeNames>
        </wim:propertySchema>
  6. 変更内容を wimxmlextension.xml ファイルに保存する。
  7. wp_profile_root/config/cells/cellname/wim/config ディレクトリーにある wimconfig.xml ファイルを開く。
  8. LAPROP 表から削除した属性に関する propertiesNotSupported 定義を見つけて削除する。例えば、
    <config:propertiesNotSupported name="attribute_name">
  9. 変更内容を wimconfig.xml ファイルに保存する。
  10. wp_profile_root/bin ディレクトリーから、server1 および WebSphere_Portal サーバーをいったん停止してから再起動する。
IBM i スタンドアロン: 動的グループを使用するための WebSphere Portal の構成

デフォルトでは、WebSphere Portal Express は静的グループに対して使用可能です。しかし、Virtual Member Manager (VMM) によってユーザーは静的グループまたは動的グループのいずれかのメンバーとなることが可能になります。静的グループとは、グループとそのメンバーの間に永続バインディングが存在するグループです。 動的グループとは、グループのメンバーを取得するための検索照会が定義されているグループのことです。動的グループを使用するように LDAP サーバーを構成した場合、WebSphere Portal Express に対してこのタスクのステップを完了し、LDAP サーバーを設定する際に動的グループ照会を使用できるようにしてください。

始める前に
スタンドアロン・サーバーまたは統合 LDAP サーバーのいずれかに対してセキュリティーを構成するために必要なタスクを実行する。
このタスクについて

このタスクのステップは動的グループに対するオブジェクト・クラスとして groupOfURLs を、動的メンバーシップ属性として memberURL を使用します。オブジェクト・クラスおよび動的メンバーシップ属性の実際の値は LDAP サーバーに依存して変化します。この理由により、オブジェクト・クラスおよび動的メンバーシップ属性を検証するには、LDIF ファイルをエクスポートする必要があります。LDIF ファイルをエクスポートする手順については、LDAP のドキュメンテーションを参照するか、LDAP 管理者にお尋ねください。

クラスター環境: Deployment Manager で以下のステップを実行してから、ノードを同期してください。

WebSphere Portal Express を構成して動的グループを使用するには、以下のようにします。

手順
  1. LDAP サーバー環境に応じて、適切なステップのセットを選択します。
    表 38. 動的グループを使用可能にするためのステップ
    LDAP サーバー環境 実行するためのステップ
    スタンドアロン LDAP サーバーまたは統合 LDAP サーバー
    1. 以下のディレクトリーにナビゲートする。wp_profile_root/cells/cell_name/wim/config
    2. wimconfig.xml を見つけて、テキスト・エディターで開きます。
    3. <config:groupConfiguration> タグに以下の行を追加します。
      <config:dynamicMemberAttributes name="memberurl" objectClass="groupofurls"/>
    4. wimconfig.xml を保管して閉じる。
    統合 LDAP サーバー
    1. 管理コンソールにログインする。
    2. 「セキュリティー」 > 「管理、アプリケーション、およびインフラストラクチャーの保護」を選択する。
    3. 「使用可能なレルム定義 (Available realm definitions)」で、「統合リポジトリー (Federated repositories)」を選択して、「構成」をクリックします。
    4. 「関連項目」で、「リポジトリーの管理 (Manage repositories)」をクリックします。
    5. リストから適切なリポジトリーを選択します。
    6. 「追加プロパティー」で、「グループ属性の定義 (Group attribute definition)」をクリックしてから、「動的メンバー属性 (Dynamic member attributes)」をクリックします。
    7. 「新規」をクリックして、「名前」フィールドおよび「オブジェクト・クラス (Object class)」フィールドに対する適切な値を指定します。以下に例を示します。
      • 名前: memberurl
      • オブジェクト・クラス: groupofurls
    8. 「OK」をクリックして、マスター構成に変更内容を保管する。
  2. 該当するサーバーを停止してから再始動し、変更を伝搬させます。 具体的な手順については、関連タスクの以下のリンクを参照してください。 『サーバー、デプロイメント・マネージャー、およびノード・エージェントの始動と停止
IBM スタンドアロン: LDAP ユーザー・レジストリー用の参照の使用可能化

参照とは、オブジェクトが存在しないか、特定のディレクトリー・ツリー内に見つけることができないときに、オブジェクト要求をある LDAP サーバーから別のサーバーへリダイレクトすることです。複数のユーザー・レジストリー・サーバーあるいはドメイン上に複数のユーザー・レジストリーが存在しているという環境の場合は、参照を使用可能にする必要があります。

このタスクについて
LDAP 参照を使用するようにポータルを構成するには、以下のようにします。
手順
  1. 任意のテキスト・エディターを使用して、以下のディレクトリーにある wkplc.properties ファイルを開きます: wp_profile_root/ConfigEngine/properties
  2. 以下のパラメーターの値を指定します。
    • et.ldap.id=ID_of_your_LDAP_server
    • et.ldap.host=hostname_of_your_LDAP_server
    • et.ldap.referral=follow
  3. wkplc.properties を保管して閉じる。
  4. wp_profile_root/ConfigEngine ディレクトリーから以下のタスクを実行し、LDAP エンティティー・タイプを作成します。
    • Linux: ./ConfigEngine.sh wp-update-et-ldap -DWasPassword=password
    • Windows: ConfigEngine.bat wp-update-et-ldap -DWasPassword=password
    • IBM i: ConfigEngine.sh wp-update-et-ldap -DWasPassword=password
  5. 該当するサーバーを停止してから再始動し、変更を伝搬させます。 具体的な手順については、関連タスクの以下のリンクを参照してください。 『サーバー、デプロイメント・マネージャー、およびノード・エージェントの始動と停止

IBM i スタンドアロン: サーバーの調整

サーバーの調整は、WebSphere Portal 環境のパフォーマンスにとって重要です。すぐに使用可能な実稼働環境用には WebSphere Portal を調整しないので、確実にパフォーマンスを最適にするには、「IBM WebSphere Portal Tuning Guide」のステップを検討してすべて行ってください。現行リリースの WebSphere Portal に関するチューニング・ガイドを入手できない場合でも、旧バージョンの製品に関するチューニング・ガイドを使用する必要があります。

このタスクについて
WebSphere Portal 環境の調整には、この環境のさまざまなシステムとコンポーネントの調整と構成が含まれます。チューニング・ガイドには、一般概念が記載されており、特定の構成に関する指示が詳述されています。以下に関する指示が含まれています。
  • アプリケーション・サーバーと、アプリケーション・サーバーに関する定義済みのリソースの構成
  • 環境を拡張するためのクローン作成戦略の判別
  • データベースとデータベース・サーバーの調整
  • ディレクトリー・サーバーとそのデータベースの調整
  • Web サーバーの調整
  • オペレーティング・システムとネットワークの調整
  • WebSphere Portal サービスの調整

IBM i でのアイドル・スタンバイ・クラスターのセットアップ

フェイルオーバーの目的で、アイドル・スタンバイ構成として IBM WebSphere Portal Express 環境をセットアップします。 アイドル・スタンバイ・クラスター・サーバーは、ユーザー・トランザクションへのサービス提供やワークロードの照会に関しては運用されません。 アイドル・スタンバイ・クラスター・サーバーは、1 次ノードで障害が起きた場合にのみアクティブになります。

このタスクについて

アイドル・スタンバイ・クラスター環境をセットアップするには、以下のタスクを実行します:

IBM i での前提条件および相互前提条件のソフトウェアの準備

高可用性実稼働環境を作成する前に、データベース、ユーザー・レジストリー、デプロイメント・マネージャー、およびリモート Web サーバーを作成する必要があります。

このタスクについて
前提条件ソフトウェアおよび相互に必要なソフトウェアを準備するには、以下のタスクを実行します。
IBM i アイドル・スタンバイ: IBM i オペレーティング・システムの準備

IBM WebSphere Portal Express 用のオペレーティング・システムのセットアップに関する情報を示します。 他のコンポーネントを使用する場合は、追加のステップが必要になる場合があります。 詳しくは、インストールする特定のコンポーネントの製品資料を参照してください。

このタスクについて

WebSphere Portal Express のインストールは、Windows ワークステーションを使用してローカルまたはリモートで行うことができます。

リモートにインストールするには、以下の情報が必要です。
  • Microsoft® Windows® のサポートされているバージョン
  • マシンの CD-ROM ドライブ
  • WebSphere Portal Express をインストールする IBM i システムへの TCP/IP 接続
  • IBM i サーバーが制限なしの状態になっていること
  • IBM i システムの有効なユーザー ID とパスワード
  • WebSphere Portal Express のインストールと構成を行うためのユーザー・タイプ (ユーザー・クラス) *SECOFR (QSECOFR 以外) のユーザー・プロファイル
ローカルにインストールするには、以下の情報が必要です。
  • IBM i の CD-ROM ドライブ
  • IBM i サーバーが制限なしの状態になっていること
  • IBM i の有効なユーザー ID とパスワード
  • WebSphere Portal Express のインストールと構成を行うためのユーザー・タイプ (ユーザー・クラス) *SECOFR (QSECOFR 以外) のユーザー・プロファイル
IBM i アイドル・スタンバイ: WebSphere Application Server デプロイメント・マネージャーの準備

IBM WebSphere Portal Express は、IBM WebSphere Application Server Network Deployment および必要なすべての保守パッケージを含む、カスタマイズ済みインストール・パッケージ (CIP) を提供します。 付属のディスクを使用して、WebSphere Application Server Network Deployment を専用システムにインストールします。

このタスクについて
アイドル・スタンバイ・クラスター環境で WebSphere Application Server デプロイメント・マネージャーを準備するには、以下の手順を実行します:
手順
  1. WebSphere Application Server Network Deployment をインストールするか、CIP を使用して既存のインストールをアップグレードします。cd_root/ISERIES/architecture/ifpackage/WAS/install (ここで、cd_root はディスクのルート・ディレクトリーで、architecture はシステムのプロセッサー・アーキテクチャーです) コマンドを実行します。
  2. manageprofile コマンドを使用して、デプロイメント・マネージャー・プロファイルを作成します。プロファイルの概念を参照してください。
    制約事項: インフォメーション・センターで記述されているバックアップおよびリストア・タスクを使用する計画の場合は、デプロイメント・マネージャー・プロファイルのデフォルト・プロファイル・パスを使用しなければなりません。使用しないと、バックアップおよびリストア・タスクでプロファイルを見つけることができません。
  3. 以下のコマンドを実行して、デプロイメント・マネージャーを開始します。startManager (dmgr_profile_root¥bin ディレクトリーにあります)
  4. 以下の URL を使用して、Network Deployment 管理コンソールを起動します。http://dmgr_hostname:9060/ibm/console (ここで、dmgr_hostname は、WebSphere Application Server Network Deployment
  5. デプロイメント・マネージャー管理コンソールにログインする。
  6. デプロイメント・マネージャーの HTTP 接続タイムアウト値を大きくします。
    1. 「システム管理」 > 「デプロイメント・マネージャー」 > 「Web コンテナー・トランスポート・チェーン」とクリックします。
    2. タイムアウト値を大きくします。 Web コンテナー・トランスポート・チェーン・セクションにリストされている WCInboundAdmin 項目と WCInboundAdminSecure 項目で、以下のステップを実行してタイムアウト値を大きくします。
      1. 「HTTP インバウンド・チャネル」をクリックします。
      2. 読み取りタイムアウト値を 180 に変更します。
      3. 書き込みタイムアウト値を 180 に変更します。
      4. 構成変更を保管します。
  7. Java Management Extensions (JMX) コネクターのタイムアウト要求期間を変更する。
    1. 「システム管理」 > 「デプロイメント・マネージャー」 > 「管理サービス」 > 「JMX コネクター」 > 「SOAPConnector」 > 「カスタム・プロパティー」とクリックする。
    2. requestTimeout プロパティーを選択して、値を 600 から 6000 に増やす。
    3. 構成変更を保管します。
  8. デプロイメント・マネージャーが使用する最大 Java ヒープ・サイズを更新するには、以下を行います。
    1. 「システム管理」 > 「デプロイメント・マネージャー」 > 「Java およびプロセス管理」 > 「プロセス定義」 > 「Java 仮想マシン」とクリックします。
    2. 「最大ヒープ・サイズ」フィールドの値を更新する。 適切なヒープ・サイズについて詳しくは、WebSphere Portal ExpressWeb Content Management Product Documentation ページにあるパフォーマンス・ガイド中のご使用のオペレーティング・システムに関する資料を参照してください。
    3. 「OK」をクリックして、変更を保存する。
  9. 「セキュリティー」 > 「グローバル・セキュリティー」をクリックし、「アプリケーション・セキュリティーの使用可能化」を選択します。 次に、構成変更を保管します。
    注: デプロイメント・マネージャーでセキュリティーが使用可能になっていない場合は、このステップを実行する前にセキュリティーの使用可能化を参照してください。
  10. WebSphere Portal Express 管理ユーザーと管理グループが、デプロイメント・マネージャー・セルのユーザー・レジストリーに存在していることを確認する。管理ユーザーおよびグループを作成する必要がある場合は、以下の手順を実行します。
    重要: ユーザー・レジストリーに関する統合リポジトリーを使用する計画の場合や、ノード上のアドミニストレーター ID がデプロイメント・マネージャー上のアドミニストレーター ID (識別名 (DN)) と一致しない場合は、これらのステップは必須です。
    1. 「ユーザーおよびグループ」 > 「ユーザーの管理」をクリックする。
    2. 「作成」をクリックする。
    3. WebSphere Portal Express 管理ユーザーの情報 (例えば、wpsadminwpsbind) を入力し、「作成」をクリックする。
    4. 「ユーザーおよびグループ」 > 「グループの管理」をクリックする。
    5. 「作成」をクリックする。
    6. WebSphere Portal Express 管理グループの名前 (例えば wpsadmins) を入力し、「作成」をクリックする。
    7. 作成したばかりのグループ (wpsadmins など) をクリックする。
    8. 「メンバー (Members)」タブをクリックする。
    9. 「ユーザーの追加 (Add Users)」をクリックする。
    10. ユーザーを検索する。
    11. グループに追加するユーザーを選択する。
    12. 「追加」をクリックして、グループにユーザーを追加する。
    13. グループにユーザーを追加し終えたら、「閉じる」をクリックする。
    14. 管理コンソールからログアウトする。
  11. Simple Object Access Protocol (SOAP) クライアントのタイムアウト要求期間を変更する。 Dmgr_profile¥properties ディレクトリーの中にある soap.client.props ファイルを編集します。

    該当の行を com.ibm.SOAP.requestTimeout=6000 に変更してください。

  12. 以下のタスクを実行して、デプロイメント・マネージャーを停止し、再始動します。
    1. stopManager -username admin_userid -password admin_password (dmgr_profile_root¥bin ディレクトリーにあります)
    2. startManager (dmgr_profile_root¥bin ディレクトリーにあります)

IBM i アイドル・スタンバイ: WebSphere Portal Express のインストール

IBM WebSphere Portal Express は、情報を保管するための統合データベースを完備した、単一のコンポーネントとしてインストールされます。したがって、WebSphere Portal Express を素早く稼働状態にし、PoC (概念検証) フェーズに入り、すぐに作成と処理を開始することができます。また、ご使用の環境を拡張して、アイドル・スタンバイ、管理が容易で分散処理の負荷が軽いリモート・データベース、および LDAP ベースの認証を組み込むこともできます。

始める前に
使用しているオペレーティング・システムに関する WebSphere Portal Express の詳細なシステム要件を検討し、WebSphere Portal Express をインストールする前に、すべてのハードウェアおよびソフトウェアが最小の製品レベルを満たしていることを確認してください。 インストール方法およびソースを検討します。
このタスクについて
WebSphere Portal Express をインストールするには、以下のステップを実行します。
手順
  1. コマンド行で ping yourserver.yourcompany.com と入力し、完全修飾ホスト名が適切に構成されていることを確認してください。
  2. コマンド行で ping localhost と入力し、ネットワークが適切に構成されていることを確認してください。
  3. WebSphere Portal Express をインストールするサーバーに、固定 IP アドレスをセットアップしてください。
  4. WebSphere Portal Express のインストールに使用するインストール方法に基づいて、以下のいずれかのインストール・コマンドを選択します。詳しくは、『インストール方法』を参照してください。
    拡張インストール・パラメーター: インストールをカスタマイズするには、インストール・コマンドにさまざまなパラメーターを追加できます。例えば、ポート情報を指定できます。詳しくは、この文書の最後にある関連参照の『拡張インストール・パラメーター』を参照してください。
    制約事項: インストール・パスの定義時にサポートされる文字は、ASCII 文字 [A から Z および a から z]、数値 [0 から 9]、スラッシュ [オペレーティング・システムに応じて / または ¥]、およびダッシュ [-] のみです。
    表 39. インストール・タスク・オプション
    インストール・タイプ タスク
    グラフィカル・ユーザー・インターフェース install400.bat (PortalExpress サブディレクトリーにあります)
    オプション属性: WebSphere Application Server のプロファイルと構成は J9 32 ビット JVM を使用して実行されます。 これを使用すると、より高速のインストールが可能になりますが、ランタイム・パフォーマンスは低下します。 パフォーマンスを向上させるには、インストール・コマンドに -W enableClassicJVM.active=false 属性を追加し、Classic 64 ビット JVM を使用してインストールしてください。
    コンソール・モード (リモート) install400.bat -console
    コンソール・モード (ローカル) install.sh
    オプション属性: WebSphere Application Server のプロファイルと構成は J9 32 ビット JVM を使用して実行されます。 これを使用すると、より高速のインストールが可能になりますが、ランタイム・パフォーマンスは低下します。 パフォーマンスを向上させるには、インストール・コマンドに -W enableClassicJVM.active=false 属性を追加し、Classic 64 ビット JVM を使用してインストールしてください。
    サイレント・インストール (リモート) install400.bat -options "path_to_file¥response_filename" (PortalExpress サブディレクトリーにあります) (ここで、path_to_file は応答ファイルへの絶対パス、response_filename はファイルの名前です)。 サンプルのインストール応答ファイル (installresponse.txt) と サンプルのアンインストール応答ファイル (uninstallresponse.txt) は、 セットアップ CD のルート・ディレクトリーにあります。
    重要: 応答ファイルのパスにスペースが含まれないようにしてください。 また、そのファイル名の中にスペースを含めないようにしてください。
    サイレント・インストール (ローカル) install.sh -options "path_to_file/response_filename" (PortalExpress サブディレクトリーにあります) (ここで、path_to_file は応答ファイルへの絶対パス、response_filename はファイルの名前です)。 サンプルのインストール応答ファイル (installresponse.txt) と サンプルのアンインストール応答ファイル (uninstallresponse.txt) は、 セットアップ CD のルート・ディレクトリーにあります。
    重要: 応答ファイルのパスにスペースが含まれないようにしてください。 また、そのファイル名の中にスペースを含めないようにしてください。
  5. インストールが成功したことを確認する。 http://yourserver:yourport/wps/portal フォーマットを使用して WebSphere Portal Express にアクセスする。 wp_profile_root/ConfigEngine ディレクトリーから以下のいずれかのタスクを実行して、server1_PortMatrix.txt ファイルと WebSphere_Portal_PortMatrix.txt ファイルを生成します。
    注: ポート・ファイルは wp_profile_root/ConfigEngine/log/ ディレクトリーにあり、このファイルには、インストールの対象となる WebSphere Application Server (server1) と WebSphere Portal Express (WebSphere_Portal) のポートがリストされています。
    • ConfigEngine.sh list-server-ports -DWasPassword=password
    • ConfigEngine.sh list-server-ports-by-name -DServerName=server1 -DWasPassword=password
    • ConfigEngine.sh list-server-ports-by-name -DServerName=WebSphere_Portal -DWasPassword=password
  6. 以下のステップを実行して、データベースに JMS リソースを作成する。
    1. wp_profile_root¥ConfigEngine ディレクトリーから ConfigEngine.sh create-jcr-jms-resources-post-dbxfer -DWasPassword=password タスクを実行する。
    2. WebSphere_Portal サーバーを再起動する。
次のタスク
WebSphere Portal Expressi バージョン 6.1 システムにインストールした場合は、MF45016 フィックスをインストールします。このフィックスを入手するには、Fix Central を参照してください。
WebSphere Application Server の管理コンソールで、WP_CacheManagerService リソース環境プロバイダーの下の以下の 2 つのキャッシュ・プロパティーを設定します。詳しくは サービス構成プロパティーの設定を参照してください。
  • cacheglobal.softref=true
  • cacheglobal.lifetime=1200

WebSphere Application Server サーバーを開始する前に、ソフトウェア・ライセンス契約を構成して、ライセンス証書 (POE) または送り状から使用制限を設定する必要があります。詳しくは、ソフトウェア・ライセンス情報の構成を参照してください。

IBM i アイドル・スタンバイ: DB2 for i の準備

リモート IBM DB2 for i データベースをセットアップするには、リモート・サーバー上でユーザー ID およびデータベースを作成します。 ユーザー ID およびデータベースの作成に役立つタスクが提供されています。 そのタスクを使用する前に、プロパティー・ファイルを変更する必要があります。

IBM i アイドル・スタンバイ: DB2 for i データベース作成の準備

ここでは、WebSphere Portal で必要なデータベースを 作成する前の必須の準備作業について説明します。

手順
  1. データベース名およびスキーマを作成する前のデータベース・ドメイン・プロパティー値の準備。データベース・スキーマを手動で構成する前に、まずデータベース・ドメイン・プロパティー・ファイルを編集する必要があります。
    1. 次のファイルを見つけ、それぞれのバックアップ・コピーを作成してから、値の変更を行う。
    2. WebSphere Portal Express データベースを使用して、Personalization (Feedback)、LikeMinds などのアプリケーションの情報を格納できます。 データベースでそれらのアプリケーション情報を格納する準備として、release.DbName などのプロパティー値に同じような命名規則を使用してください。 いくつかの例を示します。
      • release.DbName=hostname/WP70REL
      • community.DbName=hostname/WP70COM
      • customization.DbName=hostname/WP70CUS
      • jcr.DbName=hostname/WP70JCR
      • feedback.DbName=hostname/WP70FBK
      • likeminds.DbName=hostname/WP70LKM
      スキーマを作成する際は、 IBM i システムで以下のスキーマ命名規則を使用する必要があります。
      注: この製品のデフォルトのスキーマ名を使用できます。
      • 長さは 10 文字を超えてはならない
      • すべての英数字を使用可能 (「A」-「Z」および「1」-「0」)
      • 以下の文字は無効です。
        • スペース
        • ヌル値
        • アスタリスク (*)
        • 引用符 (")
        • コロン (:)
        • より大記号 (>)
        • より小記号 (<)
        • 垂直バー (|)
        • 正符号 (+)
        • セミコロン (;)
        • 単一引用符 (')
        • 疑問符 (?)
        注:
        • 有効なスキーマ名がわかっていることを確認し、ローカル・システムまたはリモート・システムに既に存在するスキーマ名は使用しないでください。 制限が適用されるため、有効なスキーマ名を定義するために、ターゲット・データベース管理システムの資料を参照してください。 WebSphere Portal Express 作成ウィザードは、スキーマ名を自動的に検査します。
        • データベースおよびスキーマの命名規則の詳細については、System i5 インフォメーション・センターで、DB2 Universal Database for System i5 のコンテンツを参照してください。
      • 以下のサブステップで指定される設定値以外は、変更しないでください。
      • リモート・データベースを使用している場合は、 必ずリモート・サーバーに対応した値を入力してください。
      • i では、¥ ではなく / を使用します。
      • 以下にイタリックで表示されている値は、特定の環境に対して変更が必要な場合があります。
      • パスワードに関する考慮事項: セキュリティー上の理由により、wkplc.propertieswkplc_dbdomain.propertieswkplc_dbtype.properties の各ファイルにパスワードを保管しないでください。構成タスクの実行前に各プロパティー・ファイルを編集して、そのタスクに必要なパスワードを挿入することをお勧めします。タスクの実行後に、各ファイルからパスワードをすべて削除する必要があります。
      • 以下に示すプロパティーの他に、追加のデータベース・プロパティーがある場合があります。 この表内のプロパティーのみ変更してください。他のプロパティーはすべてスキップしてください。
      • どのデータベース・ドメインを構成する必要があるかに応じて、変数 dbdomain を以下の値に置き換える必要があります。
        • release
        • customization
        • community
        • jcr
        • feedback
        • likeminds
    3. テキスト・エディターを使用してプロパティー・ファイルを開き、それぞれの環境に適した値を入力する。また、5250 セッションで OS/400 コマンド行に 以下を入力して、System i5 システムで 各プロパティー・ファイルをローカルに変更することもできます。
      注: このステップは、WebSphere Portal ExpressIBM i 上にインストールされていて、IBM DB2 for i に転送する場合にのみ適用されます。
      EDTF 'wp_profile_root/ConfigEngine/properties/property filename.properties'

      ここで、property filenamewkplc_dbdomainwkplc、または wkplc_dbtype のいずれかです。

      注: プロパティー・ファイルを編集するには、 IBM i サーバーにユーザー・プロファイルを持ち、少なくとも *USE 特殊権限を持っていなければなりません。
      ヒント: 『サポートされる別のデータベースにデータを転送するステップ』セクションでは、データを手動で転送する方法について説明しています。以下のステップを実行する代わりに、グラフィカル・ユーザー・インターフェースである構成ウィザードを使用して、 サポートされている別のデータベースへのデータ転送を行うこともできます。

      ローカルまたはリモートの IBM i サーバーにデータベース名およびスキーマを作成する前に、プロパティーを変更する必要があります。

  2. テキスト・エディターを使用してプロパティー・ファイル wkplc_dbdomain.properties を開き、ご使用の環境に対応するように値を変更します。
    1. dbdomain.DbType の場合は、db2_iseries と入力します。
    2. dbdomain.DbName の場合は、WebSphere Portal Express ドメイン・データベースの名前を入力します。
      注: この値は、dbdomain.DbUrl プロパティー内のデータベース・エレメントでもあります。
    3. dbdomain.DbSchema の場合は、データベース・ドメインのスキーマ名を入力します。
      注: ターゲット・データベース管理システムの文書を参照して、有効なスキーマ名を定義します。 いくつかのデータベース管理システムでは、知っておく必要のあるスキーマ名の制約があります。
    4. dbdomain.DataSourceName の場合は、WebSphere Portal Express がデータベースとの通信に使用するデータ・ソースの名前を入力します。 以下の予約語を使用しないでください。
      • releaseDS
      • communityDS
      • customizationDS
      • jcrDS
      • lmdbDS
      • feedback
    5. dbdomain.DbUrl の場合、JDBC を使用してWebSphere Portal Express データベースにアクセスするときに使用するデータベースの URL を入力します。この値は、データベースで指定された JDBC URL 構文規則に準拠する必要があります。 IBM i V7R1 より前のシステムで稼働しているデータベースには、接続プロパティー metadata source=1 を指定する必要があります。WebSphere Portal ExpressIBM i にインストール済みで、 データをリモートまたはローカルで IBM DB2 for i に転送する場合は、次の例を参照してください。dbdomain.DbUrl="jdbc:as400:daisy.mycorp.com/WPDBREL;metadata source=1" WebSphere Portal Express が Windows にインストール済みで、データをリモートで IBM DB2 for i に転送する場合は、次の例を参照してください。dbdomain.DbUrl="jdbc:as400:daisy.mycorp.com/WPDBREL;metadata source=1" WebSphere Portal Express が UNIX プラットフォームにインストール済みで、 データを IBM DB2 for i に転送する場合は、次の例を参照してください。dbdomain.DbUrl="jdbc:as400:daisy.mycorp.com/WPDBREL;metadata source=1;prompt=false"。X11 DISPLAY が設定済みで、アクティブになっている場合は、 ;prompt=false を URL に追加しないでください。
      注: この値のデータベース・エレメントは、DbName の値と一致する必要があります。
    6. dbdomain.DbUser には、データベース構成ユーザーの ユーザー ID を入力します。
    7. dbdomain.DbPassword には、 データベース構成ユーザーのパスワードを入力します。
    8. オプション: dbdomain.DBA.DbUser には、 データベース作成時の特権アクセス操作のためのデータベース管理者ユーザー ID を 入力します。このパラメーターが不要の場合は、デフォルト値を受け入れるか、 空白のままにします。
    9. オプション: dbdomain.DBA.DbPassword には、 データベース作成時の特権アクセス操作のためのデータベース管理者パスワードを 入力します。このパラメーターが不要の場合は、デフォルト値を受け入れるか、 空白のままにします。
  3. ファイルを保管して閉じる。
  4. wkplc_dbtype.properties ファイルの以下のプロパティーを更新します。
    1. db2_iseries.DbDriver の場合は、JDBC ドライバー・クラスの名前を入力します。
    2. db2_iseries.DbLibrary の場合は、JDBC ドライバー・クラスを含む .zip、または .jar ファイルのディレクトリーと名前を入力します。
    3. db2_iseries.JdbcProviderName の場合は、WebSphere Portal Express がそのデータベースとの通信に使用する JDBC プロバイダーの名前を入力します。
    4. db2_iseries.DbDriverType の場合は、データベースのドライバー・タイプを表す数値を入力します。
  5. ファイルを保管して閉じる。
  6. wkplc.properties ファイルの WasPassword 値を 更新します。この値は、ご使用の環境で使用される WebSphere Application Server セキュリティー認証のパスワードです。
  7. ファイルを保管して閉じる。
IBM i アイドル・スタンバイ: DB2 for i ユーザー・プロファイルの作成

ここでは、IBM DB2 for iWebSphere Portal Express と連動させるためのユーザー・プロファイルの設定について説明します。

始める前に
始める前に
  • データベース 所有者のユーザー・プロファイルは、インストールの 実行に使用されるアドミニストレーター・ユーザー・プロファイルとは異なるもの でなければなりません。 アドミニストレーター・ユーザー・プロファイルは必要なもの以外の権 限を持つことができ、通常は個人に属します。データベース・ユーザー・プロファイルは最低限の権限しか持たず、共用することができます。
  • 一定の期間パスワードを変更する必要のないデータベース・ユーザー・プロファイルを作成します。データベース・ユーザー・プロファイルに対するパスワードを変更した場合は、新しいパスワードを使用するように WebSphere Portal Express を再構成する必要があります。
  • 実際の実行時環境と同じ設定になっている環境でユーザーを作成してください。 例えば、トルコ語環境でユーザーを使用するつもりである場合、そのユーザーを英語環境で作成するのは避けてください。
このタスクについて
手順
ユーザー・プロファイルを作成するには、IBM DB2 for i の資料の手順に従います。
IBM i アイドル・スタンバイ: リモート DB2 for i データベースの作成

リモート・データベースは、WebSphere Portal Express とは異なるシステム上にあります。 リモート・サーバーを使用する場合は、WebSphere Portal Express で必要なデータベースを手動で作成する必要があります。

始める前に
始める前に
  • 使用するユーザー ID とパスワードには、リモート System i5 マシンでデータベース・ライブラリーを作成するための権限がなければなりません。
  • *LOCAL/schema を使用するデータベースの各プロパティー・インスタンスを、 それぞれ HostName/schema に置き換えます。

    例えば、WebSphere Portal Express の release ドメインのデフォルトのデータベース名とデータベース・ライブラリー名は、release.DbName=wpsdb です。このデータベース・ライブラリーをリモート・データベースで作成したかった場合、デフォルトの値を release.DbName=hostname/wpsdb に変更してください。

このタスクについて
すべてのドメイン・データベース・ライブラリーを作成するには、以下の手順を実行します。
手順
  1. リモート・データベース・マシンで、5250 セッションを開始する。
  2. i コマンド WRKRDBDIRE を入力し、 リモート・ロケーション *LOCAL のリレーショナル・データベース・ディレクトリー項目を表示させ、 表示される値をメモに書き留める。
  3. 5250 セッションからサインオフする。
  4. WebSphere Portal Express がインストールされているローカル・マシンで、5250 セッションを開始する。
  5. i コマンド WRKRDBDIRE を使用して、ローカル・システム上にリモート・システム用のリレーショナル・データベース・ディレクトリー項目を作成する。
  6. 以下の値を持つ項目を追加する。
    リレーショナル・データベース
    リモートのリレーショナル・データベース。 前のステップでメモした値を使用。
    リレーショナル・データベース別名
    ホスト名。リモート・システムの TCP/IP 短縮ホスト名を使用。
    リモート・ロケーション
    ドメイン修飾ホスト名。 リモート・システムの TCP/IP 完全ホスト名を使用。
    タイプ
    IP
    ポート番号またはサービス名
    DRDA
    リモート認証方式
    • 優先される方式: ENCRYPTED
    • 簡易認証を許可: ALWLOWER
  7. ローカル・マシンから次のコマンドを実行して、リモート・データベース・マシンで必要な DB2 パッケージを作成する。 JAVA CLASS(com.ibm.db2.jdbc.app.DB2PackageCreator) PARM('rdb_alias' 'userid' 'password') PROP((jdbc.drivers 'com.ibm.as400.access.AS400JDBCDriver')) ここで、rdb_alias は、ステップ 2 で作成したリレーショナル・データベース項目の名前に一致し、userid は、リモート・マシンのデータベース・アドミニストレーターのユーザー ID を表し、password は、リモート・マシンのデータベース・アドミニストレーターのパスワードを表します。 出力は次のようになります。Java program completed
  8. F3 を押して、Java Shell Display を終了する。
  9. 5250 セッションからサインオフする。
  10. リモート・データベース・マシンで、5250 セッションを開始する。
  11. コマンド WRKOBJ OBJ(QGPL/QSQCL*) OBJTYPE(*SQLPKG) を実行して、必要な DB2 パッケージが作成されたことを確認する。 すると、次のように出力されます。
    Opt  Object      Type      Library     Attribute   Text                        
         QSQCLIPKGA  *SQLPKG   QGPL        PACKAGE                                 
         QSQCLIPKGC  *SQLPKG   QGPL        PACKAGE                                 
         QSQCLIPKGL  *SQLPKG   QGPL        PACKAGE                                 
         QSQCLIPKGN  *SQLPKG   QGPL        PACKAGE                                 
         QSQCLIPKGS  *SQLPKG   QGPL        PACKAGE
  12. WebSphere Portal Express がインストールされているローカル・マシンで、5250 セッションを開始する。
  13. コマンド行で、cd wp_profile_root/ConfigEngineと入力してディレクトリーを変更する。
  14. Enter を押す。
  15. コマンド行に以下のコマンドを入力する前に、構成プロパティー・ファイル内のプロパティー値を変更する。 ConfigEngine.sh create-database
  16. Enter を押す。

IBM i アイドル・スタンバイ: デプロイメント・マネージャーの構成

IBM WebSphere Application Server Network Deployment をインストールし、IBM WebSphere Portal Express を 1 次ノードにインストールした後、デプロイメント・マネージャーを構成する必要があります。

このタスクについて
デプロイメント・マネージャーを構成するには、以下の手順を実行します:
手順
以下の手順を実行して、1 次ノードからファイルを収集し、それらのファイルをデプロイメント・マネージャーにコピーします。
  1. アーカイブ・ファイルまたは圧縮ファイルは、インストール中に PortalServer_root/filesForDmgr ディレクトリーに配置され、filesForDmgr.zip という名前が付けられます。 filesForDmgr.zip ファイルをリモート・デプロイメント・マネージャー・サーバーにコピーします。
  2. デプロイメント・マネージャーを停止します。
  3. デプロイメント・マネージャーのインストール・ルート・ディレクトリー (例えば、AppServer ディレクトリー内のサブディレクトリー) 内に filesForDmgr.zip ファイルを解凍します。このディレクトリーには、bin および profileTemplates ディレクトリーが含まれます。
    注: デフォルトの AppServer¥profiles¥Dmgr01 ディレクトリー内にデプロイメント・マネージャー・プロファイルが作成されなかった場合は、zip ファイル内の AppServer/profiles/Dmgr01/config/.repository¥metadata_wkplc.xml ディレクトリーにある metadata_wkplc.xml ファイルを、デプロイメント・マネージャー・プロファイル・ディレクトリーの下の config/.repository サブディレクトリーにコピーする必要があります。
  4. デプロイメント・マネージャーを開始します。

IBM i アイドル・スタンバイ: アイドル・スタンバイ構成の作成

IBM WebSphere Portal Express を 1 次ノードにインストールし、リモート・データベースを構成し、デプロイメント・マネージャーと通信するために 1 次ノードを準備した後、アイドル・スタンバイ・クラスターを作成できます。

このタスクについて
アイドル・スタンバイ・クラスターを作成するには、以下の手順を実行します:
手順
  1. デプロイメント・マネージャーが、スタンドアロンの LDAP ユーザー・レジストリーを使用するよう構成されている場合は、1 次ノード上の wp_profile_root/ConfigEngine/properties ディレクトリーにある wkplc.properties ファイルを、デプロイメント・マネージャーのスタンドアロン LDAP ユーザー・レジストリーのプロパティー値で更新します。 これらの設定値は VMM スタンドアロン LDAP 構成見出しの下にあります。
    重要: WasUserid および WasPassword をデプロイメント・マネージャーのユーザー ID およびパスワードに設定していることを確認してください。
  2. 1 次ノード上の server1 サーバーと WebSphere_Portal サーバーを停止し、wp_profile_root/ConfigEngine/properties ディレクトリーにある wkplc.properties ファイルに以下のパラメーターが正しく設定されていることを確認します。
    1. WasSoapPort を、デプロイメント・マネージャーにリモート接続するために使用されるポートに設定します。
    2. WasRemoteHostName をデプロイメント・マネージャーにリモート接続するために使用されるサーバーの完全ホスト名に設定します。
    3. WasPassword がデプロイメント・マネージャーのパスワードに設定されていることを確認する。
    4. PortalAdminPwdWebSphere Portal Express パスワードに設定されていることを確認する。
    5. ClusterName が設定されていることを確認する。
    6. PrimaryNodetrue に設定されていることを確認する。
  3. 使用可能な場合は、wp_profile_root/config/cells/cell_name/wim/config/wimconfig.xml および wp_profile_root/config/cells/cell_name/wim/model/wimxmlextension.xml ファイルのバックアップ・コピーを作成します。
  4. 1 次ノードの wp_profile_root/ConfigEngine ディレクトリーから、ConfigEngine.sh cluster-node-config-pre-federation -DWasPassword=dmgr_password タスクを実行します。
    注: ノード・エージェントのカスタム・ポートを指定する場合、-DPortPropsFile=full to portsfile パラメーターを cluster-node-config-pre-federation タスクに追加します。 WebSphere_Portal および server1 に関するセットアップ CD にあるポート・ファイルを参考用に使用できます。
    注: SSL 署名者証明書の承諾に関するメッセージを受け取ることがあります。SSL 署名者証明書の承諾に失敗すると、スクリプトが失敗します。代わりに、接続の試行中に署名者を承諾できるように、ssl.client.props ファイル内で「DefaultSSLSettings」に関する com.ibm.ssl.enableSignerExchangePrompt フラグを使用可能にすることもできます。
    警告: 何らかの理由で cluster-node-config-pre-federation が失敗する場合は、タスクを再実行する前に、以下のステップを実行する必要が あります。
    1. AddNode タスクが成功した場合は、ノードを除去します。
    2. 項目が存在する場合は、デプロイメント・マネージャーにログオンして、以下のステップを実行します。
      1. エンタープライズ・アプリケーションをすべて除去します。
      2. WebSphere_Portal サーバー定義を除去します。
      3. WebSphere Portal Express JDBC プロバイダーを除去します。
    注: 索引データを含むバージョン 6.1.0 より前のバージョンからマイグレーションする場合は、技術情報 Migrating with Lookaside Data を参照してください。
  5. オプション: データベース・ユーザー・レジストリーまたはプロパティー拡張 (索引) データベースを構成した場合は、以下のタスクを実行し、データベース・ドライバーへのアクセスをセットアップします。
    注: さらに、1 次ノードをバージョン 6.1.0 より前のリリースからマイグレーションした場合は、データベース・ユーザー・レジストリーまたはプロパティー拡張 (索引) データベースを構成していなくても、このタスクを実行する必要があります。
    1. データベース・ユーザー・レジストリーを使用している場合は、federated.db.DbType のプロパティー値を、wkplc.properties ファイルのプロパティー拡張データベースを使用している場合は la.DbType のプロパティー値を設定します。
      注: 1 次ノードをバージョン 6.1.0 より前のバージョンからマイグレーションした際に、データベース・ユーザー・レジストリーまたはプロパティー拡張データベースを使用していない場合は、federated.db.DbType のプロパティー値を、1 次ノード上の wkplc.properties ファイル内の値と同じ値に設定してください。
    2. wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-node-prep-vmm-db-secured-environment -DWasPassword=password -DDbDomain=la|federated.db -DVmmNodeName=node_name -Ddb_type.NodeDbLibrary=データベース jar のローカルの絶対パス タスクを実行し、VMM データベース jar にアクセスするために使用する変数を作成する。
      注: VmmNodeName は、同じデータベース・ドライバー・パスを共有している、セル内の 1 つ以上の WebSphere Portal Express ノード名です。db_type.NodeDbLibrarydb_type は、使用しているデータベースのタイプに設定する必要があります (db2 など)。
      • IBM DB2 for i タイプ 2 ドライバー: /QIBM/ProdData/Java400/ext/db2_classes.jar
      • IBM DB2 for i タイプ 4 ドライバー: /QIBM/ProdData/HTTP/Public/jt400/lib/jt400.jar
  6. ConfigEngine.sh cluster-node-config-post-federation -DWasPassword=dmgr_password タスクを実行します。
  7. WebSphere Portal Express ノードは、現在デプロイメント・マネージャー・セルのセキュリティー設定を使用しているため、そのセルのユーザー・レジストリーで定義されている管理ユーザーに一致するように WebSphere Portal Express の管理ユーザー ID とパスワードを更新する必要があります。デプロイメント・マネージャー・セルが別のユーザー・レジストリーを使用している場合は、wp_profile_root/ConfigEngine ディレクトリーから ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=password -DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid タスクを実行して、WebSphere Portal Express の管理ユーザー ID を更新します。
    重要: -DWasPassword のパスワード値は、デプロイメント・マネージャーの管理パスワードです。
    重要: newAdminId および newAdminGroupId パラメーターに完全識別名 (DN) を入力しなければなりません。
    ファースト・パス: newAdminGroupId の値にスペースが含まれている (Software Group など) 場合は、wkplc.properties ファイルを開いて、newAdminIdnewAdminPw、および newAdminGroupId の値を追加してください。変更を保存し、ConfigEngine.bat wp-change-portal-admin-user -DWasPassword=dmgr_password タスクを実行してください。
    重要: デプロイメント・マネージャー・セルでスタンドアロンの LDAP セキュリティーがすでに有効になっている場合は、cluster-node-config-cluster-setup タスクが完了した後まで wp-change-portal-admin-user タスクを遅らせます。wp-change-portal-admin-user タスクの実行後に WebSphere_Portal サーバーを始動または再始動して、更新された管理者ユーザー ID を使用します。
    注: WebSphere Portal Express 管理ユーザー ID および管理グループは、wp-change-portal-admin-user タスクを実行する前にデプロイメント・マネージャーに存在している必要があります。-DnewAdminPwwkplc.properties ファイル内の管理パスワードを更新する必要がある場合に、それを更新するためのオプション・パラメーターです。
  8. ConfigEngine.sh cluster-node-config-cluster-setup -DWasPassword=dmgr_password タスクを実行します。
  9. 以下のタスクを実行して変更を伝搬します。
    注: WebSphere_Portal_servername はこのノードの WebSphere Portal Express サーバーの名前ですが、サーバー名をカスタマイズした場合、デフォルト名は変わっています。 サーバー名が確実に分からない場合は、serverstatus -all タスクを実行して、サーバー名とその状況のリストを取得してください。
    1. stopServer.sh WebSphere_Portal_servername -username admin_userid -password admin_password
    2. startServer.sh WebSphere_Portal_servername
  10. ポータル・ビジネス・プロセスの統合 を使用している場合は、タスク・リストの設定を変更して、単一サーバーでなくアイドル・スタンバイ・クラスターを指すようにします。 詳しくは、製品資料の以下のいずれかのセクションを参照してください:
    クロス・セル
    クロス・セル・セットアップでの管理対象セルへの BPI 対応ポータル・サーバーの追加
    単一セル
    単一セル・セットアップでの管理対象セルへの BPI 対応ポータル・サーバーの追加

IBM i アイドル・スタンバイ: Web サーバーの準備

IBM WebSphere Application Server に付属する Web サーバー・プラグインをインストールして構成し、IBM WebSphere Portal Express と通信できるように Web サーバーをセットアップします。

このタスクについて
Web サーバーをインストールして構成するには、以下のステップを実行します。
手順
  1. Web サーバーをインストールして構成する (詳しくは、Web サーバーの資料を参照してください)。
  2. IBM Lotus Domino を使用している場合は、Web サーバーの NOTES.INI ファイルを編集する。HTTPEnableConnectorHeaders パラメーターを 1 に設定する。
  3. IBM HTTP Server または Apache Server を使用している場合は、Web サーバー上の httpd.conf ファイルを編集する。AllowEncodedSlashes ディレクティブを On に設定する。 このディレクティブは、グローバル・ディレクティブとして、ルート・レベルで追加する必要があります。
    表 40. HTTP Server および Apache Server の資料へのリンク
    HTTP Server のタイプ 資料リンク
    該当の HTTP Server の資料を参照してください。 IBM HTTP Server
    該当の Apache Server の資料を参照してください。 AllowEncodedSlashes ディレクティブ
  4. Web サーバーを停止する。
  5. WebSphere Application Server に用意されているプラグイン・インストール・ウィザードを使用して、Web サーバーが配置されているシステムに Web サーバー・プラグインをインストールして構成する。 情報については、Web サーバーのトポロジー・ダイアグ