ヘッダーをスキップ

Oracle E-Business Suiteセットアップ・ガイド
リリース12.2
E51769-01
目次へ
目次
前のページへ
前へ
次のページへ
次へ

技術的構成

概要

AutoConfigは、これまでも、Oracle E-Business Suiteインスタンスの自動構成をサポートするためのツールでした。アプリケーション・インスタンスの構成に必要な情報は、アプリケーション・コンテキスト・ファイルおよびデータベース・コンテキスト・ファイルという2つのローカル・リポジトリに収集されます。AutoConfigをアプリケーション層で実行すると、アプリケーション・コンテキスト・ファイルの情報が使用され、構成ファイルが生成されてデータベース・プロファイルが更新されます。AutoConfigをデータベース層で実行すると、データベース・コンテキスト・ファイルの情報が使用され、データベース層で使用されるすべての構成ファイルが生成されてデータベース・プロファイルが更新されます。

構成管理ツール

Fusion Middleware Control: このツールによって、Oracle WebLogic Server (WLS)の高度なビューが提供されます。Oracle E-Business Suite DBAの場合にさらに重要なのは、Oracle HTTP Serverの構成に使用されることです。HTTP設定には、仮想ホスト、パフォーマンス・ディレクティブ、ログ構成、ポート、mod_perlおよびmod_wl_ohsが含まれます。Fusion Middleware Controlには、Oracle Application ManagerおよびOracle WebLogic Server管理コンソールへのリンクも含まれます。

WebLogic Server管理コンソール: Oracle WebLogic Serverの設定および管理対象サーバーを処理します。例: oacore、oafm、formsおよびforms-c4wsサービス。

Oracle Application ManagerおよびAutoConfig: Oracle Databaseの設定を処理します。例: SID name、Listener、dbPorts。また、Oracle E-Business Suite設定のいくつかも処理します。例: コンカレント処理、プロファイル・オプション、Developer 10gの設定、製品固有の設定。

構成管理の変更

Oracle E-Business Suiteリリース12.2において、OC4JはOracle WebLogic Serverと置き換えられました。 これによって、Oracle HTTP Serverおよびoacore、oafm、forms、forms-c4wsサービスの構成におけるAutoConfigのロールが削減されました。

Oracle E-Business Suiteリリース12.1.3までは、AutoConfigはOracle HTTP Server構成およびOC4Jインスタンス構成の全体を管理するために使用されていました。Oracle E-Business Suiteリリース12.2では、Oracle HTTP Server構成の一部のみを管理します。また、oacore、oafm、formsおよびforms-c4wsサービスの構成も部分的にのみ管理します。AutoConfigの残りのスコープは、Oracle E-Business Suite Release 12.2よりも前のものと同じです。

この章では、依然としてAutoConfigによって取り扱われる構成管理の面を説明します。Oracle E-Business Suite Release 12.2におけるOracle WebLogic Serverのロールについて説明し、WLSの管理およびトラブルシューティングの重要なタスクについてもいくつか説明します。

リリース12.2の2つの重要な構成変更は次のとおりです。

より広いコンテキストにおける変更は次のとおりです。

リリース12.2の構成管理の変更の要約
構成アクティビティ リリース12.2未満 リリース12.2
Oracle E-Business Suiteデータベース、コンカレント処理、Oracle Developer 10g、プロファイル・オプション、その他のOracle E-Business Suiteコンポーネント。 Oracle Applications Manager。 Oracle Applications Manager。
HTTP構成への変更。 すべてのHTTP構成はAutoConfigテンプレートによって管理されていました。個々のコンテキスト変数を編集してからAutoConfigを実行することによって構成変更が行われていました。 ほとんどのHTTP構成は、ネイティブのOracle WebLogic ServerツールやFusion Middleware Controlによって、または構成ファイルを手動で編集することによって管理されます。限られたHTTP構成ファイルのセットのみがAutoConfigによって保守されます。詳細はこの章で後述します。
oacore、oafm、formsおよびforms-c4wsサービスの構成への変更。 oacore、oafm、formsおよびforms-c4wsサービスの構成設定はすべて、AutoConfigテンプレートによって管理されていました。コンテキスト変数を編集してAutoConfigを実行することによって構成変更が行われていました。 oacore、oafm、formsおよびforms-c4wsサービスのプロパティは、クラスパスおよびJVM引数を含めて、WebLogic管理コンソールなどのネイティブのWebLogicツールを使用して更新する必要があります。コンテキスト変数の値は、管理対象サーバーの作成中に初期値を設定するためにのみ使用されます。
詳細はこの章で後述します。
oacore、oafm、formsおよびforms-c4wsサービスのJVMインスタンスの管理。 サービスのインスタンス数は、Oracle Process Manager (OPMN)を介して制御されていました。この数は、nprocsコンテキスト変数を編集し、AutoConfigを実行し、サービスの停止と再起動を行うことによって変更できました。 サービスのJVMインスタンスはそれぞれ、そのサービス・タイプの管理対象サーバーに対応しています。インスタンスの数は、そのサービスの管理対象サーバーを明示的に作成または削除することによって制御する必要があります。詳細はこの章で後述します。

Oracle WebLogic Serverの要件および使用方法

Oracle E-Business Suiteリリース12.2にはWebLogic Server Basicが必要です。 これはライセンスで制約されるバージョンのWebLogic Serverであり、特定のOracle製品のライセンスにおいて使用できます。

WebLogic Server BasicはOracle E-Business Suiteリリース12.2で使用され、次の機能をサポートします。

AutoConfigのスコープおよびコンポーネント

リリース12.2のアプリケーション層はAutoConfigに対応しており、INST_TOPに<INST_TOP>/appl/admin/<CONTEXT_NAME>.xmlとして格納されたアプリケーション・コンテキスト・ファイルがあります。Rapid Installによって作成されたリリース12.2のデータベース層もAutoConfigに対応しており、RDBMS ORACLE_HOMEに<RDBMS_ORACLE_HOME>/appsutil/<CONTEXT_NAME>.xmlとして格納されたデータベース・コンテキスト・ファイルがあります。

主なAutoConfigコンポーネントは次のとおりです。

Component 説明
アプリケーション・コンテキスト APPL_TOPに固有の情報を含む、INST_TOPにあるXMLリポジトリ。
データベース・コンテキスト そのデータベース層に固有の情報を含む、RDBMS ORACLE_HOMEにあるXMLリポジトリ。
AutoConfigテンプレート・ファイル インスタンス化のプロセス中に適切なコンテキストからインスタンス固有の情報で置換される名前付きタグを含むファイル。
AutoConfigドライバ・ファイル すべてのOracle E-Business Suite製品では、AutoConfigによって使用されるドライバ・ファイルが保守されています。ドライバ・ファイルには、AutoConfigファイル・テンプレートおよびその宛先の場所がリストされています。
AutoConfigスクリプト AutoConfig APIへの簡易インタフェースを提供するスクリプトのセット。

