アップグレード・プロセスの開始

システムを静止状態にしてバックアップを作成したら、アップグレード手順を安全に開始できます。

注:
バージョン 4.3 をインストールする前に InterChange Server の旧バージョンをアンインストールする必要はありませんが、この段階で旧バージョンをアンインストールしてもかまいません。詳しくは、InterChange Server のアンインストール を参照してください。この時点でアンインストールしない場合は、関連するファイルのサイズが大きいので、アップグレードの完了後に旧バージョンを除去することをお勧めします。この段階でアンインストールする場合でも、4.3 用には別のディレクトリーを使用してください。
システムのアップグレードでは、以下の作業を行います。

データベースのインポート

データベースをアップグレードした場合は、DBA に依頼して、スキーマ情報やストアード・プロシージャーなどの保管されたデータベース情報をインポートします。手順については、データベース・サーバーの資料を参照してください。

InterChange Server の新規バージョンのインストール

4.3 以前のインストール・ファイルをバックアップすると、InterChange Server の新規バージョンをインストールする準備が整います。InterChange Server の新規バージョンをインストールするには、InterChange Server、XML データ・ハンドラー、e-Mail アダプター、 およびその他のサポート製品のインストールを参照してください。

注:

  1. アップグレード時には、既存のインストールとは別の 場所に新規バージョンをインストールする必要があります。

  2. ICS インスタンスに名前を付けることをインストーラーから要求された場合は、ICS インスタンスのこの名前を以前のバージョンと同じ名前にして、失敗したイベントの移植性を確保します。このステップは、データベースのインプレース・マイグレーションを実行している場合には不要です。

  3. InterChange Server の元の構成情報を取得するには、インストーラーが「InterChange Server 構成ウィザード」を起動したら、次のいずれか の処置を行います。

オブジェクト・リクエスト・ブローカーの構成

InterChange Server の 4.2.2 バージョンからアップグレードする場合は、オブジェクト・リクエスト・ブローカーを構成する必要はありませんサーバー・スクリプトのアップグレードの説明に進んでください。

InterChange Server の 4.2.2 リリースの時点で、VisiBroker ORB は IBM Java ORB に置き換えられました。 ハードウェアとサポートするソフトウェアのアップグレードで説明したように、ICS インストーラーは、ICS インストール・プロセスの一環として、IBM Java ORB および IBM Transient Naming Server を自動的にインストールします。ただし、次の作業を実行して、IBM Java ORB が適切に構成されていることを確認する必要があります。

ORB プロパティーのアップグレード

Visibroker ORB には、ORB を調整するために各種の ORB 関連プロパティーが存在していました。カスタマイズされたスクリプトやソフトウェアでこれらのプロパティーを使用していた場合は、これらのプロパティーが IBM Java ORB に対して適切に設定されていることを確認する必要があります。表 32 には、いくつかの VisiBroker ORB プロパティーと、これに相当する IBM Java ORB での名前を示します。

VisiBroker ORB プロパティーを参照するカスタマイズされたスクリプトが、4.2.2 以前のインストール・システムに存在する場合は、これらのプロパティーを、後出の表 32 に示す IBM ORB の相当プロパティーに置換してください。

注:
表 32 では、いくつかのプロパティー名に改行を挿入して、プロパティー名が表のセルに収まるようにしています。実際のプロパティー名には、スペースや改行は含まれません。

