BEA ホーム | 製品 | デベロッパ・センタ | support | askBEA
 ドキュメントのダウンロード   サイト マップ   用語集 
検索

移行ガイド

 前 次 目次 索引 PDFで表示  

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 ファイルの編集

以下のようにコンフィグレーション設定を入力します。

  1. <PORTAL_HOME>¥migration¥bin¥migrator.bat(または migrator.sh)ファイルを開きます。 リスト 2-1 に示すように、使用しているデータベースを示している行をコメントアウトします。

コード リスト 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

  1. <PORTAL_HOME>¥migration¥migration_install.properties ファイルを開きます。リスト 2-2 にファイルの内容を示します。編集する必要のある項目は太字で示しています。

  2. migration_start」の行で、値を true に設定します。

  3. 使用しているデータベース用の設定ブロックで、各行の先頭のコメント記号を外します。 また、その他のデータベースの設定ブロックで、すべての行がコメントアウトされていることを確認します。

  4. リスト 2-2 に示すように、データベース接続プロパティを変更します。

注意: 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 文を実行します。 データ移行ツールのタスクを再確認するに示されている順序の変更を行います。

定義が変更されたデータベースを移行するには、次の手順に従います。

  1. データベースに対して行った変更を一覧にします。

  2. データ移行ツールのタスクを再確認するで、データ移行作業の説明および前提関係に目を通し、データベースに行った変更の影響を受けるタスクを特定します。

  3. 使用しているデータベース用の .sql ファイルを探します。ファイルは <PORTAL_HOME>¥migration ディレクトリに収められています。 .sql ファイルには、処理終了文を除いて、データ移行の各ステップを実行するために必要なすべての SQL 文が入っています。

  4. .sql ファイルから、手順 2 で特定したタスクの箇所を探します。 タスク別の SQL 文のブロックは、次に示すように、タスク名を示すコメント行で始まります。 oracle-817-v4_0to7_0.sql ファイルの一部をリスト 2-3 に示します。

コード リスト 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

  1. 特定したそれぞれのタスクについて、データベース定義の変更内容に合わせて新しい SQL 文を記述するとともに、既存の SQL 文を編集します。 SQL 文を修正する必要のある移行タスク別に、SQL 文のファイルを 1 つずつ作成します。

  2. SQL*Plus などの任意の SQL ツールを使用して、データベースに対して SQL 文を実行します。

移行ツールを使用したデータの移行

移行ツールによるデータ移行ステップを完了するには、この節の手順に従います。

警告: PORTAL_HOME¥migration ディレクトリ内の migration_install.properties ファイルの編集が済んでいることを確認します。 適切な情報が入力されていないと、移行ツールを実行しようとしたときにエラー メッセージが表示されます。

データベースを参照および操作するためのツールを使用して、データ移行プロセスの進捗を確認します。 データベースに影響を及ぼすそれぞれのタスクが終了した後で、リリース 4.0 のデータベースを参照し、発生した変化を確認することができます。

  1. WebLogic Portal サーバを停止します。

  2. まだ作成していない場合、データベースとプロパティ ファイルの両方を含めて、データの完全なバックアップを 2 組作成します。 使用している場合、行動追跡データベースとイベント データベースもバックアップします。

  3. ダブルクリックするかコマンド ラインを使用して、<PORTAL_HOME>¥migration¥bin ディレクトリ内の migrator.bat または migrator.sh ファイルを実行し、移行ツールを起動します。

注意: 問題が発生した場合、migrator.bat ファイルを開き、すべての設定が正しいことを確認します。

  1. まだ前面に表示されていない場合、[Data Migrator] タブをクリックして 図 2-2 のような状態にします。

    図2-2 データ移行用ウィンドウ


     

  2. リストの先頭のタスクを選択して [Execute Task] をクリックします。

  3. 最初のタスクである「E-Business Control Center Data Migration」についてのみ、別のウィンドウが表示されます。 図 2-3 に示すように、最初の E-Business Control Center プロジェクトについて移行元ディレクトリを入力します。 これは通常プロジェクト ディレクトリ、つまり、application-sync ディレクトリの親ディレクトリです。

    図2-3 E-Business Control Center プロジェクトの移行元ディレクトリの選択


     

  4. [E-Business Control Center Project Migration] ウィンドウが表示されたら、3 つのフィールドのそれぞれに適切な値を入力します。