AutoConfigを使用したOracle E-Business Suiteサービスの管理

この項では、AutoConfigでOracle E-Business Suiteサービスおよびプロセスを管理する方法について説明します。

前のリリースのOracle E-Business Suiteでは、提供されるサービスのタイプに応じてアプリケーション・サービスがサービス・グループに分類されていました。Oracle E-Business Suiteリリース12.2では、追加のサービスおよびサービス・グループの導入によってこの概念が拡張されました。

最も注目すべきものとして、「Web Administration」サービス・グループがリリース12.2で導入されました。このサービス・グループには、WebLogic管理サーバーが含まれ、他のサービス・グループと異なり、アプリケーション層ノードの1つでのみ使用可能にできます。つまり、Rapid Install中に使用可能にされたノード以外のアプリケーション層ノードでWebLogic管理サーバーを使用可能にすることはサポートされていません。

注意: リリース12.2では2つの独立したポート・プールが使用されます。これはユーザーに透過的です。ただし、WLS管理ポートをメモしておくと役に立つこともあります。

また、前のリリースのOracle E-Business Suiteリリース12.xと異なり、Root Service GroupはOracle Process Manager (OPMN)ではなくノード・マネージャを構成するようになりました。Oracle E-Business Suiteリリース12.2では、OPMNのみがOracle HTTP Serverを管理します。その結果、「Web Entry Point Services」 サービス・グループの一部となりました。

次のテーブルは、リリース12.2に存在する、AutoConfigによって管理されるサービス・グループおよびサービスを示しています。

注意: UNIXバージョンのサービス管理スクリプトのみを示しています。Windowsに対応するものの接尾辞は.shではなく.cmdです。

サービス・グループ サービス サービス管理スクリプト
Root Service ノード・マネージャ adnodemgrctl.sh
Web Administration WebLogic管理サーバー adadminsrvctl.sh
Web Entry Point Services Oracle HTTP Server
Oracle Process Manager
adapcctl.sh
adopmnctl.sh
Web Application Services oacore
oafm
forms
forms-c4ws
admanagedsrvctl.sh
admanagedsrvctl.sh
admanagedsrvctl.sh
admanagedsrvctl.sh
Batch Processing Services Oracle TNS Listener
コンカレント・マネージャ
Fulfillmentサーバー
Oracle ICSM
adalnctl.sh
adcmctl.sh
jtffmctl.sh
ieoicsm.sh
Other Services フォーム・サーバー
Oracle MWA Service
adformsrvctl.sh
mwactlwrpr.sh

注意: サービスとそのサービス・グループの両方が使用可能な場合のみ、adstrtalまたはadstpallスクリプトを介して特定のサービスが開始または停止されます。

AutoConfigによって管理されるサービスおよびサービス・グループの変更

特定のアプリケーション・インスタンスの要件に応じて、adstrtalおよびadstpallスクリプトによってそれぞれ開始および停止されるアプリケーション・サービスおよびサービス・グループのセットを変更できます。これは、必要なサービスおよびサービス・グループを使用可能にし、必要ではないものを使用不可にすることによって実行できます。

Oracle E-Business Suiteサービス・プロセスを管理するコマンド

システム構成でのAutoConfigツールの使用

次の表に、adautocfg.shなどの既存のツールおよびadRegisterWLSListeners.plやadSyncContext.plなどの新しいツールを含むAutoConfigツールの要約を示します。各ツールの詳細はこの章で後述します。

注意: Windowsでは、コマンド・ファイル(.cmd接尾辞)はUNIXスクリプト(.sh接尾辞)と同等です。

スクリプト名 保管場所 目的
adautocfg.sh/cmd アプリケーション層: <INST_TOP>/admin/scripts
データベース層: <RDBMS_ORACLE_HOME>/appsutil/scripts/<CONTEXT_NAME>
このスクリプトはAutoConfigの実行に使用されます。
adRegisterWLSListeners.pl アプリケーション層: <AD_TOP>/bin このスクリプトは、WebLogic Serverの構成パラメータに対する変更をリスニングし、必要に応じてコンテキスト変数を更新するために使用されます。
adSyncContext.pl アプリケーション層: <AD_TOP>/bin このスクリプトは、WebLogic Serverの構成パラメータの値を明示的にプルし、コンテキスト変数の値をそれらと同期するために使用されます。これらは、OHSパラメータの同期に必要です。
adchkcfg.sh/cmd アプリケーション層: <AD_TOP>/bin
データベース層: <RDBMS_ORACLE_HOME>/appsutil/bin
このスクリプトは、AutoConfigの実行に対する変更を確認するためにAutoConfigを実行する前に実行できます。これは、既存の構成とAutoConfig実行後の構成の差異を示すレポートを生成します。
GenCtxInfRep.pl アプリケーション層: <FND_TOP>/patch/115/bin
データベース層: <RDBMS_ORACLE_HOME>/appsutil/bin
このスクリプトは、コンテキスト変数名のすべてまたは一部をキーワードとして指定して、コンテキスト変数およびそれらが使用されるテンプレートに関する詳細情報を確認するために使用できます。
adtmplreport.sh/cmd アプリケーション層: <AD_TOP>/bin
データベース層: <RDBMS_ORACLE_HOME>/appsutil/bin
このスクリプトは、インスタンス化されたファイルの場所を指定して、AutoConfigテンプレートの場所に関する情報を収集するために使用できます(逆もまた同様)。
admkappsutil.pl アプリケーション層: <AD_TOP>/bin このスクリプトは、パッチをデータベース層に適用する際に使用します。このスクリプトを実行するとappsutil.zipが生成され、そのファイルはパッチをデータベース層に移行するためにデータベース層にコピーできます。

前述のツールと同様に、Oracle E-Business Suiteサービスのランタイム・プロセスを管理するために使用する起動および停止のツールがあります。これらのツールはこの章で後述します。

前述したとおり、AutoConfigはシステム構成を自動化するために使用されます。この項では、この目的でAutoConfigツールを使用する方法について説明します。これらのツールによって実行される処理は、一般的に次のサブセクションで示される順番で実行されます。

AutoConfigの実行による影響の確認

AutoConfigを実行する前に、次のAutoConfigの実行でファイル・システムおよびデータベースで発生する変更を確認するために、構成確認ユーティリティを実行できます。このステップはオプションです。

適切なコマンドを実行して、構成確認ユーティリティを実行します。

データベース層

UNIXの場合:

sh <RDBMS_ORACLE_HOME>/appsutil/bin/adchkcfg.sh \
contextfile=<CONTEXT_FILE>

Windowsの場合:

C:\><RDBMS_ORACLE_HOME>\appsutil\bin\adchkcfg.cmd contextfile=<CONTEXT_FILE>

アプリケーション層

UNIXの場合:

$ sh <AD_TOP>/bin/adchkcfg.sh \
contextfile=<CONTEXT_FILE> 

Windowsの場合:

C:\><AD_TOP>\bin\adchkcfg.cmd contextfile=<CONTEXT_FILE>

このユーティリティの詳細は後述します。

データベース層でのAutoConfigの実行

次の処理を行った後に、データベース層でのAutoConfigの実行が必要です。

次のコマンドを実行して、データベース層でAutoConfigを実行します。

UNIXの場合:

$ sh <RDBMS_ORACLE_HOME>/appsutil/scripts/<CONTEXT_NAME>/adautocfg.sh

Windowsの場合:

C:\><RDBMS_ORACLE_HOME>\appsutil\scripts\<CONTEXT_NAME>\adautocfg.cmd

次の重要な点に注意してください:

アプリケーション層でのSyncContextの実行

Oracle E-Business Suiteリリース12.2では、一部の構成はAutoConfigによって管理され、一部はFusion Middleware ControlおよびWebLogic Server管理コンソールによってネイティブに管理されます。コンテキスト変数とOHS構成パラメータ(適用される場合)の同期を保持するための新しいメカニズムが導入されました。このメカニズムは'フィードバック・ループ'といいます。SyncContext ツールは、コンテキスト変数とWLS構成パラメータの明示的な同期に使用されるツールの1つです。

このツールは次のようにすべてのアプリケーション層ノードで実行できます。

UNIXの場合:

$ perl <AD_TOP>/bin/adSyncContext.pl contextfile=<CONTEXT_FILE>

重要: adSyncContext.plスクリプトの実行中は、ノード・マネージャおよびWebLogic管理サーバーが実行されている必要があります。

adSyncContext.plスクリプトによってWLS構成パラメータ値が読み取られ、それらがコンテキスト変数と同期されます。これはたとえば、OHS構成パラメータを対応するコンテキスト変数と同期するために使用されます。

対照的に、adRegisterWLSListeners.plスクリプトはWLS構成パラメータの変更を単にリスニングし、その値が関連するコンテキスト変数と同期されることを容易にします。

アプリケーション層サービスの停止

アプリケーション層でAutoConfigを実行する前に、すべてのアプリケーション層サービスを停止する必要があります。これは次のコマンドを使用して行うことができます。

UNIXの場合:

$ sh <ADMIN_SCRIPTS_HOME>/adstpall.sh

Windowsの場合:

C:\><ADMIN_SCRIPTS_HOME>\adstpall.cmd

アプリケーション層でのAutoConfigの実行

次の適切なコマンドを実行して、すべてのアプリケーション層ノードでAutoConfigを実行します。

UNIXの場合:

$ sh <INST_TOP>/admin/scripts/adautocfg.sh

Windowsの場合:

C:\><INST_TOP>\admin\scripts\adautocfg.cmd

次の重要な点に注意してください:

AutoConfigログ・ファイルの確認

AutoConfigログファイルは次の場所に格納されます。

ディレクトリ
アプリケーション <INST_TOP>/admin/log/<MMDDhhmm>
データベース <RDBMS_ORACLE_HOME>/appsutil/log/<CONTEXT_NAME>/<MMDDhhmm>

AutoConfigセッションごとに1つのログ・ファイルが作成されます。実行中にAutoConfigが実行したすべての処理の詳細が含まれます。

すべてのアプリケーション層サービスの起動

AutoConfigの実行後、次の適切なコマンドを実行してすべてのアプリケーション層サービスを起動します。

UNIXの場合:

$ sh <ADMIN_SCRIPTS_HOME>/adstrtal.sh

Windowsの場合:

C:\><ADMIN_SCRIPTS_HOME>\adstrtal.cmd

アプリケーション層でのadRegisterWLSListenersツールの実行

前述のように、Oracle E-Business Suiteリリース12.2の構成の一部はAutoConfigによって管理され、一部はFusion Middleware ControlまたはOracle WebLogic Server管理コンソールによってネイティブに管理されます。

adRegisterWLSListenersツールは、コンテキスト変数を関連するOracle WebLogic Serverの構成パラメータと同期するために導入されました。

注意: このツールはOracle HTTP Serverの構成パラメータへの変更はリスニングしません

次のコマンドを実行してadRegisterWLSListeners.plを起動します。

$ perl <AD_TOP>/bin/adRegisterWLSListeners.pl contextfile=<CONTEXT_FILE>

一度起動すると、adRegisterWLSListenersは実行を続け、WebLogic Serverの構成に対する変更をリスニングし、データベースに格納されたコンテキスト・ファイルを同期します。

重要: WebLogic管理サーバーが停止されるとadRegisterWLSListenersツールは自動的に停止します。UNIXインスタンスでは、WebLogic管理サーバーが起動されるとこのツールが自動的に起動されます。Windowsインスタンスでは、WebLogic管理サーバーが起動されるたびにこのツールを明示的に起動する必要があります。

AutoConfigセッションのロールバック

AutoConfigを実行するたびに、必要に応じて前の構成設定に戻すために使用できるロールバック・スクリプトが作成されます。各AutoConfigセッションからのこのスクリプトおよびバックアップ構成ファイルは、次の場所に格納されます。

ディレクトリ
アプリケーション <INST_TOP>/admin/out/<MMDDhhmm>
データベース <RDBMS_ORACLE_HOME>/appsutil/out/<CONTEXT_NAME><MDDhhmm>

ここで、<MMDDhhmm>はAutoConfig実行の<month, day, hour, minute>です。

注意: ロールバックは、AutoConfigセッションで問題が発生した場合のみ実行する必要があります。

AutoConfigセッションをロールバックするには、次のコマンドを実行します。

UNIXの場合:

$ restore.sh

Windowsの場合:

C:\>restore.cmd

AutoConfigによって管理される構成のカスタマイズ

AutoConfigによって、Oracle E-Business Suite環境の構成管理タスクが単純化および標準化されます。AutoConfigによって管理される各ファイルの冒頭には次のヘッダーがあります。

################################################################ 
# Do not edit settings in this file manually. They are managed
# automatically and will be overwritten when AutoConfig runs.
# For more information about AutoConfig, refer to
# Oracle E-Business Suite Setup Guide.
################################################################ 

ただし、AutoConfigによって生成された構成は常に固有の要件を満たすとは限らず、環境に合せたAutoConfigのカスタマイズが必要な場合もあります。

AutoConfigのカスタマイズが必要になる例は次のとおりです。

AutoConfigカスタマイズの実装

この項では、様々なタイプのAutoConfigカスタマイズおよびそれらの実装方法について説明します。カスタマイズのニーズを特定した後、それらに関連するステップを実行します。

