6 アップグレード後タスクの実行

Oracle SOA Suite 14c (14.1.2.0.0)へのアップグレード後に実行する必要のある可能性があるタスクについて概要を説明します。

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

次の各タスクは、アップグレード後に実行する必要があります。

アップグレード後のドメイン・モードの変更

アップグレード後、ドメインは元のアップグレード前のドメイン・セキュリティ・モード設定を保持します。たとえばセキュリティを強化する目的で、ドメイン・モードを変更する場合は、WebLogicリモート・コンソールを使用するか、DomainMBeanを変更して、明示的に設定を変更する必要があります。

現在ドメインが本番モードに設定されていて、追加のセキュリティを有効にする場合は、アップグレード後にWebLogicリモート・コンソールを使用してドメイン・モードを変更し、保護された本番モードを有効にします。Oracle WebLogicリモート・コンソール・オンライン・ヘルプドメイン・モードの変更

注意:

ドメイン・モードの変更には、ドメイン全体の再起動が必要です。ローリング再起動では足りません。ドメイン・モードを変更する前に、すべての管理対象サーバーを停止する必要があります。

ドメインを14c (14.1.2.0.0)にアップグレードするときに、明示的なセキュア・モード設定がない場合、再構成ウィザードによって、アップグレード後のドメインではセキュア・モードが明示的に「無効」に設定されます。これは、元のドメインに存在していた動作を保持するためです。明示的な保護モード設定がある場合は、アップグレード後のドメインでもそれが保持されます。詳細は、『Oracle WebLogic Server本番環境の保護』ドメイン・モードがデフォルトのセキュリティ構成に与える影響の理解に関する項を参照してください。

ノート:

保護された本番モードでは、より制限的で厳しいセキュリティ設定が強制され、脅威に対する脆弱性が軽減されます。ドメインがセキュアであることを確認するには、保護された本番モードを有効にしてから、証明書の取得および格納、ユーザー・アカウントの保護、ドメインが実行されるネットワークの保護など、ドメインが実行される環境に適したセキュリティ構成オプションを選択する必要があります。これらのオプションが適切に構成されていない場合、WebLogic Serverの使用はブロックされます。

WebLogicドメインの作成後には、適切なセキュリティ構成の選択など、整合性を確保するための主要なステップがいくつか残っています。詳細は、『Oracle WebLogic Serverセキュリティの管理』作成後のドメインの保護に関する項を参照してください。

JVMの開始スクリプトのプロパティの再適用

開始スクリプトを使用して、必要な起動プロパティを指定したり、既存の環境で起動時に必要になるその他の操作を実行した場合は、アップグレード後にそれらのプロパティを再適用する必要があります。

具体的には、JRockit JVMの引数を構成した場合は、アップグレード後にこれらの構成を再適用する必要があります。JVMの起動パラメータを構成する場合は、startup-plan.xmlまたはstartscript.xmlを使用することをお薦めします。

注意:

開始スクリプトの引数を更新していないと、アップグレード後にSOAサーバーとOSBサーバーが起動できなくなることがあります。

スクリプトを有効にするには:

  1. nodemanager.propertiesファイルで、StartScriptEnabledプロパティをtrueに設定します。(デフォルトはfalseです。)起動スクリプトの名前がstartWebLogic.shまたはstartWebLogic.cmdの場合は、ノード・マネージャはそれらのスクリプトのいずれかをデフォルトとして使用します。

  2. カスタム起動スクリプトを指定する場合は、nodemanager.propertiesファイルで、StartScriptNameプロパティを、使用するスクリプトの名前に設定します。

ノード・マネージャは、JAVA_VENDORJAVA_HOMEJAVA_OPTIONSSECURITY_POLICYCLASSPATH、およびADMIN_URLを設定します。管理コンソールを使用してサーバーを起動するか、または管理サーバーに接続されたWLSTを使用するとき、ノード・マネージャはこれらの値をServerMBeanServerStartMBean、およびSSLMBeanから取得します。ノード・マネージャに直接接続されたWLSTを使用する場合は、値を指定できますが、使用しない場合は空白にします。

