| Oracle® Fusion Middleware SOA SuiteおよびBusiness Process Managementのアップグレード 12c (12.2.1.2) E82837-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware SOA SuiteおよびBusiness Process Managementのアップグレード 12c (12.2.1.2) E82837-02 |
|
|
前 |
次 |
注意:
Oracle Service BusがSOA 11gまたは以前の12cドメインの一部であり、Oracle Service BusをOracle SOA Suiteの12c (12.2.1.2)へのアップグレードの一環としてアップグレードする場合は、SOA SuiteおよびBusiness Process Managementの11gからのアップグレードまたはOracle SOA SuiteおよびBusiness Process Managementの以前の12cリリースからのアップグレードで説明されている標準アップグレード手順に従ってください。Oracle SOA Suiteを含まないOracle Service Bus 11gデプロイメントをアップグレードするには、このプロセス・フローに従います。
Oracle Service Bus (OSB)は、Oracle SOA SuiteおよびBusiness Process Managementの有無にかかわらず12c (12.2.1.2)にアップグレードできます。このトピック内のアップグレード手順では、SOAを含まないOracle Service Busのアップグレード方法について説明します。
Oracle Service BusがSOA 11gまたは以前の12cドメインに含まれており、Oracle SOA Suiteの12c (12.2.1.2)へのアップグレードの一部としてOracle Service Busをアップグレードする場合は、「SOA SuiteおよびBusiness Process Managementの11gからのアップグレード」で説明している標準アップグレード・プロセスに従います。
注意:
ドメインにSOAが含まれていない場合でも、Oracle Service Busメタデータをアップグレードするために、_SOAINFRAスキーマをアップグレードする必要があります。Oracle Service Busには別個のスキーマはありません。 | タスク | 説明 |
|---|---|
| Oracle Web Services Managerがまだデプロイされていない場合は必要となります。 既存の11g環境にOracle Web Services Managerポリシー・マネージャをデプロイします。 |
Oracle Web Services Manager (OWSM)ポリシー・マネージャがOracle Service Bus 11g環境にデプロイされていない場合は、12cにアップグレードする前に、それを手動でデプロイする必要があります。 |
必須 Oracle Service Busのアップグレード時にサービス、プロジェクトおよびリソースをエクスポートします |
Oracle Service Bus 12c (12.2.1.2)にアップグレードする前に、サービス、プロジェクトおよびリソースを構成JARファイルにエクスポートする必要があります。アップグレード後に、このJARファイルを新しい12c環境にインポートします。 |
必須 既存の環境からすべてのサービス、プロジェクトおよびリソースを削除します。 |
エクスポートの後、ユーザーが作成したすべてのサービス、プロジェクトおよびリソースを、アップグレード前に削除する必要があります。 |
必須 12c Oracle Fusion Middleware Infrastructureディストリビューションを新しいOracleホームにインストールします。 |
12c Infrastructure (Oracle WebLogic ServerおよびJRFコンポーネントを含む)をインストールする必要があります。 |
必須 Oracle Service Busを新しいOracleホームにインストールします。 |
Oracle Service Busディストリビューションを入手して、そのコンテンツを新しいOracleホームにインストールします。 |
| 必須 リポジトリ作成ユーティリティ(RCU)を実行して、必要な新しいスキーマを作成します。 |
Service Tableスキーマ(_STB)は、すべてのドメインのための新しい必須スキーマです。11gからアップグレードする場合は、12cにアップグレードする前にこのスキーマを作成する必要があります。 SOAがドメインの一部でない場合でも、Oracle Service Busには、SOAスキーマ( 以前の12cリリースからアップグレードする場合、別のService Tableスキーマは作成しないでください。 |
| 必須 すべてのサーバーおよびプロセスを停止します。 |
アップグレードを開始する前に、すべてのサーバーおよびプロセスを停止する必要があります。 |
必須 Upgrade Assistantを実行して、必要なスキーマをアップグレードします。 |
以前の12cリリースからアップグレードする場合は、 |
| 必須 再構成ウィザードを実行して、既存のドメインを再構成します。 |
アップグレード後も既存のドメインを引き続き使用するため、新しいコンポーネントと機能するよう、それを再構成する必要があります。 |
| 必須 Upgrade Assistantを実行して、コンポーネント構成を構成します。 |
Upgrade Assistantをもう一度実行して、新しいドメインで機能するようコンポーネント構成を更新します。 |
必須 アップグレード後タスクをすべて実行します。 |
標準の12cアップグレード後タスクと、各自のデプロイメントに該当するOSB固有のアップグレード後タスクをすべて実行します。 |
Oracle Service Bus 11gのトポロジが単一のドメイン内の複数のコンポーネントで構成されている場合は、12c (12.2.1.2)にアップグレードできません
単一OSBドメイン内でUMSを使用する複数コンポーネントのアップグレード(未サポート)
特定のFusion Middlewareコンポーネント(Oracle SOA、Oracle Service Bus (OSB)、Business Activity Monitoring (BAM)など)は、12cでは、ユーザー・メッセージング・サービス(UMS)に対する依存関係があります。単一の12c (12.2.1.2)ドメイン内でこれらのコンポーネントのうち複数を構成する場合は、コンポーネントが動作するサーバーが1つしかない場合でも、これらのコンポーネントは各自のクラスタ内で動作する必要があります。
このようなコンポーネントをアップグレードするには、ドメインの再構成時に、各コンポーネントに個別のクラスタを作成する必要があります(クラスタに関する項を参照)。
このようなコンポーネントに対してサポートされるアップグレード・トポロジについては、「クラスタ化トポロジのアップグレード」を参照してください。
Oracle Service Busをアップグレードする場合は、アップグレードを開始する前に、次の各タスクを実行する必要があります。独自のユース・ケースのシナリオと既存のデプロイメントを調べて、次のタスクが各自の環境に当てはまるかどうかを判断してください。
Oracle Web Services Manager (OWSM)ポリシー・マネージャがOracle Service Bus 11g環境にデプロイされていない場合は、12cにアップグレードする前に、それを手動でデプロイする必要があります。
11gでは、WebLogicのセキュリティ・ポリシーとOWSMのポリシーは、どちらもOracle Service Busでサポートされていました。11g (11.1.1.7)の時点でWebLogicセキュリティ・ポリシーは非推奨になり、12c (12.2.1.2)ではサポートされなくなりました。11gではWebLogicセキュリティ・ポリシーが使用可能であったため、OWSMポリシー・マネージャのデプロイメントとOWSMポリシーの使用はオプションでした。12cではOWSMポリシーのみがサポートされているため、OWSMポリシー・マネージャのデプロイメントが必須になります。
OWSMポリシー・マネージャを手動で11g環境にデプロイする方法の詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のWebLogic ServerでのOWSMのインストールに関する項を参照してください。
Oracle Service Bus 12c (12.2.1.2)にアップグレードする前に、サービス、プロジェクトおよびリソースを構成JARファイルにエクスポートする必要があります。アップグレード後に、このJARファイルを新しい12c環境にインポートします。
リソースとサービスは、サポート対象の旧リリースから手動でエクスポートできます。「以前のリリースからのOracle Service Busリソースの移行」を参照してください。
詳細は、『Oracle Service Busでのサービスの開発』のリソースと構成のインポートおよびエクスポートに関する項を参照してください。
エクスポートの後、ユーザーが作成したすべてのサービス、プロジェクトおよびリソースを、アップグレード前に削除する必要があります。
Oracle Service Bus Consoleの使用方法の詳細は、プロジェクト、フォルダおよびリソースの削除方法に関する項を参照してください。
JDeveloperを使用したリソースの削除の詳細は、「プロジェクトまたはリソースの削除方法」を参照してください。
リソースとサービスは、次の各リリースから手動でエクスポートして、Oracle Service Bus 12c (12.2.1.2)で使用できます。
Oracle Service Bus 12cリリース12.1.3.0、12.2.1.0および12.2.1.1
Oracle Service Bus 11gリリース: 11.1.1.7.0
Oracle Service Bus 10.3リリース: 10.3.1および10.3.0
AquaLogic® Service Busリリース3.0以降
詳細は、『Oracle Service Busでのサービスの開発』のリソースと構成のインポートおよびエクスポートに関する項を参照してください。
アップグレードを開始する前に、Oracle Universal Installerを使用して、必要な製品ディストリビューションをターゲット・システムにインストールします。Oracle Service Busは、Oracle SOA SuiteおよびBusiness Process Managementなしでインストールおよびアップグレードできますが、Oracle Service Busをアップグレードする前には、Oracle Fusion Middleware Infrastructure 12c (12.2.1.2)をインストールする必要があります。
注意:
アップグレードにInfrastructureが必要な場合は、その他のFusion Middleware製品をインストールする前に、まずOracle Fusion Middleware Infrastructureディストリビューションをインストールする必要があります。Oracle Service Busには、Oracle Fusion Middleware Infrastructure (Oracle WebLogic ServerおよびJRF)が必要です。
11gからアップグレードする場合、アップグレードを開始する前に、リポジトリ作成ユーティリティ(RCU)を使用して必要な12cスキーマを作成する必要があります。
注意:
Oracle Fusion Middlewareの前の12cリリースからアップグレードする場合、これらのスキーマがすでに存在する場合には再作成する必要はありません。ドメインの既存のスキーマを特定するには、次の手順を参照してください。Oracle Fusion Middleware 11gリリースでは、SOAスキーマは必須ではなかったため、データベースなしでOracle Service Bus (OSB)を実行することもできました。ただし、12cでは、Oracle Service Bus 12c (12.2.1.2)を実行する前に、サポートされているデータベースを必須のSOAスキーマで構成しておく必要があります。
11gからアップグレードする場合は、「アップグレード前チェックリスト」を参照してドメイン内の既存のスキーマを識別します。12cにアップグレードする前に、次のスキーマが存在している必要があります。
サービス表スキーマ(prefix_STB)。このスキーマは12cで新規のものであり、ドメインベースのアップグレードに必要になります。基本的なスキーマ構成情報(スキーマ接頭辞やパスワードなど)が格納され、他のOracle Fusion Middlewareコンポーネントはドメイン作成中にこれにアクセスして使用できます。このスキーマはリポジトリ作成ユーティリティ(RCU)を実行するときに自動的に作成され、ここで他の11gスキーマに使用した既存のスキーマ所有者接頭辞を指定します。注意: サービス表スキーマが存在しない場合、UPGAST-00328: スキーマ・バージョンのレジストリ表はこのデータベースに存在しません。その場合、アップグレード・アシスタントを実行するためにはサービス表スキーマを作成する必要があります。というエラー・メッセージが表示されることがあります。
prefix_SOAINFRA)。prefix_UMS)。Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、管理サーバーや管理対象サーバーを含め、すべてのプロセスとサーバーを停止する必要があります。
Oracle Fusion Middleware環境は、Oracle WebLogic Serverドメイン、管理サーバー、複数の管理対象サーバー、Javaコンポーネント、Identity Managementコンポーネントなどのシステム・コンポーネント、およびメタデータのリポジトリとして使用されるデータベースで構成できます。それらのコンポーネントは相互に依存する場合があるため、正しい順序で停止する必要があります。
注意:
この項内の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用してサーバーおよびプロセスを停止する方法を説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。Oracle Fusion Middlewareの管理の管理サーバー、管理対象サーバーおよびノード・マネージャの起動と停止を参照してください。Fusion Middleware環境を停止するには、次の手順に従います。
手順1: システム・コンポーネントの停止
Oracle HTTP Serverなどのシステム・コンポーネントを停止するには、stopComponentスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name
(Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name
どの順序でもシステム・コンポーネントを停止できます。
手順2: 管理対象サーバーの停止
WebLogic Server管理対象サーバーを停止するには、stopManagedWebLogicスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url
(Windows) 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: Oracle Identity Managementコンポーネントの停止
環境の一部を形成する、Oracle Internet DirectoryなどのOracle Identity Managementコンポーネントを停止します。(UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name
(Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name
手順4: 管理サーバーの停止
管理サーバーを停止するときには、WebLogic Server管理コンソールおよびFusion Middleware Controlなど、管理サーバーで実行されているプロセスも停止します。
管理サーバーを停止するには、stopWebLogicスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/stopWebLogic.sh
(Windows) DOMAIN_HOME\bin\stopWebLogic.cmd
プロンプトが表示されたら、管理サーバーのユーザー名、パスワードおよびURLを入力します。
手順5: ノード・マネージャの停止
ノード・マネージャを停止するには、それが実行されているコマンド・シェルを閉じます。
またはnodemanager.propertiesのQuitEnabledの属性をtrueに設定した後(デフォルトはfalseです)、WLSTを使用して、ノード・マネージャに接続して停止できます。詳細は、WebLogic Server WLSTコマンド・リファレンスのstopNodeManagerを参照してください。
Oracle Service Busスキーマはありませんが、Oracle Service Busのデータベース・スキーマのデータは、SOAINFRAスキーマに組み込まれています。そのため、Oracle Service Busをアップグレードするには、SOAINFRAスキーマをアップグレードする必要があります。
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。
oracle_common/upgrade/binディレクトリに移動します。ORACLE_HOME/oracle_common/upgrade/binORACLE_HOME\oracle_common\upgrade\binロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。
アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。
表4-5 Upgrade Assistantコマンド・ライン・パラメータ
| パラメータ | 必須/オプション | 説明 |
|---|---|---|
|
準備状況チェックに必要 注意: 準備状況チェックは、スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。 |
実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。 スキーマおよび構成がチェックされます。
|
|
オプション | スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックに必要 |
GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantがサイレント・モード(Upgrade Assistantの画面の表示なし)で実行されます。 |
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
オプション |
次のいずれかの属性を指定して、ロギング・レベルを設定します。
デフォルトのロギング・レベルは より多くの情報がログ記録されるよう、 |
|
オプション |
アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 UNIXの場合:
Windowsの場合:
|
|
オプション |
すべてのコマンド・ライン・オプションを表示します。 |
再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)に再構成します。
WebLogic Serverドメインを再構成すると、ドメイン内のアプリケーションに応じて、次の項目が自動的に更新されます。
WebLogic Serverコア・インフラストラクチャ
ドメイン・バージョン
注意:
ドメイン再構成を開始する前に、次の制限事項に注意してください。
再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。
アップグレード・プロセスの間の非動的クラスタ・ドメインから動的クラスタ・ドメインへの変換はサポートされていません。
動的クラスタ機能は再構成ウィザードの実行時に使用可能ですが、Oracleでは、非動的クラスタのアップグレード後の動的クラスタの追加のみがサポートされています。アップグレード・プロセスの間に動的クラスタを追加することはできません。
ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。
すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。
起動スクリプトが更新されます。
変更した起動スクリプトを保持する必要がある場合は、再構成ウィザードを開始する前にそれらをバックアップするようにしてください。
注意:
ドメインの再構成プロセスを開始すると、元に戻すことはできません。再構成ウィザードを実行する前に、アップグレード前チェックリストに示されているようにドメインをバックアップしてあることを確認してください。再構成ウィザードの実行中にエラーまたは他の割込みが発生した場合、バックアップ場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーすることによって、ドメインをリストアする必要があります。これは、ドメインが再構成前の元の状態に戻されたことを確認する唯一の方法です。再構成ウィザードを実行する前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。
ドメイン・ディレクトリのバックアップを作成するには、次の手順を実行します。
Upgrade Assistantを実行する前に、再構成ウィザードを使用して、まず既存のドメインを再構成する必要があります。
注意:
ソースがクラスタ環境である場合は、再構成ウィザードをプライマリ・ノードでのみ実行します。圧縮/解凍ユーティリティを使用して、ドメイン内の他のクラスタ・メンバーに変更を適用します。注意:
「拡張構成」画面に表示されるオプション・カテゴリは、ドメインのために選択したテンプレートで定義されているリソースによって異なります。一般的な一部のカテゴリを次に示します。ドメインの各管理対象サーバーに対し、リスニング・アドレスの実際のホスト名を指定する必要があります。
デフォルトのlocalhostまたは「すべてのローカル・アドレス」オプションは使用しないでください。
実際のホスト名を、hostname.company.comのように指定する必要があります。
「管理対象サーバー」>サーバー・グループのターゲット指定
注意:
以前の12cリリース(たとえば12.1.3)で作成されたドメインをアップグレードする場合、アップグレードのドメイン再構成フェーズで、サーバーを正しいサーバー・グループにターゲット指定する必要があります。これらのサーバーのターゲット指定に失敗すると、アップグレードの失敗や不要なダウンタイムの発生につながることがあります。「管理対象サーバー」画面で「サーバー・グループ」ドロップダウン・メニューから正しいグループ名を選択して、各サーバーを正しいサーバー・グループにターゲット指定します。
GUID-E96F27A4-74D8-4A33-83E3-1829BDBD98B4-default.pngの説明が続きます。
| コンポーネントとサーバー | サーバー・グループ |
|---|---|
| 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クラスタの一部ではない場合:ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。
oracle_common/upgrade/binディレクトリに移動します。ORACLE_HOME/oracle_common/upgrade/binORACLE_HOME\oracle_common\upgrade\binロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。
アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。
表4-6 Upgrade Assistantコマンド・ライン・パラメータ
| パラメータ | 必須/オプション | 説明 |
|---|---|---|
|
準備状況チェックに必要 注意: 準備状況チェックは、スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。 |
実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。 スキーマおよび構成がチェックされます。
|
|
オプション | スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックに必要 |
GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantがサイレント・モード(Upgrade Assistantの画面の表示なし)で実行されます。 |
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
オプション |
次のいずれかの属性を指定して、ロギング・レベルを設定します。
デフォルトのロギング・レベルは より多くの情報がログ記録されるよう、 |
|
オプション |
アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 UNIXの場合:
Windowsの場合:
|
|
オプション |
すべてのコマンド・ライン・オプションを表示します。 |
アップグレードが正常に完了したら、次のタスクを1つ以上実行する必要がある場合があります。独自のユース・ケースのシナリオと既存のデプロイメントを調べて、次のタスクが各自の環境に当てはまるかどうかを判断してください。
注意:
Oracle Service Busでアップグレード後の問題が発生した場合は、「Oracle Service Busのトラブルシューティング」で、一般的な解決策の一覧を参照してください。
Oracle Service BusコンソールおよびOracle Service BusサービスにOracle HTTP Serverからルーティングできるようにするため、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定します。
詳細は、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』のOracle Service Bus用のOracle HTTP Serverの構成に関する項を参照してください。
アップグレード後に、「Oracle Service Busのアップグレード時のサービス、プロジェクトおよびリソースのエクスポート」でエクスポートしたドメイン構成データをインポートする必要があります。
詳細は、「コンソールで構成JARファイルからリソースをインポートする方法」および構成ファイルの実行に関する項を参照してください。
Oracle WebLogic Server管理コンソールを使用して、アップグレード前にエクスポートしたセキュリティ・データを新しいOracle Service Busドメインにインポートします。
詳細は、Oracle WebLogic Server管理コンソールのオンライン・ヘルプでセキュリティ・プロバイダへのデータのインポートに関する項を参照してください。
注意:
セキュリティ情報は、セキュリティ・プロバイダごとに個別にインポートする必要があります。
Oracle Service Busでは、XQuery 1.0をサポートしています。旧XQuery 2004もサポートされます。Service Busで作成された新しいXQueryリソースは、デフォルトでXQuery 1.0を使用します。
12cより前のService Busプロジェクトからアップグレードすると、そのプロジェクト内のすべてのXQueryリソースが、XQuery 2004バージョンを使用するように構成されます。
XQuery Resourcesのアップグレードの詳細は、「XQuery 1.0を使用したXQueryリソースのアップグレード方法」を参照してください。
12cにはパイプラインまたはプロキシ・サービスから分割-結合コンポーネントを直接呼び出す方法があるため、12cではFusion Middleware 11gの分割-結合ビジネス・サービスはなくなりました。アップグレード・プロセスでは、次のようにして、静的に構成されたすべての呼び出しの参照を自動的に分割-結合ビジネス・サービスに変更します。
フロー・ビジネス・サービスは削除されます。つまり、フロー・ビジネス・サービス用に構成されたTimeoutプロパティも削除されます。
ビジネス・サービスと、それを呼び出すプロキシ・サービスが同じプロジェクトに配置されている場合は、そのプロキシ・サービスに関連付けられたパイプラインにより分割-結合が直接呼び出されます。
ビジネス・サービスと、それを呼び出すプロキシ・サービスが異なるプロジェクトに配置されている場合は、分割-結合を呼び出すためのローカル プロキシ・サービスが作成されます。このローカル・プロキシ・サービスは、元のプロキシ・サービスから呼び出されます。
Oracle Service Busでアップグレード後の問題が発生した場合は、次の内容を確認して、関連する解決方法を適用してください。
クラスタ・ドメインのフロントエンド・ホストとして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>
12cより前のOSBコンソールには、URL: http://[HOST]:[PORT]/sbconsoleを使用してアクセスしていました。
12cでは、OSBコンソールのURLがhttp://[HOST]:[PORT]/servicebusに変更されています。
アップグレード後に、http://[HOST]:[PORT]/sbconsoleと入力すると、http://[HOST]:[PORT]/servicebusにリダイレクトされます。
リダイレクトに失敗して、HTTP 404エラーが返された場合は、12cのURL http://[HOST]:[PORT]/servicebusを直接入力してみてください。
