3. 移行機能を使用する場合

3.1. ソフトウェア条件

本章で対象とする移行元のAPサーバは以下のとおりです。

移行元APサーバ バージョン
WebOTX Application Server 9.2 (※)
WebOTX Application Server 9.3
WebOTX Application Server 9.4

(※) V9.20はサポートしていません。V9.20環境を移行したい場合は、V9.22.01以降の標準修正を適用のうえ移行を行ってください。

3.2. 移行の流れ

マイグレーションアシスタントを使用した移行の流れを説明します。

3.2.1. 移行全体の流れ

マイグレーションアシスタントを使用する場合、以下の流れで移行を行います。

  1. 移行元の環境から設定情報を採取

    情報採取スクリプトを使って設定ファイルなどの設定情報を採取します。

  2. 移行元の環境から採取した設定情報を変換

    WebOTX Developerに採取した設定情報をインポートして、移行先の設定情報に変換します。

  3. 変換した設定情報を確認・修正

    変換結果として表示されるパラメータシートの内容を確認し、必要に応じて設定値の修正を行います。

  4. 移行するアプリケーションの準備 (※アプリケーションを移行する場合のみ)

    必要に応じてアプリケーションソースの非互換チェックを行い、アプリケーションの実体ファイル(warやjarなど)を用意します。用意した実体ファイルは、変換後の設定情報に取り込みます。詳細は[ アプリケーションの準備 ]にて説明します。

  5. 移行先の環境にAPサーバをインストール

    パラメータシートの内容に従い、移行先の環境にWebOTX Application Serverをインストールします。

  6. 移行先の環境に設定情報を反映

    WebOTX Developerより、設定情報とアプリケーションを移行先の環境に反映します。

設定情報の採取(手順1)は移行元の環境で、APサーバのインストール(手順5)は移行先の環境で行います。その他の作業については、WebOTX Developerをインストールした環境で行います。

3.2.2. アプリケーションの準備

移行元環境からアプリケーションを移行する場合、JDKやWebOTXのバージョン間の非互換に該当していないかソースを検証し、該当している場合は内容を確認し変更して移行先環境に配備します。

種類別に以下の対応を行います。

3.2.2.1. Java EEアプリケーションの場合
  1. 移行元環境構築時に利用したEclipseのアプリケーションの作成プロジェクトを準備します。

    Eclipse形式のプロジェクトが無い場合、[ アプリケーション開発 ]を参照し、アプリケーションの種類に 応じたプロジェクトを作成してください。

  2. Eclipseのプロジェクト上でアプリケーションの非互換チェックを行います。

  3. 非互換に該当していた場合、内容を確認し必要があれば修正を行います。

  4. 修正したアプリケーションを設定情報のZIPファイルに含めて配備します。

Caution
Linux のC++アプリケーションを移行する場合、gcc 3.xとgcc 4.xのバイナリ非互換のため、 gcc 3.x でビルドされているアプリケーションは必ず gcc 4.x で再ビルドする必要があります。 gcc 4.x で再ビルドを行わない場合、正しく移行されません。

3.3. 移行作業

本章では、WebOTXの旧バージョンから移行する場合の具体的な移行の流れを説明します。

本章で対象とする移行パターンは以下です。

3.3.1. 移行の準備

移行の前に必ず行う必要がある作業と確認事項について、説明します。

そのほか、 [ 注意制限事項 > マイグレーション ] についても確認してください。

Caution
移行先の環境へWebOTX Application Serverをインストールする作業は、[ 移行先の環境構築 ]にて行います。事前にWebOTX Application Serverをインストールしないようにしてください。

3.3.2. 移行元の環境情報の採取

情報採取スクリプトを使用して、移行元環境の設定情報を採取します。複数のWebOTXサーバから移行する場合は、移行元のすべてのWebOTXサーバから情報を採取してください。

採取の前に以下の点を確認してください。

設定情報の採取は次の手順で実施します。詳細は [ 情報採取 ] をご参照ください。

  1. 情報採取スクリプトをWebOTX Developerインストール環境から移行元のWebOTXサーバにコピー・展開
  2. 環境情報設定ファイルの編集
  3. 情報採取スクリプトの実行

3.3.3. 移行元の環境情報の変換

WebOTX Developerを起動して、メニュー ファイル > インポート を選択し、インポート ダイアログが表示されます。


図1.6.3-1

採取した移行元の設定情報を変換します。複数のWebOTXサーバを一つのWebOTXサーバに移行する場合は、WebOTXサーバ単位で採取した設定情報をそれぞれ変換してください。

インポート ダイアログで マイグレーション > 設定情報圧縮ファイル を選択して 次へ ボタンを押下すると 移行元設定情報のインポート ウィザードが表示されます。


図1.6.3-2

移行元設定情報のインポート ウィザードでプロジェクト名と移行元の設定情報圧縮ファイルを入力して 次へ ボタンを押下すると 移行元設定情報の設定 ウィザードが表示されます。


図1.6.3-3

移行元設定情報の設定 ウィザードで移行元の情報を確認してから、 次へ ボタンを押下すると移行先設定情報の設定 ウィザードが表示されます。


図1.6.3-4

Caution
WebOTX Webサーバ 1.3, IIS以外の外部Webサーバの場合、移行元のWebサーバの種類が内蔵Webサーバと表示されますが、移行対象の内蔵Webサーバに移行されます。
詳細は[ 移行 > 移行機能リファレンス > マイグレーションアシスタント > 使用上の条件 > ソフトウェア条件 > WebOTX ]のドメインの動作設定とWebサーバの構成を参照してください。


移行先設定情報の設定 ウィザードで各項目を移行先サーバの情報に合わせて設定して 終了 ボタンを押下すると、マイグレーションプロジェクト webotx_migration_configs_xxxxxx が生成されます。


図1.6.3-5

マイグレーションプロジェクト webotx_migration_configs_xxxxxx の構成は下図のようになります。


図1.6.3-6

ここまでで、移行元の環境情報の変換が完了しました。

3.3.4. 変換結果の確認・修正

設定情報の変換機能で変換された設定情報をWebOTX Developerのパラメータシートビューで確認・修正できます。

マイグレーションプロジェクト webotx_migration_configs_xxxxxx のインポートが完了したあとにパラメータファイルの内容がパラメータシートビューで表示されます。


図1.6.4-1

表示内容を確認し、変換先サーバの状況に合わせて必要であれば修正してください。

詳細な使用方法は [ パラメータシートの表示 ] を参照してください。

複数のWebOTXサーバを一つのWebOTXサーバに移行する場合は、WebOTXサーバ単位での変換結果をすべて確認してください。

パラメータシートには、変換の途中で起こった問題や、設定値の妥当性チェック結果などがメッセージとして出力されます。
メッセージには以下のような三段階のレベルがあります。メッセージレベルに応じて確認を行ってください。

表1.5.4-1
メッセージレベル 説明
MUST 確認必須のメッセージです。必ず内容を確認し、必要に応じて設定値を修正してください。
SHOULD 確認したほうがよいメッセージです。内容を確認し、必要に応じて設定値を修正してください。
INFO 確認しなくても問題ないメッセージです。必要に応じて内容を確認してください。

メッセージに加えて、以下の確認・修正も行ってください。

Caution
複数のWebOTXサーバを一つのWebOTXサーバに移行する場合、変換結果に含まれるドメインの情報を調整する必要があります。複数のWebOTXサーバからの移行の場合、各種の設定に重複がある場合があり、ポート番号などのシステムにおいて一意でなければならない設定が競合して移行に失敗するためです。

競合する代表的な設定は以下になりますので、変換結果に含まれるドメイン間で競合しないように設定値を調整してください。 ポート番号の一覧は [ リファレンス > ポート番号 ] を参照してください。

特に「MUST」で表示される内容が設定されるか、確認する必要があります。▽をクリックして、メニュー パラメータ・フィルター を選択します。


図1.6.4-2

パラメータ・フィルター ダイアログが表示されて、 メッセージレベルは「MUST」のパラメータのみ表示 をチェックしてOKボタンを押下します。