ノード・マネージャは、ServerStartMBean Arguments属性で指定されるすべてのコマンド行起動オプション(-Dフラグ)とSSLArgumentsを組み合わせ、JAVA_OPTIONSという1つの環境変数にします。SSLArgumentsは、SSLMBeanの値から取得されます。SSLMBeanは、ignoreHostnameVerificationHostnameVerifier、およびReverseDNSAllowedの各値があるか検査し、それらの値は-Dフラグに付加されます。すべてのフラグは、SSLArgumentsパラメータから構成されます。ServerStartMBean内のSSLArgumentsおよびArgumentsのすべての値は、起動スクリプトに定義されるJAVA_OPTIONS環境変数から構成されます。さらに、このスクリプトは、独自定義された値をこの環境変数に追加します。

setDomainEnv.shへのカスタマイズの再適用

サーバーが起動しない場合やAdminModeで起動される場合、その最も可能性の高い原因は、以前の環境からのsetDomainEnv.shの変更内容が、新しく構成したドメインに再適用されていないことです。アップグレード・プロセスの間に、起動スクリプトは、最新バージョンに置き換えられます。これらのファイルに変更を加えた場合、新しい起動スクリプトを同じ情報で編集する必要があります。

これが原因かどうかを判断するには、アップグレード前のsetDomainEnvファイルのバックアップを新しいsetDomainEnvファイルと比較します。相違点がある場合は、新しいsetDomainEnvファイルに同様の変更を加えます。

XEngine構成ファイルへのカスタマイズの再適用

アップグレード前に、XEngineの構成ファイル(SeverityConfig.xmlなど)に加えた変更は、ドメインの再構成プロセスで再生成される新しい構成ファイルにより上書きされます。そのため、アップグレード前の構成ファイルで使用していたカスタマイズしたすべての設定を、アップグレード後に再適用する必要があります。

たとえば、アップグレード前のXEngine構成ファイルSeverityConfig.xmlに、SNIPについてのセクションを追加している場合は、それと同じセクションをアップグレード後の新しいSeverityConfig.xmlファイルに追加する必要があります。

カスタムのXPathクラスのコピー

アップグレード前の環境でデフォルトのXPathクラスを変更した場合は、アップグレード後に、次の例で示すように、カスタマイズしたXPathクラスを新しいOracleホームにコピーする必要があります:

アップグレード前のバックアップからカスタムXPathクラスをコピーします。クラスは、次のディレクトリにあります。

/12c_ORACLE_HOME/soa/modules/oracle.soa.ext_xxx/classes

コピー先は次の14cディレクトリです:

/14c_ORACLE_HOME/soa/modules/oracle.soa.ext_xxx/classes

アプリケーションのロールとポリシーに対するパーティション固有のロールの再作成

アップグレード後には、既存の環境で使用していたパーティション固有のロールを再作成する必要があります。

既存のアプリケーションに対するパーティションのアプリケーション・ロールは、14cのアップグレード・プロセスでは再作成されません。そのかわりに、次のWLSTスクリプトを使用して、これらのロールを手動で作成する必要があります。

sca_createDefaultPartitionAppRoles partition

Business Process Management (BPM)メタデータのアップグレード

Business Process Managementメタデータのアップグレードは、Business Process Composer 14c (14.1.2.0.0)に初めて(アップグレード成功後)ログインすると開始されます。

Business Process Composerの使用の詳細は、Oracle Business Process Composerを使用したビジネス・プロセスの開発を参照してください。

Oracle Fusion Middleware監査データ・ストアの構成

包括的なアップグレード処理の一環として、他のOracle Fusion Middlewareスキーマが存在するデータベースにIAUスキーマを作成しておく必要があります。

監査ストア、監査ポリシーおよびバスストップ・ファイルの管理に使用する主な管理タスクおよびツールの詳細は、Oracle Platform Security Servicesによるアプリケーションの保護監査データ・ストアの管理を参照してください。

