BEA ホーム | 製品 | デベロッパ・センタ | support | askBEA |
![]() |
![]() |
|
![]() |
e-docs > WebLogic Portal > 移行ガイド > WebLogic Portal 4.0 から WebLogic Portal 7.0 への移行 |
移行ガイド
|
WebLogic Portal 4.0 から WebLogic Portal 7.0 への移行
この章では、WebLogic Portal リリース 4.0 から 7.0 への移行に関する情報を示します。 移行プロセスをスムーズに進めるために、図 2-1 に示すような移行ツールを使用します。
図2-1 移行ツールの [Code Migrator] ウィンドウ
移行プロセスでは、まずいくつかの移行準備ステップを完了し、次にコードおよびデータを移行し、移行されたファイルをリリース 7.0 のコンフィグレーションでアセンブルします。 この章では、以下の内容について説明します。
注意: ステップ 5 には、移行したリリース 7.0 実装を稼働させるために必ず実行しなければならないタスクが含まれます。 補助的な移行タスクについては、「トラブルシューティング」の索引エントリを確認してください。 また、移行に関するその他のヒントについては、カスタマサポート (http://websupport.bea.com/welcome.jsp) および BEA dev2dev (http://dev2dev.bea.com/index.jsp) の各 Web サイトを参照してください。
ステップ 1: 移行前の環境およびファイルの準備
この節では、以下の内容について説明します。
最新のマニュアルおよび関連ファイルの入手
以下の場所から、最新のマニュアルおよび関連ファイルを入手してください。
すべてのバージョンのサービス パックに付属するリリース ノートには、ソフトウェアの変更点に関する重要な情報が記載されています。 移行を完了する前に、リリース ノートの内容をもう一度確認してください。 サービス パックは次の場所から入手できます。
インストール済みパッチのチェック
サービス パックをインストールする前に、現在インストールされているパッチの種類を確認します。 これには、WebLogic Server など、使用しているすべての WebLogic 製品のパッチが該当します。
WebLogic Portal の移行は、WebLogic Portal 4.0 のインストールと、サービス パック 2 に含まれていた一連のパッチがベースとなります。ただし、一部のパッチについては、WebLogic Portal およびその他の WebLogic 製品のサービス パックとは別途に配布されているため、移行を行う前にすべての WebLogic パッチを検証する必要があります。 たとえば、サービス パックとは別にインストールしたパッチに、移行時に使用するものとバージョンが異なる JAR ファイルが含まれているような場合があります。 BEA カスタマサポート (http://www.bea.com/support/programs.shtml) に問い合わせて、インストール済みのすべてのパッチがサービス パックに含まれていたものかどうかを調べ、そうでない場合は、該当するパッチについて移行関連の問題が報告されていないかどうかを確認してください。
移行関連の問題への対処
移行プロセスの開始前またはその間、以下の各項目の内容をよく確認し、実装環境、またそれぞれの問題が実装にどのように影響するかに応じて適切な対処を行ってください。
移行時のWebLogic Integration との相互作用
既に Web Logic Portal または WebLogic Integration を使用しており、これから WebLogic 7.0 プラットフォームへの移行を行う場合、WebLogic Portal と WebLogic Integration の両方を移行しなければなりません。 これら 2 つの製品は WebLogic Portal RDBMS レルムを共有します。 コンフィグレーション済みの RDBMS には、WebLogic Integration の事前定義済みデータが含まれています。 WebLogic Integration からインストールされた fileRealm には、WebLogic Integration のシステム ユーザだけが含まれ、WebLogic Integration からのその他の事前定義済みデータは含まれません。
これらのコンフィグレーション関連の問題は、Configuration Wizard と同様に移行による影響を受けます。 詳細については、WebLogic Integration Platform のセキュリティ ページ (http://edocs.beasys.co.jp/e-docs/wls/docs70/security.html) を参照してください。
データベースの移行と Sybase に関する重要情報
Sybase ではカラム サイズに関する制限が緩和されており、WebLogic Portal でもその緩和された制限が適用されます。
Sybase を使用している場合、以下の手順を順序どおりに実行する必要があります。
現在 Sybase 11.9 または 12.0 を使用している場合、リリース 4.0 から 7.0 に移行します。 Sybase 12.5 に更新する場合、BEA dev2dev (http://dev2dev.bea.com/index.jsp) から Sybase スキーマ更新スクリプトをダウンロードして実行してから、12.5 への更新を行います。
現在Sybase 12.5を使用している場合、リリース 4.0 から 7.0 に移行します。 次に、BEA dev2dev Web サイトから Sybase スキーマ更新スクリプトをダウンロードし、実行します。
トリガと WebLogic Portal 4.0 サービス パック 1 に関する注意事項
サービス パック 1 では、実装に悪影響を及ぼす可能性があるトリガが削除されています。 まだサービス パック 1 を使用している場合、移行の前にサービス パック 2 をインストールしてください。
サービス パックは次の場所から入手できます。
E-Business Control Center プロジェクトの移行について
E-Business Control Center プロジェクトの移行に関して、通常は特に問題となる点はありません。 ただし、プロジェクトの内容または最新バージョンへの準拠状況によっては、予期しない結果が生じる可能性があります。 プロジェクトが完全でない場合、その移行時に内容の有効性はチェックされないため、破損したファイルもすべて移行されます。 これを避けるには、移行の前に E-Business Control Center プロジェクトに対して必要なすべての作業を行ってください。 移行した後は、プロジェクトが想定どおりに機能することを確認し、管理ツールを使用して必要な変更を行ってください。
プロジェクトの移行手順の詳細については、E-Business Control Center プロジェクト移行の詳細を参照してください。
ポータルのデフォルト コンフィグレーション設定の移行
各ポータルには、匿名ユーザがポータルにアクセスしたときに使用されるデフォルト コンフィグレーションがあります。 デフォルト コンフィグレーションは、ポータルに関するその他のデータとともにこのリリースに移行されます。
デフォルト コンフィグレーションが確実に移行されるようにするには、移行を開始する前にポータル コンフィグレーションをサーバと同期します。 同期を行わないか、何か他の理由によって移行後のポータルにデフォルト コンフィグレーション セットが存在しない場合、ポータルにはデフォルト コンフィグレーション「default」が割り当てられます。 デフォルト コンフィグレーションを変更するには、WebLogic Portal Administration Toolsを使用します。
環境の準備
この節では、以下の内容について説明します。
サポート対象プラットフォームをチェックする
WebLogic Portal 7.0 のサポート対象プラットフォーム ドキュメントに記載された仕様にシステムが準拠していることを確認します。このドキュメントは http://edocs.beasys.co.jp/e-docs/platform/docs70/support/index.html から入手できます。
最新のサービス パックをインストールする
最新のサービス パックがインストール済みであることを確認してください。 このマニュアルの説明は、サービス パック 2 (SP2) からの移行を前提として記述されています。
BEA WebLogic 7.0 をインストールしてビルド環境をセットアップする
『WebLogic Platform のインストール』 (http://edocs.beasys.co.jp/e-docs/platform/docs70/install/index.html) と、このマニュアル中で示しているその他のドキュメントの指示に従って、リリース 7.0 をシステムに正しくインストールします。 次の手順に移る前に、インストール環境およびソフトウェアが正しくインストールおよびセットアップされていることを確認してください。
変換されたコード ファイルをその後の移行プロセスで修正、テスト、およびデプロイできるように、.jar ファイルやその他のファイルの作成など、リリース 7.0 のビルド環境システムのセットアップを行います。 これは、ユーザが自分自身で作成して構築する独自のビルド環境です。
警告: 4.0 形式のデータベースに対して create_all スクリプトを実行しないでください。 このスクリプトは、空のデータベースを作成し、そのデータベースを指すようにサーバを設定し、リリース 7.0 が正しくインストールされて稼働していることを移行開始前に確認する目的で実行できます。
注意: リリース 7.0 への WebLogic Portal の移行を終了するまでは、リリース 4.0 のデータベースを指すように設定されていた WebLogic Server 7.0 を実行することはできません。
コード、データ、データベースの完全バックアップを作成する
データベース スキーマを含めて、WebLogic Portal 4.0 システム全体を少なくとも 1 回完全にバックアップします。 移行プロセスが途中で失敗した場合、バックアップした内容を復元して再度移行を行う必要があります。
移行環境をチェックする
WebLogic Server がインストールされているのと同じコンピュータ上に、移行用の各種ファイルがインストールされていることを確認します。 移行時には、BEA ディレクトリ内の weblogic.jar ファイルおよびライセンス ファイルにアクセスできることが必要です。
E-Business Control Center プロジェクトをサーバと同期する
デフォルト コンフィグレーションが取得されるように、必ずすべてのポータル ファイルの最新バージョンをサーバと同期します。
DataMigratorBundle.properties または MigratorBundle.properties の修正有無の判断
これらのファイルは、移行時の重要な処理を制御します。 (任意の順序でタスクを実施できるように) Data Migrator でのタスクをスキップする必要がある場合や、移行ツールを国際化する必要がある場合の手順については、移行ファイルを参照してください。
警告: 一般的な移行では、これらのファイルを修正する必要はありません。 これらのファイルの修正は、熟練した開発者の手で、移行ツールまたは移行プロセスに対して行わなければならない変更がある場合にのみ行うようにしてください。
migrator.bat および migration_install.properties ファイルの編集
以下のようにコンフィグレーション設定を入力します。
コード リスト 2-1 migrator.bat ファイル
echo off
REM --------------------------------------------------------#
REM Migrator Starter Script on Windows #
REM --------------------------------------------------------#
SETLOCAL
set DATABASE=ORACLE_THIN
REM set DATABASE=MSSQL
REM set DATABASE=SYBASE_JCONNECT
REM set DATABASE=DB2_TYPE2
if "%DATABASE%" == "" ( echo "The DATABASE variable must be uncommented in migrator.bat"
exit 1 )
CALL ..¥..¥bin¥win32¥set-environment.bat
REM --------------------------------------------------------#
REM VARIABLES TO SET
REM --------------------------------------------------------#
REM Due to database specifics, you may have to set your
REM path to include dll
REM --------------------------------------------------------#
REM The mini script
REM --------------------------------------------------------#
set MIGRATION_DIR=%WL_COMMERCE_HOME%¥migration
set MIGRATION_LIB=%MIGRATION_DIR%¥lib
set MIG_CLASSPATH=%BEA_HOME%¥lib¥tools.jar;%MIGRATION_LIB%¥migration.jar;%MIGRATION_LIB%¥apache¥xerces-1_4_3¥xerces.jar;%MIGRATION_LIB%¥apache¥xalan-j_2_0_1¥xalan.jar;%MIGRATION_LIB%¥p13n_system.jar;%WEBLOGIC_HOME%¥lib¥weblogic.jar;%BEA_HOME%
REM --------------------------------------------------------#
REM For testing the setup only
REM --------------------------------------------------------#
REM echo BEA_HOME=%BEA_HOME%
REM echo WEBLOGIC_HOME=%WEBLOGIC_HOME%
REM echo WL_COMMERCE_HOME=%WL_COMMERCE_HOME%
REM echo MIGRATION_DIR=%MIGRATION_DIR%
REM echo MIGRATION_LIB=%MIGRATION_LIB%
REM echo MIG_CLASSPATH=%MIG_CLASSPATH%
%JDK_HOME%¥bin¥java -cp %MIG_CLASSPATH% -DMIGRATION_DIR=%migration_dir% com.bea.commerce.migration.tools.Migrator
echo on
注意: Oracle については、database.version の値は「817」だけに設定できます。Oracle 9i を使用する場合も、この設定は「817」のままにします。
SQL Server については、該当するバージョンの行をコメント解除することによって、SQL Server 7 または 2000 からバージョンを選択できます。
server=YOURSERVER の箇所で、データベース サーバの名前を入力します。 たとえば Oracle の場合、システムのコンフィグレーションに応じて、Oracle の SID または netservice 名のどちらかを入力します。
コード リスト 2-2 migration_install.properties ファイル
#################################################################
#
# PROPERTIES TO BE SET BY THE USER AT 'INSTALL' TIME
#
#################################################################
# --------------------------------------------------------------
# When you have set the properties you need, set the
# following flag to 'true' so the migrator tool will start.
# Otherwise, the Migrator will assume you have NOT set
# any property and will refuse to run.
# --------------------------------------------------------------
start_migrator=false
# --------------------------------------------------------------
# Database Properties // uncomment the database you are using
// and enter the appropriate connection values
# --------------------------------------------------------------
# Database connection properties
#
#------Oracle Thin Driver----------------------#
#
# For oracle, replace the following:
# @USER@, @PASSWORD@, @SERVER@, @PORT@, and @SID@
# e.g. jdbc:oracle:thin:@localhost:1521:ORCL
#
database.connection.driver = oracle.jdbc.driver.OracleDriver
database.connection.url = jdbc:oracle:thin:@@SERVER@:@PORT@:@SID@
database.connection.props = user=@USER@;password=@PASSWORD@
#------MS SQL Server ----------------------#
#
# For SQL Server, replace the following:
# @SERVERPORTNUMBER@, @USER@, @PASSWORD@, and @SERVER@ (in two different locations)
#
#database.connection.driver = weblogic.jdbc.mssqlserver4.Driver
#database.connection.url = jdbc:weblogic:mssqlserver4:@SERVER@:@SERVERPORTNUMBER@
#database.connection.props = user=@USER@;password=@PASSWORD@;server=@SERVER@;weblogic.t3.waitForConnection=true;weblogic.t3.waitSecondsForConnection=999999999999;weblogic.jts.waitSecondsForConnectionSecs=999999999999
#------Sybase jConnect 5.2 ----------------------#
#
# For Sybase, replace the following:
# @SERVER@, @PORTNUMBER@, @USER@, and @PASSWORD@
#
#database.connection.driver=com.sybase.jdbc2.jdbc.SybDriver
#database.connection.url=jdbc:sybase:Tds:@SERVER@:@PORTNUMBER@
#database.connection.props = user=@USER@;password=@PASSWORD@;server=@SERVER@;weblogic.t3.waitForConnection=true;weblogic.t3.waitSecondsForConnection=999999999999;weblogic.jts.waitSecondsForConnectionSecs=999999999999
#------IBMS's DB2 ---------------------------------------#
#
# For DB2, replace the following:
# @DB2_DATABASE@, @USER@, and @PASSWORD@
#
#database.connection.driver=COM.ibm.db2.jdbc.app.DB2Driver
#database.connection.url=jdbc:db2:@DB2_DATABASE@
#database.connection.props = user=@USER@;password=@PASSWORD@;server=@SERVER@;weblogic.t3.waitForConnection=true;weblogic.t3.waitSecondsForConnection=999999999999;weblogic.jts.waitSecondsForConnectionSecs=999999999999
#
# Database and version
#
# for Oracle users use database.version=817 for either Oracle 8.1.7 or 9i
database.name=oracle
database.version=817
#database.name=sql_server
#database.version=2000
#database.version=7
#database.name=sybase
#database.version=12
#database.name=db2
#database.version=7
ステップ 2: 4.0 から 7.0 へのデータの移行
この節では、データを 7.0 リリースに移行する方法について説明します。 説明する内容は以下のとおりです。
ツールとプロセスを理解する
この節では、以下のトピックの概要を示します。
移行ツールの機能
移行ツールは、WebLogic Portal バージョン 4.0 から 7.0 へのコードとデータの移行を支援します。 移行ツールは補助ユーティリティであり、コードとデータを移行してコメントを挿入しますが、それによって移行がすべて完了するわけではありません。 移行作業の多くの部分は、担当するチームが人手で行う必要があります。
移行ツールは、稼働中のサーバとのやり取りを必要としないスタンドアロン ツールです。
データ移行プロセスを再確認する
移行プロセスでは、一部のファイルを未変更のまま残す、ファイルの名前を変更する、新しいファイルを作成するなどのさまざまな処理が行われます。 データベースの移行では、リリース 4.0 のテーブルそのものを対象に処理が行われます。リリース 4.0 のテーブルに手を付けずに、新しいリリース 7.0 形式のテーブルの集合を作成するのではありません。
移行の影響を受けるテーブルはバックアップされ、tablename_temp40 のような名前が付けられます。 移行が完了し、システムがリリース 7.0 で正しく機能していることを確認した後で、それらのテーブルを削除することができます。
データ移行ツールのタスクを再確認する
この節では、ツールによって行われるタスクについて説明します。 タスクの実行順は、最後の 2 つを除いてそれほど重要ではありません。 (以下に示す中の)「RDBMS データ同期」タスクが完了していないと、サーバは起動しません。 すべてのタスクが完了するまでは、サーバは正しく機能しません。
E-Business Control Center プロジェクトの移行は個別に行う必要があります。言い換えると、すべてのプロジェクトに対して E-Business Control Center データの移行を一度ずつ実行する必要があります。
以下の手順と説明は、移行ツールを使用してデータ移行を行うときに画面上にも表示されます。
注意: 以前にデータベース テーブルの変更を行った場合、以降のタスクに影響が及ぶ場合があります。ここまでの 2 つのタスクは影響を受けません。
警告: このステップは、次のステップである「資格ルールセット データ(Entitlement Ruleset Data)の移行」の実行後に繰り返すことはできません。
変更が行われたデータベースの手動移行
リリース 4.0 のデータベース テーブルの定義を変更した場合、それらのテーブルの移行を手動で行う必要があります。
注意: これは複雑な手順になる可能性があります。 手動での移行を開始する前に、移行タスク、タスク間の依存関係、関係する SQL の内容について十分に理解しておいてください。 まず、リリース 4.0 のデータのコピーを作り、そのコピーに対して移行を試してみることをお勧めします。
移行ツールを使用して、データベース定義への変更の影響を受けない移行タスクを完了します。 次に、SQL ツールを使用して、変更の影響を受ける一連の移行 SQL 文を実行します。 データ移行ツールのタスクを再確認するに示されている順序の変更を行います。
定義が変更されたデータベースを移行するには、次の手順に従います。
コード リスト 2-3 oracle-817-v4_0to7_0.sql ファイルの一部
-- ===============================
-- ENTITLEMENT_RULESET RDBMS Migration
CREATE TABLE ENTITLEMENT_RULESET_TEMP40 ( APPLICATION_NAME VARCHAR2(100) NOT NULL, RULESET_URI VARCHAR2(254) NOT NULL, RULESET_DOCUMENT CLOB NULL, CREATION_DATE DATE DEFAULT SYSDATE NOT NULL, MODIFIED_DATE DATE DEFAULT SYSDATE NOT NULL)
INSERT INTO ENTITLEMENT_RULESET_TEMP40 ( APPLICATION_NAME, RULESET_URI, RULESET_DOCUMENT, CREATION_DATE, MODIFIED_DATE ) SELECT APPLICATION_NAME, RULESET_URI, RULESET_DOCUMENT, CREATION_DATE, MODIFIED_DATE FROM ENTITLEMENT_RULESET
移行ツールを使用したデータの移行
移行ツールによるデータ移行ステップを完了するには、この節の手順に従います。
警告: PORTAL_HOME¥migration ディレクトリ内の migration_install.properties ファイルの編集が済んでいることを確認します。 適切な情報が入力されていないと、移行ツールを実行しようとしたときにエラー メッセージが表示されます。
データベースを参照および操作するためのツールを使用して、データ移行プロセスの進捗を確認します。 データベースに影響を及ぼすそれぞれのタスクが終了した後で、リリース 4.0 のデータベースを参照し、発生した変化を確認することができます。
注意: 問題が発生した場合、migrator.bat ファイルを開き、すべての設定が正しいことを確認します。
図2-2 データ移行用ウィンドウ
図2-3 E-Business Control Center プロジェクトの移行元ディレクトリの選択
注意: まだ存在していないプロジェクト移行先ディレクトリも指定でき、その場合新しくディレクトリが作成されます。
移行先ディレクトリ内に、移行元と同じ名前と構造のプロジェクト ディレクトリが作成されます。
データ移行ウィンドウ内のメッセージについて メッセージの多くは非常に詳細で、価値のある情報を含んでおり、移行されたファイルまたは新規ファイルが作成されたディレクトリが示されることもあります。 また、移行タスクによって影響を受けるテーブルが列挙されます。 タスクごとのコメント集合の最後に、移行の成否を示すメッセージが表示されます。
migration.log ファイルには、より完全な情報が記録されます。 このファイルには、ウィンドウに表示されたすべてのメッセージだけでなく、スタック トレースなどの補足情報も含まれます。
移行上の問題が発生したことを知らせるその他のメッセージが表示された場合、画面上のエラー メッセージから原因を判断して問題を解決し、タスクを再度実行します。 一部のタスクについては、実行前にデータベースをバックアップから復元する必要があります。そのときは、問題を解決してからタスクを再実行してください。 そのような状況では、ウィンドウのメッセージにもそのことが通知されます。 データベースに対して行った変更が原因で問題が発生した場合の対処については、変更が行われたデータベースの手動移行を参照してください。
最新の XSLT に合わせたイベントの手動更新
WebLogic Portal 4.0 でイベントを使用していない場合、この節を読む必要はありません。
イベントはサイト内の特定の選択肢のクリックなど、ユーザが起こすアクションのことです。 必要に応じて、データベース内でイベントを追跡し、Broadbase などの任意のツールを使用してイベントを分析できます (WebLogic Portal にはイベント用の分析ツールは付属しません)。
7.0 形式で新しいイベント データベースを作成し、そのデータベースでイベントの記録を開始することをお勧めします。 イベントはサード パーティ製のツールで分析されるため、移行は必要ありません。
WebLogic Portal 7.0 でのイベントの記録には、最新の XSLT が使用されます。 Xylon または同様のツールを使用して WebLogic Portal 4.0 のイベント データを最新の形式に更新する場合、付属の .XSL ファイルを使用できます。
図 2-4 に示すように、ファイルは migration.jar ファイルに収められています。 イベントと関係するのは *Event.xsl という名前のファイルです。 新しい XSLT を 4.0 形式のイベント データに適用するには、Xylon またはその他の任意のツールと、*Event.xsl ファイル群を使用します。
図2-4 イベント データ更新用の XSL ファイル
システム移行後の 4.0 形式テーブルの削除 移行プロセスでは、移行中に作成されるバックアップ テーブル(tablename_temp40 のような名前)は削除されません。 移行後のサイトが正常に稼働することをある程度の期間確認したら、これらの 4.0 形式のテーブルを削除してください。
ステップ 3: 4.0 から 7.0 へのコードの移行
コードの移行に際しては、この節の情報を参考にしてください。 この節では、以下の内容について説明します。
注意: 移行プロセスを迅速化するために、複数の人物が同時に移行を実行することができます。 たとえば、ソース コード管理システムを使用する場合、1 人の開発者が、メインのリリース 4.0 ディレクトリの内部のメイン サブディレクトリのそれぞれをチェックアウトし、移行することができます。
警告: ある人物の変更によって別の人物の変更が上書きされることを防ぐには、別の人物が移行を行っているコードのサブディレクトリについて、誰も移行を行っていないことを確認します。
コード移行プロセスの再確認
コード移行ツールは .java ファイルを分析し、必要な変更を行うか、またはコードは更新せずに、変更が必要な箇所に目印となるコメントを挿入します。 変更の種類に関係なく、ファイルにはコメントが挿入されます。 コード移行ツールは移行プロセスを支援しますが、移行を完了する前に、すべてのコード ファイルを人手で見直し、必要であれば変更を加える必要があります。 変更およびコメントの挿入は、ファイルの新しいコピーに対して行われます。このコピーは、移行を開始する前に指定した位置に作成されます。
ツールによる移行が可能なコードの量は、実装によって大きく異なります。
JSP をプリコンパイルし、コード移行ツールを実行し、JSP、タグ、およびその他の関連するコードを適切に更新することによって、標準の .java ファイルおよび JSP の両方を移行することができます。
コード移行ツールは、以下の要素を重点的に分析します。
Migration Viewer の使用
リリース 7.0 でのコードへの変更点は、<PORTAL_HOME>¥migration¥doc ディレクトリ内の migrinfo.html ファイルにまとめられています。 情報を検索およびソートするには、Migration Viewer ツールを使用します。 詳細については、Migration Viewer ツールによるコードへの変更の参照を参照してください。
これは非常に有益な情報であり、このリリースでどのクラス、パッケージ、メソッド、およびその他の API 要素が変更されているかが詳細にまとめられています。 Migration Viewer は、コードおよび JSP を移行する過程で移行ツールと同時に使用します。 移行された個々のファイルの内容と移行に関するコメントを確認する過程で、API への変更にどのように対応しなければならないかを調べるために Migration Viewer を使用します。
コードの移行
この節では、ユーティリティを使用してコードを WebLogic Portal 7.0 に移行する手順を説明します。
図2-5 [Code Migrator] タブ
警告: 複数の人物が同時にコードの移行を行っている場合、ある人物が既に移行を行っているサブディレクトリに対して別の人物がさらに移行を行うことのないように注意してください。
図2-6 外部ビューアのパスの入力
注意: パスの終端のスペースと「%f%」はそのまま残す必要があります。これは、編集対象のコード ファイル名のプレースホルダです。
図2-7 移行されたファイルの一覧とステータス情報
注意: 空の文(多くの場合、静的な初期化ブロックの直後)があるとエラーが報告されます。 migration.log ファイルでエラーの詳細を確認してください。 ログを分析すると、移行中に発生した問題の原因が明らかになります。 空の文が原因でエラーが発生していた場合、空の文を取り除いてからコード移行をもう一度実行します。
注意: Migration Viewer を使用すると、ファイルの移行状況および移行後の各ファイルに挿入されたコメントに基づいて、どのような変更をどのようにして行う必要があるかを判断するのに役立ちます。 Migration Viewer の使用方法の詳細については、Migration Viewer ツールによるコードへの変更の参照を参照してください。
移行されたコード ファイルと挿入されたコメントの例を図 2-8 に示します。
図2-8 コメントが挿入された移行後のコード ファイル
JSP の移行
この節では、リリース 7.0 での JSP (JavaServer Pages) への変更点と、それらの変更に対応して行う必要のある対処について説明します。
注意: 移行が完了した後で、Webflow と JSP をコンフィグレーションするの情報を基に、JSP に対してどのようにして変更を行うかを検討する必要があります。
コード移行ツールで変換または警告が発生しなくなるまで、上記の手順を繰り返します。
JSP の .java ファイルの生成
ステップ 4: その他の WebLogic 製品の移行
前のバージョンの WebLogic Server、WebLogic Integration、またはその他の WebLogic 製品を使用している場合、ここでそれらの製品を移行することをお勧めします。 詳細については、http://edocs.beasys.co.jp/e-docs/platform/docs70/index.html にある、リリース 7.0 への移行に関するマニュアルを参照してください。
WebLogic Platform 7.0 マニュアルの参照
WebLogic Platform 7.0 のマニュアルには、ドメイン別に組織される新しいディレクトリ構造など、WebLogic Server、WebLogic Integration、および WebLogic Workshop に関する、重要かつ有益な情報が収められています。 詳細については、http://edocs.beasys.co.jp/e-docs/platform/docs70/index.html を参照してください。
ステップ 5: 移行されたファイルのアセンブルと追加のコンフィグレーション タスクの実行
すべてのファイルが移行された後で、WebLogic Portal 7.0 環境で機能するように、以下の手順でファイルを配置し、コンフィグレーションする必要があります。
すべてのファイルとデータベースが移行されたことを確認する
この節でのタスクを完了する前に、必要な移行がすべて完了していることを確認します。
新しい 7.0 プロジェクト ディレクトリを作成する
リリース 7.0 ではディレクトリ構造が大きく変化しているため、以下で説明する手順に従って、新しいビルド環境を作成します。
注意: 既存のディレクトリとファイルを再配置するのではなく、新しいドメインを作成しなければなりません。 ユーザの作成や同期などのタスクを行うための Web アプリケーション ツールには大きな変更が加えられており、4.0 バージョンのツールはリリース 7.0 では使用できません。
新しいドメインにファイルを移動する
ディレクトリ構造の詳細については、『WebLogic Server 管理者ガイド』 (http://edocs.beasys.co.jp/e-docs/wls/docs70/adminguide/overview.html) を参照してください。 ドメインの詳細については、『WebLogic Server ドメイン管理』 (http://edocs.beasys.co.jp/e-docs/wls/docs70/admin_domain/index.html) を参照してください。
図 2-9 および図 2-10 に、ディレクトリ構造の変更の要旨を示します。 これを参考にして、移行後のファイルを適切なディレクトリに配置し直してください。
図2-9 WebLogic Portal 4.0 のディレクトリ構造における WebLogic Portal アプリケーション
図2-10 WebLogic Platform 7.0 のディレクトリ構造における WebLogic Portal アプリケーション
Webflow と JSP をコンフィグレーションする この節で示す情報は、標準のポータル Webflow または JSP に対して行った変更との互換性を保ちながら、移行後のポータルに最新の WebLogic Portal 7.0 のポータル機能を取り入れるために役立ちます。 これは手作業でのプロセスであり、その難易度は行った変更の内容によって異なります。 下の各節の指示に従って、適切なコンフィグレーションを行ってください。
コンフィグレーションの必要性の判断
Web アプリケーションでポータルを使用していなかった場合は、この節を読む必要はありません。 Web アプリケーションにポータルが存在するかどうか分からない場合、application-sync/webapps/yourWebAppName ディレクトリに次のファイルがあるかどうかを確認してください。
これらのファイルが存在しない場合は、この節を読む必要はありません。 存在する場合は、次の手順に進んでください。
はじめる前に
WebLogic Portal1 の必須ベース バージョンここでの説明は、WebLogic Portal 4.0 サービス パック 2 からの移行にのみ当てはまります。 サービス パック 1 以前を使用している場合、まず SP2 にアップグレードする必要があります。 SP2 とそれ以前のバージョンの間には、この節で説明する手順に影響する相違点があります。
この節で使用しているディレクトリ変数 この節では、<BEA_HOME>/weblogic700/samples/portal/sampleportalDomain/beaApps ディレクトリを指す目的で <SAMPLE_DIR> 変数を使用しています。
Webflow ファイルのコンフィグレーション
ポータルでは、WebLogic Portal 7.0 への移行時に更新しなければならない 3 つの Webflow ファイルを使用します。 Webflow の名前は security、tools、および user_account です。Portal Web アプリケーションでは portal Webflow も使用されますが、このファイルについてはリリース 4.0 からの変更はありません)。
それぞれの Webflow は、拡張子が .wf の同名のファイルによって表されます。
以前にファイルを変更していない場合 何も行う必要はありません。新しいドメインと作成済みの Web アプリケーションで、新しいバージョンをそのまま使用できます。
以前にファイルを変更した場合 変更されたファイルに対して可能な処置が 2 通りあります。どちらの処置を行うかは、変更の度合いに応じて判断します。
JSP ファイルのコンフィグレーション
ポータル フレームワークを構成する JSP ファイルの一部が、WebLogic Portal 4.0 から WebLogic Portal 7.0 で変更されています。 Web アプリケーションを正しく機能させるためには、これらの変更を Web アプリケーションに適用しなければなりません。 移行後の Web アプリケーションに追加しなければならない新しいファイルもいくつか存在します。
新しいディレクトリ
作成した新しいドメイン内で、Web アプリケーションに 2 つの新しいディレクトリが追加されます。
<WEBAPP>¥registration
<WEBAPP>¥util
新しいファイル
新しいファイルが追加されています。これらのファイルに関して特に必要な作業はありません。
<WEBAPP>¥framework¥tools¥change_name.jsp
<WEBAPP>¥framework¥tools¥change_name.properties
修正されたファイル
次のリストは、WebLogic Portal 7.0 で更新されたファイルの一覧です。 以下の対応が可能です。
ファイルを統合する必要がある場合、コピーする前に個々のファイルを検証し、変更内容をそのまま保持する必要があるかどうかを判断します。 ファイルに何らかの変更を行った場合、7.0 バージョンのファイルとの違いを解決するのはユーザ自身が行う作業となります。 リリース 7.0 の新しいファイルに独自の変更を適用し直すのと、既存のファイルに 7.0 での変更を反映してから変更を行うのとでどちらが簡単かを判断します。
<WEBAPP>¥framework¥edit_titlebar.inc
<WEBAPP>¥framework¥header_links.inc
<WEBAPP>¥framework¥hnav_bar.jsp
<WEBAPP>¥framework¥maximize_titlebar.inc
<WEBAPP>¥framework¥minimize_titlebar.inc
<WEBAPP>¥framework¥normal_titlebar.inc
<WEBAPP>¥framework¥resourceURL.inc
<WEBAPP>¥framework¥titlebar.jsp
<WEBAPP>¥framework¥vnav_bar.jsp
<WEBAPP>¥framework¥security¥badlogin.properties
<WEBAPP>¥framework¥security¥login.properties
<WEBAPP>¥framework¥tools¥portal_prefs.jsp
<WEBAPP>¥framework¥tools¥portal_prefs.properties
<WEBAPP>¥framework¥tools¥select_portal_pages.jsp
<WEBAPP>¥framework¥tools¥select_portal_pages.properties
<WEBAPP>¥framework¥tools¥select_portlets.jsp
<WEBAPP>¥framework¥tools¥select_portlets.properties
<WEBAPP>¥framework¥tools¥select_skins.properties
注意: 移行されたプロジェクトを開こうとして問題が発生した場合、eaprj をチェックします。 「EnterpriseAppRoot」要素が大文字の E で始まっている場合、小文字に変更します。
各ドメインの起動スクリプトでデータベース接続変数の値を設定する
データベース接続情報を含むデータベース情報は、ドメインごとに固有です。 WebLogic Platform 7.0 では、起動スクリプト内でデータベース情報が定義され、set-environment.bat または set-environment.sh が使用する変数に割り当てられるように変更されています。
したがって、WebLogic Server とその他の項目を呼び出す、start-portal.bat などの各起動スクリプトに対して、set-environment スクリプト内で呼び出される変数の定義を設定します。 これは、Domain Wizard によって作成される dbsettings.properties ファイル内で、次のようにしてデータベース接続パラメータの値を編集することによって行います。
mem_args 変数の値を設定する
mem_args 変数はこのリリースで新しく追加され、すべての起動スクリプトに出現します。 この変数の値を設定する必要があります。値を設定しないと移行後のシステムが動作せず、サーバがハングしているように見えます。 この変数は、WebLogic Server によるメモリの処理方法を設定します。
MEM_ARGS="-Xms128m -Xmx128m -XX:MaxPermSize=128m"
起動スクリプトが WebLogic Server を呼び出す方式を変更する
これまでは、各起動スクリプトが WebLogic Server への Java 呼び出しを直接行っていました。 WebLogic Platform 7.0 リリースでは、この方式が変更されました。 個々の起動スクリプトが、次のようにしてサーバを呼び出す必要があります。
call %WLP_HOME%¥bin¥win32¥startWebLogic.cmd
起動スクリプトのサーバ呼び出しを上の行で置き換えます。 WLP_HOME 変数の値は、WebLogic Portal 7.0 のインストール時に設定されます。
config.xml ファイルを編集して 2 フェーズ Mbean デプロイメントを設定する
このリリースでの新機能に、2 フェーズ Mbean デプロイメントがあります。 この機能については、このリリースの WebLogic Server のマニュアル (http://edocs.beasys.co.jp/e-docs/wls/docs70/index.html) で説明しています。
config.xml ファイルを編集して、この機能を取り入れるように WebLogic Portal をセットアップする必要があります。
リスト 2-4に示すように、config.xml ファイルの Application タグに属性を追加します。
注意: 値は true または false に設定できますが、すべてのアプリケーションに対してこの属性が存在しなければなりません。
コード リスト 2-4 config.xml に追加する属性
<Application
Deployed="true" TwoPhase="false"
Name="p13nConsoleApp"
Path="D:/bea/weblogic700/samples/portal/p13nDomain/beaApps/p13nConsoleApp">
<WebAppComponent
Name="p13nConsole"
ServletReloadCheckSecs="300"
Targets="p13nServer"
URI="p13nConsole"
/>
</Application>
データベース情報を config.xml に追加する
適切なデータベース ドライバを使用するように、DOMAIN_DIR/config.xml の内容を修正します。 手順については、『管理者ガイド』 (http://edocs.beasys.co.jp/e-docs/wlp/docs70/index.htm) を参照してください。
デフォルトの commercePool とは別にデータベース接続プールまたはデータ ソースが必要な場合、DOMAIN_DIR/config.xml に追加します。 作成するプールごとに、DOMAIN_DIR/fileRealm.properties に適切な形式の行を必ず追加するようにします。 たとえば、「oraclePool」という名前の接続プールを追加する場合、次のような行を fileRealm.properties に追加します。
acl.reserve.weblogic.jdbc.connectionPool.oraclePool=everyone
コンフィグレーション ファイル内のハードコード化されたパスを更新する
以下のすべてのファイルを検索し、新しいディレクトリ構造に符合するようにパスを更新します。
EJB への参照をコンフィグレーション ファイルに追加する
EJB(存在する場合)と Web アプリケーションのエントリを次のファイルに追加します。
<DOMAIN_DIR>/beaApps/portalApp/application.xml
<DOMAIN_DIR>/config.xml
weblogic-application ファイルをすべてのアプリケーションに追加する
新しい weblogic-application.xml ファイルでは、WebLogic Portal アプリケーションで使用する WebLogic Server の機能を細かく設定することができます。
アプリケーションが動作するためには、このファイルが存在していなければなりません。 このファイルをすべてのアプリケーションの META-INF ディレクトリにコピーします。 コピー先の例を次に示します。
weblogic700¥samples¥portal¥p13nDomain¥beaApps¥p13nApp¥META-INF
このファイルを使用して設定を調整する方法については、WebLogic Server のマニュアル (http://edocs.beasys.co.jp/e-docs/wls/docs70/index.html) を参照してください。
移行後の Web アプリケーション ディレクトリ構造に新しい JAR ファイルをコピーする
アプリケーションに固有でないすべての JAR ファイルを <migrated_webapp>/WEB-INF/lib ディレクトリから削除し、次のディレクトリにあるすべての JAR ファイルで置き換えます。
<WLS_HOME>/weblogic700/samples/portal/sampleportalDomain/beaApps/sampleportal/sampleportal/WEB-INF/lib
WebLogic Server アップグレード(移行)ガイドの指示に従う
http://e-docs.beasys.co.jp/e-docs/wls/docs70/upgrade/index.html を参照して、WebLogic Server のアップグレードに関する指示に従います。 CMP エンティティ Bean の記述子内の EJB-QL の変更点に特に注意します。
Java ソースと EJB のビルドを完了する
Java ソースと EJB のビルドを完了します。 ビルドを実行するためにはビルド スクリプトを使用しなければなりません。
Xerces を使用するためにクラスパスをコンフィグレーションする
ソース ファイルで Xerces パーサを使用する場合、JAR ファイル <WLS_HOME>/weblogic700/lib/xerces.jar をサーバの起動クラスパスに追加します。
移行に関する補足情報をチェックする
移行に関する補足情報は、カスタマサポート (http://websupport.bea.com/welcome.jsp) および BEA dev2dev (http://dev2dev.bea.com/index.jsp) の各 Web サイトで公開されます。
ステップ 6: 4.0 から 7.0 への移行の検証
サーバを起動します。 E-Business Control Center から、または EBCC プロジェクト ディレクトリにある sync.bat ファイルを使用して、datasync を実行します。
ポータル Web アプリケーションが正しく同期されることを確認します。ただしこの後も、グループ ポータルや、ポートレットの可視性およびレイアウトなどのその他の設定を、JSP 管理ツールを使用して再度コンフィグレーションする必要があります。
正しく移行されていれば、この時点でポータルにログインすることができます。
ステップ 7: 次に行うこと
以上で、一通りの移行作業が完了しました。次のステップに進み、移行の細部をチェックして WebLogic Portal 7.0 の使用を開始してください。
オンライン ドキュメント サイト (http://edocs.beasys.co.jp/e-docs/wlp/docs70/index.htm) にアクセスし、製品をより詳しく理解するために必要なマニュアルを入手してください。
![]() |
![]() |
![]() |
![]() |
||
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |