ヘッダーをスキップ
Oracle® Fusion Middleware SOA SuiteおよびBusiness Process Managementのアップグレード
12c (12.1.3)
E57555-04
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
次
 

3 SOA SuiteおよびBusiness Process Management 12c (12.1.3)のアップグレード

この章では、単一ノードの本番SOA SuiteおよびBusiness Process Management 11gリリース1 (11.1.1.6または11.1.1.7)インストールを、SOA SuiteおよびBusiness Process Management 12c (12.1.3)にアップグレードする詳しい手順について説明します。


注意:

実際の本番環境の完全な作業用コピーを作成し、クローン環境をアップグレードし、アップグレードされたコンポーネントが予想どおりに動作することを確認してから(必ず確認した後で)、本番環境をアップグレードすることをお薦めします。

潜在的なアップグレードの問題をクローン環境で特定しておくと、本番環境で無駄な停止時間を排除できます。

詳細は、第2.1.1項「本番環境の開発コピーの作成、アップグレードおよびテスト」を参照してください。


3.1 Oracle SOA SuiteおよびBusiness Process Managementのインストール

既存のSOAおよびBusiness Process Management (BPM) 11gのコンポーネントをアップグレードする前に、まず、SOA SuiteおよびBusiness Process Management 12c (12.1.3)ディストリビューションをインストールする必要があります。Oracle SOA Suite FoundationおよびBusiness Process Managementのインストールおよび構成で説明されている手順に従ってください。


注意:

使用するSOAドメインに別のSOA統合コンポーネントがある場合は、それらのディストリビューションもインストールする必要があります。インストレーション・ガイドの完全なリストは、Oracle Fusion Middlewareドキュメント・ライブラリを参照してください。このドキュメントの、コンポーネント固有の章を確認して、追加のインストールに対する追加のアップグレード前の手順があるかどうかを判断してください。

インストール・プロセス中に、新しくインストールしたドメインを構成するように指示されます。ただし、アップグレードの際、SOA 12.1.3ドメインの構成に構成ウィザードは使用しないでください。構成ウィザードは新しいドメインのインストールを構成するために使用します。既存のドメインは、アップグレード中にこのガイドで後述する再構成ウィザードを使用してアップグレードします。


3.2 Oracle SOA SuiteおよびBPMに必要な12c (12.1.3)スキーマの作成

第2.5.2項「アップグレード前の必要なスキーマの作成」で説明しているように、SOA 11gからアップグレードする場合は、必要な12cスキーマを作成してからアップグレードを開始する必要があります。

具体的には、12c (12.1.3)リポジトリ作成ユーティリティ(RCU)を実行して、次のスキーマを作成します。

  • Audit Servicesの_IAU (IAU_APPENDおよびIAU_VIEWER)

  • Service Tableの_STB (12cで新規)

  • Webの_WLF (Business Activity Monitoring (BAM) 11.1.1.6および11.1.1.7のアップグレードに必要)


    注意:

    Oracle Fusion Middlewareでは、バイトモードのデータベースのスキーマのみをサポートしています。スキーマがあるデータベース上のnls_length_semantics初期化パラメータのCHARへの設定はサポートされていないため、BYTEに設定する必要があります。

    SQL*Plusを使用してこのパラメータの値を確認するには、次のようにshow parametersコマンドを使用します。

    prompt> sqlplus "sys/<password> as sysdba"SQL> show parameters nls_length_semantics
    

    <password>の部分は、実際のSYSユーザーのパスワードに置き換えてください。

    別の方法として、次のようにV$PARAMETERビューを問い合せて値を確認することもできます。

    prompt> sqlplus "sys/password as sysdba"SQL> select name,value from v$parameter;
    

    詳細は、使用するデータベースの管理ドキュメントを参照してください。


3.3 スキーマのアップグレード中のログ・ファイルの生成(推奨)

アップグレードのトラブルシューティングを容易にするために、_SOAINFRAスキーマのアップグレード時にログ・ファイルを生成することをお薦めします。デフォルトでは、ロギングは無効になっています。

