Oracle Service Bus (Oracle SOA Suiteなし)のアップグレード

4 Oracle Service Bus (Oracle SOA Suiteなし)のアップグレード

Oracle SOA SuiteおよびBusiness Process Managementを含まないOracle Service Busをアップグレードする際の、アップグレード固有のタスクについて説明します。

ノート:

Oracle Service Busが既存の12cドメインに含まれており、Oracle SOA Suiteの14c (14.1.2.0.0)へのアップグレードの一部としてOracle Service Busをアップグレードする場合は、「SOA SuiteおよびBusiness Process Managementのアップグレード」で説明している標準アップグレード・プロセスに従います。

Oracle Service Busのスタンドアロン・アップグレードの理解

Oracle SOA Suiteを含まないOracle Service Bus 12c (12.2.1.4.0)デプロイメントをアップグレードするには、このプロセス・フローに従います。

Oracle Service Bus (OSB)は、Oracle SOA SuiteおよびBusiness Process Managementの有無にかかわらず14c (14.1.2.0.0)にアップグレードできます。このトピック内のアップグレード・ステップでは、SOAを含まないOracle Service Busのアップグレード方法について説明します。

Oracle Service Busが既存のSOA 12cドメインに含まれており、Oracle SOA Suiteの14c (14.1.2.0.0)へのアップグレードの一部としてOracle Service Busをアップグレードする場合は、「SOA SuiteおよびBusiness Process Managementのアップグレード」で説明している標準アップグレード・プロセスに従います。

ノート:

ドメインにSOAが含まれていない場合でも、Oracle Service Busメタデータをアップグレードするために、_SOAINFRAスキーマをアップグレードする必要があります。Oracle Service Busには別個のスキーマはありません。

タスク	説明
必須 Oracle Service Busのアップグレード時にサービス、プロジェクトおよびリソースをエクスポートします	Oracle Service Bus 14c (14.1.2.0.0)にアップグレードする前に、サービス、プロジェクトおよびリソースを構成JARファイルにエクスポートする必要があります。アップグレード後に、このJARファイルを新しい環境にインポートします。
必須既存の環境からすべてのサービス、プロジェクトおよびリソースを削除します。	エクスポートの後、ユーザーが作成したすべてのサービス、プロジェクトおよびリソースを、アップグレード前に削除する必要があります。
必須 14c (14.1.2.0.0) Oracle Fusion Middleware Infrastructureディストリビューションを新しいOracleホームにインストールします。	14c (14.1.2.0.0)インフラストラクチャ(Oracle WebLogic ServerおよびJRFコンポーネントを含む)をインストールする必要があります。
必須 Oracle Service Busを新しいOracleホームにインストールします。	Oracle Service Busディストリビューションを入手して、そのコンテンツを新しいOracleホームにインストールします。
必須すべてのサーバーおよびプロセスを停止します。	アップグレードを開始する前に、すべてのサーバーおよびプロセスを停止する必要があります。
必須 Upgrade Assistantを実行して、必要なスキーマをアップグレードします。	`_SOAINFRA`スキーマは、14c (14.1.2.0.0)にアップグレードする必要があります。
必要再構成ウィザードを実行して、既存のドメインを再構成します。	アップグレード後も既存のドメインを引き続き使用するため、新しいコンポーネントと機能するよう、それを再構成する必要があります。
必須 Upgrade Assistantを実行して、コンポーネント構成を構成します。	Upgrade Assistantをもう一度実行して、新しいドメインで機能するようコンポーネント構成を更新します。
必須アップグレード後タスクをすべて実行します。	標準のアップグレード後タスクと、各自のデプロイメントに該当するOSB固有のアップグレード後タスクをすべて実行します。

Oracle Service Busのアップグレードに関する制限事項

Oracle Service Busのトポロジが単一のドメイン内の複数のコンポーネントで構成されている場合は、14c (14.1.2.0.0)にアップグレードできません

単一OSBドメイン内でUMSを使用する複数コンポーネントのアップグレード(未サポート)

特定のFusion Middlewareコンポーネント(Oracle SOA、Oracle Service Bus (OSB)、Business Activity Monitoring (BAM)など)は、ユーザー・メッセージング・サービス(UMS)に対する依存関係があります。単一の14c (14.1.2.0.0)ドメイン内でこれらのコンポーネントのうち複数を構成する場合は、コンポーネントが動作するサーバーが1つしかない場合でも、これらのコンポーネントは各自のクラスタ内で動作する必要があります。

このようなコンポーネントをアップグレードするには、ドメインの再構成時に、各コンポーネントに個別のクラスタを作成する必要があります(クラスタに関する項を参照)。

このようなコンポーネントに対してサポートされるアップグレード・トポロジについては、「クラスタ化トポロジのアップグレード」を参照してください。

Oracle Service Bus (OSB)のアップグレード前タスクの実行

Oracle Service Busをアップグレードする場合は、アップグレードを開始する前に、次の各タスクを実行する必要があります。独自のユース・ケースのシナリオと既存のデプロイメントを調べて、次のタスクが各自の環境に当てはまるかどうかを判断してください。

Oracle Service Busのアップグレード時のサービス、プロジェクトおよびリソースのエクスポート

Oracle Service Bus 14c (14.1.2.0.0)にアップグレードする前に、既存のサービス、プロジェクトおよびリソースを構成JARファイルにエクスポートする必要があります。アップグレード後に、このJARファイルを新しい環境にインポートします。

ノート:

WebLogic Serverでは、JNDI名でmyqueues/myqueueのようにフォワード・スラッシュを使用できますが、フォワード・スラッシュのあるJNDI名は、Service Busに必要とされるURI形式と一致しないため、このような名前は使用できません。この問題を回避するには、JMS外部サーバーを定義してURIでその外部サーバーを参照します。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部サーバーの構成に関する項を参照してください。