図1.6.4-3

パラメータシートビューでメッセージレベルが「MUST 」のパラメータのみ表示されて、修正に必要がある場合に該当パラメータをダブルクリックして、関連ファイルにジャンプし、編集して保存します。


図1.6.4-4

詳細な使用方法は [ パラメータシートの表示 ] を参照してください。

3.3.4.1. Object Broker JavaTM/C++

ファイルやディレクトリのパス、通信で使用するホスト名やIPアドレスの設定は、環境に依存するため、必要に応じて移行先の環境に適した値に変更してください。

このような環境に依存する設定については、パラメータシートにMUSTレベルでメッセージを出力していますので、必ずご確認ください。

JNDIサービス

以下の設定は移行元環境の設定が反映されています。移行先環境に合わせて設定を変更してください。

(例)

otxadmin > set server.jndi-service.url=corbaname://<ホスト名>

3.3.5. 移行するアプリケーションの準備

移行するアプリケーションは 配備可能なファイルプロジェクト の2つ形式で指定できます。

本サンプルでは、移行する5つアプリケーションの中に、1つが プロジェクト として指定し、それ以外は 配備可能なファイル として指定します。

表1.6.5-1
アプリケーション アプリケーションタイプ 関連プロジェクト/配備可能なファイル
HelloServer EJB HelloServer.jar
CartAppClient APP_CLIENT CartAppClient.jar
CartApp1 JAVAEE CartApp1.ear
testservlet WEB dynamicWeb
inbound2 RESOURCE inbound2.rar
(1) プロジェクト として指定されるアプリケーション

アプリケーション testservlet の関連プロジェクト dynamicWeb をワークスペースにインポートして、WebOTX V9.4 サーバに利用できるかのチェックを行います。

dynamicWeb を右クリックして 検証 をクリックします。


図1.6.5-1

実行後、検証結果が マーカービュー に表示されます。


図1.6.5-2

検証結果に 互換性の問題 がある場合、その内容を確認し、必要であれば修正してください。
詳細な使用方法は [ アプリケーション非互換チェック ] を参照してください。

次はマイグレーションプロジェクトとの関連付けを設定します。

webotx_migration_configs_xxxxxx を選択し、右クリックメニュー プロパティー を選択すると プロパティー ダイアログが表示されます。


図1.6.5-3

プロパティー ダイアログで 関連アプリケーション を選択し、関連アプリケーションページが表示されます。


図1.6.5-4

testservlet を選択して 編集 ボタンを押下すると、関連アプリケーションの情報 ダイアログが表示されます。


図1.6.5-5

参照 ボタンを利用して、dynamicWebを指定し、OK ボタンを押下して、プロパティー ダイアログに戻ります。


図1.6.5-6

プロパティー ダイアログで OK ボタンを押下して、関連アプリケーションの設定を完了します。

(2) 配備可能なファイル と指定するアプリケーション


図1.6.5-7

ここまでで、移行するアプリケーションの準備が完了しました。

3.3.6. 移行先の環境構築

移行先の環境に WebOTX Application Server をインストールします。

パラメータシートの「インストール設定」に記載された内容でインストールしてください。

具体的なインストール手順については詳細は、各インストールガイド( WindowsLinuxHP-UX )を参照してください。

Caution
HP-UX、Linux環境にインストールする場合は、WebOTX運用管理ユーザではなくrootユーザでインストールしてください。WebOTX運用管理ユーザでWebOTXを運用したい場合は、移行完了後に運用ユーザを変更してください。具体的な手順は [ WebOTX運用管理ユーザの変更 ] を参照してください。

3.3.7. 環境情報の移行先への反映

変換した設定情報を移行先の環境に反映します。

複数のWebOTXサーバを一つのWebOTXサーバに移行する場合は、全WebOTXサーバの設定情報を反映します。ただし、システムおよび管理ドメインの設定は一つの環境からのみ移行可能なため、どのWebOTXサーバからシステムおよび管理ドメインの設定を移行するかを検討のうえ、システムおよび管理ドメインの設定を含む設定情報を最初に移行してください。また、既に存在するドメインと同名のドメインは移行できないため、二つ目以降の設定情報を反映する際にドメイン名の重複があればドメイン名を変更する必要があります。