ロギングを有効化するには:

  1. soainfraユーザー・ディレクトリをUPGRADE_DIRという名前で作成します。

  2. set_LogLevel(1)またはALTER PROCEDURE log_debug COMPILE PLSQL_CCFLAGS = 'debug_on:TRUE';関数を呼び出して、デバッグ・ログを有効化します。

次のUNIXの例に示すように、ロギング・パラメータを使用してアップグレード・アシスタントを起動することもできます。

./ua [-logLevel <log_level>] [-logDir <log_directory>]

ログ・ファイルの生成および使用の詳細は、『Upgrade Assistantによるアップグレード』のオプションの引数を使用したアップグレード・アシスタントの起動に関する項を参照してください。

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

アップグレード・アシスタントを使用してSOAおよびBPMのスキーマとインスタンスをアップグレードするには、この項の手順に従います。


注意:

パージ・スクリプトまたはスケジュールされたデータベース・ジョブの実行中は、アップグレード・アシスタントを起動しないでください。

パージまたはアップグレードが完了するまで待ってから、アップグレード・プロセスを開始してください。アップグレード・アシスタントを使用してスキーマをアップグレードするときに、パージ・スクリプトまたはインスタンスのアップグレード・ジョブを実行していると、アップグレードは失敗します。

アップグレード・アシスタントを起動する必要がある場合は、「バックグラウンド制御ジョブの有効化と無効化(オプション6)」で説明しているように、パージを停止してスケジュールされたジョブを無効にしてください。


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

次の手順を実行して、アップグレード・アシスタントを起動します。

  1. ディレクトリをORACLE_HOME/oracle_common/upgrade/bin (UNIXオペレーティング・システムの場合)またはORACLE_HOME\oracle_common\upgrade\bin (Windowsオペレーティング・システムの場合)に変更します。

  2. 次のコマンドを入力してアップグレード・アシスタントを起動します。

    (UNIX) ./ua

    (Windows) ua.bat

アップグレード・アシスタントは、次の例に示すようにロギングを有効にして実行することをお薦めします。

./ua [-logLevel <log_level>] [-logDir <log_directory>]
タスク2 スキーマのアップグレード

スキーマのアップグレード時、アップグレード・アシスタントでは表3-1に示す一連の画面が表示されます。各画面でそれぞれの操作を実行します。「Oracle SOA」を選択すると、アップグレードには_IAU_MDS_OPSS_SOAINFRAおよび_UMSスキーマが含まれます。

表3-1 Upgrade Assistant画面: スキーマのアップグレード

画面 説明および必要なアクション

ようこそ

この画面では、アップグレード・アシスタントの概要と、アップグレード前の重要なタスクについての情報が示されます。

スキーマ

「スキーマ」を選択します。

使用可能なコンポーネント

この画面では、アップグレード可能なスキーマがあるインストール済のOracle Fusion Middlewareコンポーネントのリストが提供されます。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。たとえば、「Oracle SOA」を選択すると、アップグレードには_IAU_MDS_OPSS_SOAINFRAおよび_UMSスキーマが含まれます。

注意: デフォルトでは、Oracle Platform Security Services (OPSS)とAudit Servicesのスキーマが選択されています。ほとんどのコンポーネントのアップグレードでは、これらのスキーマが必要です。これらのスキーマがアップグレードに一切不要な場合以外は、これらのオプションを選択解除しないでください。

AIAFPをアップグレードする場合は、第7章「SOAコア拡張機能12c (12.1.3)へのアップグレード」を参照してください。

1213_ua_avail_comp_soa_crop.pngの説明が続きます
図1213_ua_avail_comp_soa_crop.pngの説明

ドメイン・ディレクトリ

この画面では、「使用可能なコンポーネント」画面でOracle Platform Security ServicesまたはOracle監査サービスのどちらを選択したかが表示されます。

既存のWebLogicドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックしてアップグレードする11gドメイン・ディレクトリに移動して選択します。

前提条件

スキーマ・アップグレードの前提条件が満たされていることを確認します。「次」をクリックする前に、それぞれの前提条件を選択する必要があります。

注意: アップグレード・アシスタントは、これらの前提条件が満たされていることを確認しません。

スキーマ資格証明

