Sun Identity Manager 8.1 アップグレード

タスク 6: 開発環境のアップグレード

次の各ステップを開発環境で実行する必要があります。

注 –

環境をアップグレードするときには、次のいくつかのステップを実行する必要があります。ただし、これは、Identity Manager アプリケーションに合わせてベースラインを更新する環境なので、次のステップの多くは開発環境に固有です。

ステップ 1: Active Sync と調整の停止

Active Sync プロセスを手動開始に設定し、必要に応じて、アップグレードが正常に完了するまで、計画済みの調整を無効にします。

ヒント –

ステップ 1 は省略可能ですが、本稼働環境をアップグレードするときのベストプラクティスと考えられています。

また、本稼働環境でステップ 1 を実行する場合は、その他すべての環境をアップグレードするときの標準ステップとしてください。

ステップ 2: Identity Manager アプリケーションの停止

Identity Manager アプリケーションを休止して、すべての管理者とエンドユーザーから使用できないようにします。

ステップ 3: Identity Manager アプリケーションのバックアップ

既存のデータベースと Identity Manager のファイル構造のコピーを作成します。

データベースとファイル構造をバックアップすることにより、必要に応じて作業環境を復元できます。

ステップ 4: ホットフィックスの削除

WEB-INF/classes ディレクトリからホットフィックスのクラスファイルを削除します。

通常、ホットフィックスのクラスファイルは、そのホットフィックスが配布された Identity Manager 製品の特定バージョンでのみ動作します。

ステップ 5: スナップショット作成

既存の構成オブジェクトのコピーを作成します。また、リポジトリにある他のタイプのオブジェクトのコピー、または少なくともそれらのオブジェクトの代表サンプルのコピーを作成します。

Identity Manager 製品をアップグレードすることにより、JSP ファイルなど、Identity Manager 製品が上に重なるファイルシステムのアーティファクトが保存されますが、アップグレードではリポジトリ内で変更する各オブジェクトの「以前のイメージ」は保持しません。スナップショットを作成することにより、Identity Manager 製品のアップグレードによるリポジトリオブジェクトに対する変更内容を検出できます。

スナップショットを作成するには

次に、Identity Manager のスナップショット機能を使用して、配備内のカスタマイズ済みリポジトリオブジェクトのベースラインを作成する方法、および 2 つのスナップショットを比較して、アップグレードの前後に特定のシステムオブジェクトに対して実行された変更内容を特定する方法を説明します。

注 –

スナップショット機能は、進行中の XML の詳細な違いを対象とするものではありません。これは「最初の実行」での比較を行うための最小のツールにすぎません。

Identity Manager の「デバッグ」ページにある「スナップショット」ボタンをクリックして、「SnapShot Management」ページを表示します。

「作成」フィールドにスナップショットの名前を入力して、「作成」ボタンをクリックします。

Identity Manager がスナップショットを追加すると、そのスナップショットの名前が、「比較」メニューリスト、および「エクスポート」ラベルの右側に表示されます。

2 つのスナップショットを比較するには、次の操作を行います。
1. 2つの「比較」メニューから、それぞれスナップショットを選択します。
2. 「比較」ボタンをクリックします。
  - 変更されたオブジェクトがない場合は、差が検出されなかったことを示すメッセージが表示されます。
  - オブジェクトの変更が検出された場合は、メッセージにオブジェクトのタイプと名前が表示され、オブジェクトが異なる、実在しない、実在するのいずれであるかが示されます。
    
    たとえば、baseline_1 にはオブジェクトが存在するが、baseline_2 には存在しない場合、「baseline_1」列には「Present」、「baseline_2」列には「Absent」が示されます。

スナップショットを XML 形式でエクスポートする場合は、スナップショットの名前のリンクをクリックします。

スナップショットを削除する場合は、「削除」メニューからスナップショットを選択して「削除」をクリックします。

ステップ 6: プラットフォームの更新

Identity Manager 製品のターゲットバージョンでプラットフォームの変更が必要な場合、それらの変更を行ってから Identity Manager 製品をアップグレードする必要があります。

JDK または JRE をアップグレードする場合は、使用中の JDK と同じベンダーから提供される JDK または JRE を使用する必要があります。たとえば、これまで IBM の JDK を使用していた場合は、Sun JDK をインストールしないでください。