Oracleでは、次のタイプのカスタマイズがサポートされます。

これらを順番に考えます。

AutoConfigカスタマイズの高度な機能

この項では、AutoConfigカスタマイズの使用時に使用可能な高度な機能について説明します。

AutoConfigカスタマイズの制限および制約

この項では、AutoConfigカスタマイズを使用する際に存在する制限および制約について説明します。

AutoConfigのパッチ適用

Oracle E-Business Suiteリリース12.2では、AutoConfigにパッチを適用する場合、アプリケーション層およびデータベース層の両方でAutoConfigを使用可能にする必要があります。

最新のAutoConfig更新の適用

アプリケーション層およびデータベース層の両方で最新のAutoConfig更新を取得するには、次のステップをリストされた順番で実行します。

  1. RDBMS ORACLE_HOMEへのAutoConfigのコピー

    次のステップを実行して、RDBMS ORACLE_HOMEファイル・システムを新しいAutoConfigファイルで更新します。

    1. アプリケーション層(APPLMGRユーザーとして)。

      1. APPL_TOP環境にログインして、環境ファイルを入手します。

      2. 次のコマンドを実行してappsutil.zipファイルを作成します。

        $ perl <AD_TOP>/bin/admkappsutil.pl

        これによって、<INST_TOP>/admin/outにappsutil.zipが作成されます。

    2. データベース層(ORACLEユーザーとして)。

      1. appsutil.zipファイルをRDBMS ORACLE_HOMEにコピーまたはFTPで転送して、次のコマンドを実行します。

        $ cd <RDBMS ORACLE_HOME>
        $ unzip -o appsutil.zip
  2. AutoConfigの実行

    AutoConfigをデータベース層で実行し、次にアプリケーション層で実行します。

新しいOracleホームでのAutoConfigの有効化

リリース12.2では、アプリケーション層でAutoConfigはデフォルトで使用可能です。ただし、次のシナリオではデータベース層で使用可能にできない場合があります。

データベース層でAutoConfigを使用可能にするには、次のステップをリストされた順番に実行します。

  1. RDBMS ORACLE_HOMEへのAutoConfigのコピー

    前述の「最新のAutoConfig更新の適用」のステップに従って、RDBMS ORACLE_HOMEファイル・システムを更新します。

  2. データベース層へのJava Runtime Environment (JRE)のインストール

    JREはデータベース層の<ORACLE_HOME>/appsutil/jreディレクトリに存在します。データベース層のJREのバージョンが次のバージョン以上であることを確認します。

    公式のダウンロード場所からJREを取得できます。

    警告: Java SE Development Kit (JDK)はダウンロードしないでください。そのかわり、64ビットJVMをサポートするJREをダウンロードしてください。インストレーションの追加情報は、『Using Latest Java 6.0 Update With Oracle E-Business Suite Release 12』(Doc ID 455492.1)を参照してください(32ビットJREのダウンロードに関する注意は無視してください)。

  3. データベース・コンテキスト・ファイルの生成

    次のコマンドを実行して、データベース・コンテキスト・ファイルを作成します。

    $ perl <RDBMS_ORACLE_HOME>/appsutil/bin/adbldxml.pl

    重要: Oracle RAC環境の一部であるインスタンスに対してadbldxml.plユーティリティを実行する場合、adbldxml.plがそれらのインスタンスに接続して構成に関する情報を収集できるように、すべてのOracle RACインスタンスが実行されている必要があります。

  4. データベース層でのAutoConfigの実行

    次のいずれかのコマンドを実行してデータベース層でAutoConfigを実行します。

    UNIXの場合:

    $ <RDBMS_ORACLE_HOME>/appsutil/bin/adconfig.sh \
    contextfile=<context_file> 

    Windowsの場合:

    C:\><RDBMS_ORACLE_HOME>\appsutil\bin\adconfig.cmd contextfile=<context_file> 

高度なAutoConfig機能および追加ユーティリティ

この項では、いくつかの高度なAutoConfig機能およびユーティリティの概要を示します。

複数ノード間でのAutoConfigの同時実行

この機能は、Oracle E-Business Suiteリリース12.2インスタンスの複数ノード間でAutoConfigを同時に実行できるようにします。次のコマンドを実行することによって、AutoConfigをこのパラレル・モードで実行できます。

重要: 複数ノードでAutoConfigを同時に実行する場合、各ノードでAutoConfigを実行するときに-parallelオプションを指定する必要があります。そうしない場合、個別ノードでのAutoConfigプロセスの実行は同期されず、ファイル・システムまたはデータベースの不整合が発生する可能性があります。

AutoConfig実行のプロファイリング

AutoConfigのパフォーマンス・プロファイラ機能を使用して、AutoConfigの実行をプロファイルし、HTML形式での統合レポートを生成できます。レポートには、すべての製品トップおよびそれらのテンプレートのインスタンス化/実行の合計時間をリストする要約ビューが表示されます。プロファイル・レポートは次のセクションで構成されます。

次のコマンドを発行することによって、AutoConfigをプロファイル・モードで実行できます。

構成確認ユーティリティの使用

構成確認ユーティリティ(adchkcfg)を使用して、次のAutoConfigの実行中にOracle E-Business Suiteインスタンスで有効になる構成変更を確認できます。ファイル・システムとデータベースの両方への潜在的な変更が識別されます。これは、アプリケーション層およびデータベース層の両方で実行できます。

このユーティリティは次の場所にあります。

保管場所
アプリケーション <AD_TOP>/bin
データベース <ORACLE_HOME>/appsutil/bin

次のコマンドを実行して、構成確認ユーティリティを実行します。

このスクリプトによってHTMLおよびテキストの両方のレポートが生成されます。レポートによって、次の通常のAutoConfigの実行中に行われるファイル変更、プロファイル・オプション変更およびその他の重要なデータベース更新のすべてに関する情報が提供されます。情報は次の2つのタブの下に編成されます。

スクリプトによってzipファイル・レポートであるADXcfgcheck.zipも作成され、これには前述のファイルおよびレポートがすべて含まれます。ADXcfgcheck.zipファイルはローカル・クライアント・デバイスにコピーでき、そこではHTMLレポートがレポート内のハイパーリンクが切れることなく表示されます。

コンテキスト変数情報ユーティリティの使用

このコマンドライン・ユーティリティは、コンテキスト変数およびそれらが使用されているテンプレートに関する詳細情報を調べるために使用できます。このユーティリティは、コンテキスト変数名のすべてまたは一部を受け取り、一致するコンテキスト変数に関する情報(説明、デフォルト値および現在の値など)を含むHTMLまたはテキストのレポートを生成します。変数の説明には推奨設定、許容値の範囲、および使用方法に関する詳細情報を提供するドキュメントへのリンクが含まれます。また、このユーティリティによって、各コンテキスト変数が使用される構成テンプレートがリストされます。