この画面を使用して、アップグレードする各スキーマのデータベース接続の詳細を入力します。

  1. 「データベース・タイプ」ドロップダウン・メニューからデータベース・タイプを選択します。

  2. データベース接続の詳細を入力して、「接続」をクリックします。

  3. 「スキーマ・ユーザー名」ドロップダウン・メニューからアップグレードするスキーマを選択し、スキーマのパスワードを入力します。

    場合によっては(_ORASDPMなど)、スキーマ・ユーザー名とパスワードを手動で入力する必要があります。

    注意: UCSUMSスキーマは自動的には移入されません。ユーザーとして、接頭辞_ORASDPMを入力します。アップグレード環境ではスキーマ名に_ORASDPMが使用されますが、12c環境ではこれは_UMSスキーマと見なされます。

  4. 「次へ」をクリックします。

注意:

  • _OPSS_IAU_MDSおよび_ODIのスキーマには、昇格したログイン資格証明(AS SYSDBA)が必要です。

  • スキーマ資格証明画面のタイトルは、アップグレードするスキーマに応じて変化します。たとえば、_SOAINFRAスキーマをアップグレードする場合、画面のタイトルはSOAINFRAスキーマと表示されます。

  • データベースへの接続に必要なフィールドの詳細は、「ヘルプ」をクリックするか、『Upgrade Assistantによるアップグレード』のスキーマ資格証明に関する項を参照してください。

調査

各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するアップグレード・アシスタントのステータスを確認します。

スキーマごとに表示される「ソース・バージョン」に、アップグレード対象のスキーマの正しいバージョン番号が示されていることを確認します。

アップグレード・サマリー

スキーマ・アップグレードのために選択したオプションのサマリーを確認します。正しいソース・バージョンとターゲット・バージョンが、アップグレード対象の各スキーマにリストされていることを確認します。

「アップグレード」をクリックしてスキーマをアップグレードするか、構成を変更する場合は「戻る」をクリックします。

アップグレードの進行状況

現在のアップグレード・プロセスのステータスを確認します。

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

アップグレードが完了したら「次へ」をクリックします。

アップグレード成功

アップグレードが成功していれば「閉じる」をクリックします。

アップグレードが失敗した場合または正常に完了する前にアップグレードを取り消した場合は、ログ・ファイルを確認してバックアップ環境をリストアし、アップグレード・アシスタントを再起動する必要があります。


タスク3 スキーマのアップグレードの検証

次のSQLコマンドを使用して、schema_version_registryのスキーマ・バージョンが正しく更新されていることを検証します。

SET LINE 120
COLUMN MRC_NAME FORMAT A14
COLUMN COMP_ID FORMAT A20
COLUMN VERSION FORMAT A12
COLUMN STATUS FORMAT A9
COLUMN UPGRADED FORMAT A8
SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;

VERSION列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。『Upgrade Assistantによるアップグレード』の表1-1「アップグレードが必要なスキーマ」を参照して、スキーマの更新されたバージョン番号が正しいことを確認します。

問合せ結果のSTATUSフィールドは、スキーマへのパッチ適用処理中は「UPGRADING」または「UPGRADED」に、処理が終了すると「VALID」になります。

ステータスが「INVALID」と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。

タスク4   インスタンスのアップグレードの確認(該当する場合)

スキーマのアップグレードの一部としてインスタンスをアップグレードした場合は、インスタンスにエラーがないことを確認します。

  • アップグレード・アシスタントのレポートに、アップグレード対象のインスタンスが存在しなくなったと示された場合は、アップグレード・アシスタントのUIを閉じて、残りのアップグレード手順(再構成ウィザードを起動するなど)を続行します。

  • アップグレード・アシスタントのレポートに、インスタンスのアップグレード中にエラーが発生したと示されている場合は、エラーを修正してからデータベース・ジョブを再発行して、アップグレードを完了します。Report Upgrade Summary管理スクリプト(オプション1)を使用して、レポートのUPGRADE ERROR COUNTセクションを確認することもできます。詳細は、第9.10項「インスタンス・アップグレードのエラーの解決」を参照してください。

  • アップグレード対象のクローズされたインスタンスが残っている場合は、アップグレード・アシスタントの終了後に、クローズされたインスタンスのアップグレードがバックグラウンドで続行されることが通知されます。アップグレード・アシスタントが完了を報告し、次のメッセージが表示されるまでは、アップグレード・アシスタントを閉じないでください。

    Oracle SOA
    1. The Upgrade Assistant has successfully upgraded all active instances. You can now close the Upgrade Assistant.
    2. The automated upgrade of closed instances will continue in the background after the Upgrade Assistant is exited and until the SOA server is started,at which point the upgrade will stop. You can schedule the upgrade of any remaining closed instances for a time when the SOA server is less busy.
    Close the Upgrade Assistant and use the instance data administration scripts to administer and monitor the overall progress of this automated upgrade. For more information see "Administering and Monitoring the Upgrade of SOA Instance Data" in Upgrading SOA Suite and Business Process Management. 
    