注意 –

Oracle のリポジトリを使用している場合、Identity Manager のリポジトリの DDL は、古い Oracle JDBC ドライバでは適切に処理されないデータ型を使用します。ojdbc14.jar に含まれる JDBC ドライバは、ログテーブルの一部の列を正しく読み取ることができません。

Identity Manager を正しく動作させるには、JDK 5 ドライバを ojdbc5.jar にアップグレードする必要があります。

ステップ 7: Identity Manager 製品のアップグレード

Identity Manager の製品自体をアップグレードするには、次の操作が必要な場合があります。

リポジトリのデータベーステーブル更新

Identity Manager のメジャーリリースの多く、および一部のマイナーリリースでは、データベーステーブルが変更されています。このため、環境に合わせて SQL のサンプルスクリプトの変更が必要な場合があります。

また、次の変更を行った場合は、データベーステーブルも更新する必要があります。

データベースインスタンスの名前の変更
データベーステーブルを所有するデータベースアカウントの名前の変更
データベースへの接続に使用するデータベースアカウントから、データベーステーブルの所有者の分離
異なるテーブルやインデックスのセットについて特定のテーブル空間や増加特性を構成するなど、より高度な DBA の変更

Identity Manager の各バージョンについて、SQL のサンプルスクリプトに対する変更内容を記録しておき、ソース管理を使用してそれらの変更内容を管理する必要があります。将来、Identity Manager の後続バージョンに対して、同様の変更が必要になります。

Identity Manager 製品のアップグレード

Identity Manager 製品をアップグレードするには、次のいずれかの方法を使用できます。

Identity Manager インストーラプログラムを使用します (「Identity Manager インストーラの使用法」を参照)。
Identity Manager の手動アップグレードプロセスを使用します (「手動によるアップグレード」を参照)。

両方の方法の結果は同じです。

注 –

一部の環境では、手動アップグレード手順が望ましい場合があります。たとえば、次のとおりです。

繰り返し可能なアップグレード手順の一部として、アップグレードをフルに自動化する場合
本稼働環境へのアクセスが制限されている場合やコンソールを起動できない場合

Identity Manager 製品のアップグレードにより、Identity Manager リポジトリオブジェクト、および .jsp ファイル、Identity Manager 製品の JAR、他社製の JAR などファイルシステムの一部のアーティファクトが変更されることがあります。.

Identity Manager 製品をアップグレードするときには、次の点に注意してください。

インストールメディアから実際に使用する場所にファイルをコピーする場合、idm.war と install.class のファイルを同じディレクトリに入れる必要があります。
アップグレード時には、Identity Manager サーバーを 1 台のみ使用して update.xml をインポートし、Identity Manager サーバーを 1台のみ稼働します。

アップグレード中にほかの Identity Manager サーバーを起動する場合は、それらのサーバーを停止して再起動してから、使用可能な状態にする必要があります。
アプリケーションサーバーが、UNIX® システムを実行するマシンにインストールされている場合は、ディレクトリを $WSHOME/bin ディレクトリに変更し、次のコマンドを実行して、このディレクトリ内のスクリプトを実行可能にします。
```
chmod -R +x *
```
UNIX 環境では、次のいずれかの位置に install ディレクトリがあること、およびそのディレクトリに書き込む権限があることを確認します。

Linux/HP-UX の場合

/var/opt/sun/install

Solaris^TM の場合

/var/sadm/install

以前インストール済みのホットフィックスは $WSHOME/ patches/HotfixName ディレクトリにアーカイブされています。
アップグレードプログラムには、アップグレード前処理ステップ、アップグレードステップ、アップグレード後処理ステップの3つのステップがあります。アップグレード後処理ステップは個別の Java 仮想マシンで実行され、このステップのデフォルトのヒープサイズは 1024 Mバイトです。アップグレード時にメモリ不足の例外が発生する場合は、この値を高く設定してください。カスタム値を設定するには、—Xmx <heap size> の書式を使用して、 JAVA_OPTS 環境変数を設定します。「heap size」は、2048m のような値です。たとえば、-Xmx2048m のように指定します。

Identity Manager インストーラの使用法

Identity Manager のインストールおよびアップグレードのプログラムを使用して、開発環境をアップグレードします。

