|
|
| 注意 : | Datasync Web アプリケーションは非推奨です。datasync データを伝播する場合は、伝播ツールの利用をお勧めします。ブラウザで Datasync Web アプリケーションを使用する場合は、次の WAR ファイルをアプリケーションに追加する必要があります。 |
| 注意 : | WEBLOGIC_HOME/common/p13n/lib/deprecated/datasync.war |
この章では、別のデプロイメント プロセスでデータベースにブートストラップする必要がある、ユーザ プロファイルのプロパティ、ユーザ セグメント、コンテンツ セレクタ、キャンペーン、割引などのプロパティ セットが入ったポータル アプリケーションの datasync データを更新する手順について説明します。
| 注意 : | 管理対象サーバを管理サーバとは別のマシンで実行している WebLogic Portal クラスタでは、管理対象サーバそれぞれの ListenAddress 属性に独自の IP アドレスまたは DNS 名を設定する必要があります。これにより、datasync でクラスタ全体に更新を伝播できます。クラスタ アドレスを DNS アドレスに設定する方法については、WebLogic Server ドキュメントの「WebLogic クラスタの設定」で説明しています。 |
WebLogic Portal を使用すると、開発からプロダクションに移行する場合や、プロダクションから開発に戻す場合に慎重に管理する必要がある、ユーザ プロファイルやコンテンツ セレクタなどの定義ファイルを多数作成できます。
Workshop for WebLogic では、ポータル定義は特殊な datasync プロジェクトに作成されます。このプロジェクトには、ユーザ プロファイルのプロパティ セット、ユーザ セグメント、コンテンツ セレクタ、キャンペーン、割引、カタログのプロパティ セット、イベントのプロパティ セット、およびセッションとリクエストのプロパティ セットを保持できます。
開発段階では、datasync プロジェクトに作成されたファイルはすべて datasync プロジェクトに格納されます。各定義に対する実行時コンポーネントからのアクセスを最適化するために、datasync には、ファイルのインメモリ キャッシュが用意されています。このキャッシュは、定義に対する変更をインテリジェントにポーリングし、コンテンツが変更されると、新しいコンテンツをメモリにロードして、リスナベースの通知サービスを提供します。これにより、開発者は、開発環境で datasync の機能をプレビューできるようになります。
datasync 定義は、Workshop for WebLogic の開発者だけでなく、WebLogic Portal Administration Console でユーザ セグメント、キャンペーン、プレースホルダ、およびコンテンツ セレクタを変更できるビジネス ユーザやポータル管理者によっても変更されます。開発環境では、Workshop for WebLogic と WebLogic Portal Administration Console の両方で、datasync プロジェクト ディレクトリ内のファイルの書き込みが行われます。
プロダクション システムにデプロイされる場合、ポータル定義は一般に、WebLogic Portal Administration Console で修正可能である必要があります。ほとんどのプロダクション環境では、ポータル アプリケーションは圧縮 EAR ファイルとしてデプロイされるため、ファイルに変更を書き込む機能が制限されます。プロダクション環境では、ファイル システム内のすべての datasync 資産をデータベースにロードして、アプリケーションを更新できるようにする必要があります。
図 11-1 は、更新されたポータル アプリケーションの /data ディレクトリが、どのようにスタンドアロン JAR に配置され、データベースにブートストラップされるかを示しています。
一方、プロダクション環境によっては、ポータル アプリケーションを非圧縮 EAR としてデプロイする場合があります。
圧縮 EAR ファイルの場合も、非圧縮 EAR ファイルの場合も、datasync 定義は、Datasync Web アプリケーションを使用して表示および更新できます。
| 注意 : | ブラウザで Datasync Web アプリケーションを使用する場合は、次の WAR ファイルをアプリケーションに追加する必要があります。 |
WEBLOGIC_HOME/common/p13n/lib/deprecated/datasync.war
各ポータル アプリケーションには、そのアプリケーションのルート ディレクトリの 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 アプリケーションを使用すると、図 11-2 に示すように、リポジトリの内容を表示したり、新しいコンテンツをアップロードしたりできます。
Repository Browser を操作する - Data Repository Browser では、ページの左側に並んでいるアイコンを使ってリポジトリ内のすべてのファイルを操作することも、特定のサブリポジトリ (プロパティ セットの定義がすべて含まれるリポジトリなど) のみを操作することもできます。
コンテンツを表示する - リポジトリのコンテンツを表示するには、
アイコンをクリックして、図 11-3 のウィンドウを起動します。
このリストの特定のデータ項目をクリックすると、図 11-4 に示すように、そのデータ項目の内容が表示されます。
図 11-4 のように、特定の項目の XML データを表示できます。
リポジトリの内容を削除するには、ページの左側にあるごみ箱のアイコンをクリックします。
アプリケーションをデプロイするときに JDBC リポジトリが空の (データがない) 場合は、EAR 内のファイルを使用してデータベースがブートストラップ (初期化) されます。datasync の資産が格納されるテーブル : DATA_SYNC_APPLICATION、DATA_SYNC_ITEM、DATA_SYNC_SCHEMA_URI、および DATA_SYNC_VERSION。デフォルトでは、ブートストラップ処理はデータベースが空の場合にのみ実行されます。インクリメンタル更新を実行する場合、Datasync Web アプリケーションでは新しい定義をデータベースに直接ロードできます。この操作は、ポータル アプリケーションの再デプロイメントの一部として行うか、または「図 11-4 データ項目の内容」に示すように、定義を格納する特殊な JAR ファイルを使って個別に行うことができます。
アイコンをクリックすると、次のようなページが表示され、データをデータベースにロードできます。
ブートストラップを行うときは、ブートストラップ ソースを選択できます。このソースは、デプロイしたポータル アプリケーションか、スタンドアロン 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 定義を開発ドメインに戻さなければならない場合があります。変更されたファイルはデータベースに格納されているため、WebLogic Portal には、データベースの 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\weblogic92\p13n\lib\p13n_system.jar;
C:\bea\weblogic92\p13n\lib\p13n_ejb.jar;
C:\bea\weblogic92\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
datasync 定義をプロダクション システムに反復的にデプロイするときは、考慮しなければならない一般的な概念があります。通常、新しい datasync 定義をプロダクション システムに追加することは、いつでも実行できるルーチン プロセスです。しかし、datasync 定義を削除したり、datasync 定義に有害な修正を加えることは、注意を怠ると、予期せぬ結果を招く可能性があります。
datasync 定義を削除したり、危険な修正を行う際は、まず、それらのコンポーネントにリンクしているコンポーネントがあるかどうかを確認する必要があります。定義間には、数種類のバインディングが存在している場合があります。
| 注意 : | 特に認識しておくべきことは、これらのバインディングの中に、プロダクション サーバで WebLogic Portal Administration Console を使用して定義され、開発者に知らされていないものも含まれている可能性があるということです。 |
バインディングの一例に、2 つの datasync 定義を 1 つにバインドしている場合があります。このような例としては、ユーザ プロパティ セットに定義されたユーザ プロパティに基づくキャンペーンが挙げられます。たとえば、そのプロパティ セットを削除したり、プロパティを指定したりすると、そのキャンペーンは正しく実行されなくなります。この場合は、プロパティ セットやプロパティを削除する前に、関連付けられている datasync 定義を更新する必要があります。
2 つ目のシナリオは、datasync 定義にバインドされた資格ルールを定義している場合です。たとえば、ユーザに特定のユーザ プロパティ値があるかどうかをチェックする動的なロールに基づいて、ポートレットをロックしているとします。この場合は、プロパティ セットやプロパティを削除する前に、その動的なロールを更新する必要があります。
3 つ目のシナリオは、datasync 項目とポータル JSP タグの間にページ内バインディングが存在する場合です。たとえば、コンテンツ セレクタを参照する <pz:contentSelector> タグなどがその例です。この場合は、コンテンツ セレクタを削除する前に、プロダクション環境のコンテンツ セレクタ タグを更新します。これは、WebLogic Portal Administration Console ではなく、開発時に Workshop for WebLogic で唯一コンフィグレーションされるバインディング タイプの 1 つです。
開発者に推奨されるガイドラインは、プロダクション環境の既存の datasync 定義を削除したり、重要な変更を加えたりしないことです。代わりに、必要な変更を盛り込んだ新しい定義を作成します。たとえば、キャンペーンの場合は、予期せぬ方法で使用される可能性のない新しいバージョンを作成します。さらに、プロダクション システムの既存の datasync 定義のブートストラップを、開発システムに対して定期的に実行します。
プロパティ セットを削除する場合、WebLogic Portal によってローカルにデータベースに格納されている既存の値は、自動的に削除されません。PROPERTY_KEY テーブルおよび PROPERTY_VALUE テーブルを調べ、必要に応じてデータのクリーンアップを行う必要があります。
  
|