表 32. IBM ORB プロパティーと等価の VisiBroker プロパティー
IBM ORB プロパティー 等価の VisiBroker プロパティー 説明
org.omg.CORBA.ORBInitialHost vbroker.agent.addr IBM Transient Naming Server (tnameserv) が稼働しているマシンの IP アドレスまたはホスト名を指定します。このプロパティーのデフォルト値は localhost です。
org.omg.CORBA.ORBInitialPort vbroker.agent.port IBM Transient Naming Server の listen 先ポートを指定します。
com.ibm.CORBA.ListenerPort vbroker.se.iiop_tp.scm.iiop_tp. listener.port ORB サーバーが着信要求を listen するポート。このプロパティーを指定すると、ORB はORB.init() の実行時に listen を開始します。デフォルトでは、このポートは動的に割り当てられます。4.3 では、VisiBroker のプロパティー名 OAport が引き続きサポートされます。
com.ibm.CORBA.LocalHost vbroker.se.iiop_tp.host このプロパティーは、ORB が稼働しているマシンのホスト名 (または IP アドレス) を表します。ローカル・ホスト名は、サーバーのホスト名をリモート・オブジェクトの IOR に置くために、サーバー・サイド ORB が使用します。このプロパティーを設定しなかった場合は、InetAddress.getLocalHost(). getHostAddress(); を呼び出すことにより、ローカル・ホストが検索されます。4.3 では、VisiBroker のプロパティー名 OAipAddr が引き続きサポートされます。
com.ibm.CORBA.ThreadPool. MaximumSize vbroker.se.iiop_tp.scm.iiop_tp. dispatcher.threadMax Server Connection Manager によって作成可能なスレッドの最大数を指定します。デフォルト値 0 は、制限がないことを意味します。4.3 では、VisiBroker のプロパティー名 OAthreadMax が引き続きサポートされます。
com.ibm.CORBA.ThreadPool. InactivityTimeout vbroker.se.iiop_tp.scm.iiop_tp. dispatcher.threadMaxIdle アイドル状態のスレッドが破棄されるまでの時間を (秒単位で) 指定します。4.3 では、VisiBroker のプロパティー名 OAthreadMaxIdle が引き続きサポートされます。
com.ibm.CORBA.BufferSize vbroker.orb.streamChunkSize 最初の試行でソケットから読み取られる (GIOP メッセージとしての) バイト数。バッファー・サイズを増やすと、1 回の試行でメッセージ全体を読み取る確率が高くなり、パフォーマンスの向上につながります。デフォルトは 2048 です。

登録済み ICS ORB コンポーネントの識別

InterChange Server の 4.2.2 以前のバージョンでは、InterChange Server によって登録されたすべての ORB オブジェクトを識別するために、VisiBroker ORB に osfind ツールが用意されていました。IBM Java ORB には、このために CosNameServer_Dump と呼ばれるツールが用意されています。このツールは、ProductDir/bin ディレクトリーにあります。詳しくは、「システム管理ガイド」を参照してください。

高可用性 (HA) 機能のアップグレード

InterChange Server の 4.2.2 リリースの時点で、VisiBroker ORB は IBM Java ORB に置き換えられました。この変更により、HA のために以前使用されていた VisiBroker Smart Agent は、Transient Naming Server に置き換えられました。HA 環境に合うように IBM ORB を構成することの詳細については、オブジェクト・リクエスト・ブローカー (ORB) のインストールおよび構成を参照してください。

サーバー・スクリプトのアップグレード

既存の InterChange Server にカスタム・ファイルを作成した場合は、次のファイルを評価して、これらのファイルをアップグレードする必要があるかどうかを判断する必要があります。

サーバー始動スクリプトのアップグレード

InterChange Server の 4.2.2 リリースでは、VisiBroker ORB から IBM Java ORB への移行に対応し、IBM JRE をサポートするために、すべての始動スクリプトが変更されました。

任意のサーバー始動スクリプトをカスタマイズし、4.2.2 以外のリリースから 4.3 にアップグレードしている場合は、新規のスクリプトにも同様な変更を行う必要があります。これらの始動スクリプトには、次のようなカスタマイズが必要な場合があります。

注:
統合テスト環境には、簡単な開始コマンドでアクセスできるようになりました。サーバーの始動スクリプトの開始行に -test オプションを追加することにより、ICS をテスト・モードに設定します。 詳細については、「WebSphere InterChange Server インプリメンテーション・ガイド」を参照してください。

ツール構成ファイルのアップグレード

ツール構成ファイル cwtools.cfg のタスクの 1 つは、カスタムの .jar ファイルを提供して、これをコンパイル時に組み込むことです。カスタムの .jar ファイルを作成した場合は、CLASSPATH 変数の codeGeneration セクションに追加する必要があります。cwtools.cfg ファイルは、ツールが稼働している Windows マシンの次のディレクトリーにあります。

ProductDir¥bin
 

環境変数の確認

すべての環境変数が単一の CWSharedEnv.sh ファイルに設定されるようになりました。すべての始動スクリプトでは、その起動プロシージャーの一部としてこのファイルが読み取られます。ICS システム規模のプロパティー (IBM Java ORB のプロパティーなど) が設定されるのは、このファイル内です。アップグレード・プロセスの一環として、次に示すシステム規模のプロパティーが正常に設定されていることを確認してください。