アプリケーション層の環境ファイルを入手した後は、コンテキスト変数情報ユーティリティを次のように実行できます。

ユーティリティは次の引数を取ります。

Oracle RACインスタンスでのAutoConfigの使用

この項では、Oracleリリース12.2インスタンスをOracle Real Application Clusters (Oracle RAC)環境で実行するときに実行する必要があるステップを順に説明します。

Oracle E-Business Suiteリリース12.2では、Oracle RACに必要なtnsnames.oraファイルを完全に生成するしくみが提供されています。これには次が含まれます。

tnsnames.oraファイルは、ネット・サービス・トポロジ・データ・モデルを使用して動的に生成されます。ネット・サービス・トポロジ・データ・モデルには、単一のOracle E-Business Suite環境のトポロジの情報がすべて格納されます。

Oracle RACでAutoConfigをサポートするには次のステップを実行します。

  1. init.oraの確認: AutoConfigは既存のinit.oraファイルを上書きしません。ただし、init.oraファイルが存在しない場合は、Oracle RACと互換性のあるinit.oraがAutoConfigによって生成されます。既存のinit.oraファイルのバックアップを作成し、AutoConfigによって新しいinit.oraファイルを生成することをお薦めします。こうすることによって、たとえば、サービス名としてのDB_Nameの使用や、ローカルおよびリモート・リスナーの処理など、Oracleの標準にinit.oraファイルが準拠します。

  2. データベース層へのAutoConfigパッチの移行: 前述のステップに従い、AutoConfigパッチをデータベース層に移行します。

  3. すべてのデータベース層ノードでのAutoConfigの実行: 前述の指示に従って、すべてのデータベース層ノードでAutoConfigを実行します。

  4. アプリケーション層でのAutoConfigの実行: 各アプリケーション層ノードでAutoConfigを実行します。前述のadautocfg.sh (またはadautocfg.cmd)を使用します。

  5. データベース・リスナーの再起動: データベース・リスナーを停止して再起動します。

これでOracle RACでAutoConfig対応になり、前述のようにシステム構成を管理できます。

Oracle HTTP Server構成の管理

Oracle E-Business Suiteリリース12.2よりも前は、システムのライフサイクル全体を通して、すべてのOracle HTTP Server構成ファイルがAutoConfigによって管理されていました。リリース12.2では、Oracle HTTP Server構成ファイルの初期設定にのみAutoConfigが関係しています。

その後で、Oracle HTTP Server構成ファイルの限られたセットを管理およびカスタマイズするために使用することもできます。そうしない場合は、この項で後述するように、ネイティブのOracle WebLogic ServerおよびFusion Middlewareのツールを使用してこれらのファイルを管理します。

AutoConfigによって管理されるOracle HTTP Server構成の更新

次の表に、Oracle E-Business Suiteリリース12.2でAutoConfigによって管理されるOracle HTTP Server構成テンプレートを示します。これらのファイルで定義される構成は、テンプレートをカスタマイズすることによってカスタマイズできます。

テンプレート名 構成ファイル
ssl_terminator_conf_FMW.tmp ssl_terminator.conf
trusted_conf_FMW.tmp trusted.conf
oracle_apache_conf_FMW.tmp oracle_apache.conf
url_fw_conf_FMW.tmp url_fw.conf
url_fw_ws_conf_FMW.tmp url_fw_ws.conf
security_dmz_conf_FMW.tmp security_dmz.conf
custom_conf_FMW.tmp custom.conf

シード済Oracle HTTP Server構成の更新

Oracle HTTP Serverインスタンスの作成中に、AutoConfigは、httpd.confやmod_wl_ohsなどの構成ファイルの最初のインスタンス化を実行します。リリース12.2のインストールまたはリリース12.2へのアップグレードが完了すると、シード済Oracle HTTP Server構成は一般的にFusion Middleware Controlによって管理されます。しかし、特定の場合において、ネイティブの構成ファイルの手動編集が必要になることがあり、これについては必要に応じて別に説明します。

注意: 詳細は、『Oracle Fusion Middleware管理者ガイド』Oracle Enterprise Manager Fusion Middleware Controlの使用の概要に関する項を参照してください。このドキュメントは、Oracle Fusion Middlewareドキュメント・ライブラリにあります。

Oracle HTTP Serverのプロトコルまたはポート番号を変更する場合、これらの値はHTTP構成ファイルのみでなくコンテキスト・ファイルでも更新する必要があります。これによって、AutoConfigによって管理されるデータベース・プロファイル値においても新しい値が確実に更新されます。

Oacore、Oafm、FormsおよびForms-c4wsアプリケーション構成の管理

Oracle E-Business Suiteリリース12では、oacore、oafm、formsおよびforms-c4wsサービスはOC4Jインスタンスであり、Oracle Process Manager (OPMN)によって管理されていました。Oracle E-Business Suiteリリース12.2ではOracle WebLogic ServerによってのOC4Jが置換されたため、これらのサービスは個別の管理対象サーバー上のアプリケーションとしてデプロイされるようになりました。

その結果、これらのアプリケーションおよび管理対象サーバーの一部の構成のみが引き続きAutoConfigによって管理されています。この項では、AutoConfigによって引き続き管理されるこれらの領域および管理されない領域について説明します。

個別のアプリケーション用の構成パラメータの更新

oacore、oafm、formsおよびforms-c4wsアプリケーションの基本的な構成は、それぞれのデプロイメント・プランで保守されます。デプロイメント・プランには、セッション・タイムアウト、ログ・ファイル・ローテーション・サイズ、ログ・ファイル・ローテーション・タイムなどの各アプリケーションの構成可能パラメータが含まれます。これらのデプロイメント・プランはそれぞれ、限られたコンテキスト変数のセットを含めてAutoConfigテンプレートとして提供されます。

デプロイメント・プランは、最初はAutoConfigによってインスタンス化されます。その後、AutoConfigによって既存のデプロイメント・プランの更新のみが行われます。これは、デプロイメント・プランで使用されているコンテキスト変数がカスタマイズされている場合に必要となります。

AutoConfigを使用して更新または変更できるパラメータは、oacoreのデプロイメント・プランにおける次のパラメータのみです。

パラメータ
help_InitParam_ohwConfigFileURL file:%s_ora_config_home%/FMW/oacore/config/ohwconfig.xml
CGIServlet_InitParam_cgiDir %s_config_home%/admin/install
CGIServlet_InitParam_*.pl %s_adperlprg%
oowa_InitParam_log_main_file %s_logs_dir%/ora/FMW/oacore/oowa.log
oowa_InitParam_log_spl2_file %s_logs_dir%/ora/FMW/oacore/oowa.log
LoopProcServlet_InitParam_ARCHIVE %s_applptmp%
TransmitServlet_InitParam_ARCHIVE %s_applptmp%