タスク5   無効なデータベース・オブジェクトの確認

Oracle Databaseを使用している場合は、アップグレード・アシスタントを実行した後、SYSとしてデータベースに接続し、SQL*Plusから次の方法を実行することで、データベース・オブジェクトを再コンパイルしてください。

SQL>@?/rdbms/admin/utlrp.sql

これによって、アップグレード・アシスタントによってアップグレードされたデータベース・オブジェクトがコンパイルされます。

その後、次の問合せを発行して、無効なデータベース・オブジェクトがなくなったことを確認します。

SELECT owner, object_name FROM all_objects WHERE status='INVALID';

この時点で、アップグレードしたスキーマに無効なデータベース・オブジェクトがあってはなりません。もしあった場合は、utlrp.sqlコマンドをもう一度実行して再確認します。問題が続く場合は、サービス・リクエストを提出します。

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

再構成ウィザードを使用して既存の11gドメインを再構成するには、この項の手順に従います。ドメインの再構成についての一般情報は、『Oracle WebLogic Serverのアップグレード』のWebLogicドメインの再構成に関する項を参照してください。

タスク1   再構成ウィザードの起動

次の手順を実行して、再構成ウィザードをグラフィカル・モードで起動します。

  1. ドメインが存在するシステムにログインします。

  2. コマンド・シェル(UNIXオペレーティング・システムの場合)またはコマンド・プロンプト・ウィンドウ(Windowsオペレーティング・システムの場合)を開きます。

  3. エディション・ベースのデータベース・ユーザーのみ: スキーマがEBRデータベースを使用して構成されている場合、再構成ウィザードを実行する前に、手動でデフォルトのエディション名を設定する必要があります。

    次のSQLコマンドを実行して、デフォルト・エディションを設定します。

    ALTER DATABASE DEFAULT EDITION = edition_name;
    

    ここで、edition_nameは、子エディションの名前です。

  4. 次のディレクトリに移動します。

    (UNIX) ORACLE_HOME/oracle_common/common/bin

    (Windows) ORACLE_HOME\oracle_common\common\bin

    ORACLE_HOMEはOracleホーム・ディレクトリです。

  5. 次のコマンドを実行します。

    (UNIX) ./reconfig.sh -log=<log_file> -log_priority=ALL
    (Windows) reconfig.cmd -log=<log_file> -log_priority=ALL
     
    

    log_fileは、ドメイン再構成セッション用に作成するログ・ファイルの絶対パスに置き換えます。これは、再構成処理をトラブルシューティングする必要がある場合に役立つことがあります。

    パラメータ-log_priority=ALLは、ログを詳細モードで出力します。


    注意:

    reconfig.cmdまたはreconfig.shコマンドを実行すると、デフォルト・キャッシュ・ディレクトリが無効であることを示す次のようなエラー・メッセージが表示される場合があります。
    *sys-package-mgr*: can't create package cache dir
    

    環境変数CONFIG_JVM_ARGSを設定することでキャッシュ・ディレクトリを変更できます。次に例を示します。

    CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory


タスク2   ドメインの再構成

再構成ウィザードでは表3-2に示す一連の画面が表示されます。各画面でそれぞれの操作を実行します。次に示す画面は、いくつかが表示されないこともあります。また、使用する環境の設定に基づいた追加の画面を完了する必要がある場合もあります。詳細は、『Oracle WebLogic Serverのアップグレード』のWebLogicドメインの再構成に関する項を参照してください。

表3-2 再構成ウィザードの画面