リソースとサービスは、サポート対象の旧リリースから手動でエクスポートできます。「以前のリリースからのOracle Service Busリソースの移行」を参照してください。

詳細は、『Oracle Service Busでのサービスの開発』のリソースと構成のインポートおよびエクスポートに関する項を参照してください。

すべてのサービス、プロジェクトおよびリソースの削除

エクスポートの後、ユーザーが作成したすべてのサービス、プロジェクトおよびリソースを、アップグレード前に削除する必要があります。

Oracle Service Bus Consoleの使用方法の詳細は、プロジェクト、フォルダおよびリソースの削除方法に関する項を参照してください。

JDeveloperを使用したリソースの削除の詳細は、「プロジェクトまたはリソースの削除方法」を参照してください。

以前のリリースからのOracle Service Busリソースの移行

リソースとサービスは、手動でエクスポートして、Oracle Service Bus 14c (14.1.2.0.0)で使用できます。

詳細は、『Oracle Service Busでのサービスの開発』のリソースと構成のインポートおよびエクスポートに関する項を参照してください。

Oracle Service Busのインストール

Oracle Universal Installerを使用して、必要な製品ディストリビューションをターゲット・システムにインストールします。Oracle Service Busは、Oracle SOA SuiteおよびBusiness Process Managementなしでインストールおよびアップグレードできますが、Oracle Service Busをアップグレードする前には、Oracle Fusion Middleware Infrastructure 14c (14.1.2.0.0)をインストールする必要があります。

ノート:

アップグレードにInfrastructureが必要な場合は、他のFusion Middleware製品をインストールする前に、まずOracle Fusion Middleware Infrastructureディストリビューションをインストールする必要があります。ご使用のJDKがサポートされていない場合、またはJDKをインストールしていない場合は、開始前に必要なJava SE JDKをダウンロードする必要があります

開始する前に、次の点に注意してください。

Oracle Service Busには、Oracle Fusion Middleware Infrastructure (Oracle WebLogic ServerおよびJRF)が必要です。

Oracle Service BusでOracle Web Services Managerポリシーを使用する場合、Oracle WebLogicドメインの構成時にいずれかのOracle Service Busドメイン・テンプレートを選択した後、Oracle Web Services Manager拡張テンプレートを選択する必要があります。

Oracle Service Busの必須ディストリビューションをインストールするには:

ターゲットのシステムにサインインします。
Oracle Technology NetworkまたはOracle Software Delivery Cloudから、ターゲット・システムにOracle Fusion Middleware Infrastructure (fmw_14.1.2.0.0_infrastructure.jar)をダウンロードします。
- Fusion Middleware Infrastructureディストリビューション(fmw_14.1.2.0.0_infrastructure.jar)
- Oracle Service Bus (fmw_14.1.2.0.0_osb.jar)
14c (14.1.2.0.0)製品ディストリビューションをダウンロードしたディレクトリに移動します。
Oracle Fusion Middleware Infrastructureのインストール・プログラムを起動します。
- (UNIX) JDK_HOME/bin/java -jar fmw_14.1.2.0.0_infrastructure_generic.jar
- (Windows) JDK_HOME\bin\java -jar fmw_14.1.2.0.0_infrastructure_generic.jar
UNIXオペレーティング・システムでは、このホストにOracle製品を初めてインストールする場合に、「インストール・インベントリの設定」画面が表示されます。
中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名に対して中央インベントリの場所への書込み権限が付与されていることを確認し、「次へ」をクリックします。

ノート:
「インストール・インベントリの設定」画面は、Windowsオペレーティング・システムでは表示されません。
「ようこそ」画面で、情報をレビューしてすべての前提条件を満たしていることを確認します。「次へ」をクリックします。
「インストールの場所」画面でOracleホーム・ディレクトリの場所を指定し、「次へ」をクリックします。
Oracle Fusion Middlewareディレクトリ構造の詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成のためのディレクトリの理解に関する項を参照してください。
「インストール・タイプ」画面で、インストールする製品(1つまたは複数)を選択します。製品の依存関係が自動的に選択されます。「次へ」をクリックします。
「前提条件チェック」画面では、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
確認されたタスクのリストを表示するには、「正常なタスクの表示」を選択します。ログの詳細を表示するには、「ログの表示」を選択します。前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。エラー・メッセージや警告メッセージを無視してインストールを続けるには、「スキップ」をクリックします(非推奨)。
「インストール・サマリー」画面で、選択したインストール・オプションを確認します。
これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルには、入力したすべての情報が収集して格納され、後で(コマンドラインから)サイレント・インストールを実行するために使用できます。
「インストール」をクリックしてインストールを開始します。
「インストールの進行状況」画面で、進行状況バーに100%と表示されたら、「終了」をクリックしてインストーラを終了するか、「次へ」をクリックしてサマリーを表示します。
「インストール完了」画面に、インストールの場所とインストールされた機能セットが表示されます。情報を確認し、「終了」をクリックしてインストーラを閉じます。
Infrastructureをインストールしたら、ステップ3から11までを繰り返してOracle Service Busディストリビューションをインストールします。

サーバーとプロセスの停止

Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、すべてのプアップグレード前のプロセスと管理サーバーや管理対象サーバーを含めたすべてのサーバーを停止する必要があります。

Oracle Fusion Middleware環境は、Oracle WebLogic Serverドメイン、管理サーバー、複数の管理対象サーバー、Javaコンポーネント、システム・コンポーネント、およびメタデータのリポジトリに使用されるデータベースで構成できます。コンポーネントは相互に依存していることがあるため、適切な順序で停止する必要があります。