各アプリケーションの残りのパラメータは、次のようにWebLogic Server管理コンソールを使用して更新する必要があります。

  1. WebLogic Server管理コンソールにログオンします。

  2. 「ドメイン構造」の左パネルにある「デプロイメント」リンクをクリックします。

  3. すべてのデプロイメントの要約が示されるページを確認します。

  4. アプリケーション・レベルで構成をカスタマイズする場合、構成を更新するアプリケーションをクリックします。たとえば、oacore構成を更新する場合、「oacore」のリンクをクリックし、アプリケーションの設定を編集できるページで必要な処理を行います。

  5. Webアプリケーション・レベルで構成変更を行う場合、「デプロイメント」ページで対応するWebアプリケーションのリンクをクリックし、「構成」タブを選択してアプリケーションの構成パラメータをカスタマイズします。

  6. パラメータを編集および設定した後、「保存」ボタンをクリックします。これによってアプリケーションのデプロイメント・プランが更新されます。

  7. すべての構成変更を保存した後、「チェンジ・センター」パネルの「変更のアクティブ化」ボタンをクリックして変更をアクティブ化します。

注意: 詳細は、『Oracle Fusion Middleware管理者ガイド 11g リリース1(11.1.1)』Oracle WebLogic Server管理コンソールの使用の概要に関する項を参照してください。このドキュメントは、Oracle Fusion Middlewareドキュメント・ライブラリにあります

個別の管理対象サーバーの構成パラメータの管理

管理対象サーバーの構成は、WebLogic Server管理コンソールやWLSTコマンドなどのネイティブのWebLogicツールを使用してカスタマイズできます。

次のステップを使用して、WebLogic Server管理コンソールによって管理対象サーバーの構成をカスタマイズします。

  1. WebLogic Server管理コンソールにログオンします。

  2. 「サーバー」リンクをクリックします。このリンクは、WebLogic管理サーバーおよびすべての管理対象サーバーの要約を含むページを表示します。

  3. 構成を更新する必要がある管理対象サーバーをクリックします。管理対象サーバーの設定用の様々なタブを含むページが表示されます。

  4. 必要に応じて構成パラメータを更新します。

  5. 「保存」ボタンをクリックして構成変更を保存します。

  6. カスタマイズが完了して保存された後、「チェンジ・センター」パネルの「変更のアクティブ化」ボタンをクリックして変更をアクティブ化します。

注意: 管理対象サーバーのポート番号を変更する場合、WebLogicのネイティブ・ツールを使用してポート番号を更新することに加えて、「管理対象サーバーのポート番号の変更」の項にある追加ステップも実行します。

管理対象サーバーのクラスパスおよびJVM引数の管理

管理対象サーバーのクラスパスおよびJVM引数は、前述のようにWebLogic Server管理コンソールからまたはWLSTコマンドを介して変更できます。

さらに、これらのプロパティも次のようにバックエンドから設定できます。

adstrtal.sh/cmdスクリプトまたは個別の制御スクリプトadmanagedsrvctl.sh/cmdを使用した管理対象サーバーの起動中に、Oracle E-Business Suite固有のライブラリ・パスが管理対象サーバーのJVM引数において更新されます。JVM引数が管理対象サーバーに対してすでにカスタマイズされている場合は、EBS固有のライブラリ・パスがカスタマイズ済ライブラリ・パスのリストに追加されます。

管理対象サーバーのクラスパスおよびJVM引数のデフォルト値へのリセット

どの時点でも、管理対象サーバーのクラスパスまたはJVM引数をデフォルト値にリセットする必要がある場合は、コンテキスト・ファイルからデフォルト値を参照し、ネイティブのWebLogicツールまたは前述のadProvisionEBS.plスクリプトを使用してこれらのプロパティを更新することによって、これを行うことができます。

管理対象サーバーのクラスパスのデフォルト値は、次の表にリストされたコンテキスト変数から参照できます。

サービス・タイプ コンテキスト変数
oacore s_oacore_nodes
oafm s_oafm_nodes
forms s_forms_nodes
forms-c4ws s_forms-c4ws_nodes

管理対象サーバーのJVM引数のデフォルト値は、次のコンテキスト変数から参照できます。

サービス・タイプ コンテキスト変数
oacore s_oacore_jvm_start_options
oafm s_oafm_jvm_start_options
forms s_forms_jvm_start_options
forms-c4ws s_forms-c4ws_jvm_start_options

管理対象サーバーのポート番号の変更

管理対象サーバーのポート番号を変更するには、まず前述のサブセクション「個別の管理対象サーバーの構成パラメータの管理」にあるステップに従ってポート番号を編集する必要があります。それから次のステップを実行して、Oracle HTTP Server構成ファイル内の管理対象サーバーのポート番号を編集します。

  1. Oracle E-Business Suiteリリース12.2インスタンスのすべてのノードのアプリケーション層コンテキスト・ファイルで、特定の管理対象サーバー・タイプに対応するノード関連コンテキスト変数を編集して、古いポート番号を新しいポート番号と置換します。adRegisterWLSListeners.plスクリプトが主ノードで実行されている場合、このステップは自動的に行われます。

    次に示すのは、各管理対象サーバー・タイプについて更新されるコンテキスト変数をリストする表です。

    サービス・タイプ コンテキスト変数
    oacore s_oacore_nodes
    oafm s_oafm_nodes
    forms s_forms_nodes
    forms-c4ws s_forms-c4ws_nodes
  2. Oracle HTTP Serverを含むノードで、AutoConfigを実行します。それから次のスクリプトを実行して、Oracle HTTP Server構成ファイルを新しい管理対象サーバーのポート番号で更新します。

    perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl \
    -ctxfile=$CONTEXT_FILE -outfile=<OUT_FILE>
  3. Oracle HTTP Serverを含むノードで、Oracle HTTP Serverを次のように再起動します。

    UNIXの場合:

    $ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh stop
    $ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh start

    Windowsの場合:

    C:\><ADMIN_SCRIPTS_HOME>/adapcctl.cmd stop
    C:\><ADMIN_SCRIPTS_HOME>/adapcctl.cmd start

特定のサービス・タイプのインスタンス数のカスタマイズ

デフォルトでは、各アプリケーション層ノードに、oacore、oafm、formsおよびforms-c4wsサービスの単一インスタンスのみが含まれます。アプリケーション層ノードの特定のサービスのインスタンスを増やす必要がある場合、新しい管理対象サーバーを作成する必要があります。同様に、特定のサービスのインスタンス数を減らす必要がある場合、対応する管理対象サーバーを削除する必要があります。