再構成ウィザードの画面 説明および必要なアクション

ドメインの選択

既存のドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックしてドメイン・ディレクトリを選択します。

再構成セットアップの進行状況

再構成テンプレートの適用の進行状況が表示されます。

ドメイン・モードとJDK

ドメイン・モードは変更できません。

ドメイン内の使用するJDKを選択するか、「参照」をクリックして、使用するJDKに移動します。

Oracle Fusion Middleware 12cにはJava SE 7が必要であることに注意してください。詳細は、『Oracle Fusion Middlewareのインストールのプランニング』の動作保証とシステム要件の検証に関する項を参照してください。

データベース構成タイプ

「RCUデータ」オプションを使用して、Server Table (_STB)スキーマを収集します。Repository Creation Utilityはサービス表を自動的に使用して、他の12cスキーマ資格証明を自動的にロードします。後続JDBC画面のデータを常に確認してください。

注意: 既存の11gデータ・ソースの場合、再構成では既存の値が保存されます。スキーマが12c RCUで作成された新しいデータ・ソースの場合、デフォルトの接続データは_STBスキーマから取得されます。特定のスキーマの接続データが_STBスキーマにない場合は、デフォルトの接続データが使用されます。

詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のデータベース構成タイプに関する項を参照してください。

JDBCデータ・ソース

この画面は、11gでデータベースベースのOPSSセキュリティ・ストアまたは監査データ・ストア用にカスタム・データ・ソースを作成していた場合に表示されます。

この画面では、ドメイン・ソースに定義されているJDBCデータ・ソースを構成します。

このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCデータ・ソースに関する項を参照してください。

JDBCデータ・ソース・テスト

「JDBCデータ・ソース」画面で構成したデータ・ソース接続をテストします。

警告: データ・ソースのテストに失敗した場合、その問題を修正してから次の手順に進んでください。すべてのデータ・ソースのテストがPASSのステータスを示す必要があります。

このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCデータ・ソースのテストに関する項を参照してください。

JDBCコンポーネント・スキーマ

各スキーマ名の横のチェック・ボックスを選択して、画面に表示された各スキーマのデータソース設定を指定します。

注意:

  • 第3.4項でアップグレードしたスキーマについて、11gスキーマの詳細を指定する必要があります。それ以外については、12.1.3スキーマの詳細を指定します。

  • このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCコンポーネント・スキーマに関する項を参照してください。

JDBCコンポーネント・スキーマ・テスト

前の画面でデータ・ソースに指定した構成をテストします。テストするスキーマ名の横のチェック・ボックスを選択し、「選択された接続のテスト(T)」をクリックします。

テストの結果は「ステータス」列に表示されます。すべてのスキーマでテストに成功した場合、「次へ」をクリックします。

ノード・マネージャ

この画面は、再構成するドメインで、ホストごとのノード・マネージャが使用されている場合にのみ表示されます。この画面を使用して、再構成するドメインに使用するノード・マネージャ構成を選択します。結果として得られる構成は、「ノード・マネージャ・タイプ」と「ノード・マネージャ構成」に選択したオプションの組合せによって異なります。

ドメインごとおよびホストごとのノード・マネージャの構成の詳細は、Oracle WebLogic Serverのノード・マネージャの管理のノード・マネージャのデフォルトの構成に関する項を参照してください。

拡張構成

この画面に表示されるカテゴリは、ドメインの構成中にドメインに選択したテンプレートで定義されているリソースによって異なります。

たとえば、SOA SuiteおよびBPMテンプレートをドメインに適用するときに、次の事項が1つ以上当てはまる場合は、「管理対象サーバー、クラスタおよびCoherence」を選択します。

  • 単一のドメイン(たとえば、soa_server1やbam_server1)に複数の管理対象サーバーがある

  • クラスタまたはCoherenceのデータを変更する必要がある

「ノード・マネージャ」、「デプロイメントとサービス」、「ドメイン・フロントエンド・ホストのキャプチャ」、「JMSファイル・ストア」など、その他の拡張構成オプションの使用の詳細は、『Oracle WebLogic Serverのアップグレード』の拡張構成に関する項を参照してください。

管理対象サーバー

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

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