CWSharedEnv.sh ファイルの詳細については、「システム管理ガイド」を参照してください。

カスタム・コンポーネントの評価

リポジトリー表 (スクリプト、データベース表、ストアード・プロシージャーなど) を使用する完全にカスタムのコンポーネントがある場合は、各コンポーネントを評価して、コンポーネントのアップグレードが必要かどうかを判断する必要があります。例えば、新規リリースで変更されたリポジトリー表をストアード・プロシージャーが使用する場合は、このストアード・プロシージャーを変更して、リポジトリー表の新構造と連動する必要があります。

注:
スキーマが変更されていない場合は、イベント表とトリガーのいずれもまったく変更する必要はありません。

新規のアップグレード・バージョンの始動

インストールが完了した後は、必要なサポート・ソフトウェアがすべて稼働していれば、既存バージョンのリポジトリーを使用して新規バージョンの InterChange Server を始動できます。インプレース・アップグレードによってデータベースをアップグレードした場合は、ICS を元のリポジトリーにポイントする必要があります。ICS を始動するには、次の手順を実行します。

  1. マシンをリブートすることをお勧めしますが、必須ではありません。
  2. インプレース・アップグレードによってデータベースをインストールする場合は、前のサーバー構成ファイル InterchangeSystem.cfg を再使用します。インプレースでデータベースをアップグレードしない場合は、インストーラーによって生成される新規の構成ファイルを使用します。前の構成ファイルを使用する場合は、古い構成ファイルを新規インストールの ProductDir ディレクトリーにコピーします。新規構成ファイルを使用する場合は、サーバーの構成ウィザードを使用して適切に設定を変更します。 旧 ICS から失敗したイベントをアップグレードする場合は、前のサーバー・インストールと同じサーバー名を必ず使用してください。
  3. 必要なすべてのサポート・ソフトウェアが稼働していることを確認します。サポート・ソフトウェアの内容は、次のとおりです。

    サポート・ソフトウェアが稼働していることを確認する方法については、サポート・ソフトウェアの始動および IBM ORB Transient Naming Server の始動を参照してください。

  4. InterChange Server を始動します。

    InterChange Server を始動する方法については、InterChange Server の始動および System Manager の始動を参照してください。

ProductDir ディレクトリーの InterchangeSystem.log ファイルを調べると、始動が正常であったことを確認できます。

注:
InterChange Server システムのアップグレード後に InterChange Server の始動に失敗した場合は、このアップグレード手順を調べて、すべての指示に従ったかどうかを確認してください。

それでも失敗の原因が不明であれば、修正したり、バックアップから復元したりする前に、IBM ソフトウェア・サポートにお問い合わせください。

リポジトリーのアップグレード

InterChange Server リポジトリーは、InterChange Server コンポーネントについてのメタデータを保持するデータベースです。アップグレードは、インプレース・データベース・アップグレードを使用するか、または使用しないで実行できます。4.3 ICS インストーラーは、ICS リポジトリーの内容を自動的にはアップグレードしません。ただし、インプレース・アップグレードを使用すると、前の手順で ICS を始動した場合は、ICS により 4.3 以前のリポジトリーのスキーマが 4.3 での変更内容よってアップグレードされます。アップグレード・プロセスのこの時点で、次のどちらのオブジェクトをリポジトリーにロードするかを決定する必要があります。

要確認:
データベースのインプレース・アップグレードを使用しないでアップグレードする場合は、以前から存在しているリポジトリー・オブジェクトと一緒に新規 4.3 リポジトリーを読み込みます。 詳しくは、既存のリポジトリー・オブジェクトを参照してください。

接続された Windows マシンで稼働する System Manager の「InterChange Server コンポーネント管理」ビューを使用すると、サーバーにロードされたコンポーネントを参照できます。

既存のリポジトリー・オブジェクト

このセクションで説明する手順は、データベースのインプレース・アップグレードを使用しないで InterChange Server をアップグレードする場合にのみ必要になります。

ICS インストール・プロセスの一環として、これらの ICS データベースの名前は「InterChange Server 構成ウィザード」で指定済みです。ICS の新規バージョンを始動したときに、サーバーはリポジトリー・データベースのスキーマをアップグレード済みです。この新規リポジトリーを初期化するには、既存のリポジトリー・オブジェクトをロードする必要があります。