注意: まだ存在していないプロジェクト移行先ディレクトリも指定でき、その場合新しくディレクトリが作成されます。

  1. 表示されるステータス メッセージで、移行の進捗状況を確認します。

    データ移行ウィンドウ内のメッセージについて メッセージの多くは非常に詳細で、価値のある情報を含んでおり、移行されたファイルまたは新規ファイルが作成されたディレクトリが示されることもあります。 また、移行タスクによって影響を受けるテーブルが列挙されます。 タスクごとのコメント集合の最後に、移行の成否を示すメッセージが表示されます。

    migration.log ファイルには、より完全な情報が記録されます。 このファイルには、ウィンドウに表示されたすべてのメッセージだけでなく、スタック トレースなどの補足情報も含まれます。

    移行上の問題が発生したことを知らせるその他のメッセージが表示された場合、画面上のエラー メッセージから原因を判断して問題を解決し、タスクを再度実行します。 一部のタスクについては、実行前にデータベースをバックアップから復元する必要があります。そのときは、問題を解決してからタスクを再実行してください。 そのような状況では、ウィンドウのメッセージにもそのことが通知されます。 データベースに対して行った変更が原因で問題が発生した場合の対処については、変更が行われたデータベースの手動移行を参照してください。

  2. その他すべての E-Business Control Center プロジェクトを移行します。

  3. [Next Task] をクリックし、次の移行タスクに進みます。

  4. タスクが問題なく完了したら、[Next Task] をクリックします。 以後、すべてのタスクが完了するまでこの手順を繰り返します(MigratorBundle.properties および DataMigratorBundle.properties ファイルで説明されているように、DataMigratorBundle.properties を編集することによってタスクを省略した場合、リスト内のそれらのタスクをスキップできます。それ以外の場合は、すべてのタスクを順番に実行しなければなりません)。

最新の 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 に移行する手順を説明します。

  1. 移行ユーティリティをまだ実行していない場合、¥migration¥bin ディレクトリにある migrator.bat または migrator.sh ファイルをダブルクリックして起動します。

  2. まだ前面に表示されていない場合、[Code Migrator] タブをクリックして図 2-5 のような状態にします。

    図2-5 [Code Migrator] タブ


     

  3. 移行元ディレクトリと移行先ディレクトリを指定します。

警告: 複数の人物が同時にコードの移行を行っている場合、ある人物が既に移行を行っているサブディレクトリに対して別の人物がさらに移行を行うことのないように注意してください。

  1. 図 2-6 に示すように、コード ファイルの表示および編集に使用するエディタ プログラムのパスを入力します。 エディタを登録すると、移行を行った後で、コード移行ツール ウィンドウの下部にあるリスト内でファイルを選択することによってコード ファイルを開けるようになります。

    図2-6 外部ビューアのパスの入力


     

注意: パスの終端のスペースと「%f%」はそのまま残す必要があります。これは、編集対象のコード ファイル名のプレースホルダです。

  1. 移行が完了すると、移行されたファイルの一覧がウィンドウの下半分に表示されます。 ウィンドウ内でファイル名をダブルクリックすると、登録しておいたエディタでファイルを開くことができます。

  2. 移行プロセスでは、移行元ディレクトリ内のすべてのコードが 1 回のプロセスで移行されます。ファイルを 1 つずつ移行する必要はありません。 プロセスの進行中は、ステータス メッセージと移行処理中のファイルの名前が画面に表示されます。

    移行元ディレクトリ全体を移行する準備ができたら、[Start Code Migration Helper] をクリックします。

    エラーが発生した場合、PORTAL_HOME¥migration ディレクトリ内の migration.log ファイル、画面上のステータス メッセージ、および、移行後のコード ファイルに挿入された移行に関するコメントを参考にして問題を解決します。

  3. 移行プロセスが完了すると、移行処理中に発生した問題、ファイル変更の有無などの情報とともにファイルの一覧が表示されます。図 2-7 に例を示します。

    図2-7 移行されたファイルの一覧とステータス情報


     

    各ファイルの移行結果は、0 〜 3 のレベルで示されます。レベル 3 は、人手による確認および追加の変更の必要性が最も高いことを示します。以下、それぞれのレベルについての説明です。