実際のホスト名をhost name.company.comとして指定する必要があります

reconfig_soa11g_crop_managed_servers.pngの説明が続きます
図reconfig_soa11g_crop_managed_servers.pngの説明

サーバーのマシンへの割当

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

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

サーバーのクラスタへの割当

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

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

構成のサマリー

構成のサマリーを確認します。

「再構成」をクリックしてドメインを再構成するか、「戻る」をクリックして構成を変更します。

再構成の進行状況

再構成の進行状況を確認します。処理が完了したら「次へ」をクリックします。

再構成に成功しました

再構成処理の最終的なステータスを確認します。「終了(F)」をクリックして再構成ウィザードを終了します。


3.6 アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード

アップグレード・アシスタントを使用して追加ドメイン・コンポーネント構成をアップグレードするには、この項の手順に従います。


注意:

アップグレード・アシスタントを起動する前に、管理サーバーを起動しないでください。

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

次の手順を実行して、管理サーバーが実行されているホストでアップグレード・アシスタントを起動します。

  1. ディレクトリをORACLE_HOME/oracle_common/upgrade/bin (UNIXオペレーティング・システムの場合)またはORACLE_HOME\oracle_common\upgrade\bin (Windowsオペレーティング・システムの場合)に変更します。

  2. 次のコマンドを入力してアップグレード・アシスタントを起動します。

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

    ./ua

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

    ua.bat

タスク2   コンポーネント構成のアップグレード

WebLogicコンポーネント構成のアップグレード時には、アップグレード・アシスタントでは表3-3に示す一連の画面が表示されます。各画面でそれぞれの操作を実行します。

注意: 表示される再構成ウィザードの画面は、使用している環境に基づいています。次に示す画面は、すべてが表示されない場合もあります。

表3-3 アップグレード・アシスタント画面: WebLogicコンポーネント構成のアップグレード

画面 説明および必要なアクション

ようこそ

この画面では、アップグレード・アシスタントの概要と、アップグレード前の重要なタスクについての情報が示されます。

「次へ」をクリックして続行します。

WebLogicコンポーネント

「WebLogicコンポーネント構成」を選択します。

管理対象WebLogic Serverドメインのコンポーネント構成をアップグレードするには、「WebLogicコンポーネント構成」オプションを選択します。アップグレードするドメインのドメイン・ディレクトリを入力してください。

「次へ」をクリックします。

OWSMポリシー・マネージャ

この画面は、11g環境に複数のWebLogic Serverドメインがある場合に、OWSMポリシー・マネージャが1つのWLSドメインのみにあり、他のドメインにはOWSMエージェントがあるときに表示されます。

Oracle Web Services Manager (OWSM)ポリシー・マネージャがデプロイされているWebLogic管理サーバー・ドメインの資格証明を指定します。

このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Upgrade Assistantによるアップグレード』のOWSMポリシー・マネージャに関する項を参照してください。

コンポーネント・リスト

この画面では、ドメインのコンポーネント構成アップグレードに含められるコンポーネントのリストが提供されます。

前提条件

コンポーネント構成アップグレードの前提条件が満たされているかどうかを確認します。

UMS構成

この画面は、UMS 11g構成ファイルをホストする、リモートの管理対象サーバーがある場合に表示されます。アップグレード・アシスタントで構成ファイルにアクセスするには、これらのサーバーに資格証明を指定する必要があります。

注意: アップグレード・アシスタントでUMS構成ファイルを見つけられない場合は、それらのファイルを手動でコピーする必要があります。『Oracle Fusion Middleware Infrastructureへのアップグレード』のアップグレード・アシスタント: UMS構成ファイルのコピーに関する項を参照してください。

調査

各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するアップグレード・アシスタントのステータスを確認します。

アップグレード・サマリー

スキーマ・アップグレードのために選択したオプションのサマリーを確認します。

「アップグレード」をクリックしてスキーマをアップグレードするか、構成を変更する場合は「戻る」をクリックします。

アップグレードの進行状況

アップグレード処理のステータスを確認します。

アップグレードが完了したら「次へ」をクリックします。

アップグレード成功

アップグレードが成功していれば「閉じる」をクリックします。