設定情報の反映を行う前には、以下の点を確認してください。

確認できましたら設定情報を反映します。

webotx_migration_configs_xxxxxxを選択し、右クリックメニュー 実行 > 移行先サーバに配備 を選択します。


図1.6.7-1

移行先サーバに配備 ダイアログが表示されます。

移行先サーバに配備 ダイアログで各項目を設定して、終了 ボタンを押下して、移行先サーバの配備を行います。


図1.6.7-2

3.3.8. 移行後の作業

3.3.8.1. Windows
サービスやドメインの動作確認

サービスが開始できること、ドメインが起動できることを確認します。

具体的な手順は インストールガイド(Windows)の[動作確認]を参照ください。

なお、マイグレーションでの移行後はドメインのパスワードが既定に変更されています。ドメインのパスワードが必要な場合はadminadminを使用してください。

JMS

移行元環境において、JDBCストアを利用していた場合、移行先の環境では、ファイルストアに変更されています。 また、JMSサーバクラスタを利用していた場合は、移行先の環境では無効になっています。 移行先でも、JDBCストアや、JMSサーバクラスタを利用する場合は、それぞれ、次の手順で有効化してください。

  1. JMSサービスを停止します。
    otxadmin> stop-jms
    
  2. 【JDBCストア利用時】JDBCストア利用のための準備をします。
    1. 次のコマンドにより、永続ストアタイプと、接続先の情報を設定します。
      otxadmin> set server.jms-service.storeType=<永続ストアタイプ>
      otxadmin> set server.jms-service.jdbcStoreURL=<JDBC URL>
      otxadmin> set server.jms-service.jdbcStoreUser=<DBユーザ名>
      otxadmin> set server.jms-service.jdbcStorePassword=<DBパスワード>
      
    2. 移行元で利用していたDBを移行先からも利用する場合、移行元環境のテーブルを削除します。
      > jmqdbmgr delete tbl -u <DBユーザ名> -p <DBパスワード> -t <DBの種類> -url <JDBC URL>
      
      Memo
      -url オプションで接続先を指定する場合、${INSTANCE_ROOT}/lib/ext に移行されているjarファイルを参照しませんので、${AS_INSTALL}/jmq/lib/ext に、対象データベースのJDBCドライバのjarファイルを格納してください。
    3. 移行先のテーブルを作成します。
      > jmqdbmgr create tbl -otxdomain <ドメイン名>
      
  3. 【JMSサーバクラスタ利用時】JMSサーバクラスタ有効化のための設定をします。
    otxadmin> set server.jms-service.enableCluster=true
    
    JMSサーバクラスタを構成するサーバ情報に変更がある場合は、次のコマンドにより変更してください。
    otxadmin> set server.jms-service.clusterBrokerList=<JMSサーバのアドレスリスト>
    otxadmin> set server.jms-service.clusterMasterBroker=<マスターブローカのアドレス>
    
  4. JMSサービスを起動します。
    otxadmin> start-jms
    
Webサーバ

パラメータシートで差分を確認し、移行元の設定ファイルの行番号情報を参考に、必要な定義を移行先の設定ファイルに移行してください。 移行の注意点は、[ 注意制限事項 > マイグレーション > 注意事項 > WebOTX Webサーバ > WebOTX Webサーバ 2.x からの移行 ] を参照してください。

運用ユーザの追加、及びパスワードの変更

マイグレーション実行後の環境は、下記のユーザを設定しています。

また、他にユーザを追加していた場合も、パスワードが移行されていないため、ユーザの追加やパスワードの変更が必要になることがあります。 この場合、統合運用管理ツールや、otxadminコマンドを利用して運用ユーザの作成、及び変更を実施してください。

キーストア/トラストストアの設定

WebOTXが提供しているもの以外の独自の証明書や、独自のキーストアエントリは移行されません。 利用している場合、Javaが提供するkeytoolコマンドを利用し、移行先の環境に対して証明書やキーストアエントリを登録する必要があります。