リポジトリーのロードを準備するには、次の手順を実行します。

  1. マップとコラボレーションに対応する既存の Java クラス (.class) ファイルを、新規ディレクトリー構造に次のようにコピーします。

    ここで、ProductDir は、新規の 4.3 リリースの製品ディレクトリーです。この手順により、既存のマップおよびコラボレーションの .class ファイルが、新規の 4.3 ディレクトリー構造に確実に置かれるようになります。

  2. 関係とデータベース接続のために ICS システムが使用するすべてのデータベースが稼働していることを確認します。ICS が稼働していることも確認します。
  3. 次の手順に従って、既存のリポジトリー・オブジェクトをロードします。
    1. リポジトリー・ファイルを編集して、不適合箇所をいくつか修正します。
    2. すべてのリポジトリー・オブジェクトのリポジトリーをクリアします。
    3. 既存のオブジェクトをロードします。

    リポジトリーをロードするこれらの各手順は、以降のセクションで説明します。

リポジトリー・ファイルの準備

このセクションの手順は、バージョン 4.1.1 からアップグレードする場合にのみ必要になります。

(リポジトリー・ファイルと呼ばれる) 既存の repos_copy バックアップ・ファイルを調べて、すべての値が新規リポジトリーに関連していることを確認します。既存のリポジトリー・ファイルのバックアップ・コピーを作成し、元のリポジトリー・ファイルを編集することにより、次の情報を修正します。

注:
既存のリポジトリー・オブジェクトのファイル内にあるリポジトリー・オブジェクトを、必ずしもすべてロードしない場合は、4.3 リポジトリーにインポートしたリポジトリー・ファイルから不要なオブジェクトを除去できます。

新規リポジトリーの消去

既存のリポジトリー・オブジェクトをインポートする前に、4.3 リポジトリーに既に存在している可能性のある重複オブジェクトを削除する必要があります。この手順が必要な理由は、repos_copy ユーティリティーが、以前のフォーマットをリポジトリーにインポートするときに -ar オプションや -arp オプション (重複オブジェクトを処理するオプション) を認識しないからです。ICS は、リポジトリー・ファイル内に重複オブジェクトを検出すると、インポート操作全体をロールバックします。

これらのリポジトリー・オブジェクトを削除するには、repos_copy ユーティリティーの -d オプションを使用します。例えば、次の repos_copy コマンドを実行すると、リポジトリーの内容が削除されます。

repos_copy -sNewICSinstance -uadmin -ppasswd -d 
 

この repos_copy コマンドの詳細について、以下に説明します。

リポジトリー・ファイルのインポート

リポジトリー・ファイルの内容をリポジトリーにロードするには、repos_copy ユーティリティーを使用します。InterChange Server システムのバックアップで説明したように、repos_copy ユーティリティーの -o オプションを使用して、既存のリポジトリー・オブジェクトをエクスポートし、1 つ以上のリポジトリー・ファイルを作成しておきます。これが終了したら、repos_copy-i オプションを使用して、これらのリポジトリー・オブジェクトを新規のリポジトリーにインポートします。

注:
バージョン 4.1.1 の InterChange Server では、プロジェクトの定義がリポジトリーに格納されていました。InterChange Server の 4.3 バージョンでは、プロジェクト定義はリポジトリーに格納されなくなりました。プロジェクト定義は、統合コンポーネント・ライブラリー (ICL) およびユーザー・プロジェクトを介して定義されるようになりました。インポート操作では、リポジトリー・ファイルに定義されたすべてのリポジトリー・オブジェクトがロードされます。ただし、プロジェクト定義はこの対象外 です。詳しくは、「システム・インストール・ガイド (Windows 版) 」を参照してください。

例えば、Repository411.txt というリポジトリー・ファイルがある場合を考えます。次の repos_copy コマンドを実行すると、このファイル内のすべてのリポジトリー・オブジェクトがロードされます。

  repos_copy -iRepository411.txt -sserverName -uuserName -ppassword -r*
 

この repos_copy コマンドの詳細について、以下に説明します。

既存のリポジトリー・オブジェクトが新規のリポジトリーに格納されたら、さらに追加の手順を実行して、コラボレーション・テンプレートおよびマップのアップグレードを完了する必要があります。詳しくは、コラボレーション・テンプレートおよびマップのアップグレードの完了を参照してください。

Copyright IBM Corp. 1997, 2004