注意: 空の文(多くの場合、静的な初期化ブロックの直後)があるとエラーが報告されます。 migration.log ファイルでエラーの詳細を確認してください。 ログを分析すると、移行中に発生した問題の原因が明らかになります。 空の文が原因でエラーが発生していた場合、空の文を取り除いてからコード移行をもう一度実行します。

  1. 移行先ディレクトリで、移行されたそれぞれのファイルについて挿入されたコメントを確認し、必要であればコメントに従ってさらに変更を行います。

注意: Migration Viewer を使用すると、ファイルの移行状況および移行後の各ファイルに挿入されたコメントに基づいて、どのような変更をどのようにして行う必要があるかを判断するのに役立ちます。 Migration Viewer の使用方法の詳細については、Migration Viewer ツールによるコードへの変更の参照を参照してください。

移行されたコード ファイルと挿入されたコメントの例を図 2-8 に示します。

図2-8 コメントが挿入された移行後のコード ファイル


 

  • 各ファイルの移行が完了したら、移行ユーティリティのウィンドウで、そのファイルの [Reviewed] カラムがチェックされていることを確認します。
  • JSP の移行

    この節では、リリース 7.0 での JSP (JavaServer Pages) への変更点と、それらの変更に対応して行う必要のある対処について説明します。

    注意: 移行が完了した後で、Webflow と JSP をコンフィグレーションするの情報を基に、JSP に対してどのようにして変更を行うかを検討する必要があります。

    1. それぞれの JSP に対して .javaファイルを作成します (2 通りある作成方法については、JSP の .java ファイルの生成を参照してください)。

      アプリケーションの WEB-INF ディレクトリで始まるパスに .java ファイルが作成されます。 たとえば、JSP の位置が mywebapp¥myJSPs¥JSPfilenames.JSP である場合、生成される .java ファイルは WEB-INF¥_tmp*¥jsp_compiled¥_myJSPs¥*JSPfilename.java になります。

    2. コードの移行の手順に従って、生成された .java ファイルに対してコード移行ツールを実行します。 移行先ディレクトリとして、PORTAL_HOME ディレクトリの外部のディレクトリを選択します。

      移行された JSP の確認と変更を行う前に、PORTAL_HOME ディレクトリ内の適切なディレクトリに JSP を移動する必要があります。 変更内容が有効であることを検証するには、JSP をリリース 7.0 の環境に配置する必要があります。 通常、この配置先は <PORTAL_HOME>¥applications¥wlcsApp-project¥webappdir¥ です。

    3. 移行されたそれぞれの .java ファイルについて、挿入されたコメントと行われた変更を確認します。 .java ファイルに挿入された移行に関する注記(コメント)には、JSP 内で対応する箇所の行番号が示されます。各 .java ファイルの先頭には、対応する JSP ファイルの名前とパスが付加されます。

    4. JSP に必要な変更を行います。

    コード移行ツールで変換または警告が発生しなくなるまで、上記の手順を繰り返します。

    JSP の .java ファイルの生成

    2 通りの方法で行うことができます。

    <!-- JSP configuration -->

    <jsp-descriptor>

    <jsp-param>

    <param-name>keepgenerated</param-name>

    <param-value>true</param-value>

    </jsp-param>

    </jsp-descriptor>

     


    ステップ 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 環境で機能するように、以下の手順でファイルを配置し、コンフィグレーションする必要があります。

    1. すべてのファイルとデータベースが移行されたことを確認する

    2. 新しい 7.0 プロジェクト ディレクトリを作成する

    3. 新しいドメインにファイルを移動する

    4. Webflow と JSP をコンフィグレーションする

    5. 各ドメインの起動スクリプトでデータベース接続変数の値を設定する

    6. mem_args 変数の値を設定する

    7. 起動スクリプトが WebLogic Server を呼び出す方式を変更する

    8. config.xml ファイルを編集して 2 フェーズ Mbean デプロイメントを設定する

    9. データベース情報を config.xml に追加する

    10. コンフィグレーション ファイル内のハードコード化されたパスを更新する

    11. EJB への参照をコンフィグレーション ファイルに追加する

    12. weblogic-application ファイルをすべてのアプリケーションに追加する

    13. 移行後の Web アプリケーション ディレクトリ構造に新しい JAR ファイルをコピーする

    14. WebLogic Server アップグレード(移行)ガイドの指示に従う

    15. Java ソースと EJB のビルドを完了する

    16. Xerces を使用するためにクラスパスをコンフィグレーションする

    17. 移行に関する補足情報をチェックする

    すべてのファイルとデータベースが移行されたことを確認する

    この節でのタスクを完了する前に、必要な移行がすべて完了していることを確認します。

    新しい 7.0 プロジェクト ディレクトリを作成する

    リリース 7.0 ではディレクトリ構造が大きく変化しているため、以下で説明する手順に従って、新しいビルド環境を作成します。

    1. すべてのビルド スクリプトを含む新しいプロジェクト ディレクトリを作成します。

    2. 作成したプロジェクト ディレクトリで Configuration Wizard を実行し、プロジェクトに新しいドメインを作成します。 作成するドメインは必ず WebLogic Portal ポータル ドメインとします。ウィザードを使用すると、さまざまな種類のドメインを作成できます。

      Configuration Wizard の詳細については、『コンフィグレーション ウィザードの使い方』 (http://edocs.beasys.co.jp/e-docs/platform/docs70/confgwiz/index.html) を参照してください。

    注意: 既存のディレクトリとファイルを再配置するのではなく、新しいドメインを作成しなければなりません。 ユーザの作成や同期などのタスクを行うための Web アプリケーション ツールには大きな変更が加えられており、4.0 バージョンのツールはリリース 7.0 では使用できません。

    新しいドメインにファイルを移動する

    1. 移行されたすべての Java ソース ファイルを、新しいプロジェクトの所定のディレクトリにコピーします。

    2. 移行を行っている Web アプリケーションのディレクトリを、Configuration Wizard で作成したエンタープライズ アプリケーション ディレクトリにコピーします。 たとえば、Configuration Wizard で DOMAIN_DIR/beaApps/portalApp というディレクトリを作成したとします。 この場合、Web アプリケーション ディレクトリを portalAppディレクトリにコピーします。

    3. ポータル Web アプリケーションでのみ使用する E-Business Control Center プロジェクト ファイルを、移行後の E-Business Control Center データ ファイル ディレクトリから、Configuration Wizard によって作成された E-Business Control Center プロジェクト ディレクトリに手動でコピーします。 コピー先のディレクトリは DOMAIN_DIR/beaApps/portalApp-project です。 対象の Web アプリケーションのファイルだけをコピーします。Web アプリケーションがポータルである場合にのみ存在する tools Web アプリケーションなど、その他の Web アプリケーションのファイルはコピーしません。 次に示したのは、その内部の一部またはすべてのファイルをコピーすることが推奨されるディレクトリの例です。

      application-sync¥pipelines
      application-sync¥entitlements
      application-sync¥entitlements¥GlobalEntitlements
      application-sync¥Portlets
      application-sync¥userprofiles
      application-sync¥webapps¥
      your_web_app

    ディレクトリ構造の詳細については、『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 の名前は securitytools、および 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 ファイル内で、次のようにしてデータベース接続パラメータの値を編集することによって行います。

    1. 使用しているデータベース用の情報を定義している行をコメント解除します。

    2. データベース接続変数の正しい値を入力します(@variablename@ の代わりに正しい値を入力します)。

    mem_args 変数の値を設定する

    mem_args 変数はこのリリースで新しく追加され、すべての起動スクリプトに出現します。 この変数の値を設定する必要があります。値を設定しないと移行後のシステムが動作せず、サーバがハングしているように見えます。 この変数は、WebLogic Server によるメモリの処理方法を設定します。

    1. 適切な量のメモリを割り当てます。 次の例は、メモリを 128MB RAM に設定する方法を示しています。
      MEM_ARGS="-Xms128m -Xmx128m -XX:MaxPermSize=128m"

    2. アプリケーションごとに適した値を選択します。 Hotspot VM エラーでサーバがロックアップまたはクラッシュする場合、この数値を大きくする必要があります。 この現象は Hotspot VM の問題が原因で発生します。

    起動スクリプトが 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) にアクセスし、製品をより詳しく理解するために必要なマニュアルを入手してください。

     

    ページの先頭 前 次