登録の必要がある場合、パラメータシートに手動で追加することを促すメッセージが出力されます。 その場合は、下記の設定方法に基づき、マイグレーション完了後に設定を行ってください。

ライフサイクルモジュールの配置と設定変更
ライフサイクルモジュールの配置

マイグレーション機能ではライフサイクルモジュール設定の移行のみを行っており、ライブラリは手動で配置する必要があります。 パラメータシートを確認し、アプリケーションのノード配下にライフサイクルモジュールの設定が存在する場合、移行元から移行先へライフサイクルモジュールのライブラリをコピーしてください。

また、ライブラリのコピー先は、パラメータシート上で[アプリケーション/ライフサイクルモジュール]-[ライフサイクルモジュール名]-[クラスパス]で指定しているパス、またはWebOTXがロードする場所に配置する必要があります。

ライブラリの配置についての詳細は、下記を参照してください。

ライフサイクルモジュールの設定変更

ライフサイクルモジュールの設定を移行する際に、[サービス起動失敗時動作]の設定をfalseに変更しています。移行元でtrueを設定していた場合は、ライブラリを配置した後に下記のコマンドにより設定を変更してください。

otxadmin > set server.applications.lifecycle-module.{ライフサイクルモジュール名}.is-failure-fatal=true
内部ライフサイクルモジュールの設定変更

内部ライフサイクルモジュールは、WebOTXが既定で提供する機能です。

本設定を移行する際に、[サービス起動失敗時動作]の設定をfalseに変更しています。移行元でtrueを設定していた場合は、下記のコマンドにより設定を変更してください。

otxadmin > set server.internal-lifecycle-module.{内部ライフサイクルモジュール名}.is-failure-fatal=true

提供しているサービス名は、下記の章の内部ライフサイクルモジュール配下を参照してください。

JDBCデータソースの接続確認

移行後、そのままの状態ではJDBCドライバの設定やパスワードの設定が足りないため接続に失敗します。次の手順で接続確認を行ってください。

  1. 次のマニュアルを参照し、必要に応じてクラスパス設定などの準備作業を実施してください。

  2. セキュリティ上、パスワードは移行しません。次のコマンドで正しいパスワードを設定してください。
    otxadmin> set server.resources.jdbc-datasource.<datasource-name>.password=<パスワード>
    
    * datasource-nameは、"jdbc/"で始まるJDBCデータソースの定義名です。
  3. 次のgetコマンドでJDBC URLまたはデータベース名、データソース名[dataSourceName]およびサーバ名[serverName]を取得し、データベースサーバの接続先が正しいことを確認してください。
    otxadmin> get server.resources.jdbc-datasource.<datasource-name>.dataSourceName
    otxadmin> get server.resources.jdbc-datasource.<datasource-name>.serverName
    
    必要であれば次のsetコマンドで設定を行ってください。
    otxadmin> get server.resources.jdbc-datasource.<datasource-name>.dataSourceName=<JDBC URLまたはデータベース名、データソース名>
    otxadmin> get server.resources.jdbc-datasource.<datasource-name>.serverName=<データベースサーバ側のサーバ名>
    
    JDBC URLまたはデータベース名、データソース名[dataSourceName]およびサーバ名[serverName]の詳細は次のマニュアルを確認してください。
  4. 次のコマンドで、接続テストを実施してください。
    otxadmin> ping-jdbc-datasource <datasource-name>
    

    接続テストの詳細は次のマニュアルを確認してください。

TransactionサービスのJCAリソースについて

JCAリソースのユーザ名、パスワードは移行の対象外です。移行元で独自に設定を行っていた場合は、移行後に設定を行ってください。

コマンド実行例:
otxadmin> set server.resources.jca-resource.<リソース名>.user-name=<ユーザ名>
otxadmin> set server.resources.jca-resource.<リソース名>.password=<パスワード>

・[リファレンス > 設定 > Transactionサービス > リソースを管理するためのコマンド]

組込IIOPサービス

以下のパスワード設定は移行されません。

移行元環境で既定値から変更を行っている場合は、手動でパスワードを設定してください。