注意: oacoreサービスの場合、サイズ2 GBのJVM当たりのコンカレント・ユーザー数は150から200までにすることをお薦めします。

新しい管理対象サーバーの追加

管理対象サーバーの追加は、RUNファイル・システムとPATCHファイル・システムの両方に対して別々に行う必要があります。

特定のサービス・タイプの新しい管理対象サーバーを追加するには、RUNファイル・システムで次のステップを実行します。

  1. 次のコマンドを実行して、新しい管理対象サーバーを追加します。これにより管理対象サーバーが作成されて、対応するサービスのクラスタにデプロイされ、adstrtalおよびadstpallスクリプトによって新しい管理対象サーバーを起動および停止するための新しいエントリがコンテキスト・ファイルに追加されます。

    $ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl \
    ebs-create-managedserver -contextfile=<CONTEXT_FILE> \
    -managedsrvname=<MANAGED_SERVER_NAME> -servicetype=<SERVICE_TYPE> \
    -managedsrvport=<managed_server_port> -logfile=<LOGFILE>
    

    たとえば、タイプ'oacore'の管理対象サーバー'oacore_server2'を追加するには、次のコマンドを実行します。

    $ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl \
    ebs-create-managedserver -contextfile=<CONTEXT_FILE> \
    -managedsrvname=oacore_server2 -servicetype=oacore \
    -managedsrvport=<oacore_port> -logfile=<LOGFILE>
    

    注意: 指定する管理対象サーバー名は、<SERVICE_TYPE>_server<n> (nは整数)の形式にする必要があります。

    注意: 管理対象サーバーのポート番号を指定するとき、そのポートが空いていることを確認してください。管理対象サーバーのポート番号は、各管理対象サーバーごとに異なる必要があります。RUNファイル・システムおよびPATCHファイル・システム上の2つの管理対象サーバーが同じ値を持つことはできません。

  2. すべての管理対象サーバーを追加した後、すべてのアプリケーション層ノード上でAutoConfigを実行します。

  3. Oracle HTTP Serverを含むノード上で次のスクリプトを実行して、新しい管理対象サーバーのポート番号でOracle HTTP Server構成ファイルを更新します。

    $ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl \
    -ctxfile=$CONTEXT_FILE -outfile=<OUT_FILE>
  4. Oracle HTTP Serverを含むノードで、Oracle HTTP Serverを次のように再起動します。

    UNIXの場合:

    $ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh stop
    $ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh start

    Windowsの場合:

    C:\><ADMIN_SCRIPTS_HOME>/adapcct.cmd stop
    C:\><ADMIN_SCRIPTS_HOME>/adapcctl.cmd start

RUNファイル・システムで管理対象サーバーの追加が完了した後、次のステップを実行して管理対象サーバーをPATCHファイル・システムに追加します。

  1. 主ノードのPATCHファイル・システムで次のコマンドを実行して、PATCHファイル・システムのWebLogic管理サーバーを起動します。

    UNIXの場合:

    $ sh <ADMIN_SCRIPTS_HOME>/adadminsrvctl.sh start forcepatchfs

    Windowsの場合:

    C:\> <ADMIN_SCRIPTS_HOME>\adadminsrvctl.cmd start
  2. RUNファイル・システムから次のコマンドを実行して、新しい管理対象サーバーを追加します。

    $ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl ebs-create-managedserver \ 
    -contextfile=<PATCH_CONTEXT_FILE> -managedsrvname=<MANAGED_SERVER_NAME> \ 
    -servicetype=<SERVICE_TYPE> -managedsrvport=<managed_server_port> \ 
    -logfile=<LOGFILE>
  3. PATCHファイル・システム上ですべての管理対象サーバーを追加した後、すべてのアプリケーション層ノードのRUNファイル・システムから、PATCHファイル・システムのコンテキスト・ファイルを渡してadSyncContext.plを実行します。

    $ perl <AD_TOP>/bin/adSyncContext.pl -contextfile=<PATCH_CONTEXT_FILE>
  4. RUNファイル・システムを入手した後、次のコマンドを実行することによって、すべてのアプリケーション層ノードのPATCHファイル・システム上のfsclone_config.txtファイルをインスタンス化します。

    java oracle.apps.ad.autoconfig.InstantiateFile -e <PATCH_CONTEXT_FILE> -tmpl  \
    <PATCH_AD_TOP>/admin/template/fsclone_config_txt.tmp -out  \
    <PATCH_INST_TOP>/appl/admin/fsclone_config.txt
  5. Oracle HTTP Serverを含むノードで、RUNファイル・システムから、PATCHファイル・システムのコンテキスト・ファイルを渡して次のスクリプトを実行します。これにより、PATCHファイル・システム上のOracle HTTP Server構成ファイルが、新しい管理対象サーバーのポート番号で更新されます。

    $ PERL <FND_TOP>/patch/115/bin/txkSetAppsConf.pl -ctxfile=<PATCH_CONTEXT_FILE> \
    -outfile=<OUT_FILE>
  6. 主ノードのPATCHファイル・システムで次のコマンドを実行して、PATCHファイル・システムのWebLogic管理サーバーを停止します。

    UNIXの場合:

    $ sh <ADMIN_SCRIPTS_HOME>/adadminsrvctl.sh stop

    Windowsの場合:

    C:\> <ADMIN_SCRIPTS_HOME>\adadminsrvctl.cmd stop

注意: 管理対象サーバーの作成は、前述のようにadProvisionEBS.plスクリプトによってのみ行う必要があります。管理対象サーバーは、WebLogic Server管理コンソールから作成しないでください。

管理対象サーバーの削除

管理対象サーバーをドメインから削除するには、次のステップを実行する必要があります。管理対象サーバーの追加の場合と同様に、管理対象サーバーの削除もRUNおよびPATCHファイル・システム上で明示的に行う必要があります。

特定のサービス・タイプの管理対象サーバーをRUNファイル・システムから削除するには、RUNファイル・システムで次を実行します。

  1. 管理対象サーバーが存在するアプリケーション層ノード上で次のコマンドを実行します。これによって管理対象サーバーが削除され、削除された管理対象サーバーへの参照を含む各コンテキスト変数が更新されます。

    $ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl ebs-delete-managedserver \
    -contextfile=<CONTEXT_FILE> -managedsrvname=<MANAGED_SERVER_NAME> \
    -servicetype=<SERVICE_TYPE> -logfile=<LOGFILE>     

    たとえば、タイプ'oacore'の管理対象サーバー'oacore_server2'を削除するには、次のコマンドを実行します。

    $ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl ebs-delete-managedserver \
    -contextfile=<CONTEXT_FILE> -managedsrvname=oacore_server2 \ 
    -servicetype=oacore -logfile=<LOGFILE>     
  2. Oracle HTTP Serverを含むノードで、AutoConfigを実行します。それから次のスクリプトを実行して、削除された管理対象サーバーの詳細をOracle HTTP Server構成ファイルから削除します。

    $ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl -ctxfile=$CONTEXT_FILE \ 
    -outfile=<OUT_FILE>     
  3. Oracle HTTP Serverを含むノードで、Oracle HTTP Serverを次のようにバウンスします。

    UNIXの場合:

    $ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh stop 
    $ sh <ADMIN_SCRIPTS_HOME>/adapcctl.sh start         

    Windowsの場合:

     C:\><ADMIN_SCRIPTS_HOME>/adapcct.cmd stop 
     C:\><ADMIN_SCRIPTS_HOME>/adapcctl.cmd start  