ノート:

この項内の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用して既存のアップグレード前のサーバーおよびプロセスを停止する方法を説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Serverリモート・コンソールを使用することもできます。管理サーバー、管理対象サーバーおよびノード・マネージャの起動と停止を参照してください。

リリース14c (14.1.2.0.0)以降、WebLogic Server管理コンソールは削除されました。同等の機能を使用するには、WebLogicリモート・コンソールを使用する必要があります。詳細は、Oracle WebLogicリモート・コンソールを参照してください。

アップグレード前のFusion Middleware環境を停止するには、アップグレード前のドメインに移動し、次のステップに従います。

ノート:

次のサーバーを正しい順序で停止することが重要です。

ステップ1: システム・コンポーネントの停止

Oracle HTTP Serverなどのシステム・コンポーネントを停止するには、stopComponentスクリプトを使用します。

(UNIX) EXISTING_DOMAIN_HOME/bin/stopComponent.sh component_name
(Windows) EXISTING_DOMAIN_HOME\bin\stopComponent.cmd component_name

どの順序でもシステム・コンポーネントを停止できます。

ステップ2: 管理対象サーバーの停止

WebLogic Server管理対象サーバーを停止するには、stopManagedWebLogicスクリプトを使用します。

(UNIX) EXISTING_DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url
(Windows) EXISTING_DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url

プロンプトが表示されたらユーザー名とパスワードを入力します。

SOAサーバーおよびプロセスは、次の順番で停止してください。

Business Activity Monitoring (BAM)管理対象サーバー
Oracle Service Bus (OSB)管理対象サーバー
サービス指向アーキテクチャ(SOA)管理対象サーバー
Oracle Web Services Manager (OWSM)管理対象サーバー

ステップ3: 管理サーバーを停止する

管理サーバーを停止するには、stopWebLogicスクリプトを使用します。

(UNIX) EXISTING_DOMAIN_HOME/bin/stopWebLogic.sh
(Windows) EXISTING_DOMAIN_HOME\bin\stopWebLogic.cmd

プロンプトが表示されたら、管理サーバーのユーザー名、パスワードおよびURLを入力します。

ステップ4: ノード・マネージャを停止する

ノード・マネージャを停止するには、それが実行されているコマンド・シェルを閉じます。

またはnodemanager.propertiesの属性QuitEnabledをtrueに設定した後(デフォルトはfalseです)、WLSTを使用して、ノード・マネージャに接続して停止できます。『WebLogic Server WLSTコマンド・リファレンス』のstopNodeManagerに関する項を参照してください。

Upgrade Assistantを使用したスキーマのアップグレード

ノート:

Service Busの場合、アップグレードする必要があるドメインのスキーマが存在する場合のみ、このステップが必要です。RCUを使用して必要なスキーマを作成し、ドメインに他のスキーマが存在しない場合、このステップをスキップして再構成ウィザード・ステップに移動できます。

Oracle Service Busスキーマはありませんが、Oracle Service Busのデータベース・スキーマのデータは、SOAINFRAスキーマに組み込まれています。そのため、Oracle Service Busをアップグレードするには、SOAINFRAスキーマをアップグレードする必要があります(存在する場合)。

アップグレード・アシスタントの起動

Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを14c (14.1.2.0.0)にアップグレードします。

Upgrade Assistantを起動するには、次の手順に従います。

ノート:

Upgrade Assistantを起動する前に、Upgrade Assistantを実行しているプラットフォームにJVM文字エンコーディングがUTF-8に設定されていることを確認してください。文字エンコーディングがUTF-8に設定されていない場合、名前にUnicode文字を含むファイルをダウンロードできません。アップグレードが失敗することがあります。文字エンコーディングを設定するには、次を実行します。

UNIXオペレーティング・システムの場合:

export UA_PROPERTIES="-Dfile.encoding=UTF-8 ${UA_PROPERTIES}"

Windowsオペレーティング・システムの場合:

set UA_PROPERTIES=-Dfile.encoding=UTF-8 %UA_PROPERTIES%

oracle_common/upgrade/binディレクトリに移動します。
- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin
- (Windows) ORACLE_HOME\oracle_common\upgrade\bin
Upgrade Assistantを起動します。
- (UNIX) ./ua
- (Windows) ua.bat

ロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。

アップグレード・アシスタントのパラメータ

アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。

表4-1 Upgrade Assistantコマンドライン・パラメータ

パラメータ	必須またはオプション	説明
`-readiness`	準備状況チェックに必要ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。	実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。スキーマおよび構成がチェックされます。 `-examine`パラメータを指定した場合は、このパラメータを使用しないでください。
`-threads`	オプション	スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。値は、1 - 8の正の整数である必要があります。デフォルトは4です。
`-response`	サイレント・アップグレードまたはサイレント準備状況チェックに必要	GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。
`-examine`	オプション	調査フェーズを実行しますが、実際のアップグレードは実行しません。 `-readiness`パラメータを指定した場合、このパラメータを指定しないでください。
`-logLevel attribute`	オプション	次のいずれかの属性を指定して、ロギング・レベルを設定します。 `TRACE` `NOTIFICATION` `WARNING` `ERROR` `INCIDENT_ERROR` デフォルトのロギング・レベルは`NOTIFICATION`です。より多くの情報がログ記録されるよう、`-logLevel TRACE`属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。`-logLevel TRACE`が使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。
`-logDir location`	オプション	アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。デフォルトの場所は次のとおりです。 (UNIX) `ORACLE_HOME/oracle_common/upgrade/logs` `ORACLE_HOME/oracle_common/upgrade/temp` (Windows) `ORACLE_HOME\oracle_common\upgrade\logs` `ORACLE_HOME\oracle_common\upgrade\temp`
`-help`	オプション	すべてのコマンドライン・オプションを表示します。

