一部の InterChange Server
コンポーネントは、アップグレードを完了するための追加作業を行う必要があります。以下のセクションでは、これらのアップグレードを完了する方法について説明します。
- 要確認:
- このセクションで説明する手順を実行する必要があるかどうかは、現行の
InterChange Server のバージョンによって異なります。
- InterChange Server の 4.1.1
バージョンからアップグレードする場合は、このセクションで説明する手順を実行して、既存の
ICS コンポーネントを統合コンポーネント・ライブラリー (ICL)
にインポートします。
- InterChange Server の 4.2.0、4.2.1 または
4.2.2 バージョンからアップグレードする場合は、既存の ICL
がそのまま残るため、ICS コンポーネントを ICL
にインポートする必要はありません。コラボレーション・テンプレートおよびマップのアップグレードの完了の説明に進んでください。
バージョン 4.2.0 より、ICS
コンポーネントの作成は、(4.1.1 の場合のように) ICS
インスタンス内で実行されるのではなく、ローカルで行われるようになりました。したがって、4.1.1
バージョンからアップグレードする場合は、ツールを実行している Windows
マシン上の System Manager 内部で統合コンポーネント・ライブラリー (ICL)
を作成する必要があります。ICL には、InterChange Server
のコンポーネントが保持されています。ICL の作成方法については、「System
Integration Guide」を参照してください。ICL を作成すると、UNIX マシンの
InterChange Server
リポジトリーからコンポーネントをインポートする準備が整います。
- 注:
- 大量のデータを一括してインポートすると、処理速度が低下して
System Manager にメモリー・エラーが発生する場合があるため、ICS
コンポーネントは分割してインポートすることをお勧めします。コンポーネントの数が著しく大量の場合は、インポート処理をさらに細分化することもできます。コンポーネントの推奨インポート順序を表 33 に示します。
表 33. ICS コンポーネントのインポート順序
順序
| ICS コンポーネント
| インポートの手順
|
1
| ビジネス・オブジェクト
|
既存のビジネス・オブジェクト定義を ICS リポジトリーから System Manager
内部の ICL にインポートします。System Manager の「Import components
wizard」を使用してコンポーネントをインポートする方法の詳細については、「WebSphere
InterChange Server インプリメンテーション・ガイド」を参照してください。
|
2
| マップ
| コラボレーション・テンプレートおよびマップのアップグレードの完了
|
3
| コラボレーション・テンプレートとコラボレーション・オブジェクト
| コラボレーション・テンプレートおよびマップのアップグレードの完了
|
4
| コネクター
| コネクターのアップグレードの完了
|
5
| 関係
|
既存の関係定義を ICS リポジトリーから System Manager 内部の ICL
にインポートします。System Manager の「Import components
wizard」を使用してコンポーネントをインポートする方法の詳細については、「WebSphere
InterChange Server インプリメンテーション・ガイド」を参照してください。
|
このセクションの指示は、バージョン 4.1.1
からアップグレードする場合にのみ必要になります。
ICS
リポジトリーをアップグレードすると、既存のマップおよびコラボレーション・テンプレートのアップグレードを完了する準備ができています。このアップグレードには、以下の手順が必要です。
コードが新規バージョンと互換であることを確認するには、マップとコラボレーション・テンプレートの既存の
Java クラス (.class) ファイルを調べることが重要です。
- 注:
- 次に示す新規バージョンの適切なディレクトリーにクラス・ファイルが存在することを確認してください。
既存の Java
クラス・ファイルに次のコードが存在するかどうか確認してください。
- マップおよびコラボレーションのカスタム・コードに VisiBroker 固有の CORBA
拡張機能が使用されている場合、このコードは IBM Java ORB では動作しません。
このコードはベンダーに依存しない Java コードに変更する必要があります。
コラボレーションまたはマップが 対応するスタブを持つカスタム IDL
を使用する場合は、idlj コンパイラーを
使用してこれらのスタブを再コンパイルします。すべてのプラットフォームに対応する
idlj コンパイラーが JDK に用意されており、JDK CD
に収録されています。
- 注:
- Sun または HP から JDK と共にダウンロードした idlj
コンパイラーは、IBM ORB とは互換性がない場合があります。JDK CD
に収録されているツールを使用します。
- IBM JDK は Java
互換であると認証されており、以前にコンパイルしたコラボレーション・クラスおよびマップ・クラスを実行しても問題は発生しません。ただし、コラボレーションまたはマップに
Sun JDK
固有のカスタム・コードが含まれる場合は、該当のコードをベンダーに依存しない
Java コードに変更する必要があります。
Java
クラス・ファイルを変更した場合は、コードを再コンパイルして関連のコンポーネントを
ICS
リポジトリーに再展開する必要があります。マップのコンパイル方法については、「マップ開発ガイド」を参照してください。コラボレーション・テンプレートのコンパイル方法については、「コラボレーション開発ガイド」を参照してください。再展開する方法の詳細については、ICS への展開を参照してください。
- 要確認:
- このセクションで説明する手順を実行する必要があるかどうかは、現行の
InterChange Server のバージョンによって異なります。
- InterChange Server の 4.1.1
バージョンからアップグレードする場合は、このセクションで説明する手順を実行して、既存のコラボレーション・テンプレートおよびマップのフォーマットを変換してください。
- InterChange Server の 4.2.0 バージョン、4.2.1
バージョンまたは 4.2.2
バージョンからアップグレードする場合は、コラボレーション・テンプレートまたはマップのフォーマットを変換する必要はありません。コネクターのアップグレードの完了の説明に進んでください。
リリース 4.2.0 以前のバージョンの InterChange Server
ソフトウェアで作成されたコラボレーション・テンプレートおよびマップは、現行ソフトウェアと互換性のある新規フォーマットに変換する必要があります。新規フォーマットでは、すべてのコラボレーション情報およびマップ情報はコラボレーション・テンプレート定義およびマップ定義の一部としてリポジトリーに格納されます。
- 注:
- リリース 4.0.0 以前のバージョンの InterChange Server
ソフトウェアで作成されたコラボレーション・テンプレートおよびマップでは、コラボレーション・モデル
(CollaborationName.clm) ファイルおよびマップ設計
(MapName.dlm)
ファイルを使用していましたが、これらは必要なくなりました。支援が必要な場合は、IBM
ソフトウェア・サポートに連絡してください。
コラボレーション・テンプレートおよびマップを新規フォーマットに変換するには、次の手順を実行します。
- 接続されている Windows マシン上で稼働している System Manager
内部の統合コンポーネント・ライブラリー (ICL) へ、ICS
リポジトリーから既存のマップおよびコラボレーション・テンプレートをインポートします。
System Manager の「Import components
wizard」を使用してコンポーネントをインポートする方法の詳細については、「WebSphere
InterChange Server インプリメンテーション・ガイド」を参照してください。
- 注:
- 「Import components wizard」では、4.3
以前のフォーマットで作成されているマップまたはコラボレーション・テンプレートが検出されます。この場合は、これらを変換するかどうかをたずねられます。マップおよびコラボレーション・テンプレートを
4.3
フォーマットに変換するには、「マップ」チェック・ボックスおよび「コラボレーション・テンプレート」チェック・ボックスが使用可能になっていることを確認してください。
- クラス・ファイルのアップグレード (コンポーネントのクラス・ファイルのアップグレードを参照)
のために、インポート済みのマップおよびコラボレーション・テンプレートをまだコンパイルしていない場合は、この時点でコンパイルします。マップのコンパイル方法については、「マップ開発ガイド」を参照してください。コラボレーション・テンプレートのコンパイル方法については、「コラボレーション開発ガイド」を参照してください。
- アップグレード済みのマップおよびコラボレーション・テンプレートを、UNIX
マシンの ICS リポジトリーに上書きオプションを使用して展開します。詳しくは、ICS への展開を参照してください。
このセクションでは、次に示すように、コネクターを InterChange Server
の 4.3 バージョンにアップグレードするための手順を説明します。
- 関係のあるアダプターをインストールします。
- 次の手順により、コネクターを統合ブローカーにアップグレードします。
- コネクター始動スクリプトをカスタマイズしてある場合は、これらのアップグレードも必要な場合があります。詳しくは、コネクター始動スクリプトのアップグレードを参照してください。
- コネクターのアップグレードを確認します。詳しくは、コネクター構成の確認を参照してください。
WebSphere Business Integration Adapter を取得して InterChange Server
と連動させるには、WebSphere Business Integration Adapter のバージョン
2.6
をインストールする必要があります。ただし、新規にインストールするために、既存のアダプター・ディレクトリー
(ProductDir/connectors
ディレクトリーのサブディレクトリーに存在)
をそのままコピーすることはできません。ここには、WebSphere Business Integration
Adapters
のインストーラーによって提供される共用コンポーネントが存在するためです。すべてのアダプターに共通の単一インストーラーは存在しなくなったため、関連の各
アダプターに固有のインストーラーを使用してアダプターをインストールする必要があります。
- 注:
- InterChange Server がご使用の統合ブローカーである場合は、Adapter Framework
製品を個別にインストールする必要はありません。Adapter Framework
は、InterChange Server インストール・システムの一部として組み込まれます。
アダプターをインストールする方法の詳細については、個々のアダプター・ガイドを参照してください。
ICS 構成ファイル (InterchangeSystem.cfg)
にコネクター・エージェント情報が含まれる場合は、登録されているコネクターごとに個別のコネクター固有構成ファイルが作成されます。
- 構成ファイルへのパスは変更されているため、start_adapter.sh
スクリプトを呼び出すカスタムのコネクター始動スクリプト内部の行に、このファイルへの完全修飾パスを指定する必要があります。このためには、次のように
-c
オプションを使用します。
start_adapter.sh -dconnector_name -nconnector_name
-cfully_qualified_name_of_new_config_file
- アップグレードしたコネクター定義をリポジトリーに取り込むには、Connector
Configurator (ツールが稼働する接続先の Windows マシンに存在)
を使用してコネクターに付属の新規コネクター定義ファイルを開きます
(通常、付属のファイルの名前は connectorName.txt
です)。
Connector Configurator
で開いたファイルで、コネクター・プロパティーを設定し、「Save As
Project」を選択し、構成を System Manager に保管します。System Manager
では、新規コネクター構成を InterChange Server
に展開できます。詳細については、「WebSphere InterChange Server
インプリメンテーション・ガイド」を参照してください。
- 注:
- アップグレードしたコネクターのプロパティーが最新であることを確認するには、該当するアダプター・ガイドを参照してください。
WebSphere メッセージ・ブローカー (MQ Integrator、MQ Integrator
Broker、 Business Integration Message Broker のいずれか) から InterChange
Server システムのリリース 4.3
へコネクターをマイグレーションするには、次の手順に従います。これらの手順の一部は、ツールが稼働している接続先の
Windows マシンで実行する必要があります。
- System Manager
ツールを使用して、新規の統合コンポーネント・ライブラリーを作成します。
- Connector Configurator
を使用して、ローカル構成で指定されたすべてのキューが InterChange Server
に対して有効であることを確認します。
- コネクター定義ファイルごとに、Connector Configurator
を使用して次の手順を実行します。
- DeliveryTransport コネクター・プロパティーを WebSphere Message
Broker-JMS から JMS に変更します。
- RepositoryDirectory プロパティーを REMOTE
に変更します。
- コネクターのプロパティーを次のようにアップグレードします。
- コネクター固有のプロパティーを追加または削除します。アップグレードしたコネクターのコネクター固有プロパティーが最新であることを確認するには、関連のアダプター・ガイドを参照してください。
- 該当するすべての標準プロパティーに値があることを確認してください。アップグレードしたコネクターの標準プロパティーが最新であることを確認するには、関連のアダプター・ガイドの標準プロパティーの付録を参照してください。
- Connector Configurator
の「プロジェクトに保管」オプションを使用して、コネクター定義を統合コンポーネント・ライブラリーに保管します。
- Business Object Designer ツールを使用してビジネス・オブジェクト定義
(.xsd)
ファイルをアップグレードし、ロケール情報を格納します。
- Business Object Designer
の「プロジェクトに保管」オプションを使用して、ビジネス・オブジェクト定義を統合コンポーネント・ライブラリーに保管します。
- System Manager
で、更新済みのコネクター構成およびビジネス・オブジェクト定義を InterChange
Server に展開します。詳細については、「WebSphere InterChange Server
インプリメンテーション・ガイド」を参照してください。
すべての InterChange Server 始動スクリプトは、VisiBroker ORB から IBM Java
ORB へのマイグレーションに対応するために変更されました。 4.2.2
以前のコネクターの始動スクリプトに変更を加えている場合は、新規の始動スクリプトにも同様の変更を加える必要があります。
4.2.2
リリースでは、次に示す主な変更点を含む新規の始動スクリプト構造が導入されました。
- すべてのシステム環境変数が新しくなり、単一の
CWSharedEnv.sh
ファイルに設定されます。すべての始動スクリプトでは、その起動プロシージャーの一部としてこのファイルが読み取られます。ICS
システム規模のプロパティー (IBM Java ORB のプロパティーなど)
が設定されるのは、このファイル内です。この CWSharedEnv.sh
ファイルの詳細については、「システム管理ガイド」を参照してください。
- コネクターを始動するには、start_connName.sh
始動スクリプトを使用します。このスクリプトには、コネクター固有の情報が記述されています。この
start_connName.sh スクリプトにより、今度は
start_adapter.sh
ファイルが呼び出されます。このファイルには、すべてのコネクターの全般的な設定が格納されています。これにより、アダプター環境がセットアップされ、コネクターが呼び出されます。
- 注:
- 既存の IBM
提供アダプターの大半では、その始動スクリプトにこの新構造を採用していません。
これらの IBM
提供アダプターの始動スクリプトを変更する必要はありません。カスタム・アダプターの始動スクリプトのみ変更してください。
4.2.2
より前のリリースでコネクター始動スクリプトをカスタマイズした場合は、スクリプトを再度吟味し、カスタマイズしたスクリプトが、4.3
によっても使用される新規始動スクリプト構造の正しいファイルに存在することを確認してください。
- 注:
- コネクター始動スクリプトでは、コネクターが使用するすべてのカスタマイズ済みデータ・ハンドラーの
CLASSPATH (または JCLASSES) 変数に .jar
ファイルを必ず指定してください。特に、CLASSPATH
に登録されているデータ・ハンドラーの順序を確認してください。例えば、XML
データ・ハンドラーを使用する場合は、CwXMLDataHandler.jar
ファイルが CwDataHandler.jar
ファイルの前にあることを確認してください。xml.class
ファイルは、これらの .jar
ファイルの両方に存在するので、CwXMLDataHandler.jar
にあるファイルが呼び出されるようにします。
コネクターのアップグレードまたは変更が完了したら、そのコネクターが新しい環境に合わせて適切に構成されているかを確認します。それには以下の手順を行います。
- コネクターに正しいユーザー名とパスワード (変更された場合)
が設定されていること、およびコネクターが正しいシステムを示していることを確認します。
- 各コネクターが適切なアプリケーションを示していること、および適切な設定を使用していることを確認するため、データベース管理ツールまたは該当するアプリケーションを使用してテストしてください。
アクセス・クライアントは、IBM Java ORB と連動するように、または CORBA
2.3 に準拠する別の ORB 実装を使用する場合はその ORB
と連動するようにアップグレードする必要があります。ORB
ベンダーに連絡し、ご使用の ORB が CORBA 2.3
に準拠していることを確認してください。このセクションの残りの部分では、IBM Java
ORB を使用することを想定して説明を続けます。
現在、IBM Java ORB を使用せずに VisiBroker ORB
を使用しているアクセス・クライアントをアップグレードするには、次の手順を実行します。
- 以前のバージョンの相互運用オブジェクト参照 (.ior)
ファイルは、VisiBroker ORB
によって生成され、アクセス・クライアントが格納されているマシンにコピーされていました。このファイルは、InterChange
Server の始動後に IBM Java ORB によって生成される .ior
ファイルに置き換える必要があります。
- AccessInterfaces.idl ファイルは、idlj
コンパイラーによって再コンパイルする必要があります。JDK CD に収録されている
idlj コンパイラーを使用します。
- 注:
- Sun または HP から JDK をダウンロードした場合、それに含まれる idlj
コンパイラーは、IBM ORB とは互換性がない場合があります。JDK CD
に収録されている idlj コンパイラーを使用します。
- アクセス・クライアントのコードは、VisiBroker ORB ではなく IBM ORB
を初期化する必要があります。例えば、「アクセス開発ガイド」のサーブレット・サンプルから取られたコード断片では、2
つの CORBA 初期化プロパティーを変更して、VisiBroker ORB ではなく IBM ORB
の使用を反映する必要があります。変更方法を以下に例示します。変更点は太字のフォントで示されています。
Properties orbProperties=new java.util.Properties();
orbProperties.setProperty("org.omg.CORBA.ORBClass",
"com.inprise.vbroker.orb.ORB");
orbProperties.setProperty("org.omg.CORBA.ORBSingletonClass",
"com.inprise.vbroker.orb.ORBSingleton");
org.omg.CORBA.ORB orb =
org.omg.CORBA.ORB.init((String[])null, orbProperties);
正しく更新されると、クライアント・アクセス・コードは次のようになります。
Properties orbProperties=new java.util.Properties();
orbProperties.setProperty("org.omg.CORBA.ORBClass",
"com.ibm.CORBA.iiop.ORB");
orbProperties.setProperty("org.omg.CORBA.ORBSingletonClass",
"com.ibm.rmi.corba.ORBSingleton");
org.omg.CORBA.ORB orb =
org.omg.CORBA.ORB.init((String[])null,orbProperties);
アクセス・クライアントをサーブレット内部から使用すると、IBM ORB は
WebSphere Application Server
のランタイムに格納されます。したがって、次の変更が必要です。
- すべての VisiBroker .jar
参照をクラスパスから除去します。
- 前述のように AccessInterfaces.idl を再コンパイルします。
- サーブレットのコードにより、VisiBroker ORB ではなく IBM ORB
が初期化されることを確認します。これも前述のとおりです。
WebSphere Access for EJB を使用した場合、IBM Java ORB は WebSphere
Application Server
のランタイムに格納されます。この場合、必要な唯一の変更は、VisiBroker の
.jar 参照をクラスパスから除去することです。これは、WebSphere
Access EJB の .jar ファイルには、コンパイル済み IDL や
Session Bean など、その他の必要な成果物がすべて格納されているからです。
カスタムの .jar ファイル (データ・ハンドラーなど)
を持つその他のコンポーネントを作成した場合は、カスタムの
.jar
ファイルを新規ディレクトリーの適切な場所にコピーする必要があります。通常、カスタムの
.jar ファイルは、製品ディレクトリーの lib
サブディレクトリーにあります。
- 注:
- これらのカスタム .jar
ファイルが、適切な始動スクリプトに記述されていることも確認してください。詳しくは、サーバー始動スクリプトのアップグレードを参照してください。
4.3 リリースの SNMP Agent
の内部データ構造の変更により、古い状態ファイル (sts)
は認識されなくなります。状態ファイルには、Agent のコミュニティー名
(パスワードのように動作)、トラップ転送宛先、ターゲット ICS 接続、および RBAC
セキュリティーのユーザー名とパスワードについての情報が記述されています。
4.3 リリースの SNMP Agent にアップグレードしたら、SNMP
構成マネージャーを実行して、状態ファイルに以前保管しておいた情報を再入力する必要があります。
また、MIB ファイルが変更されるので、SNMP Agent
によって使用される管理コンソールすべてを手動で再構成する必要があります。 MIB
ファイルは、SNMP Agent
によって提供される情報の種類を識別するために、管理コンソールによって使用されます。
このファイルは 4.3 リリースでは変更されているので、新しい SNMP Agent
を使用するユーザーは、新規 MIB
ファイルを自分の管理コンソールに読み込む必要があります。
- 注:
- 構成ファイルの形式は変更されていませんが、ファイル名は
cwsnmpagent.cfg から wbi_snmpagent.cfg
に変更されています。したがって、SNMP
構成ウィザードを使用して新規バージョンを作成するよう特にお勧めします。この操作は、SNMP
Agent を起動する前に実行することが重要です。
システム・モニターを使用する場合は、既存のビューおよびモニターはマイグレーションされ、ICS
バージョン 4.3 との互換性を持つようになります。これは、ユーザーが
System Monitor にログインするときに自動的に実行されます。
- 要確認:
- このセクションで説明する手順を実行する必要があるかどうかは、現行の
InterChange Server のバージョンによって異なります。
- InterChange Server の 4.1.1
バージョンからアップグレードする場合は、ICS
コンポーネントのユーザー・プロジェクトを作成する必要があります。プロジェクトの作成の説明に進んでください。
- InterChange Server の 4.2.0 バージョン、4.2.1
バージョンまたは 4.2.2
バージョンからアップグレードする場合で、既存のユーザー・プロジェクトをエクスポートしてある場合
(既存のプロジェクトのマイグレーションに記述) は、既存のプロジェクトのインポートの手順を実行して、既存のユーザー・プロジェクトをすべてインポートします。既存のユーザー・プロジェクトが存在しない場合は、プロジェクトの作成の手順に従ってください。
既存のユーザー・プロジェクトをエクスポートしてある場合は、ICS
を稼働した後にインポートできます。接続先の Windows マシンで稼働している System
Manager を既存の ICS インスタンスに接続し、次の手順を実行します。
- 「ユーザー・プロジェクト」フォルダーを展開し、右マウス・ボタンで「InterChange
Server
プロジェクト」をクリックして、「ソリューションのインポート」を選択します。
- 4.3
以前のバージョンからエクスポートしたときに作成したフォルダーの場所を選択します。
- ユーザー・プロジェクトがすべて正常にインポートされたことを確認します。
インターフェースごとにプロジェクトを作成し、共通のコンポーネント
(メタオブジェクトやコネクターなど)
に対して個別にプロジェクトを作成することをお勧めします。接続先の Windows
マシンで稼働している System Manager を既存の ICS
インスタンスに接続し、次の手順を実行します。
- 「ユーザー・プロジェクト」を右マウス・ボタンでクリックし、「新規ユーザー・プロジェクト」を選択します。
- ユーザー・プロジェクトに名前を付けます。この名前は、インターフェースを一意的に識別するものにします。
- 注:
- ユーザー・プロジェクトの名前を既存のユーザー・プロジェクトや既存の ICL
プロジェクトと同じにすることはできません。
- ユーザー・プロジェクトのコンポーネントを選択します。この手順では、必要な各コンポーネントへのショートカットを作成します。コンポーネント自体はその
ICL に格納されたままです。
プロジェクトを作成する方法については、「WebSphere InterChange Server
インプリメンテーション・ガイド」を参照してください。
- 要確認:
- このセクションで説明する手順を実行する必要があるかどうかは、現行の
InterChange Server のバージョンによって異なります。
- InterChange Server の 4.1.1
バージョンからアップグレードする場合は、このセクションで説明する手順を実行して、既存の
ICS コンポーネントを新規リポジトリーに展開してください。
- InterChange Server の 4.2.0 バージョン、4.2.1
バージョンまたは 4.2.2
バージョンからアップグレードする場合は、クラス・ファイルを変更済みの場合にコラボレーション・テンプレートまたはマップを展開することだけが必要です
(コンポーネントのクラス・ファイルのアップグレードで説明済み)。コラボレーション・テンプレートまたはマップを展開するには、このセクションで説明する手順を実行します。それ以外の場合は、アップグレードの検証の説明に進んでください。
ICL およびユーザー・プロジェクトを、接続先 Windows マシンの System Manager
内部で定義すると、UNIX マシンの InterChange Server
リポジトリーにコンポーネントを展開する準備が整います。 ICS
コンポーネントに変更を加えていない場合、再展開が必要なコンポーネントはマップおよびコラボレーション・テンプレートのみです。
System Manager を ICS
インスタンスに接続した場合は、次の作業を実行します。
- ユーザー・プロジェクトを右マウス・ボタンでクリックし、「Deploy User
Project」を選択します。
- 登録済みおよび接続済みの ICS
インスタンスのドロップダウン・リストから、展開するためのターゲット ICS
インスタンスを選択します。
- InterChange Server を停止して再始動します。
コンポーネントをサーバーに展開する方法の詳細については、「WebSphere
InterChange Server インプリメンテーション・ガイド」を参照してください。