RUNファイル・システム上で管理対象サーバーが削除されたら、次のステップを実行してPATCHファイル・システムからそれらを削除します。

  1. 主ノードのPATCHファイル・システムで次のコマンドを実行して、PATCHファイル・システムのWebLogic管理サーバーを起動します。

    UNIXの場合:

    $ sh <ADMIN_SCRIPTS_HOME>/adadminsrvctl.sh start forcepatchfs         

    Windowsの場合:

    C:\> <ADMIN_SCRIPTS_HOME>\adadminsrvctl.cmd start     
  2. RUNファイル・システムから次のコマンドを実行して、対応する管理対象サーバーを削除します。

    $ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl ebs-delete-managedserver / 
    -contextfile=<PATCH_CONTEXT_FILE> -managedsrvname=<MANAGED_SERVER_NAME> / 
    -servicetype=<SERVICE_TYPE> -logfile=<LOGFILE>     
  3. PATCHファイル・システム上で管理対象サーバーを削除した後、すべてのアプリケーション層ノードのRUNファイル・システムから、PATCHファイル・システムのコンテキスト・ファイルを渡してadSyncContext.plを実行します。

    $ perl <AD_TOP>/bin/adSyncContext.pl -contextfile=<PATCH_CONTEXT_FILE>     
  4. RUNファイル・システムを入手した後、次のコマンドを実行することによって、すべてのアプリケーション層ノードのPATCHファイル・システム上のfsclone_config.txtファイルをインスタンス化します。

    java oracle.apps.ad.autoconfig.InstantiateFile -e <PATCH_CONTEXT_FILE> -tmpl  \
    <PATCH_AD_TOP>/admin/template/fsclone_config_txt.tmp -out  \
    <PATCH_INST_TOP>/appl/admin/fsclone_config.txt
  5. Oracle HTTP Serverを含むノードで、RUNファイル・システムから、PATCHファイル・システムのコンテキスト・ファイルを渡して次のスクリプトを実行します。これにより、削除された管理対象サーバーのエントリが、PATCHファイル・システム上のOracle HTTP Server構成ファイルから削除されます。

    $ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl \
    -ctxfile=<PATCH_CONTEXT_FILE> -outfile=<OUT_FILE>     
  6. 主ノードのPATCHファイル・システムで次のコマンドを実行して、PATCHファイル・システムのWebLogic管理サーバーを停止します。

    UNIXの場合:

    $ sh <ADMIN_SCRIPTS_HOME>/adadminsrvctl.sh stop         

    Windowsの場合:

    C:\> <ADMIN_SCRIPTS_HOME>\adadminsrvctl.cmd stop  

注意: 管理対象サーバーの削除は、前述のようにadProvisionEBS.plスクリプトによってのみ行う必要があります。管理対象サーバーは、WebLogic Server管理コンソールから削除しないでください。

非共有複数ノード・システムで必要な追加ステップ

Oracle WebLogic Server (WLS)コンソールによってOACORE、Forms、OAFMおよびForms-C4WSのいずれかのアプリケーションに対して実行された構成変更は、関連するデプロイメント・プランに反映されます。. 変更は、管理サーバーが実行されているノード上のデプロイメント・プランに自動的に加えられます。

複数ノード・システムの場合は、他のノード上のデプロイメント・プランを手動で更新して、すべてのノード上のプランが同期するようにする必要があります。

デプロイメント・プランの場所は次のとおりです。

WLSコンソールを介してデプロイメント・プランに構成変更が行われた場合、次のステップに従って他のノード上のデプロイメント・プランを同期します。

  1. 関連するデプロイメント・プランを編集して、変数定義セクションに新しい構成値を入力します。

    たとえば、セッションのCookieの最大年齢パラメータがWLSコンソールを介して変更された場合、デプロイメント・プランの変数定義セクションの変数WeblogicApplication_SessionDescriptor_CookieMaxAgeSecsに対応する更新を行う必要があります。

  2. デプロイメント・プランを保存します。

  3. 管理対象サーバーを再起動します。

Oracle WebLogic Serverのプロファイルの使用

Oracle E-Business Suiteリリース12.2では、管理コンソールを介してJDBCデータソースに関連したランタイム統計を表示する機能がOracle WebLogic Serverによって提供されています。モニターされたランタイム統計からのパフォーマンスの問題または詳細によって、ドメイン内に問題がある可能性が示されると、問題の原因を突き止めるために特定のプロファイルを使用可能にすることができます。これを行うには、管理コンソールに移動して次のようにナビゲートします。

ドメイン構造: ドメイン・サービス => データソース => (定義済データ・ソース) => 「診断」タブ

詳細は、標準のOracle WebLogic Serverのドキュメントで、特にWebLogic JDBCリソースのモニタに関する項を参照してください。

プロファイリングは有益な診断ツールですが、Oracle E-Business Suiteリリース12.2では、データ・ソース構成が長時間接続を維持するように明確に構成されています。つまり、プロファイリングが使用可能なときに収集されたすべてのオブジェクトは、接続が破棄されるまでメモリーに留まり、最終的にはOracle WebLogic Serverのメモリー不足エラーになります。

メモリー不足エラーが発生するまでにかかる時間は、次を含むいくつかの要因によります。

メモリー不足エラーの発生を最小限にするには、プロファイリングに対する次のガイドラインをお薦めします。

さらに、本番環境ではプロファイリングの代替ストラテジを考慮する必要があります。これらには、JDBCデバッグの有効化、またはWebLogic診断フレームワーク・ツールを使用した定期ダンプの取得が含まれます。

Oracle WebLogic Server管理ユーザー・パスワードの変更

Oracle WebLogic Server管理ユーザー・パスワードをデフォルト以外の値に設定するオプションは、Oracle E-Business Suiteのインストール中に使用できます。後でパスワードを変更する必要がある場合は、『Oracle Fusion Middleware管理者ガイド 11g リリース1』(11.1.1)、部品番号B60984-02の第3章にある管理ユーザー・パスワードの変更に関する項を参照してください。

既知の問題

この項では、Oracle E-Business Suiteリリース12.2の環境におけるAutoConfigに関連した構成管理での既知の問題を示します。