アップグレード・アシスタントを使用したSOAスキーマのアップグレード

Upgrade Assistantの各画面を通じて、製品スキーマをアップグレードします。

Upgrade Assistantを実行して、Service Busドメインの製品スキーマをアップグレードします。また、Upgrade Assistantは必要なスキーマを検出でき、RCUを使用して以前のステップで作成しなかった場合に作成します。

Upgrade Assistantで製品スキーマをアップグレードするには:

「ようこそ」画面で、Upgrade Assistantの概要、および重要なアップグレード前作業に関する情報を確認します。「次へ」をクリックします。

ノート:
Upgrade Assistantの画面の詳細は、その画面上のヘルプをクリックしてください。
「選択したスキーマ」画面で、実行するスキーマ・アップグレード操作を選択します。
- 「ドメインで使用されるすべてのスキーマ」を使用すると、Upgrade Assistantは、ドメイン内でアップグレードに対応可能な「ドメイン・ディレクトリ」フィールドで指定されたスキーマを持つコンポーネントをすべて検出して選択します。これは、ドメイン支援のスキーマ・アップグレードとも呼ばれています。さらに、Upgrade Assistantはスキーマの入力画面に接続情報を事前に移入します。
  
  ノート:
  すべての必要なスキーマがアップグレードに含まれていることを確認するためにほとんどのアップグレードに「ドメインで使用されるすべてのスキーマ」を選択することをお薦めします。
- 「個別に選択されたスキーマ」: ドメインで使用されるスキーマをすべてアップグレードするのではなく、アップグレードするスキーマを個別に選択する場合のオプションです。
  
  注意:
  14c (14.1.2.0.0)コンポーネントをサポートするために使用されるスキーマのみをアップグレードしてください。Oracle Fusion Middleware 14c (14.1.2.0.0)に含まれないコンポーネントをサポートするために現在使用されているスキーマは、アップグレードしないでください。
「次へ」をクリックします。
「個別に選択されたスキーマ」を選択した場合: 「使用可能なコンポーネント」画面で、スキーマをアップグレードするコンポーネントを選択します。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。
「使用可能なコンポーネント」画面でOracle Platform Security ServicesまたはOracle Audit Servicesが選択されている場合は、「ドメイン・ディレクトリ」画面が表示されます。既存のWebLogicドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックして、アップグレードするドメイン・ディレクトリに移動して選択します
「前提条件」画面で、すべてのチェック・ボックスを選択することで、前提条件を満たしていることを認めます。「次へ」をクリックします。

ノート:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。
スキーマ資格証明画面で、アップグレードしている各スキーマのデータベース接続詳細を指定します(選択したスキーマに基づいて画面名が変わります)。
- 「データベース・タイプ」ドロップダウン・メニューからデータベース・タイプを選択します。
- データベース接続の詳細を入力して、「接続」をクリックします。
- 「スキーマ・ユーザー名」ドロップダウン・メニューからアップグレードするスキーマを選択し、スキーマのパスワードを入力します。アップグレードするスキーマに対して正しいスキーマ接頭辞を使用してください。
「スキーマの作成」画面で、Upgrade Assistantが欠落スキーマを作成するかどうかを指定します。デフォルトでは、指定されたドメインの欠落スキーマの作成オプションが有効です。Upgrade Assistantは、指定されたデータベース接続詳細およびスキーマ所有者名を使用してドメインの欠落スキーマを作成します。Upgrade Assistantは、デフォルト設定を使用してスキーマを作成します。同じパスワードがすべてのスキーマに使用される場合、「すべてのスキーマに同じパスワードを使用」を選択します。表のパスワードを入力して確認します。パスワードを指定する必要があるのは1回のみです。

ノート:

スキーマにカスタマイズされたオプションが必要な場合、Upgrade Assistantによるスキーマの作成を許可しないでください。デフォルトのリポジトリ作成ユーティリティ設定を使用して、スキーマが作成されます。たとえば、スキーマに追加の表領域が必要な場合、RCUを使用してスキーマを作成する必要があります。

アップグレード・アシスタントでこれらのスキーマを作成しない場合は、このオプションの選択を解除し、「次」をクリックします。リポジトリ作成ユーティリティを使用してスキーマを作成する必要があります。
「調査」画面で、各スキーマを調査したUpgrade Assistantのステータスを確認して、スキーマのアップグレードの準備が整っていることを検証します。ステータスが「調査が終了しました。」の場合は、「次」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、一般的なアップグレード・エラーの解決の詳細をUpgrade Assistantによるアップグレードのアップグレードのトラブルシューティングで参照してください。
ノート:
- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、Upgrade Assistantを再度開始する前に、バックアップからアップグレード前の環境をリストアする必要があります。
- 調査プロセスを取り消してもスキーマまたは構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報を再収集する必要があります。
「アップグレード・サマリー」画面で、アップグレードまたは作成、あるいはその両方が行われるスキーマのサマリーを確認します。
アップグレード対象の各スキーマについて、正しいソース・バージョンとターゲット・バージョンがリストされていることを確認します。

これらのオプションをレスポンス・ファイルに保存して、後で再度レスポンス(またはサイレント)モードでUpgrade Assistantを実行する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を提供します。サイレント・アップグレードでは、Upgrade Assistantとまったく同じ機能が実行されますが、データを手動で再入力する必要はありません。

「次」をクリックします
「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

注意:
アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないスキーマがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

ノート:
この画面上の進行状況バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