インストーラを起動するには、次のいずれかの方法を使用します。
- GUI インストーラを使用するには、 install.bat ( Windows) または install (UNIX) を実行します。
  
  インストーラの開始画面が表示されます。
- nodisplay モードでインストーラを起動するには、ソフトウェアのあるディレクトリに移動して、次のコマンドを入力します。
  
  install -nodisplay
  
  インストーラの開始テキストが表示され、次に GUI インストーラと同じ順序で、インストール情報を収集するための質問リストが表示されます。
  
  ディスプレイ装置がない場合は、インストーラはデフォルトで nodisplay オプションを使用します。
  
  インストーラは、ソフトウェアの旧バージョンを新バージョンの後にインストールしません。この場合、エラーメッセージが表示され、インストーラは終了します。

開始画面の「次へ」をクリックします。

「Install or Upgrade?」画面の「アップグレードする」を選択して、「次へ」をクリックします。

「インストールディレクトリを選択します」画面で、Identity Manager の旧バージョンがあるディレクトリを選択して、「次へ」をクリックします。

インストーラにアップグレード前処理とアップグレード後処理の進捗バーが表示され、その後「インストール構成の確認」画面に進みます。

インストールの詳細については、「詳細」をクリックしてログファイルを表示し、その後「閉じる」をクリックしてインストーラを終了します。

アプリケーションサーバーの作業ディレクトリからコンパイル済みの Identity Manager ファイルをすべて削除します。

手動によるアップグレード

一部の環境では、Identity Manager のインストールおよびアップグレードのプログラムを使用せずに、手動でアップグレードを実行する場合があります。

JAVA_HOME 環境変数を必ず設定してください。
JAVA_HOME ディレクトリの bin ディレクトリを、必ずパスに入れてください。
以前インストール済みのホットフィックスは、 $WSHOME/patches/HotfixName ディレクトリにアーカイブされます。

注 –

この節の操作方法は、Identity Manager を Tomcat アプリケーションサーバーにインストールする場合のものです。使用しているアプリケーションサーバーにより、多少異なるコマンドの使用が必要な場合があります。

アプリケーションサーバーに固有の操作方法については、『Sun Identity Manager 8.1 Installation』のパート II「Installing Identity Manager」の該当する章を参照してください。

Windows プラットフォームで手動アップグレードを実行するには

サポートする Windows プラットフォームで Identity Manager を手動でアップグレードするには、次の手順を実行します。

アプリケーションサーバーと Gateway を停止します。.

Identity Manager のデータベースを更新します。