アップグレードが失敗した場合または正常に完了する前にアップグレードを取り消した場合は、ログ・ファイルを確認してバックアップ環境をリストアし、アップグレード・アシスタントを再起動する必要があります。



注意:

追加の構成タスクが必要になる場合があります。

アップグレード・アシスタントによるスキーマとコンポーネント構成のアップグレードが正常に完了したら、第8章「アップグレード後のタスクの実行」のアップグレード後のタスクを実行して、コンポーネントが引き続き期待通りに機能していることを確認する必要がある場合があります。


3.7 JDeveloperプロジェクトの一括アップグレード

多数のJDeveloperプロジェクトを、JDeveloperで1つずつ開くことなく一括でアップグレードする場合は、12c OracleホームにインストールされたJDeveloper移行ツールojmigrateを使用できます。ワークスペース・ファイル名とアップグレードするワークスペースを持つファイルを指定する必要があります。

次に例を示します。

ojmigrate [option]... file...|@file

Where: file is the name of the Workspace to upgrade and @file is the file with workspaces to upgrade (one filename per line) 

また、次のオプションを指定できます。

  • -ade

    現在のADEビューへの接続

  • -dry

    マイグレータの呼出しをスキップ

  • -failFast

    最初の失敗後に移行を停止

  • -generateDefaults

    アップグレード・オプションのデフォルト値を含むファイルをアップグレード・ツールに生成させる。通常、これらの生成ファイルは、migration.propertiesファイルと.jws fileです。

3.8 BPM Webフォームのアップグレード

BPM 11g (11.1.1.7.0)で開発されたほとんどのBPM Webフォームは、12cと互換性があります。少数ですが要素間に手動で空白を指定している場合があり、そのようなフォームは、12cで正しく動作しない可能性があります。これらのフォームは手動でアップグレードする必要があります。手動の操作がない場合、これらのフォームは一時停止モードになります。これらの手動によるレイアウトを使用しないフォームは、移行なしで正しく動作します。

BPM Webフォームをアップグレードするには、管理権限のあるユーザーが次のURLに移動し、プロンプトが表示されたら管理者資格証明を入力します。

http://host name:port/workflow/DefaultToDoTaskFlow/migratewebforms

このページをロードすることでアップグレードが開始され、アップグレードされたフォームが表示されます。エラーが発生した場合は、ログ・ファイルを確認し、エラーがリカバリできる場合はページのロードを再試行します。エラーがリカバリできない場合は、エラーが発生したフォームが含まれるBPMコンポジットのデプロイを試行します。


注意:

このURLは何度でも起動できますが、Webフォームを使用しているアクティブ・ユーザーがいるときにはアップグレードは実行できません。

3.9 アップグレードしたOracle Fusion Middleware 12cソフトウェアの管理

表3-4に、SOA 12.1.3へのアップグレード後に実行することが多い一般的な管理タスクを示します。また、コンポーネント固有の管理ガイドでは、アップグレード後に実行する追加の構成タスクについても説明している場合があります。

表3-4 基本的な管理タスク

タスク 説明 詳細

コンポーネントの追加のアップグレード後構成手順の実行

第8章「アップグレード後のタスクの実行」で説明しているアップグレード後のタスクに加えて、追加の構成タスクを実行して、新しくアップグレードしたコンポーネントが期待通りに機能するかどうかを確認する必要もあります。

  • Oracle Fusion Middlewareの管理

  • Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理

  • Oracle Service Busの管理

  • Oracle User Messaging Serviceの管理


Fusion Middleware管理ツールについての学習

環境の管理に使用できる様々なツールについて学習します。

『Oracle Fusion Middlewareの管理』のOracle Fusion Middleware管理ツールの概要に関する項を参照してください。

Secure Sockets Layer (SSL)の構成

SSLを使用してOracle Fusion Middlewareコンポーネント間にセキュアな通信を設定する方法を説明します。

『Oracle Fusion Middlewareの管理』のOracle Fusion MiddlewareにおけるSSLの構成に関する項

Oracle Fusion Middlewareの監視

Oracle Fusion Middlewareコンポーネントのステータスを追跡する方法を学習します。

『Oracle Fusion Middlewareの管理』のOracle Fusion Middlewareのモニタリングに関する項