「次へ」をクリックします。
アップグレードが正常に終了した場合: 「アップグレード成功」画面で、「閉じる」をクリックしてアップグレードを完了しウィザードを閉じます。

アップグレードが失敗した場合: 「アップグレード失敗」画面で、「ログの表示」をクリックしてエラーを表示し、トラブルシューティングします。ログはNEW_ORACLE_HOME/oracle_common/upgrade/logsにあります。

ノート:
アップグレードが失敗した場合は、バックアップからアップグレード前の環境をリストアし、問題を修正してから、Upgrade Assistantを再起動する必要があります。

ドメインの再構成について

再構成ウィザードを実行して、ドメイン・コンポーネント構成を14c (14.1.2.0.0)に再構成します。

ノート:

ソースがクラスタ環境である場合は、再構成ウィザードをプライマリ・ノードでのみ実行します。

WebLogic Serverドメインを再構成すると、ドメイン内のアプリケーションに応じて、次の項目が自動的に更新されます。

WebLogic Serverコア・インフラストラクチャ
ドメイン・バージョン

ノート:

ドメイン再構成を開始する前に、次の制限事項に注意してください。

再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。
アップグレード・プロセスの間の非動的クラスタ・ドメインから動的クラスタ・ドメインへの変換はサポートされていません。

動的クラスタ機能は再構成ウィザードの実行時に使用可能ですが、Oracleでは、非動的クラスタのアップグレード後の動的クラスタの追加のみがサポートされています。アップグレード・プロセスの間に動的クラスタを追加することはできません。

アップグレードするインストールでOracle Access Management (OAM)が使用されない場合は、2つのファイルを編集して、再構成ウィザードが、存在しないOAMインフラストラクチャ・スキーマの更新(アップグレードが失敗する)を試みないようにする必要があります。

$DOMAIN/init-info/domain-info.xmlに次の例のような行をコメント・アウトします。

<!--extention-template-ref name="Oracle Identity Navigator" 
  version="14.1.2.0.0" 
  location="/u01/app/oracle/product/fmw/iam111130/common/templates/applications/yourcomany.oinav_14.1.2.0.0_template.jar" 
  symbol=""/-->

<!--install-comp-ref name="oracle.idm.oinav" version="14.1.2.0.0" 
  symbol="yourcompany.idm.oinav_14.1.2.0.0_iam141200_ORACLE_HOME" 
  product_home="/u01/app/oracle/product/fmw/iam141200"/-->

また、同様に、$DOMAIN/config/config.xmlに次の例のような行をコメント・アウトします。

<!--app-deployment> 
  <name>oinav#14.1.2.0.0</name>
  <target>AdminServer</target>
  <module-type>ear</module-type>

  <source-path>/u01/app/oracle/product/fmw/iam141200/oinav/modules/oinav.ear_14.1.2.0.0/oinav.ear</source-path>
  <deployment-order>500</deployment-order>
  <security-dd-model>DDOnly</security-dd-model>
  <staging-mode>nostage</staging-mode>
</app-deployment-->

具体的には、ドメインを再構成すると、次のようになります。

ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。
すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。
起動スクリプトが更新されます。

変更した起動スクリプトを保持する必要がある場合は、再構成ウィザードを開始する前にそれらをバックアップするようにしてください。

ノート:

ドメインの再構成プロセスを開始すると、行う変更を元に戻すことはできません。再構成ウィザードを実行する前に、アップグレード前チェックリストに示されているようにドメインをバックアップしてあることを確認してください。再構成ウィザードの実行中にエラーまたは他の割込みが発生した場合、バックアップ場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーすることによって、ドメインをリストアする必要があります。これは、ドメインが再構成前の元の状態に戻されたことを確認する唯一の方法です。

ドメインのバックアップ

再構成ウィザードを実行する前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。

ドメイン・ディレクトリのバックアップを作成します。
各リモート管理対象サーバー上でドメインを更新する前に、各リモート・マシン上のドメイン・ディレクトリのバックアップ・コピーを作成します。
ドメインのバックアップしたバージョンが完全であることを確認します。

ドメインの再構成がなんらかの理由で失敗した場合は、すべてのファイルおよびディレクトリをバックアップ・ディレクトリから元のドメイン・ディレクトリにコピーして、ドメインを再構成前の元の状態に完全に戻す必要があります。

再構成ウィザードの起動

ノート:

再構成プロセスを開始する前に管理サーバーおよびすべてのコロケートされた管理対象サーバーを停止します。「サーバーとプロセスの停止」を参照

再構成ウィザードをグラフィカル・モードで起動するには:

ドメインが存在するシステムにサインインします。
コマンド・シェル(UNIXオペレーティング・システムの場合)またはコマンド・プロンプト・ウィンドウ(Windowsオペレーティング・システムの場合)を開きます。
oracle_common/common/binディレクトリに移動します。
- (UNIX) NEW_ORACLE_HOME/oracle_common/common/bin
- (Windows) NEW_ORACLE_HOME\oracle_common\commom\bin
再構成ウィザードを次のロギング・オプションを指定して起動します。
- (UNIX) ./reconfig.sh -log=log_file -log_priority=ALL
- (Windows) reconfig.cmd -log=log_file -log_priority=ALL
log_fileは、ドメイン再構成セッション用に作成するログ・ファイルの絶対パスです。これは、再構成処理をトラブルシューティングする必要がある場合に役立つことがあります。
パラメータ-log_priority=ALLを指定すると、ログが詳細モードで記録されます。
ノート:

このコマンドを実行すると、デフォルトのキャッシュ・ディレクトリが無効であることを示す次のエラー・メッセージが表示される場合があります。
```
*sys-package-mgr*: can't create package cache dir
```
環境変数CONFIG_JVM_ARGSを設定することでキャッシュ・ディレクトリを変更できます。たとえば:

CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

再構成ウィザードを使用したSOAドメインの再構成

ドメイン・コンポーネント構成を構成するには、Upgrade Assistantを実行する前に、再構成ウィザードを使用して、まず既存のドメインを再構成する必要があります。

ノート:

ソースがクラスタ環境である場合は、再構成ウィザードをプライマリ・ノードでのみ実行します。圧縮/解凍ユーティリティを使用して、ドメイン内の他のクラスタ・メンバーに変更を適用します。

ドメインを再構成するには:

「ドメインの選択」画面で、アップグレードするドメインの場所を指定するか、「参照」をクリックしてナビゲートし、ドメインのディレクトリを選択します。「次へ」をクリックします。
「再構成セットアップの進行状況」画面で、設定プロセスの進行状況を確認します。完了したら、「次へ」をクリックします。
このプロセスでは次の処理が行われます。
- Fusion Middleware製品を含む、インストール済製品の再構成テンプレートが自動的に適用されます。これにより、config.xml、config-groups.xml、security.xmlなどの様々なドメイン構成ファイルが更新されます。
- Fusion Middleware製品をサポートするスクリプトおよびその他のファイルが更新されます。
- ドメイン・アップグレードが検証されます。
「ドメイン・モードおよびJDK」画面で、ドメインで使用するJDKを選択するか、「参照」をクリックして、使用するJDKにナビゲートします。14c (14.1.2.0.0)でサポートされているJDKバージョンは、17.0.12以降です。「次へ」をクリックします。

ノート:
このステージでは、「ドメイン・モード」を変更することはできません。ドメインは、アップグレード前のドメイン・モードを保持します。ドメインをセキュア・モードに変更する場合は、アップグレード後に「アップグレード後のドメイン・モードの変更」を参照してください。

特定のプラットフォームでサポートされているJDKのリストは、Oracle Fusion Middlewareでサポートされているシステム構成の説明を参照してください。
「データベース構成タイプ」画面で、「RCUデータ」を選択して、サーバー表 (<PREFIX>_STB) スキーマに接続します。
ノート: <PREFIX>は、アップグレードされる12.2.1.4ドメインのRCUスキーマ接頭辞です。

RCUサービス表 (<PREFIX>_STB)スキーマ資格証明を使用してデータベース接続の詳細を入力して、「RCU構成の取得」をクリックします。

再構成ウィザードは、この接続を使用して、ドメインのコンポーネントに必要なデータソースを自動的に更新します。

ノート:
デフォルトでは、Oracleのサービス接続用ドライバ(Thin)、バージョン: 任意が選択されたドライバです。サービス名のかわりに接続詳細のインスタンス名を指定した場合、Oracleのサービス接続用ドライバ(Thin)、バージョン: 任意を選択する必要があります。ドライバ・タイプを変更しないと、接続は失敗します。

チェックが成功した場合は、「次へ」をクリックします。チェックが失敗した場合は、接続の正しい詳細を再入力し、再試行します。
「JDBCコンポーネント・スキーマ」画面で、各コンポーネント・スキーマのDBMS/サービスおよびホスト名が正しいことを確認し、「次へ」をクリックします。
「JDBCコンポーネント・スキーマ・テスト」画面で、すべてのコンポーネント・スキーマを選択して「選択された接続のテスト」をクリックし、各スキーマの接続をテストします。テストの結果は、「ステータス」列に表示されます。
チェックが完了したら、「次へ」をクリックします。

「拡張構成」画面で、拡張構成を実行するすべてのカテゴリを選択できます。選択したカテゴリごとに、詳細構成を行うことができる適切な構成画面が表示されます。

ノート:

「拡張構成」画面に表示されるオプション・カテゴリは、ドメインのために選択したテンプレートで定義されているリソースによって異なります。一般的な一部のカテゴリを次に示します。

「拡張構成」>「管理対象サーバー」:

ドメインの各管理対象サーバーに対し、リスニング・アドレスの実際のホスト名を指定する必要があります。

デフォルトのlocalhostまたは All Local Addressesオプションは使用しないでください。

実際のホスト名を、hostname.yourcompany.comのように指定する必要があります

「管理対象サーバー」>サーバー・グループのターゲット指定

12c (12.2.1.4.0)で作成されたドメインをアップグレードする場合、アップグレードのドメイン再構成フェーズで、サーバーを正しいサーバー・グループにターゲット指定する必要があります。これらのサーバーのターゲット指定に失敗すると、アップグレードの失敗や不要なダウンタイムの発生につながることがあります。

「管理対象サーバー」画面で「サーバー・グループ」ドロップダウン・メニューから正しいグループ名を選択して、各サーバーを正しいサーバー・グループにターゲット指定します。

各サーバーが正しいサーバー・グループにターゲット指定され、「未指定」と表示されていないことを確認します。

コンポーネントとサーバー	サーバー・グループ
SOA (soa_server1)	SOA-MGD-SVRS-ONLY
Oracle Service Bus - OSB (osb_server1)	OSB-MGD-SVRS-ONLY
Business Activity Monitoring - BAM (bam_server1)	BAM-MGD-SVRS-ONLY
Managed File Transfer - MFT (mft_server1)	MFT-MGD-SVRS-ONLY

「拡張構成」>「サーバーのマシンへの割当」

アップグレード・プロセスの一部としてサーバーを作成した場合は、「サーバー」リスト・ボックスでサーバー名を選択して、適切なノード・マネージャ・マシンにターゲット設定します。

そうでない場合は、ドメインのアップグレード時または再構成時にこの画面で操作は必要ありません。

「拡張構成」>「サーバーのクラスタへの割当」