次のコマンドを入力して、環境を設定します。
set ISPATH=Path-to-install-software set WSHOME=Path-to-Identity-Manager-Installation OR Staging-Directory set TEMP=Path-to-Temporary-Directory
注 –
Identity Manager のインストールディレクトリへのパスにスペースがある場合は、次の例に示すように、WSHOME 環境変数を二重引用符 (") で囲まずに指定する必要があります。

パスにスペースがない場合でも、パスを指定するときには、末尾にバックスラッシュ (\) を使用しないでください。
set WSHOME=c:\Program Files\Apache Group\Tomcat 6.0\idm
または
set WSHOME=c:\Progra~1\Apache~1\Tomcat~1\idm
次のパスの指定は正しくありません。
set WSHOME="c:\Program Files\Apache Group\Tomcat 6.0\idm"

前処理を実行します。

mkdir %TEMP%
cd /d %TEMP%
jar -xvf %ISPATH%\IDM.WAR\
WEB-INF\lib\idm.jar WEB-INF\lib\idmcommon.jar
set TMPLIBPTH=%TEMP%\WEB-INF\lib
set CLASSPATH=%TMPLIBPTH%\idm.jar;\
%TMPLIBPTH%\idmcommon.jar;
java -classpath %CLASSPATH% -Dwaveset.home=%WSHOME%\
   com.waveset.install.UpgradePreProcess

ソフトウェアをインストールします。
cd %WSHOME% jar -xvf %ISPATH%\IDM.WAR

後処理を実行します。
java -classpath %CLASSPATH% -Dwaveset.home=%WSHOME% com.waveset.install.UpgradePostProcess
注 –
- アップグレードの後処理ステップは、個別の Java 仮想マシンで実行されます。このステップのデフォルトのヒープサイズは 1024 Mバイトです。このステップでメモリ不足の例外が発生する場合は、ヒープサイズの最大値を高く設定してください。カスタム値を設定するには、—Xmx <heap size> の書式を使用して、JAVA_OPTS 環境変数を設定します。「heap size」は、2048m のような値です。たとえば、-Xmx2048m のように指定します。
- インストーラは、デフォルトの Configurator アカウントの名前が変更されていたり、アカウントが削除されていたり、無効になっていたりするインストール環境に対してもアップグレードインストールをサポートしています。
  
  アップグレードの後処理で、 update.xml をインポートするために、インストーラはユーザー名とパスワードの入力を要求します。ユーザー名またはパスワードが正しく入力されない場合、正しいユーザー名またはパスワードを入力するように要求されます (最大 3 回)。このエラーは、インストーラのテキストボックスに表示されます。
  
  手動インストールの場合、 -U username -P password のフラグを指定して、認証情報を UpgradePostProcess 手続きに渡す必要があります。

ステージングディレクトリにインストールした場合は、アプリケーションサーバーへの配備用 .war ファイルを作成します。

アプリケーションサーバーの作業ディレクトリから Identity Manager のファイルを削除します。

UNIX プラットフォームで手動アップグレードを実行するには

サポートする UNIX プラットフォームで Identity Manager を手動でアップグレードするには、次のステップを実行します。

アプリケーションサーバーと Gateway を停止します。.

Identity Manager のデータベースを更新します。

環境を設定します。

export ISPATH=Path-to-Install-Software export WSHOME=Path-to-Identity-Manager-Installation-or-Staging Directory 
export TEMP=Path-to-Temporary-Directory

前処理を実行します。

mkdir $TEMP
cd $TEMP
jar -xvf $ISPATH/idm.war \
WEB-INF/lib/idm.jar WEB-INF/lib/idmcommon.jar
CLASSPATH=$TEMP/WEB-INF/lib/idm.jar:\
$TEMP/WEB-INF/lib/idmcommon.jar:
java -classpath $CLASSPATH -Dwaveset.home=$WSHOME \
com.waveset.install.UpgradePreProcess

ソフトウェアをインストールします。
cd $WSHOME jar -xvf $ISPATH/idm.war

後処理を実行します。
java -classpath $CLASSPATH -Dwaveset.home=$WSHOME com.waveset.install.UpgradePostProcess
注 –
- アップグレードの後処理ステップは、個別の Java 仮想マシンで実行されます。このステップのデフォルトのヒープサイズは 1024 Mバイトです。このステップでメモリ不足の例外が発生する場合は、ヒープサイズの最大値を高く設定してください。カスタム値を設定するには、—Xmx <heap size> の書式を使用して、JAVA_OPTS 環境変数を設定します。「heap size」は、2048m のような値です。たとえば、-Xmx2048m のように指定します。
- インストーラは、デフォルトの Configurator アカウントの名前が変更されていたり、アカウントが削除されていたり、無効になっていたりするインストール環境に対してもアップグレードインストールをサポートしています。
  
  アップグレードの後処理で、 update.xml をインポートするために、インストーラはユーザー名とパスワードの入力を要求します。ユーザー名またはパスワードが正しく入力されない場合、正しいユーザー名またはパスワードを入力するように要求されます (最大 3 回)。このエラーは、インストーラのテキストボックスに表示されます。
  
  手動インストールの場合、 -U username -P password のフラグを指定して、認証情報を UpgradePostProcess 手続きに渡す必要があります。

ディレクトリを $WSHOME/bin/solaris または $WSHOME/bin/linux に変更し、そのディレクトリ内のファイルを実行できるように、それらのファイルのアクセス権を設定します。

ステージングディレクトリにインストールした場合は、アプリケーションサーバーへの配備用 .war ファイルを作成します。

アプリケーションサーバーの作業ディレクトリから Identity Manager のファイルを削除します。

アップグレードのトラブルシューティング

アップグレード時に問題が発生した場合は、$WSHOME/patches/ logs ディレクトリにあるアップグレードのログファイルをチェックします。ログファイルの名前は、アップグレードのタイムスタンプとステージに基づきます。

すべての Gateway インスタンスのアップグレード

環境にインストール済みの Sun Identity Manager Gateway をすべてアップグレードします。Identity Manager サーバーの新バージョンは、Gateway の旧バージョンとは動作しません。

Identity Manager Gateway をアップグレードするには

Windows システムにログインして、Gateway がインストールされているディレクトリに移動します。

Gatewayサービスを停止します。
gateway -k

少なくとも Windows 2000 を使用している場合は、サービスの MMC プラグインのインスタンスをすべて終了します。

Gateway サービスを削除します。
gateway -r

既存の Gateway ファイルをバックアップして、削除します。

新規の Gateway ファイルを抽出します。

Identity Manager サーバー以外のシステムに Gateway の新規アップグレードをインストールする場合は、Identity Manager のインストールパッケージから gateway.zip ファイルをコピーします。

Gateway がインストールされていたディレクトリに、 gateway.zip ファイルを展開します。

Gateway サービスをインストールします。
gateway -i

Gateway サービスを開始します。
gateway -s

すべての PasswordSync インスタンスのアップグレード

リリースノートに特記されていない限り、新規にインストールした Identity Manager サーバーのバージョンは、旧バージョンの PasswordSync を一時的に制限付きでサポートします。このサポートは、PasswordSync インスタンスをアップグレードしている間に、Identity Manager の実行を継続できるようにするためのものです。PasswordSync のすべてのインスタンスを、できるだけ早く Identity Manager サーバーと同じバージョンに更新してください。

PasswordSync をアップグレードするには、環境にインストール済みの PasswordSync をすべてアンインストールして、再起動する必要があります。削除を正常に実行するには、Windows の「コントロールパネル」の「プログラムの追加と削除」機能を使用します。

個々の旧バージョンの代わりに新バージョンの PasswordSync をインストールして、再起動します。インストール先のオペレーティングシステムに対応するバイナリファイルを使用します。32 ビット Windows のバイナリは IdmPwSync_x86.msi、64 ビット Windows のバイナリは IdmPwSync_x64.msi という名前です。

注 –

PasswordSync のアンインストール後に 1 回、新バージョンのインストール後に 1回、合計で Windows を 2 回再起動する必要があります。再起動が 2 回必要な理由は、Windows Security Service が PasswordSync の DLL をロードする方法にあります。

インストール方法については、『Sun Identity Manager 8.1 ビジネス管理者ガイド』の「Windows での PasswordSync のインストールと設定」を参照してください。

ステップ 8: もう 1 つのスナップショットの作成

Identity Manager を正常にアップグレードしたら、既存の構成オブジェクトのコピーを作成します。また、リポジトリ内のほかのタイプのオブジェクトのコピー、または少なくともそれらのオブジェクトの代表サンプルのコピーを作成します。

Identity Manager 製品のアップグレードでは、リポジトリのオブジェクトに対する変更内容は記録されません。このスナップショットを、アップグレード前のスナップショットと比較することにより、アップグレードによるリポジトリオブジェクトに対する変更内容を容易に検出できます。

ステップ 9: 変更内容を解析する

Identity Manager 製品のアップグレードによる変更内容を解析し、それに合わせて構成とカスタマイズを更新する必要があります。たとえば、次のとおりです。

JSP ファイルまたはスタイルシートを変更した場合は、それらの変更内容を新規の JSP ファイルまたはスタイルシートにマージする必要があります。
お使いの Identity Manager アプリケーションベースラインに Identity Manager 製品の JAR やサードパーティの JAR が含まれる場合は、ベースラインのそれらの JAR の更新も必要なことがあります。また、ベースラインには、データベーステーブルの作成や更新に使用した SQL スクリプトも含める必要があります。
Identity Manager のデフォルトオブジェクト (デフォルトユーザーフォームなど) を変更した場合は、アップグレードプロセスでそれらのオブジェクトが savedObjects ディレクトリに移動されます。以降のアップグレードを容易にするには、変更済みのオブジェクトの名前をカスタム名に変更し、そのカスタム名を SystemConfiguration オブジェクト内で参照します。
WPMessages.properties を /config ディレクトリに抽出して、メッセージをカスタマイズした場合には、再度抽出を行ってそれらのカスタマイズを再適用する必要があります。

Identity Manager 製品のアップグレード時に行われたリポジトリオブジェクトに対する変更内容を注意して解析する必要があります。たとえば、次のとおりです。

Identity Manager 製品のアップグレードでソース管理ベースライン内の構成オブジェクトが変更された場合は、それらの変更内容を構成ベースラインにマージする必要があります。詳細については、「ステップ 14: 変更内容のソース管理へのマージ」を参照してください。
Identity Manager 製品のアップグレードで、現在のベースラインに含まれていない構成オブジェクトが変更された場合は、これらの構成オブジェクトをアプリケーションベースラインに追加する必要があります。これらの構成オブジェクトをアプリケーションベースラインに追加しない場合は、アップグレード手順で各環境にインポートされる update.xml のサブセットに、適切なオブジェクトやコマンドを含めるなど、それらの変更内容を組み込む他の方法を計画する必要があります。

ヒント –

これらのオブジェクトの変更を無視しても問題がないと判断することもできますが、多くの場合、これらの構成オブジェクトをベースラインに追加することがベストプラクティスと考えられています。

Identity Manager 製品のアップグレードで、構成オブジェクト以外のリポジトリのオブジェクトが変更された場合は、それらのオブジェクトをソース管理ベースラインの一部にはしないでください。たとえば、Identity Manager の update.xml ファイルが、TaskInstance オブジェクト、User オブジェクト、Account オブジェクト、または Entitlement オブジェクトを更新することがあります。

Identity Manager の技術は通常、これらのオブジェクトタイプの更新を防止します。この理由は、各タイプのインスタンスが膨大にあるからです。ただし、場合によっては、変更が必要であるか、変更が妥当であることがあります。このような場合には、ベースライン、およびアップグレードプロセスで、Identity Manager の update.xml ファイルの適切なサブセットを実行します。この update.xml のサブセットを使用して、ベースラインには含まれないリポジトリオブジェクトを更新します。

アップグレード後、カスタマイズ済みのファイルとオブジェクトを復元します。

カスタマイズ済みのファイルを復元する

アップグレード時に、Identity Manager は、JSP や HTML のファイルなどのカスタマイズ済みのファイルをすべて、次のディレクトリに自動的にコピーします。

$WSHOME/patches/Sun_Java_System_Identity_Manager_Version_Date_/savedFiles

次の表に、このディレクトリ内のファイルを示します。

表 3–1 savedFiles ディレクトリファイル構造


ファイル名	説明
`changedFileList`	保存したすべてのカスタマイズ済みファイルのリストを持つファイル。このファイルには、アップグレード時に同じ名前のファイルがインストールされる場合に上書きされるファイル (旧バージョンの Identity Manager とともにインストールされたファイル) のリストもあります。
`notRestoredFileList`	アップグレードプロセスで復元されない、すべてのカスタマイズ済みファイルのリストを持つファイル
`notInstalledFileList`	アップグレードプロセスでインストールされない、新バージョンのファイルのリストを持つファイル

アップグレードでは、元の Identity Manager とともにインストール済みの一部のファイルが追加されることがあります。古いファイルを上書きする前に、Identity Manager はそれらのファイルをsavedFiles ディレクトリに自動的に保存します。それらのファイルのリストについては、 changedFileList ファイルを参照してください。

Identity Manager は、アップグレードプロセスで changedFileList にリストされているファイルの多く (すべてではない) を自動的に復元します。それらのファイルのリストについては、 notRestoredFileList を参照してください。カスタマイズ済みのファイルの復元時に、Identity Manager は、アップグレードでインストールされたファイルの新バージョンを上書きします。

カスタマイズ済みファイルの一部を手動で復元する必要がある場合があります。アップグレードで復元されないファイルのリストについては、 notRestoredFileList ファイルを参照してください。カスタマイズ済みファイルを手動で復元する必要がある場合は、アップグレード時にインストールされた新規ファイルを編集してカスタマイズし、その編集したファイルを保存します。

カスタマイズ済みオブジェクトの復元

システム構成に書式とプロセスのマッピングを設定した場合は、アップグレード後にそれらのオブジェクトのカスタマイズ内容を復元する必要はありません。システム構成にリストされていないオブジェクトをカスタマイズした場合は、それらのオブジェクトの XML をインポートすることで、それらのオブジェクトを手動で復元する必要があります。

安全な方法として、Identity Manager は、update.xml のインポート時に一般的なカスタマイズ済みオブジェクトの多くをファイルに自動保存します。これらのファイルは、 WEB-INF/ savedObjects ディレクトリのサブディレクトリに保存されます。これらのサブディレクトリの名前は、インポートの実行時のタイムスタンプです。

update.xmlをインポートすると、savedObjects ディレクトリに最大 3 つのサブディレクトリが作成されることがあります。オブジェクトの XML ファイルを手動でインポートして、オブジェクトのカスタマイズ内容を復元できます。

ステップ 10: すべてのカスタム Java クラスの再構築

新規の製品ライブラリに対して、カスタム Java クラスをすべて再構築する必要があります。たとえば、新規 JAR ファイルやアプリケーションサーバーのライブラリを再構築する必要があります。

再コンパイルにより非推奨の警告が表示された場合は、その非推奨メッセージを解析し、『Sun Identity Manager 8.1 リリースノート』を参照して、非推奨の問題をすぐに解決できるかどうかを判断します。非推奨の問題を即座に解決できない場合は、プロジェクト計画に、将来その問題を解決するための項目を追加します。

注 –

Identity Manager は、非推奨 API を無制限にはサポートしません。非推奨のクラスとメソッドは通常、製品の次のメジャーリリースで削除されます。

ステップ 11: XPRESS での必要な変更の実行

XPRESS で、書式、ルール、およびワークフローを変更します。.

Identity Manager 製品の新規バージョンで提供される書式、ルール、およびワークフローは通常、旧バージョンの書式、ルール、およびワークフローと後方互換性があります。必要な変更のもっとも一般的な種類は、Identity Manager のワークフローサービスや書式ユーティリティーのメソッドを変更することです。

注 –

ワークフローサービスや書式ユーティリティーのメソッドに対するリリース固有の変更の詳細については、アップグレードするリリースの Identity Manager のリリースノートを参照してください。

ステップ 12: Identity Manager アプリケーションの開発環境での評価

アプリケーションサーバーを再起動し、&Product_IDMgr を評価して、少なくとも基本機能が予測どおり機能することを確認します。

Identity Manager のアップグレード後に、Web アプリケーションを再配備する必要があります。これは、多くのアプリケーションサーバーが web.xml ファイルをキャッシュしているからです。

アップグレード後に Web アプリケーションを再配備する

たとえば、Sun GlassFish^TM エンタープライズサーバーを使用している場合は、Identity Manager のアップグレード後に次のステップを実行して Web アプリケーションを再配備します。

GlassFish の管理者インタフェースにログインします。

メニューバーから「アプリケーション」>「Web アプリケーション」の順に選択します。

Web アプリケーションを見つけて、その「再配備」リンクをクリックします。

「Application Server からアクセス可能なローカルのパッケージファイルまたはディレクトリ」オプションの横のボタンをクリックします。

「フォルダを参照」ボタンをクリックして、インストール先の最上位のフォルダを選択します。

たとえば、次のとおりです。

C:\Sun\AppServer\domains\domain1\applications\j2ee-modules\idm

「OK」をクリックします。

アプリケーションサーバーを再起動します。

ステップ 13: Active Sync と調整の再起動

アップグレードが正常に完了したら、Active Sync のプロセスの設定を復元し、計画済みの調整 (該当ずる場合) を再度有効にする必要があります。

ヒント –

ステップ 13 は省略可能ですが、本稼働環境をアップグレードするときのベストプラクティスと考えられています。

また、本稼働環境でステップ 13 を実行する場合は、その他すべての環境をアップグレードするときの標準ステップとしてください。

ステップ 14: 変更内容のソース管理へのマージ

注 –

重要性を強調するために、ここでは、変更内容のソース管理へのマージを別のステップとして特に記述しています。実際には、ステップ 9 ～ 12 を実行するときに、変更内容をソース管理にマージできます。

変更内容をソース管理にマージするときには、次の操作が必要です。

既存のカスタマイズ内容のすべてにタグが付けられ、バージョン管理システムに保存されていることを確認します。
アップグレードの評価サイクルの完了後、変更した次の項目を含む新規のカスタマイズ内容をすべてチェックインします。
- データベーステーブルのスクリプト
- リポジトリのオブジェクト
- JSP ファイルやイメージなどのファイルシステムオブジェクト