(例)

otxadmin > set server.embedded-iiop-service.cert-key-pass-phrase=<パスワード>
コネクタコネクションプール

各コネクタコネクションプールに対応したセキュリティマップは移行されません。

(例)

移行元環境でセキュリティマップを作成している場合は、手動でセキュリティマップを再作成してください。

otxadmin > create-connector-security-map --poolname <コネクタコネクションプール名> --principals <プリンシパル名> --mappedpassword <ユーザグループ名> --mappedusername <enterprise information systemユーザ名>  --mappedpassword <enterprise information systemパスワード> <セキュリティマップ名>
TPモニタマネージャ

Standardエディションの場合、TPシステムの以下の設定は、環境に依存するため移行されません。

手動で適した値を設定してください。

(例)

otxadmin > set tpsystem.nameSvHostName=<名前サーバのホスト名>
3.3.8.2. HP-UX、Linux
WebOTX運用管理ユーザの変更

WebOTX運用管理ユーザでWebOTXを運用したい場合は、運用ユーザの変更を行います。

具体的な手順は [ 構築・運用 > ドメインの構築 > ユーザ管理 > その他の管理ユーザ > 管理ユーザ設定(UNIX) > WebOTX管理ユーザ(運用ユーザ)の設定 ] を参照してください。

サービスやドメインの動作確認

サービスが開始できること、ドメインが起動できることを確認します。

具体的な手順は、インストールガイド(LinuxHP-UX )の[動作確認]を参照ください。

なお、マイグレーションでの移行後はドメインのパスワードが既定に変更されています。ドメインのパスワードが必要な場合はadminadminを使用してください。

JMS

移行元環境において、JDBCストアを利用していた場合、移行先の環境では、ファイルストアに変更されています。 また、JMSサーバクラスタを利用していた場合は、移行先の環境では無効になっています。 移行先でも、JDBCストアや、JMSサーバクラスタを利用する場合は、それぞれ、次の手順で有効化してください。

  1. JMSサービスを停止します。
    otxadmin> stop-jms
    
  2. 【JDBCストア利用時】JDBCストア利用のための準備をします。
    1. 次のコマンドにより、永続ストアタイプと、接続先の情報を設定します。
      otxadmin> set server.jms-service.storeType=<永続ストアタイプ>
      otxadmin> set server.jms-service.jdbcStoreURL=<JDBC URL>
      otxadmin> set server.jms-service.jdbcStoreUser=<DBユーザ名>
      otxadmin> set server.jms-service.jdbcStorePassword=<DBパスワード>
      
    2. 移行元で利用していたDBを移行先からも利用する場合、移行元環境のテーブルを削除します。
      > jmqdbmgr delete tbl -u <DBユーザ名> -p <DBパスワード> -t <DBの種類> -url <JDBC URL>
      
      Memo
      -url オプションで接続先を指定する場合、${INSTANCE_ROOT}/lib/ext に移行されているjarファイルを参照しませんので、${AS_INSTALL}/jmq/lib/ext に、対象データベースのJDBCドライバのjarファイルを格納してください。
    3. 移行先のテーブルを作成します。
      > jmqdbmgr create tbl -otxdomain <ドメイン名>
      
  3. 【JMSサーバクラスタ利用時】JMSサーバクラスタ有効化のための設定をします。
    otxadmin> set server.jms-service.enableCluster=true
    
    JMSサーバクラスタを構成するサーバ情報に変更がある場合は、次のコマンドにより変更してください。
    otxadmin> set server.jms-service.clusterBrokerList=<JMSサーバのアドレスリスト>
    otxadmin> set server.jms-service.clusterMasterBroker=<マスターブローカのアドレス>
    
  4. JMSサービスを起動します。
    otxadmin> start-jms
    
Webサーバ

パラメータシートで差分を確認し、移行元の設定ファイルの行番号情報を参考に、必要な定義を移行先の設定ファイルに移行してください。 移行の注意点は、[ 注意制限事項 > マイグレーション > 注意事項 > WebOTX Webサーバ > WebOTX Webサーバ 2.x からの移行 ] を参照してください。