クラスタのアップグレードのみ: クラスタをアップグレードする場合は、この画面を使用して管理対象サーバーをクラスタに割り当てます。

「サーバー」リスト・ボックスには管理対象サーバーのみが表示されます。管理サーバーは、クラスタに割り当てることができないので、リストに表示されません。

ノート:

OWSMPMがそれ固有のクラスタ内にあり、SOAまたはOSBクラスタの一部ではない場合:

SOA-MGD-SVRS-ONLYユーザー拡張可能サーバー・グループのみをSOAクラスタのターゲットに指定します

OSB-MGD-SVRS-ONLYのみをOSBクラスタのターゲットに指定します
WSMPM-MAN-SVERサーバー・グループをOWSMのターゲットに指定します

「構成のサマリー」画面で、ドメインの詳細な構成設定を確認してから続行します。
「表示」ドロップダウン・リストからフィルタ・オプションを選択すると、右側のパネルに表示される項目を制限できます。

構成を変更するには、「戻る」をクリックして適切な画面に戻ります。ドメインを再構成するには、「再構成」をクリックします。

ノート:
ドメインを再構成しても、その場所は変更されません。
「再構成の進行状況」画面には、再構成プロセスの進行状況が表示されます。
このプロセスでは次の処理が行われます。
- ドメイン情報が抽出、保存および更新されます。
- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。
進捗バーが100%になったら、「次へ」をクリックします。
「構成の終了」画面には、再構成プロセスが正常に完了したか失敗したかが示されます。管理サーバーURL(リスニング・ポートを含む)とともに再構成されたドメインの場所も表示します。再構成が成功した場合は、Oracle Weblogic Serverの再構成に成功しましたと表示されます。
再構成プロセスが正常に完了しなかった場合は、その理由を示すエラー・メッセージが表示されます。問題を解決するための適切な措置を講じます。問題を解決できない場合は、My Oracle Supportに連絡してください。

以後の操作のためにドメインの場所と管理サーバーURLをノートにとります。

ドメイン・コンポーネント構成のアップグレード

ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。

アップグレード・アシスタントの起動

Upgrade Assistantを起動するには、次の手順に従います。

ノート:

UNIXオペレーティング・システムの場合:

export UA_PROPERTIES="-Dfile.encoding=UTF-8 ${UA_PROPERTIES}"

Windowsオペレーティング・システムの場合:

set UA_PROPERTIES=-Dfile.encoding=UTF-8 %UA_PROPERTIES%

oracle_common/upgrade/binディレクトリに移動します。
- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin
- (Windows) ORACLE_HOME\oracle_common\upgrade\bin
Upgrade Assistantを起動します。
- (UNIX) ./ua
- (Windows) ua.bat

ロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。

アップグレード・アシスタントのパラメータ

アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。

表4-2 Upgrade Assistantコマンドライン・パラメータ

パラメータ	必須またはオプション	説明
`-readiness`	準備状況チェックに必要ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。	実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。スキーマおよび構成がチェックされます。 `-examine`パラメータを指定した場合は、このパラメータを使用しないでください。
`-threads`	オプション	スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。値は、1 - 8の正の整数である必要があります。デフォルトは4です。
`-response`	サイレント・アップグレードまたはサイレント準備状況チェックに必要	GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。
`-examine`	オプション	調査フェーズを実行しますが、実際のアップグレードは実行しません。 `-readiness`パラメータを指定した場合、このパラメータを指定しないでください。
`-logLevel attribute`	オプション	次のいずれかの属性を指定して、ロギング・レベルを設定します。 `TRACE` `NOTIFICATION` `WARNING` `ERROR` `INCIDENT_ERROR` デフォルトのロギング・レベルは`NOTIFICATION`です。より多くの情報がログ記録されるよう、`-logLevel TRACE`属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。`-logLevel TRACE`が使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。
`-logDir location`	オプション	アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。デフォルトの場所は次のとおりです。 (UNIX) `ORACLE_HOME/oracle_common/upgrade/logs` `ORACLE_HOME/oracle_common/upgrade/temp` (Windows) `ORACLE_HOME\oracle_common\upgrade\logs` `ORACLE_HOME\oracle_common\upgrade\temp`
`-help`	オプション	すべてのコマンドライン・オプションを表示します。

Upgrade Assistantの使用によるドメイン・コンポーネントのアップグレード

Upgrade Assistantで複数の画面をナビゲートし、WebLogicドメイン内のコンポーネント構成をアップグレードします。

再構成ウィザードを実行してWebLogicドメインをOracle Analyticsサーバーに再構成した後、アップグレード・アシスタントを実行して、ドメイン・コンポーネント構成を更新済ドメイン構成に一致するようにアップグレードする必要があります。

Upgrade Assistantでドメイン・コンポーネント構成をアップグレードするには:

「ようこそ」画面で、Upgrade Assistantの概要、および重要なアップグレード前作業に関する情報を確認します。「次へ」をクリックします。

ノート:
Upgrade Assistantの画面の詳細は、その画面上のヘルプをクリックしてください。
次の画面で、次のことを実行します。
- 「ドメインによって使用されるすべての構成」を選択します。画面名が「WebLogicコンポーネント」に変わります。
- 「ドメイン・ディレクトリ」フィールドで、WebLogicドメイン・ディレクトリのパスを入力します。
「次へ」をクリックします。
アップグレード前の環境に複数のWebLogicドメインがあるが、Oracle Web Services Manager (OWSM)ポリシー・マネージャが1つのドメインのみにあり、OWSMエージェントが他のドメインにある場合: OWSMポリシー・マネージャ画面で、Oracle Web Services Manager (OWSM)ポリシー・マネージャがデプロイされているWebLogic管理サーバー・ドメインの資格証明を提供します。
「コンポーネント・リスト」画面で、構成をアップグレードするすべてのコンポーネントを含んだリストを確認し、「次」をクリックします。
アップグレード対象のコンポーネントが表示されていない場合は、「戻る」をクリックして前の画面に戻り、別のドメインを指定します。
「前提条件」画面で、すべてのチェック・ボックスを選択することで、前提条件を満たしていることを認めます。「次へ」をクリックします。