アップグレードしたコンポーネントが予想どおりに動作していることの確認

アップグレードが正常に終了したら、次のタスクを実行して、コンポーネントが引き続き期待どおりに機能していることと、新しいデプロイメントに問題がないことを確認する必要があります。

サーバーおよびプロセスの起動

アップグレードが正常に終了したら、管理サーバーおよび管理対象サーバーを含め、すべてのプロセスおよびサーバーを再起動します。

それらのコンポーネントは相互に依存する場合があるため、正しい順序で起動する必要があります。

ノート:

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

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

Fusion Middleware環境を起動するには、次のステップに従います。

ノート:

既存のセキュリティ設定によっては、保護された本番モードが有効になっているドメインを管理する前に、追加の構成を実行しなければならない場合があります。詳細は、「WebLogicリモート・コンソールを使用した管理サーバーへの接続」を参照してください

.

ステップ1: 管理サーバーの起動

管理サーバーを起動するには、startWebLogicスクリプトを使用します。

  • (UNIX) NEW_DOMAIN_HOME/bin/startWebLogic.sh

  • (Windows) NEW_DOMAIN_HOME\bin\startWebLogic.cmd

    ノート:

    保護された本番モードを使用する場合は、管理サーバーを起動するための追加パラメータを指定する必要があります。『Oracle WebLogic Serverのセキュリティの管理』WLSTを使用した管理サーバーへの接続に関する項を参照してください。

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

ステップ2: ノード・マネージャの起動

ノード・マネージャを起動するには、startNodeManagerスクリプトを使用します。

  • (UNIX) NEW_DOMAIN_HOME/bin/startNodeManager.sh

  • (Windows) NEW_DOMAIN_HOME\bin\startNodeManager.cmd

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

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

  • (UNIX) NEW_DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

  • (Windows) NEW_DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

    ノート:

    保護された本番モードを使用する場合は、管理対象サーバーを起動するための追加パラメータを指定する必要があります。『Oracle WebLogic Serverセキュリティの管理』起動スクリプトを使用した管理対象サーバーの起動に関する項を参照してください。

SOAサーバーおよびプロセスを次の順番で起動します。

  1. Oracle Web Services Manager (OWSM)管理対象サーバー
  2. サービス指向アーキテクチャ(SOA)管理対象サーバー

  3. Managed File Trasfer (MFT)

  4. Oracle Service Bus (OSB)管理対象サーバー

  5. Business Activity Monitoring (BAM)管理対象サーバー

ノート:

通常は、管理対象サーバーの起動により、それにデプロイされているアプリケーションが起動します。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。

ステップ4: システム・コンポーネントを起動する

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

  • (UNIX) NEW_DOMAIN_HOME/bin/startComponent.sh component_name

  • (Windows) NEW_DOMAIN_HOME\bin\startComponent.cmd component_name

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

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

ドメイン・コンポーネント構成のアップグレードが成功したことを確認するには、次のURLを使用してリモート・コンソールおよびFusion Middleware Controlにログインし、各コンポーネントでアップグレードされたバージョン番号を確認します:

リモート・コンソールのURL: http://administration_server_host:administration_server_port/console

Fusion Middleware ControlのURL: http://administration_server_host:administration_server_port/em

ノート:

アップグレード後には、既存の12c (12.2.1.4) Oracleホームではなく、新しい14c (14.1.2.0.0) Oracleホームからすべての管理ツールを実行する必要があります。

アップグレード後のコンポーザの起動

ユーザーweblogicがログインするまで、コンポーザはアップグレード後に操作できません。weblogicユーザーがコンポーザを起動するまで、デモ・ユーザーとしてログインできません。demoユーザーとしてログインすると、次のメッセージが表示されます。

移行はバックグラウンドで実行されています。

このエラーを取得する場合、weblogicユーザーとしてログアウトして再ログインし、移行の完了まで待機します。