運用ユーザの追加、及びパスワードの変更

マイグレーション実行後の環境は、下記のユーザを設定しています。

また、他にユーザを追加していた場合も、パスワードが移行されていないため、ユーザの追加やパスワードの編集が必要になることがあります。 この場合、統合運用管理ツールや、otxadminコマンドを利用して運用ユーザの作成、及び変更を実施してください。

キーストア/トラストストアの設定

WebOTXが提供しているもの以外の独自の証明書や、独自のキーストアエントリは移行されません。 利用している場合、Javaが提供するkeytoolコマンドを利用し、移行先の環境に対して証明書やキーストアエントリを登録する必要があります。

登録の必要がある場合、パラメータシートに手動で追加することを促すメッセージが出力されます。 その場合は、下記の設定方法に基づき、マイグレーション完了後に設定を行ってください。

ライフサイクルモジュールの配置と設定変更
ライフサイクルモジュールの配置

マイグレーション機能ではライフサイクルモジュール設定の移行のみを行っており、ライブラリは手動で配置する必要があります。 パラメータシートを確認し、アプリケーションのノード配下にライフサイクルモジュールの設定が存在する場合、移行元から移行先へライフサイクルモジュールのライブラリをコピーしてください。

また、ライブラリのコピー先は、パラメータシート上で[アプリケーション/ライフサイクルモジュール]-[ライフサイクルモジュール名]-[クラスパス]で指定しているパス、またはWebOTXがロードする場所に配置する必要があります。

ライブラリの配置についての詳細は、下記を参照してください。

ライフサイクルモジュールの設定変更

ライフサイクルモジュールの設定を移行する際に、[サービス起動失敗時動作]の設定をfalseに変更しています。移行元でtrueを設定していた場合は、ライブラリを配置した後に下記のコマンドにより設定を変更してください。

otxadmin > set server.applications.lifecycle-module.{ライフサイクルモジュール名}.is-failure-fatal=true
内部ライフサイクルモジュールの設定変更

内部ライフサイクルモジュールは、WebOTXが既定で提供する機能です。

本設定を移行する際に、[サービス起動失敗時動作]の設定をfalseに変更しています。移行元でtrueを設定していた場合は、下記のコマンドにより設定を変更してください。

otxadmin > set server.internal-lifecycle-module.{内部ライフサイクルモジュール名}.is-failure-fatal=true

提供しているサービス名は、下記の章の内部ライフサイクルモジュール配下を参照してください。

JDBCデータソースの接続確認

移行後、接続確認を行ってください。手順はWindowsと同様ですので、次の箇所を参照してください。

TransactionサービスのJCAリソースについて

移行後、必要な場合は設定を行ってください。手順はWindowsと同様ですので、次の箇所を参照してください。

組込IIOPサービス

以下のパスワード設定は移行されません。

移行元環境で既定値から変更を行っている場合は、手動でパスワードを設定してください。

(例)

otxadmin > set server.embedded-iiop-service.cert-key-pass-phrase=<パスワード>
コネクタコネクションプール

各コネクタコネクションプールに対応したセキュリティマップは移行されません。

移行元環境でセキュリティマップを作成している場合は、手動でセキュリティマップを再作成してください。

(例)

otxadmin > create-connector-security-map --poolname <コネクタコネクションプール名> --principals <プリンシパル名> --mappedpassword <ユーザグループ名> --mappedusername <enterprise information systemユーザ名>  --mappedpassword <enterprise information systemパスワード> <セキュリティマップ名>
TPモニタマネージャ

Standardエディションの場合、TPシステムの以下の設定は、環境に依存するため移行されません。

手動で適した値を設定してください。

(例)

otxadmin > set tpsystem.nameSvHostName=<名前サーバのホスト名>

3.4. 注意制限事項

3.4.1. 注意事項

[ 注意制限事項 > 機能ごとの注意制限事項 > マイグレーション > 注意事項 ] を参照してください。

3.4.2. 制限事項

[ 注意制限事項 > 機能ごとの注意制限事項 > マイグレーション > 制限事項 ] を参照してください。