ノート:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。
ユーザー・メッセージング・サービス(UMS)構成ファイルをホストするリモート管理対象サーバーがある場合: UMS構成画面で、Upgrade Assistantが構成ファイルにアクセスできるよう、これらのサーバーへの資格証明を提供します。

ノート:
Upgrade AssistantでUMS構成ファイルが見つからない場合は、それらのファイルを手動でコピーする必要があります。ユーザー・メッセージング・サービス(UMS)構成ファイルのコピー中のエラーを参照してください。
Upgrade Assistantで各コンポーネントを調査したら、「調査」画面で、Upgrade Assistantのステータスを確認し、コンポーネント構成のアップグレード準備が整っていることを確かめます。ステータスが「調査が終了しました。」の場合は、「次」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、一般的なアップグレード・エラーの解決の詳細をUpgrade Assistantによるアップグレードのアップグレードのトラブルシューティングで参照してください。
ノート:
- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、Upgrade Assistantを再度開始する前に、バックアップからアップグレード前の環境をリストアする必要があります。
- 調査プロセスを取り消しても構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報を再収集する必要があります。
「アップグレード・サマリー」画面で、コンポーネント構成のアップグレードのために選択したオプションについて、概要を確認します。
レスポンス・ファイルにより、入力したすべての情報を収集および保存し、後でサイレント・アップグレードを実行できます。サイレント・アップグレードでは、Upgrade Assistantとまったく同じ機能が実行されますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。
「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

注意:
アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないコンポーネントがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

ノート:
この画面上の進行状況バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

「次へ」をクリックします。
アップグレードが正常に終了した場合: 「アップグレード成功」画面で、「閉じる」をクリックしてアップグレードを完了しウィザードを閉じます。新規インストールでコンポーネントを機能させるために手動で実行する必要のある作業が、アップグレード後のアクションウィンドウに表示されます。このウィンドウは、コンポーネントにアップグレード後のステップがある場合のみ表示されます。

アップグレードが失敗した場合: 「アップグレード失敗」画面で、「ログの表示」をクリックしてエラーを表示し、トラブルシューティングします。ログはORACLE_HOME/oracle_common/upgrade/logsにあります。

ノート:
アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を修正して、Upgrade Assistantを再度起動する必要があります。

Oracle Service Busのアップグレード後タスクの実行

アップグレードが正常に完了したら、次のタスクを1つ以上実行する必要がある場合があります。独自のユース・ケースのシナリオと既存のデプロイメントを調べて、次のタスクが各自の環境に当てはまるかどうかを判断してください。

ノート:

Oracle Service Busでアップグレード後の問題が発生した場合は、「Oracle Service Busのトラブルシューティング」で、一般的な解決策の一覧を参照してください。

WLS_OSB管理対象サーバーのOracle HTTP Serverの構成

Oracle Service BusコンソールおよびOracle Service BusサービスにOracle HTTP Serverからルーティングできるようにするため、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定します。

詳細は、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』のOracle Service Bus用のOracle HTTP Serverの構成に関する項を参照してください。

ドメイン構成データのインポート

アップグレード後に、「Oracle Service Busのアップグレード時のサービス、プロジェクトおよびリソースのエクスポート」でエクスポートしたドメイン構成データをインポートする必要があります。

ノート:

Oracle WebLogicリモート・コンソール・オンライン・ヘルプの外部サーバーの構成に関する項を参照してください。

詳細は、「コンソールで構成JARファイルからリソースをインポートする方法」および構成ファイルの実行に関する項を参照してください。

セキュリティ構成のインポート

Oracle WebLogicリモート・コンソールを使用して、アップグレード前にエクスポートしたセキュリティ・データを新しいOracle Service Busドメインにインポートします。

詳細は、Oracle WebLogicリモート・コンソールのオンライン・ヘルプでセキュリティ・プロバイダへのデータのインポートに関する項を参照してください。

ノート:

セキュリティ情報は、セキュリティ・プロバイダごとに個別にインポートする必要があります。

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

Oracle Service Busでアップグレード後の問題が発生した場合は、次の内容を確認して、関連する解決方法を適用してください。

クラスタのフロントエンド・ホストとしてOHSを使用するOSBのアップグレード後のHTTP 404エラーの解決

クラスタ・ドメインのフロントエンド・ホストとしてOracle HTTP Server (OHS)を構成する場合は、OHS構成ファイル(ohs.confg)に次のコードを追加する必要があります。

 <Location /sbconsole>
  SetHandler weblogic-handler
  WebLogicCluster [ADMIN_SERVER_HOST]:[ADMIN.SERVER:PORT]
</Location>
<Location /servicebus>
  SetHandler weblogic-handler
  WebLogicCluster [ADMIN_SERVER_HOST]:[ADMIN.SERVER:PORT]
</Location>

ADMIN.SERVER:PORTは、OHSに使用するマシン名、サーバー名およびポート番号です。

次のサンプル・コード内のmymachine.us.mycompany.com:7001がその例です。

<Location /sbconsole>
  SetHandler weblogic-handler
  WebLogicCluster mymachine.us.mycompany.com:7001
</Location>
<Location /servicebus>
  SetHandler weblogic-handler
  WebLogicCluster mymachine.us.mycompany.com:7001
</Location>