プロダクション業務ユーザーズ ガイド
|
 |
 |
|
この章では、別のデプロイメント プロセスでデータベースにブートストラップする必要がある、ユーザ プロファイルのプロパティ、ユーザ セグメント、コンテンツ セレクタ、キャンペーン、割引などのプロパティ セットが入ったポータル アプリケーションの datasync データを更新する手順について説明します。
注意 : 管理対象サーバを管理サーバとは別のマシンで実行している WebLogic Portal クラスタでは、管理対象サーバそれぞれの ListenAddress 属性に 独自の IP アドレスまたは DNS 名を設定する必要があります。これにより、datasync でクラスタ全体に更新を伝播できます。クラスタ アドレスを DNS アドレスに設定する方法については、「Configuration Wizard でのプロダクション クラスタ環境の作成」で説明しています。
WebLogic Portal を使用すると、開発からプロダクションに移行する場合や、プロダクションから開発に戻す場合に慎重に管理する必要がある、ユーザ プロファイルやコンテンツ セレクタなどの定義ファイルを多数作成できます。
WebLogic Workshop では、ポータル定義は、WebLogic Workshop の [アプリケーション] ウィンドウで /data サブディレクトリとしてエクスポーズされる特殊な Datasync プロジェクトに作成されます (ファイル システム上では、このディレクトリはアプリケーションの /META-INF/data ディレクトリに存在します)。このプロジェクトには、ユーザ プロファイルのプロパティ セット、ユーザ セグメント、コンテンツ セレクタ、キャンペーン、割引、カタログのプロパティ セット、イベントのプロパティ セット、およびセッションとリクエストのプロパティ セットを保持できます。
開発段階では、datasync プロジェクトに作成されたファイルはすべてポータル アプリケーションの META-INF/data ディレクトリに格納され、WebLogic Workshop の <portalApplication>/data ディレクトリにエクスポーズされます。各定義に対する実行時コンポーネントからのアクセスを最適化するために、datasync には、ファイルのインメモリ キャッシュが用意されています。このキャッシュは、定義に対する変更をインテリジェントにポーリングし、コンテンツが変更されると、新しいコンテンツをメモリにロードして、リスナベースの通知サービスを提供します。これにより、開発者は、開発環境で datasync の機能をプレビューできるようになります。
Datasync 定義は、WebLogic Workshop の開発者だけでなく、WebLogic Administration Portal でユーザ セグメント、キャンペーン、プレースホルダ、およびコンテンツ セレクタを変更できるビジネス ユーザやポータル管理者によっても変更されます。開発環境では、WebLogic Workshop と WebLogic Administration Portal の両方で、META-INF/data ディレクトリ内のファイルの書き込みが行われます。
プロダクション システムにデプロイされる場合、ポータル定義は一般に、WebLogic Administration Portal で修正可能である必要があります。ほとんどのプロダクション環境では、ポータル アプリケーションは圧縮 EAR ファイルとしてデプロイされるため、ファイルに変更を書き込む機能が制限されます。プロダクション環境では、ファイル システム内のすべての datasync 資産をデータベースにロードして、アプリケーションを更新できるようにする必要があります。
図 10-1 は、更新されたポータル アプリケーションの /data ディレクトリが、どのようにスタンドアロン JAR に配置され、データベースにブートストラップされるかを示しています。
図 10-1 更新された Datasync ファイルのデータベースへのロード
一方、プロダクション環境によっては、ポータル アプリケーションを非圧縮 EAR としてデプロイする場合があります。この場合、管理サーバにデプロイされたポータル アプリケーションは、datasync 定義の主ストアになります。管理サーバの WebLogic Administration Portal で実行された作業は、自動的にこの主ストアと同期が取られます。
圧縮 EAR ファイルの場合も、非圧縮 EAR ファイルの場合も、datasync 定義は、Datasync Web アプリケーションを使用して表示および更新できます。
各ポータル アプリケーションには、そのアプリケーションのルート ディレクトリの datasync.war に、Datasync Web アプリケーションが格納されています。一般に、Datasync Web アプリケーションの URL は、http://server:port/appNameDataSync の形式をとります (http://localhost:7001/portalAppDataSync など)。また、Datasync Web アプリケーションの URL は、WebLogic Server Administration Console をロードして、[デプロイメント｜アプリケーション｜appName｜ *DataSync] を選択し、[テスト] タブをクリックしても確認できます。
Datasync Web アプリケーションを使用すると、図 10-2 に示すように、リポジトリの内容を表示したり、新しいコンテンツをアップロードしたりできます。
図 10-2 Datasync Web アプリケーションのホーム ページ
Repository Browser を操作する - Data Repository Browser では、ページの左側に並んでいるアイコンを使ってリポジトリ内のすべてのファイルを操作することも、特定のサブリポジトリ (プロパティ セットの定義がすべて含まれるリポジトリなど) のみを操作することもできます。
アイコンをクリックします。これにより、図 10-3 に示すようなウィンドウが開きます。
このリストの特定のデータ項目をクリックすると、図 10-4 に示すように、そのデータ項目の内容が表示されます。
図 10-4 のように、特定の項目の XML データを表示できます。
リポジトリの内容を削除するには、ページの左側にあるごみ箱のアイコンをクリックします。
アプリケーションをデプロイするときに JDBC リポジトリが空の (データがない) 場合は、EAR 内のファイルを使用してデータベースがブートストラップ (初期化) されます。Datasync の資産が格納されるテーブル : DATA_SYNC_APPLICATION、DATA_SYNC_ITEM、DATA_SYNC_SCHEMA_URI、および DATA_SYNC_VERSION。デフォルトでは、ブートストラップ処理はデータベースが空の場合にのみ実行されます。インクリメンタル更新を実行する場合、Datasync Web アプリケーションでは新しい定義をデータベースに直接ロードできます。この操作は、ポータル アプリケーションの再デプロイメントの一部として行うか、または「図 10-4 データ項目の内容」に示すように、定義を格納する特殊な JAR ファイルを使って個別に行うことができます。
アイコンをクリックすると、次のようなページが表示され、データをデータベースにロードできます。
図 10-5 新しい Datasync データのアップロード
ブートストラップを行うときは、ブートストラップ ソースを選択できます。このソースは、デプロイしたポータル アプリケーションか、スタンドアロン JAR ファイルのどちらかです。たとえば、プロダクション環境に再デプロイした最新のポータル アプリケーションがある場合は、その中に含まれるすべての新しい定義をポータルに追加できます。また、個別にロードしたい新しい定義を作成した場合は、それらの定義のみが含まれる JAR ファイルを作成して、任意の時点でロードできます。
いずれの場合も、データ リポジトリを更新するときは、[Overwrite ALL data in the Master Data Repository]、[Bootstrap only if the Mastery Repository is empty]、または [Merge with Master Data Repository-latest timestamp wins] を選択できます。
既存の EAR アプリケーションを再デプロイして新しい定義をデータベースにロードする場合は、[Application Data (META-INF/data)] をブートストラップ ソースとして選択し、適切なブートストラップ モードを選択します。情報を失わないようにするには、「プロダクションから定義を取り込む」の手順に従って、最初にバックアップを作成します。デプロイされない EAR ファイルから定義データをブートストラップすることはできません。
新しい定義ファイルを更新に関係なくポータル アプリケーションにブートストラップするには、サーバにロードする JAR ファイルを作成し、プロダクション システムに追加するファイル (コンテンツ セレクタ、キャンペーン、ユーザ セグメントなど) を格納します。
これには、META-INF/data ディレクトリの jar コマンドを使用できます。次に例を示します。
jar -cvf myfiles.jar *
この例では、myfiles.jar という JAR ファイルが作成され、そのルートに、データ ディレクトリ内のすべてのファイルが格納されます。次に、[Jar File on Server] をデータ ソースとして選択し、JAR ファイルの完全な物理パスを指定して、適切なブートストラップ モードを選択すると、この JAR ファイルから情報をブートストラップできます。このプロセスを実行することにより、JAR ファイルにパッケージ化されたすべてのファイルがアップグレードされます。JAR ファイルの内容を制御すれば、更新する内容を部分的に選択できます。
JAR ファイルを作成するときは、META-INF/data ディレクトリの内容が JAR ファイルのルートになければなりません。JAR 自体の META-INF/data ディレクトリにファイルを格納しないようにしてください。
データをブートストラップしたら、Datasync Web アプリケーションの表示機能を使用して、ロードした内容を確認した方がよいでしょう。
開発者やテスト担当者は、プロダクション環境で変更された Datasync 定義を開発ドメインに戻さなければならない場合があります。変更されたファイルはデータベースに格納されているため、ポータルには、データベースの XML をエクスポートしてファイルに戻すメカニズムが用意されています。
その 1 つは、Datasync Web アプリケーションのブラウズ機能を使用して、データベースに格納されているすべての XML を Web ブラウザに表示する方法です。表示された情報は、そこで切り取ってファイルに貼り付けることができます。
もっと便利な方法は、DataRepositoryQuery コマンドライン ツールを使用する方法です。このツールを使用すると、FTP 同様のインタフェースを使用して、データベースの特定のファイルをフェッチできます。
DataRepositoryQuery コマンドライン ツールは、サーバ上のデータ リポジトリを照会するための、基本的な FTP 形式のインタフェースをサポートしています。
コマンドライン クラスは、com.bea.p13n.management.data.DataRepositoryQuery です。これを使用するには、p13n_ejb.jar、p13n_system.jar、および weblogic.jar が CLASSPATH に指定されている必要があります。
引数 help を使用してこのクラスを実行すると、基本的な使用方法のヘルプを印刷できます。
set classpath=c:\bea\weblogic81\p13n\lib\p13n_system.jar;
c:\bea\weblogic81\p13n\lib\p13n_ejb.jar;
C:\bea\weblogic81\server\lib\weblogic.jar
java com.bea.p13n.management.data.DataRepositoryQuery help
サーバの接続には、いくつかのオプションのコマンド引数を使用できます。BEA が提供するサンプルではデフォルト値で十分です。実際のデプロイメントでは、オプションが必要になる場合があります。
-app と -url はそれぞれ、サーバへの異なる接続方法を指定するため、どちらか一方しか使用できません。
URL はサーバへの最も直接的なルートですが、Datasync Web アプリケーション内の DataRepositoryQuery サーブレットを参照している必要があります。このサーブレットには DataRepositoryQuery の URI を指定する必要がありますが、さらにアプリケーションの datasync.war のデプロイに使用したホスト名、ポート、および context-root を指定する必要があります。したがって、datasync.war が datasync の context-root を使用してデプロイされた場合、URL は http://localhost:7001/datasync/DataRepositoryQuery というようになります。
-app オプションを使用した場合は、それほど細かく指定する必要はありません。必要なのは、ホスト名、ポート番号、およびアプリケーション名のみです。デプロイされた datasync.war が 1 つのみの場合は、アプリケーション名すら必要ありません。-app を使用した場合の記述形式は appname@host:port ですが、この中の値がデフォルトである localhost ポート 7001 上の 1 つのアプリケーションと同じ場合は、その値を省くことができます。
-app オプションは、サーバに対して多数のクエリを実行する必要があるため、処理が遅くなる可能性があります。しかし、このオプションでは、検出された URL が印刷されるので、以降の接続には -url オプションを使用して、その検出された URL を指定することができます。
この節では、DataRepositoryQuery コマンドの使用例を示します。
ここでは、CLASSPATH が前述の説明どおりに設定され、デフォルトのユーザ名とパスワード weblogic/weblogic が有効であると仮定します。
localhost ポート 7001 で実行されている p13nBase というアプリケーションを検索する
java com.bea.p13n.management.data.DataRepositoryQuery -app p13nBase
snidely ポート 7501 で実行されている p13nBase というアプリケーションを検索する
java com.bea.p13n.management.data.DataRepositoryQuery -app p13nBase@snidely:7501
localhost ポート 7101 で実行されている 1 つのアプリケーションを検索する
java com.bea.p13n.management.data.DataRepositoryQuery -app @7101
snidely ポート 7001 で実行されている 1 つのアプリケーションを検索する
java com.bea.p13n.management.data.DataRepositoryQuery -app @snidely
snidely ポート 7501 で実行されている 1 つのアプリケーションを検索する
java com.bea.p13n.management.data.DataRepositoryQuery -app @snidely:7501
それぞれの結果の最初の行は、次のような形で出力されます。Using url: http://snidely:7001/myApp/datasync/DataRepositoryQuery
このツールの最も簡単な使用方法は、シェル モードでの使用です。このモードを使用するには、引数を使用せずに (前述の接続に必要な引数は使用する) DataRepositoryQuery を呼び出します。
このモードを使用すると、コマンド シェルが起動して drq> プロンプトが表示されます。このコマンド シェルでは、ftp と同様の方法で対話式にコマンドを入力できます。
この方法の代わりに、1 つのコマンドを引数とともに入力することもできます。この場合は、DataRepositoryQuery がそのコマンドを実行して終了します。
HELP コマンドは、使用できるコマンドのヘルプを表示します。HELP command と入力すると、特定のコマンドのヘルプを表示できます。
コマンドは大文字と小文字を区別しませんが、ファイル名やデータ項目の URI などの引数は大文字と小文字を区別する場合があります。上記以外のヘルプは、HELP コマンドを使用して、詳細を知りたいコマンドを指定すると表示されます。
複数の URI を使用できる場合 (上記リストで uri(s) と記載されているヘルプ) は、複数の URI を指定することも、単にワイルドカードのみを使用することもできます。コマンドの結果には、一致したすべてのデータ項目が出力されます。
角括弧 ([]) で囲まれたオプションは省略可能で、次の意味があります。
次の例は、リポジトリ内のすべての資産をファイルとして取り込みます。
java com.bea.p13n.management.data.DataRepositoryQuery -app mget
非圧縮 EAR を使用してプロダクション サーバを操作する場合、開発モードとの唯一の違いは、ポーラー スレッドがないことです。
WebLogic Administration Portal を使用して定義ファイルを更新すると、これらのファイルは管理サーバ上のデプロイされた非圧縮 EAR ディレクトリ内で自動的に更新されます。つまり、WebLogic Administration Portal はクラスタ内のどの管理対象サーバでも使用できますが、主ストアは常に管理サーバ上に存在することになります。デプロイ可能な EAR ディレクトリが読み込み専用の場合は、WebLogic Administration Portal を使用してファイルを変更することはできません。
ファイルが上書きされないことを確認する - プロダクション環境で非圧縮 EAR ファイルを操作するときは、定義ファイルの扱いに特に注意する必要があります。アプリケーションをプロダクション環境に再デプロイすると、既存の定義ファイルが置換されます。WebLogic Administration Portal を使用して定義を更新している管理者がいる場合、その管理者が行った変更は、最新のアプリケーションを再デプロイしたとたんに失われてしまいます。
開発にコピーする - 管理者が定義ファイルに行った変更を、新しいポータル アプリケーションを再デプロイするときに上書きしないようにするには、まず、管理サーバ上のすべての定義ファイルを、手動または Datasync Web アプリケーションを使用して開発環境にコピーする必要があります。
datasync 定義をプロダクション システムに反復的にデプロイするときは、考慮しなければならない一般的な概念があります。通常、新しい datasync 定義をプロダクション システムに追加することは、いつでも実行できるルーチン プロセスです。しかし、datasync 定義を削除したり、datasync 定義に有害な修正を加えることは、注意を怠ると、予期せぬ結果を招く可能性があります。
datasync 定義を削除したり、危険な修正を行う際は、まず、それらのコンポーネントにリンクしているコンポーネントがあるかどうかを確認する必要があります。定義間には、数種類のバインディングが存在している場合があります。
注意 : 特に認識しておくべきことは、これらのバインディングの中に、プロダクション サーバで WebLogic Administration Portal を使用して定義され、開発者に知らされていないものも含まれている可能性があるということです。
バインディングの一例に、2 つの datasync 定義を 1 つにバインドしている場合があります。このような例としては、ユーザ プロパティ セットに定義されたユーザ プロパティに基づくキャンペーンが挙げられます。たとえば、そのプロパティ セットを削除したり、プロパティを指定したりすると、そのキャンペーンは正しく実行されなくなります。この場合は、プロパティ セットやプロパティを削除する前に、関連付けられている datasync 定義を更新する必要があります。
2 つ目のシナリオは、datasync 定義にバインドされた資格ルールを定義している場合です。たとえば、ユーザに特定のユーザ プロパティ値があるかどうかをチェックする動的なロールに基づいて、ポートレットをロックしているとします。この場合は、プロパティ セットやプロパティを削除する前に、その動的なロールを更新する必要があります。
3 つ目のシナリオは、datasync 項目とポータル JSP タグの間にページ内バインディングが存在する場合です。たとえば、コンテンツ セレクタを参照する <pz:contentSelector> タグなどがその例です。この場合は、コンテンツ セレクタを削除する前に、プロダクション環境のコンテンツ セレクタ タグを更新します。これは、WebLogic Administration Portal ではなく、開発時に WebLogic Workshop で唯一コンフィグレーションされるバインディング タイプの 1 つです。
開発者に推奨されるガイドラインは、プロダクション環境の既存の datasync 定義を削除したり、重要な変更を加えたりしないことです。代わりに、必要な変更を盛り込んだ新しい定義を作成します。たとえば、キャンペーンの場合は、予期せぬ方法で使用される可能性のない新しいバージョンを作成します。さらに、プロダクション システムの既存の datasync 定義のブートストラップを、開発システムに対して定期的に実行します。
プロパティ セットを削除する場合、WebLogic Portal によってローカルにデータベースに格納されている既存の値は、自動的に削除されません。PROPERTY_KEY テーブルおよび PROPERTY_VALUE テーブルを調べ、必要に応じてデータのクリーンアップを行う必要があります。
|
|
|
