ヘッダーをスキップ

Oracle Fusion Middleware Adapter for Oracle Applications ユーザーズ・ガイド
11g リリース1 (11.1.1.6.0)
B61389-03		目次へ移動
目次 		前のページへ移動
前 		次のページへ移動
次

Adapter for Oracle Applicationsの概念

この章の構成は、次のとおりです。

アプリケーション・コンテキストについて

Oracle Applicationsとのインタフェースを起動するには、アプリケーションのコンテキストが必要です。アプリケーション・コンテキストは、「ユーザー名」、「職責」、「職責アプリケーション」および「セキュリティ・グループ」を組み合せたものです。これらの要素は、Oracle Applicationsとのインタフェースを正しく確立するために必要になることがあります。

複数の組織でのアプリケーション・コンテキスト

複数の組織と組織間のリレーションシップは、Oracle Applicationsの単一インストールで定義できます。これらの組織には、会計帳簿、ビジネス・グループ、法的エンティティ、営業単位または在庫組織があります。

各階層の最上位のビジネス・グループを使用して、複数レベルの組織階層を定義できます。新しい組織を定義すると、現在のセッションに関連付けられたビジネス・グループに自動的に割り当てられます。各組織はビジネス・グループに属しています。通常、ビジネス・グループは企業の組織図の最上部にあるボックスです。

ビジネス・グループ階層

図の説明は本文にあります。

複数組織の設定の例

次の図に示すように、複数レベルの会社構造を作成するには、Oracle Applicationsの会計、配布および資材管理の各機能を使用して、在庫組織、営業単位、法的エンティティおよび会計帳簿間のリレーションシップを定義します。

複数組織トランザクション

図の説明は本文にあります。

フランスの営業所とドイツの倉庫という、社内の2つの異なる組織を考えてみましょう。顧客からの発注トランザクションが存在します。この図は発注から搬送までの全体的なプロセスを示しています。

  1. 顧客がフランスの営業所に発注します。

  2. ドイツの倉庫が顧客へ製品出荷を行います。

  3. ドイツの倉庫がフランスの営業所に会社間請求書を発行します。

  4. フランスの営業所がドイツの倉庫に会社間支払を実行します。

  5. フランスの営業所が顧客に顧客請求書を送付します。

  6. 顧客がフランスの営業所に支払を実行します。

データベース・アーキテクチャは、複数組織インストールでも非複数組織インストールでも同じであり、標準のインストール・ツール機能が使用されます。この機能により、ベース製品表ごとにAPPSスキーマにシノニムが自動的に作成され、ベース製品表と同じ名前を使用してこれらのシノニムが定義されます。たとえば、PO OracleスキーマにはPO_HEADERS_ALLという名前の表があり、APPSスキーマには同じ名前の対応するシノニムPO_HEADERS_ALLがあります。PO_HEADERS_ALLシノニムを使用すると、パーティション化されていないデータにアクセスできます。

スキーマ・シノニム

図の説明は本文にあります。

営業単位別複数組織アクセス制御(MOAC)セキュリティ

システム・プロファイル値の設定時、ユーザー名と職責は組織単位または営業単位と関連付けます。

複数組織システム・プロファイル

図の説明は本文にあります。

ユーザーがアクセス権のある営業単位についてアクセス権を許可したりデータの報告を行ったりするためのセキュリティ保護された方法を設定するため、Oracle Applicationsの多くのインタフェースではMOACセキュリティ機能を使用して営業単位のアクセス権限を決定し、関連プロファイル値に基づいて組織IDを設定します。Adapter for Oracle Applicationsは必須のMOAC設定を暗黙的に実行できます。ORG_IDを渡すと、データのアクセスは渡されたOrganization IDに設定されます。

MOACでは、システム管理者はアクセス権限の範囲をセキュリティ・プロファイルに事前定義でき、その後、プロファイル・オプションMO: Security Profileを使用して、セキュリティ・プロファイルを職責に関連付けます。この方法を使用することにより、複数営業単位がセキュリティ・プロファイルと関連付けられ、そのセキュリティ・プロファイルが職責に割り当てられます。したがって、ユーザーはセキュリティ・プロファイルのアクセス制御を介して職責を変更することなく、複数営業単位のデータにアクセスできます。

セキュリティ・プロファイルは、組織階層に基づいて定義します。たとえば、アメリカとイギリスの営業単位で構成される販売会社があるとします。アメリカの販売会社には西部地域販売と東部地域販売があります。販売統括者はアメリカとイギリスの両方の販売に職責があり、管理者はアメリカまたはイギリスのいずれかに職責があり、販売担当は指定された販売地域にのみ職責があります。販売組織階層は次のようになります。

販売組織階層

図の説明は本文にあります。

会社内の販売データをセキュリティ保護するために、事前定義済のセキュリティ・プロファイルに関連営業単位を関連付けできます。たとえば、すべての販売データのアクセス権限がVision Salesセキュリティ・プロファイルにグループ化されています。アメリカ販売セキュリティ・プロファイルはアメリカ関連データ用に作成され、地域セキュリティ・プロファイルは指定地域データ用に作成されています。システム管理者は、複数の営業単位を含むこれらのセキュリティ・プロファイルを適切な職責を介してユーザーに関連付けることができます。したがって、販売管理者は、その職責を変更することなく東部または西部地域の販売データに容易にアクセスできます。次の図は、この販売会社のセキュリティ・プロファイル、職責および営業単位間の関係を示しています。

セキュリティ・プロファイル、職責および営業単位間の関係図

図の説明は本文にあります。

職責によって決まる営業単位

職責は、その関連付けられているセキュリティ・プロファイルが営業単位にリンクしているため、どの営業単位にアクセス権があるかは職責がキーとなって決まります。

  1. PL/SQL APIまたはコンカレント・プログラムを使用してOracle Applicationsと統合する場合、アプリケーションのコンテキストは、「ユーザー名」、「職責」、「職責アプリケーション」および「セキュリティ・グループ」の各ヘッダー・プロパティに渡される値に基づいて設定されます。

    注意: 下位互換性維持のため、「職責アプリケーション」、「セキュリティ・グループ」または「NLS言語」ヘッダー・プロパティが渡された場合を除いて、コンテキスト関連の例外またはエラーはスローされません。

  2. MOAC設定は、ユーザーが所属する「職責アプリケーション」に基づいて行われます。Organization IDを渡すと、組織のアクセスは渡された組織に設定されます。

  3. ユーザーが希望の言語でインタフェースを起動する必要がある場合は、ヘッダー・プロパティ「NLS言語」を渡すことができます。「NLS言語」のデフォルト値は、Oracle Applications内のユーザーのプリファレンスで指定された言語です。

ビジネス・プロセスをOracle Applicationsと統合する際には、これらのアプリケーション・コンテキスト値を、Adapter for Oracle Applicationsがヘッダー・プロパティを通じて提供する柔軟なメカニズムによって伝播することが重要です。

この項の内容は、次のとおりです。

正規化されたメッセージ・プロパティのサポート

BPELプロセスで必要なアプリケーション・コンテキスト値を効果的に設定したり、XML Gatewayインバウンド・トランザクションが正常に完了するために必須のヘッダー・プロパティを移入するために、Adapter for Oracle Applicationsには柔軟なメカニズムが備えられています。それぞれのコンテキスト値やヘッダー変数はこのメカニズムによって設定され、invokeアクティビティによってアダプタ・ユーザー・インタフェースに直接渡されます。このメッセージの正規化機能により、ヘッダー・サポート上の柔軟なソリューションが提供されるだけでなく、ヘッダー値を渡すときにassignアクティビティを使用しないことによって設計時タスクが簡易化されます。

アプリケーション・コンテキストのメッセージ・プロパティの設定

次のヘッダー・プロパティは、PL/SQLおよびコンカレント・プログラムのインタフェースでアプリケーションのコンテキストを設定するために使用します。

注意: 以前のリリースで使用されている既存のヘッダー・プロパティは、入力として「職責キー」および「職責名」を使用できるようになりました。ヘッダー・プロパティjca.apps.NLSLanguageが設定されており、かつ「職責名」が渡される場合、jca.apps.Responsibilityに渡される値は同じ言語で記述されていることが想定されます。ただし、「職責キー」およびその他のヘッダー・プロパティは言語非依存です。

アプリケーション・コンテキストを設定するために、これらのすべてのヘッダー・プロパティを同時に使用する場合があります。または、「ユーザー名」および「職責」のみを渡すと、以前のリリースと同様に処理されます。

NULLまたは空の値の場合は、デフォルトの「ユーザー名」は「SYSADMIN」、デフォルトの「職責」は「システム管理者」、デフォルトの「セキュリティ・グループ・キー」は「標準」およびデフォルトの「NLS言語」は「US」となります。

XML Gatewayインバウンド・トランザクションのメッセージ・プロパティの設定

XML Gatewayのインバウンド・トランザクションおよびエンキュー・トランザクションに必要なXML Gateway情報の設定には、次のヘッダー・メッセージ・プロパティが使用されます。

メッセージ・プロパティ・サポートの設計時タスク

Adapter for Oracle Applicationsでは、次の手順に従って、メッセージの正規化をサポートするための設計時タスクを完了します。

  1. BPELプロセスを使用した新しいSOAコンポジット・アプリケーションの作成

  2. パートナ・リンクの作成

  3. invokeアクティビティの構成

    このアクティビティでは、次のタスクを実行します。

複数組織アクセス制御(MOAC)のサポート

Adapter for Oracle Applicationsでは、Organization IDを、invokeアクティビティの「プロパティ」タブのjca.apps.ORG_IDとして設計時に使用可能なヘッダー・プロパティとして渡すことができます。

リリース12.0以降のOracle Applicationsでは、MOAC設定はMO_GLOBAL.INIT(<Application Name>)コールを使用して自動的に行われます。続いて、ORG_IDが渡された場合、組織による特定のORG_IDへのアクセスを設定するために、MO_GLOBAL.set_policy_context('S', <ORG_ID>)へのコールが行われます。

ヘッダー・メッセージ・プロパティの設定

図の説明は本文にあります。

「複数組織の設定の例」に示した例では、フランスの営業所で変更オーダーが処理されると、フランス営業所の営業マネージャがシステムにログオンしてオーダーを更新します。これにより、その変更に関するPL/SQL APIが起動します。ヘッダーに含まれる組織IDにプロパティ値(フランス営業所を表す207など)が割り当てられていれば、営業マネージャに関連付けられている組織IDがフランス営業所に設定され、APIの起動に使用されます。

複数言語のサポート

前に説明したメッセージの正規化機能およびOracle E-Business Suiteの複数言語サポート(MLS)機能を利用することにより、Adapter for Oracle Applicationsには、適切な言語を実行時に動的に設定できる包括的な言語サポート・メカニズムが備えられています。

「NLS言語」プロパティ値の優先

アプリケーション・ユーザーがAPIの実行中にシステムからトランザクション・データを取得したり、エラー・メッセージを受信すると、データやエラー・メッセージのセッション言語は次の条件に基づいて決定されます。

  1. 「NLS言語」の値は、ヘッダー・プロパティjca.apps.NLSLanguageを使用して設定できます。有効な言語の値が渡される(すなわち、言語がOracle E-Business Suiteインスタンスで有効化されている)場合、セッション言語は対応する言語に設定されます。

  2. 「NLS言語」ヘッダー・プロパティが渡されない場合は、セッション言語を設定するために、ユーザー作業環境に基づくユーザーのデフォルト言語が使用されます。

  3. ユーザーのデフォルト言語が見つからないか、または設定されていない場合、「NLS言語」(jca.apps.NLSLanguage)プロパティ値は「US」(アメリカ)に設定されます。

このメカニズムにより、適切なセッション言語が最初に「NLS言語」プロパティ値に基づいて実行時に動的に設定され、その後、ユーザーのデフォルト言語に基づいて設定されて、最後にデフォルトの「NLS言語」プロパティ値「US」によって決定されます。

jca.apps.NLSLanguageを使用した「NLS言語」プロパティ値の設定方法は、「正規化されたメッセージ・プロパティのサポート」を参照してください。

ユーザーのデフォルト言語の決定

データの問合せや取得にデータベース・セッションで使用されるデフォルトの言語を特定するために、Adapter for Oracle Applicationsは、ユーザー、職責、アプリケーションおよびサイトを含むすべてのレベルでICX: Languageプロファイル・オプションを調べます。どのレベルでも設定されていない場合、Adapter for Oracle Applicationsはデータベース・インスタンスのNational Language Support(NLS)パラメータからNLS_LANGUAGEパラメータをとります。セッションで初期化されているNLSパラメータは次のとおりです。

たとえば、デフォルト言語が日本語のユーザーがシステムにログインして、BPELプロセスのパートナ・リンクでユーザーが定義したAPIを実行してトランザクションを実行する場合、Adapter for Oracle Applicationsでは、最初に「NLS言語」プロパティ値が渡されているかどうかが検査されます。有効な言語が渡される場合、セッション言語は、デフォルト言語に関係なく、渡された値に基づいて設定されます。「NLS言語」プロパティが渡されない場合、Adapter for Oracle Applicationsでは、セッション言語がユーザー優先言語またはデフォルト言語に設定されます。それらの言語が見つからない場合、言語は「US」(アメリカ)となります。デフォルト言語はOracle Applicationsの「一般作業環境」ページで設定します。

注意: 「一般作業環境」ページで設定したデフォルト言語によって、ICX: Languageプロファイル・オプションが更新されます。

アプリケーション・コンテキストが設定されている場合、ユーザー作業環境(日付書式やタイムゾーンなど)が自動的に考慮される場合があります。

ユーザー・プリファレンス設定の詳細は、Oracle E-Business Suiteユーザーズ・ガイドの「Oracle E-Business Suiteスタート・ガイド」の章にあるプリファレンス設定に関する項を参照してください。

Adapter for Oracle Applicationsのセキュリティについて

セキュリティは、アプリケーション・コンテンツを不正アクセスから保護するように設計された、最も重要な機能です。Adapter for Oracle Applicationsでは、Oracleユーザー管理のセキュリティ・メカニズムを利用することにより、BPELプロセスを介して公開される、Oracle Applicationsを更新するAPIの実行を、認証済権限のあるユーザーのみに許可するセキュリティ機能を提供できます。この機能により、不正アクセスやセキュリティ・チェックなしの実行からApplication Program Interface(API)が保護されます。

ロールベースのアクセス制御(RBAC)を使用した機能セキュリティ

機能セキュリティは、Oracle Applicationsにおける基本的なアクセス制御です。システム内の個々のメニューとメニュー・オプションへのユーザー・アクセスを、行内にどのアプリケーション・データがあるかに関係なく制限します。APIは、Oracle Applicationsへのデータの挿入および更新を可能にするストアド・プロシージャであるため、機能セキュリティ・レイヤーにAPIへのアクセスを強制されるとき、実際に暗黙的にデータ・アクセスをアプリケーションに制限します。

データ・セキュリティは機能セキュリティ上に構築され、特定のデータ・レコードのセキュリティをモデリングまたは強制するためにセキュリティ制御の追加のレイヤーを提供します。言い換えると、データ・セキュリティは、アプリケーションのレコードへのアクセスのセキュリティをさらにデータ・レベルにまで細かくします。

セキュリティ制御に粒度を持たせ、APIの実行を正しい権限を持つ適切なユーザーのみに許可するようにするために、Adapter for Oracle ApplicationsではOracleユーザー管理のロールベースのアクセス制御セキュリティ(RBAC)を利用して、ユーザー・ロールを介することで機能セキュリティを強化します。ユーザーがAPIにアクセスできるかどうかは、ユーザーに付与されたロールで決まります。このアプローチはデータ・セキュリティと機能セキュリティを踏まえたものですが、その両方の範囲を超えた内容になっています。

ロールベースのアクセス制御を使用した機能セキュリティ

図の説明は本文にあります。

Oracle Adapter for Oracle Applicationsにおけるセキュリティのしくみについて理解を深めるため、このセクションには次のトピックが含まれています。

オーバーロードされた機能に対する機能セキュリティのサポート

Adapter for Oracle Applicationsで、オーバーロードされたPL/SQL APIのアクセス制御を扱う方法が提供されるようになりました。この機能は統合リポジトリのユーザー・インタフェースから作成された権限付与と連動し、どのプロファイル・オプションにも依存しません。

注意: このセキュリティ・サポートは、統合リポジトリ内で使用可能なすべてのインタフェースで機能します。その他のインタフェースについては、「プロファイル・オプションを介した機能セキュリティのサポート」で説明するプロファイル・オプションを使用して、機能セキュリティを有効にする必要があります。

このため、2つの新しいJCAプロパティが導入されています。

ユーザーが機能セキュリティ認可チェックの実行を希望する場合、次のプロパティ情報をWSDLファイル(XX_apps.jca)に追加する必要があります。

<property name="DataSecurityCheck" value="yes"/>

ただし、もう一方のプロパティIRepOverloadSeqは、設計時、パートナ・リンク作成中にAdapter for Oracle Applicationsによって自動的に導出されます。これらの2つのプロパティに基づき、ヘッダー・プロパティとして渡されるユーザー名に対して機能セキュリティ・チェックが実行されます。

統合リポジトリを介したセキュリティ権限付与の作成

オーバーロードされた機能に対するこのタイプのデータ・セキュリティ・チェックは、統合リポジトリのユーザー・インタフェースで作成されたセキュリティ権限付与と連動します。このセキュリティ権限付与を特定のインタフェース・タイプについて「付与の作成」ページで実行すると、メソッドを非常に粒度の高いレベルで制御できます。

統合リポジトリ管理者は、PL/SQL APIで1つ以上のメソッドを選択してから、選択したメソッドをユーザー、ユーザー・グループまたはすべてのユーザーが実行できるように、適切なセキュリティ権限付与を作成して認証できます。

統合リポジトリ内でのセキュリティ権限付与の作成

図の説明は本文にあります。

統合リポジトリのユーザー・インタフェースでは、インタフェースに含まれるオーバーロードされた機能はそれぞれ、「付与の作成」機能を使用して特定のユーザー、ユーザー・グループまたはすべてのユーザーに個別に付与できます。「プロシージャとファンクション」領域(または「メソッド」領域)で2つ以上のオーバーロードされた機能を選択した場合、「付与の作成」ページで選択したメソッドのテーブルに「過負荷」列が表示され、2つ以上のオーバーロードされた機能が付与用に選択されていることを示します。

統合リポジトリのユーザー・インタフェースを使用してセキュリティ権限付与を作成する方法の詳細は、Oracle E-Business Suite統合ゲートウェイ実装ガイドの「ネイティブ統合インタフェースとサービスの管理」の章にあるセキュリティ権限付与の管理に関する項を参照してください。

プロファイル・オプションを介した機能セキュリティのサポート

セキュリティ・アクセス制御は、ロールベースのアクセス制御セキュリティ(RBAC)における機能セキュリティに基づいてユーザー・ロールを介して定義され、ユーザーがAPIにアクセスできるかどうかがユーザーに付与されたロールで決まります。ロールは、ユーザーが特定の機能を実行するために必要な職責、権限、権限セットおよび機能セキュリティ・ポリシーを一元管理するように構成できます。これにより、ユーザー権限の一括更新が簡素化されます。新しい権限セットを自動継承するロールを使用することで、変更を実施できるためです。ジョブ機能に基づいて、各ロールに特定の権限(または必要な場合は権限セット)を割当てできます。たとえば、調達組織には「購買担当」ロール、「購買管理者」ロールおよび「購買サポート」ロールなどを組み込むことができます。「購買管理者」ロールには発注(PO)作成、発注変更および契約発注関連のAPIすべてを含む権限セットを組み込み、「購買担当」ロールや「サポート」ロールにはアクセス権限を与えないジョブ機能の実行をこのロールに許可するなどが可能です。

Adapter for Oracle Applicationsでは、Oracle Integration Repositoryにある注釈付きのAPIはFND_FORM_FUNCTIONS表に登録されており、機能セキュリティ(FND_FORM_FUNCTIONS)が適用可能です。これにより、各APIについて、セキュリティ保護された機能を作成できます。

Adapter for Oracle Applicationsでは、権限セットの概念を使用して、関連するAPIを1つの権限セット下にまとめ、順序付けできます。各権限セットを機能ロールに関連付け、セキュリティ権限付与を介してユーザーに割り当てることができます。

機能セキュリティの有効化

Adapter for Oracle Applicationsでは、このセキュリティ・サポートをオプション機能として提供しています。すべてのログイン・ユーザーがセキュリティ・チェックなしでAPIにアクセスし実行できるようにする場合は、「BPEL用EBSアダプタ、機能セキュリティ使用可能(EBS_ADAPTER_FUNCTION_SEC_ENABLED)」プロファイル・オプションを使用して、この機能を無効にできます。

注意: セキュリティ権限付与を作成することは容易で、どのプロファイル・オプションにも依存しないため、統合リポジトリにリストされたインタフェースに対して推奨する方法は、オーバーロードされた機能に前述の「DataSecurityCheck」を使用することです。

ユーザーがBPELプロセスを介してOracle E-Business Suite内のAPIを起動しようとした場合、機能セキュリティ・プロファイルが有効になっていると、API上で認証権限の検証が完了した後で初めてAPIが起動されます。

たとえば、BPELプロセスで公開されているPL/SQL APIに対するアクセス権限がユーザーにない場合、PL/SQL APIを起動しようとすると、BPELプロセスの実行は失敗します。認証済権限がなければ、機能セキュリティ検証例外メッセージが生成され、ユーザーにそのPL/SQL APIの権限がないことが示されます。

この機能の詳細は、My Oracle Support Knowledge Document 787637.1『Oracle Fusion Middleware Adapter for Oracle Applications, Release 11g』を参照してください。機能セキュリティおよびRBACセキュリティ・モデルの詳細は、Oracle E-Business Suite システム管理者ガイド - セキュリティを参照してください。

ユーザー・ロールを介したセキュリティ権限付与の作成

APIの起動を適切な実行権限のあるユーザーにのみ許可するようセキュリティ保護するため、Oracle Applicationsで次の手順を実行して、ユーザー・ロールを介してユーザーにセキュリティ権限付与を作成する必要があります。

  1. 権限セットの作成

  2. ユーザー・ロールの作成

  3. ロールを介したユーザーへの権限セットの付与

権限セットの作成

権限セットは、次の手順を使用して作成します。

  1. システム管理者の職責を使用してOracle E-Businessにログインします。

  2. 「ナビゲータ」から「アプリケーション・メニュー」を選択して「メニュー」ウィンドウにアクセスします。

  3. 次のメニュー情報を入力します。

  4. 「順序」と「機能」の値を入力して、この権限セットにグループ化する機能をすべて追加します。

    1. 「順序」フィールドに入力します。

    2. 「機能」の列で、この権限セットに割り当てる機能を検索します。

      「機能」ウィンドウで検索を実行して機能名を選択します。たとえば、パブリックPL/SQL API検索の構文は、PLSQL:<package name>:<procedure name>です。「検索」フィールドに%PLSQL:OE%と入力し、「検索」をクリックして検索を実行します。

      機能の検索

      図の説明は本文にあります。

      コンポジット・アプリケーションに基づいて機能を選択し、BPELプロセスまたはMediatorから起動するAPIに権限を付与します。

      たとえば、受注明細変更のBPELプロセスの場合は、受注変更PL/SQL APIに含まれている受注明細変更関連の機能を選択して権限セットとしてグループ化し、ロールを介して該当するユーザーにその権限セットを付与します。

      関連項目: ユーザー・ロールの作成

      権限セット・メニュー

      図の説明は本文にあります。

  5. 権限セットを保存します。

ユーザー・ロールの作成

権限セットはユーザー・ロールを介して付与されます。したがって、最初にロールを作成してからユーザーにそのロールを割り当てる必要があります。

ユーザー・ロールは、次の手順を使用して作成します。

  1. ユーザー管理職責を使用してOracle E-Businessにログインします。

  2. 「ナビゲータ」から「ロールおよびロール継承」を選択し、「ロールおよびロール継承」ページにアクセスします。

  3. 「ロールの作成」をクリックして、「ロールの作成」ページにアクセスします。

  4. 次の情報を入力してユーザー・ロールを作成します。

  5. 情報を保存して「付与の作成」をクリックします。

  6. 「付与の作成: 付与の定義」ページに次の情報を入力します。

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

  8. 「付与の作成: オブジェクト・パラメータの定義およびセットの選択」ページで、「権限セットの作成」項で作成した権限セットを選択し、「次」をクリックします。

  9. 「終了」をクリックします。

ロールを介したユーザーへの権限セットの付与

ロールを介してユーザーに権限セットを付与するには、次の手順を使用します。

  1. ユーザー管理職責を使用してOracle E-Businessにログインします。

  2. 「ナビゲータ」から「ユーザー」を選択して「ユーザー保守」ページにアクセスします。

  3. ロールを割り当てるユーザーを検索して「移動」をクリックします。

  4. ロールを割り当てるユーザー名の隣にある「更新」アイコンを選択します。

  5. 「ユーザーの更新」ページで「ロールの割当」をクリックすると「検索」ウィンドウが移入され、以前に作成したロールが検索できます。

  6. ロール(EBS_ADAPTER_ROLEなど)を選択して更新内容を保存します。

ロギング

Oracle Fusion Middleware Adapter for Oracle Applicationsでは、Oracle SOA Suiteのロギング・フレームワークを実装し、診断ログ・ファイルをテキスト形式で記述します。したがって、Oracle Adapter for Oracle Applicationsを使用してOracle E-Business Suiteサービスを起動すると、必ずシステム管理者がアクセスできるログ・メッセージが記録されます。これによって、問題の識別メカニズムが強化され、Oracle Adapter for Oracle Applicationsの実行時に、サービスを起動する際の問題を追跡できるようになります。

Oracle Adapter for Oracle Applicationsおよびテクノロジ・アダプタは、JCAバインディング・コンポーネントのLogManagerインタフェースを実装し、これによって、インバウンドとアウトバウンドの両方の相互作用のログ・ファイルがOracle Diagnostic Logging(ODL)形式でsoa-diagnostic.logファイルにリダイレクトされます。これらのログ・ファイルは、すべてのタイプのイベント(起動と停止の情報、エラーと警告メッセージ、HTTPリクエストへのアクセス情報、追加情報など)を記録します。これによって、発生する可能性のある問題を管理者が効率的に特定して解決するために役立つ、起動プロセスについてのインサイド・アウトのクイック・ビューが表示されます。Oracle Enterprise Manager Fusion Middleware Controlコンソールで適切なログ・レベルを構成すると、Oracle Adapter for Oracle Applicationsおよびテクノロジ・アダプタの実行時に単一ファイルに書き込まれたODLレベルのログ・ファイルを表示できます。

ロギング・メカニズムがどのように動作するかについては、この章の次の項で説明します。

SOA Suiteの詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

アダプタのロギングの有効化

Oracle Adapter for Oracle Applicationsとテクノロジ・アダプタのすべてのログは、soa-diagnostic.logファイルにOracle Diagnostic Logging(ODL)形式でリダイレクトされます。Oracle Adapter for Oracle Applicationsのログを表示できるようにするには、Oracle Enterprise Manager Fusion Middleware Controlコンソールを使用して、適切なメッセージ・タイプとそれに関連付けられたログ・レベルをログ出力oracle.soa.adapter用に設定し、有効にする必要があります。これによって、Oracle SOA Suiteレベルでログ設定が有効になります。

注意: ログ出力構成は$FMWHOME/user_projects/domains/soainfra/config/fmwconfig/servers/soa_server1/logging.xmlにあり、すべてのOracle JCAアダプタに対応するログ出力名はoracle.soa.adapterと呼ばれます。

次の表に、診断メッセージ・タイプとログ・レベルを示します。

注意: 各メッセージ・タイプで、メッセージ・レベルに設定できる値は1(重大度が最も高い)から32(重大度が最も低い)です。各メッセージ・タイプに一部のレベルだけがサポートされているコンポーネントもあります。一般に、タイプだけで指定する必要があり、レベルを指定する必要はありません。

各ログ出力のデフォルトのメッセージ・タイプは、NOTIFICATION、レベル1に設定されています。

メッセージ・タイプ レベル 説明
INCIDENT_ERROR 1 製品の不具合によって発生し、Oracleサポートに報告する必要のある深刻な問題。
たとえば、リカバリ不能なエラーなどの深刻な問題があります。
ERROR 1 管理者が注意する必要があるが、製品の不具合によって発生するものではない深刻な問題。
Oracle Fusion Middlewareではログ・ファイルを処理できないが、ドキュメントに対する権限を修正することで問題を解決できる場合などが、これに該当します。
WARNING 1 管理者による確認を要する、潜在的な問題。
NOTIFICATION 1 プライマリ・サブコンポーネントや機能のアクティブ化や非アクティブ化などの主要なライフサイクル・イベント。
NOTIFICATION 16 通常のイベントをレポートする粒度の詳細なレベル。
TRACE 1 パブリックAPIエントリや終了ポイントなど、管理者に重要なイベントに関するトレースまたはデバッグ情報。
TRACE 16 特定のサブシステムにおける問題を診断するためにOracleサポート・サービスが利用できる詳細トレース情報または詳細デバッグ情報。
TRACE 32 特定のサブシステムにおける問題を診断するためにOracleサポート・サービスが利用できるきわめて詳細なトレース情報またはデバッグ情報。

SOA SuiteでOracle Adapter for Oracle Applicationsに診断メッセージ・タイプとログ・レベルを設定する手順:

次の手順に従って、メッセージ・タイプとそれに関連付けられたログ・レベルを設定します。

  1. http://<servername>:<portnumber>/emに移動します。

    Oracle Enterprise Manager Fusion Middleware Controlコンソールのホーム・ページが表示されます。

  2. ユーザー名とパスワードを入力して、コンソールにログオンします。

  3. 「ナビゲータ」ツリーで「SOA」フォルダの「soa-infra」を右クリックします。

  4. ポップアップ・メニューから「ログ」>「ログ構成」を選択します。

    注意: SOAインフラストラクチャ」メニューをクリックして、ドロップダウン・メニューから「ログ」>「ログ構成」を選択しても、「ログ構成」ページにアクセスできます。

    図の説明は本文にあります。

    ログ出力のリストを表示でき、ログ・ファイルに書き込む情報の量と種類、およびログ・レベル状態を設定するためのOracle Diagnostic Logging(ODL)レベルを構成できる「ログ構成」ページが開きます。

    アダプタのログ・レベルの構成

    図の説明は本文にあります。

  5. 「ログ・レベル」タブを選択します。

  6. 「表示」ドロップダウン・リストから次のいずれかの値を選択します。

    注意: デフォルトでは、ログ・レベルはランタイム出力用に設定されています。ランタイム出力は、コンポーネントを再起動するとリセットされます。コンポーネントを再起動してもログ・レベルが保持されるようにするには、「表示」リストから「永続ログ・レベル状態のログ出力」を選択します。

  7. oracle.soaノードを展開し、「ログ出力名」リストでoracle.soa.adapterランタイム・ログ出力を検索します。Oracle Diagnosticの「ログ・レベル」ドロップダウン・リストからログ出力レベルを選択します。たとえば、「TRACE:32 (FINEST)」を選択します。

  8. 「適用」をクリックします。

「ログ・ファイル」タブでのログ・ファイルの作成と編集

「ログ・ファイル」列に表示されるログ・ヘッダー・リンクをクリックして、特定のログ・ファイルを編集できます。基本的な構成設定や詳細なログ設定を構成できる「ログ・ファイル」タブが開きます。これらの設定には、ハンドラ名、ログ・メッセージが記録されるログ・ファイル、ログ・メッセージの処理機、使用されるローテーション・ポリシー、ログ・ファイル構成クラスに基づくその他のパラメータが含まれます。

たとえば、表からログ・ハンドラを選択し、「構成の編集」を選択します。「ログ・ファイルの編集」ダイアログ・ボックスが表示されます。

ログ・ファイルの構成方法の詳細は、see the Managing Log Files and Diagnostic Data Chapter, 『Oracle Fusion Middleware管理者ガイド』の「ログ・ファイルと診断データの管理」の章を参照してください。

SOA Suiteの詳細は、『Oracle Fusion Middleware Oracle SOA Suite管理者ガイド』を参照してください。

oracle.soa.adapterランタイム・ログ出力を使用した、PL/SQL APIおよびコンカレント・プログラム用の自動FNDロギング

Oracle SOA Suiteのoracle.soa.adapterランタイム・ログ出力に設定されたログ・レベルに基づき、ランタイム実行時にPL/SQL APIおよびコンカレント・プログラムのインタフェースが起動されている間、これらのインタフェースのロギングを自動的に制御または有効化できます。Oracle E-Business Suite側でFNDロギング・フレームワークを別途有効化する必要はありません。

注意: この自動FNDロギングを使用できるのは、Oracle E-Business Suiteリリース12.1.3以上のみです。

oracle.soa.adapterランタイム・ログ出力と、対応するOracle E-Business Suiteのログ・レベルのマッピングを次の表に示します。

ランタイム・ログ出力oracle.soa.adapterのログ・レベル Oracle E-Business Suiteのログ・レベル
INCIDENT_ERROR LEVEL_UNEXPECTED
ERROR LEVEL_ERROR
WARNING LEVEL_EXCEPTION
NOTIFICATION 1, 16, 32 LEVEL_EVENT
TRACE 1 LEVEL_PROCEDURE
TRACE 16, 32 LEVEL_STATEMENT

アダプタ・ログの検索と表示

Oracle Adapter for Oracle Applicationsとテクノロジ・アダプタは、JCAバインディング・コンポーネントのLogManagerインタフェースを実装し、Oracle Diagnostic Logging(ODL)フォーマットで実行時に単一ファイルに書き込まれたログ・ファイルがリダイレクトされます。

アウトバウンドとインバウンドの両方の相互作用で、ログ・ファイルは単一ファイルsoa-diagnostic.logにリダイレクトされます。

server-soa管理対象サーバーにデプロイされたOracle SOA Suiteのログ・ファイルは、MW_HOME/user_projects/domains/<domain_name>/servers/server-soa/logs/soa-diagnostic.logに格納されます。

Oracle Adapter for Oracle Applicationsログ・ファイルを検索して表示するには、Oracle Enterprise Manager Fusion Middleware Controlコンソール、WLST displayLogsコマンドライン・ツールを使用するか、またはローカル・クライアントにログ・ファイルをダウンロードして、別のツール(テキスト・エディタや別のファイル表示ユーティリティなど)を使用して表示します。WLSTコマンドライン・ツールを使用してログ・ファイルを検索して表示する方法の詳細は、『Oracle Fusion Middleware管理者ガイド』の「ログ・ファイルおよび診断データの管理」の章を参照してください。

Oracle Enterprise Manager Fusion Middleware Controlコンソールを使用したアダプタ・ログの検索と表示手順

次の手順を使用して、Oracle Enterprise Manager Fusion Middleware Controlコンソールからアダプタ・ログを検索します。

  1. http://<servername>:<portnumber>/emに移動します。

    Oracle Enterprise Manager Fusion Middleware Controlコンソールのホーム・ページが表示されます。

  2. ユーザー名とパスワードを入力して、コンソールにログオンします。

  3. 左側のペインにある「ナビゲータ」ツリーから「ログ・メッセージ」ページにアクセスするには、次の2つの方法があります。

    ポップアップ・メニューから「ログ」>「ログ・メッセージの表示」を選択します。「ログ・メッセージ」ページに、「検索」セクションとデフォルトの検索基準が表示されたメッセージのサマリーが表示された表が表示されます。

    「ログ・メッセージ」ページ: 検索

    図の説明は本文にあります。

  4. Oracle Adapter for Oracle Applicationsのログ・メッセージを検索するための検索基準を入力します。

  5. 「検索」をクリックして、検索を実行します。検索基準に一致するすべてのメッセージが検索され、表に表示されます。これらのメッセージはメッセージとして表示することも、「表示」フィールドで選択した値に応じて、メッセージ・タイプやメッセージIDごとにグループ分けすることもできます。

    図の説明は本文にあります。

  6. 表からいずれかのログ・メッセージをクリックします。メッセージ・レベル、コンポーネント、ECID(Execution Context ID)、関係ID、実際のメッセージなどのメッセージの詳細がメッセージ表の下に表示されます。

    「ECID」リンクをクリックすると、「ECIDごとの関連メッセージ」ページに同じECIDを持つ関連メッセージが検索されます。関連メッセージの詳細は、「ログ・ファイルとコンポーネント間のメッセージの関連付け」を参照してください。

  7. ログ・メッセージをOracle Diagnosticログ・テキスト・ファイル(.txt)、XMLファイル(.xml)またはカンマ区切りリスト(.csv)ファイルとしてエクスポートする場合は、「メッセージをファイルにエクスポート」ドロップダウン・リストから適切な出力オプションを選択します。

  8. 「ターゲット・ログ・ファイル」をクリックして、管理対象サーバー(server-soa)に関連するログ・ファイルのリストが表示される「ログ・ファイル」ページを開きます。

    「ログ・ファイル」ページ

    図の説明は本文にあります。

    1. ファイルを選択して「ログ・ファイルの表示」をクリックします。選択したログ・ファイルの「ログ・ファイルの表示」ページが表示され、このログに含まれるメッセージのリストを表示できます。

      「ログ・ファイルの表示」ページ

      図の説明は本文にあります。

    2. メッセージの詳細を表示するには、メッセージを選択します。メッセージ・レベル、コンポーネント、ECID、関係ID、実際のメッセージなどのメッセージの詳細が、メッセージ表の下に表示されます。

    3. 時間またはECIDを基準にして関連メッセージを表示するには、「関連メッセージの表示」をクリックして、「時間ごと」または「ECID(実行コンテキストID)ごと」を選択します。

      または、メッセージの詳細から「ECID」リンクを直接クリックしても、「ECIDごとの関連メッセージ」ページに同じECIDを持つ関連メッセージを検索できます。

ログ・ファイルとコンポーネント間のメッセージの関連付け

Oracle Fusion Middlewareコンポーネントは、診断メッセージにメッセージ相関情報を提供します。メッセージ相関情報は、診断メッセージを表示したユーザーがコンポーネント間のメッセージの関係を判定する際に役立ちます。診断メッセージのそれぞれに、実行コンテキストID(ECID)と関係IDが組み込まれています。

ECIDは、特定のリクエストの実行に関連付けられたグローバルに一意の識別子です。ECIDは、リクエストが最初に処理されるときに生成されます。関係IDは、同じリクエストのかわりに、あるプロセスの1つのスレッドで実行された作業と、このプロセスまたは他のプロセスの別のスレッドで実行された作業を区別します。

Oracle Enterprise Manager Fusion Middleware Controlコンソールにログ・メッセージを表示した状態で、ログ・メッセージを選択した後、「関連メッセージの表示」ドロップダウン・リストから次のいずれかの値を選択すると、関連するメッセージを表示することができます。

注意: 「関連メッセージの表示」は、検索基準に基づいて一致するすべてのメッセージを表示している状態で、「表示」フィールドで「メッセージ」 が選択されているときだけ選択できます。「表示」フィールドで「メッセージ・タイプ別グループ」または「メッセージID別グループ」が選択されていると、一致するすべてのメッセージがメッセージ・タイプまたはメッセージIDごとにグループ分けされて表示されます。この場合、「関連メッセージの表示」フィールドは使用できません。

メッセージの関連付け情報を使用して関連メッセージを検索して、複数のメッセージを調査し、最初に問題が発生したコンポーネントを識別できます。メッセージ相関データは、コンポーネント間で診断メッセージのクリア・パスを確立する際に役立ち、これによって、エラーおよびそれに関連した動作を理解できます。

エラーおよび例外処理の拡張

Business Suiteインタフェースの起動中に発生する可能性のある問題またはエラーの根本原因を特定するため、Adapter for Oracle Applicationsでは、わかりやすく説明的な例外やエラー・メッセージを生成するようになりました。これらは特に、任意のPL/SQL APIまたはコンカレント・プログラムの起動中に使用できます。

アダプタの前処理中、およびデータベース・アダプタやAQアダプタによるランタイム実行中にエラーを処理するほか、PL/SQL APIが生成した機能エラーを、取得するために追加のコールを行う必要なくいつでも取得できます。これらのメッセージにより、ランタイムにおける障害の原因を特定しやすくなります。

さらに、他のJCAアダプタによって使用されている共通ロギング・フレームワークに基づき、Adapter for Oracle Applicationsに関するすべてのエラーと例外およびデバッグ情報がロギングされます。これにより、実行中に発生したことを管理者や開発者が把握し、問題解決に必要な行動を取りやすくなります。

機能エラーの処理

Adapter for Oracle Applicationsでサポートされている統合インタフェースの起動中に問題やエラーが発生した場合(OE_ORDER_PUB.CHANGE_ORDER APIの起動時に入力した注文番号が存在しないなど)、例外(ORA-20100: 注文番号が存在しません)がスローされ、このようなエラーに機能エラーが含まれます。このタイプの例外は、API実行中の機能的な問題な問題を報告するために幅広く使用されます。

ほとんどのPL/SQL APIでは、機能エラーはAdapterのランタイム・エンジンによって捕捉されたSQLExceptionとして、コードとメッセージとともに、あるいはAPI出力パラメータの一部としてスローできます。しかし、一部のPL/SQL APIは実行中に機能エラーをスローせず、メモリ・スタックに蓄積し続けます。エラーをフェッチする責任は、APIのコール元に繰延べられます。

たとえば、HRMS APIは、FND_MSG_PUB.putパッケージを使用して、FND_MESSAGEスタックに機能エラーを配置します。APIコールが完了したら、コール元はFND_MSG_PUB.GET()メソッドを使用して、このスタックから明示的にエラーをフェッチする必要があります。

注意: このリリースでは、エラー・メッセージはスタックFND_MSG_PUBからのみ取得できます。

明示的な処理が必要なAPI用には、APIErrorHandlerという新しいJCAプロパティが導入され、FND_MESSAGEメモリ・スタックから機能エラーをフェッチできるようになりました。このプロパティがエラーのフェッチ用インジケータとして機能することで、コール元は明示的に取得するためのコールを行う必要なくエラーを取得できます。ランタイム実行時、Adapter for Oracle ApplicationsはJCAプロパティAPIErrorHandlerの存在をチェックします。存在する場合、PL/SQL APIの実行直後にエラー・ハンドラが呼び出されます。

このようなAPIの機能エラーをフェッチするには、次の機能エラー処理パラメータをWSDLファイル(XX_apps.jca)に追加する必要があることに注意してください。

<property name="APIErrorHandler" value="FND_MSG_PUB.GET_DETAIL"/>

J2EEデータ・ソースの実装を使用したOracle E-Business SuiteとOracle Fusion Middleware SOA Suite間の保護された接続

Oracle E-Business SuiteとOracle SOA Suite間の保護された接続に対してJ2EEデータ・ソースを実装することには、2つの明確な利点があります。1つ目は、AppsまたはAppsと同等のスキーマのユーザー名やパスワードを必要としないOracle E-Business Suiteのアプリケーション・データベースに対して、FNDユーザー名/パスワード(Oracle Applicationsのユーザー名とパスワードの概念)のみを使用して、安全に接続できることです。2つ目は、パスワードがミドルウェアに保存されないことです。これにより、セキュリティ上のリスクが取り除かれるだけでなく、パスワードをOracle E-Business SuiteとSOA Suite間で同期して保持する必要がありません。

Oracle Adapter for Oracle Applicationsでは、新しいメカニズムを使用して実行時にユーザーを認証し、J2EEデータ・ソースを使用してOracle E-Business Suiteデータベースに接続します。この方法は、アプリケーション・データベースにアクセスするために接続プールを定義することが、Oracle E-Business Suite固有です。

この新しいメカニズムにより、データベース接続の構成の一環として必要なアプリケーション・ログインのユーザー名およびパスワードなどのアカウントの詳細情報が、J2EEデータ・ソース作成時に入力パラメータとしてdbcファイルの位置とともに追加されます。

このプロセスを完了するため、次の手順を使用してOracle E-Business SuiteデータベースへのJ2EEデータ・ソース接続を定義します。

  1. Oracle E-Business Suite環境にサービス指向アーキテクチャ(SOA)スイート中間層ノードを登録し、接続をインスタンス化するためのデータ・ソース実装で使用されるdbcファイルを生成します。

  2. SOAスイート・サーバーが稼動する中間層サーバーにdbcファイルをコピーし、SOAスイートの所有者がアクセス権を持つファイル・システム上の場所に配置します。

  3. 接続プールを作成します。ここには、コネクション・ファクトリのプロパティとしてアプリケーションのログイン・ユーザー名、パスワードおよびdbcファイルの場所を入力する必要があります。

  4. アプリケーション・データ・ソースを作成します。この手順では、Oracle Adapter for Oracle Applicationsのアプリケーション・データベース接続のために、アプリケーション・データ・ソースをJava Naming and Directory Interface(JNDI)名と関連付けます。

J2EEデータ・ソース機能を使用したネイティブOracle E-Business Suite接続機能を使用するには、

注意: この機能を使用可能にするには、最小限の要件として、Oracle E-Business Suiteリリース11iは11i.ATG_PF.H.Delta.6(RUP6)であり、Oracle E-Business Suiteリリース12は12.0.4リリースであることが必要です。

または、Oracle E-Business Suiteと外部アプリケーション・サーバー間の接続を有効化するのに必要なパッチを適用する必要があります。詳細は、My Oracle Support Knowledge Document 787637.1『Oracle Fusion Middleware Adapter for Oracle Applications, Release 11g』を参照してください。

Oracle Applicationsモジュール・ブラウザについて

Oracle Applicationsモジュール・ブラウザは、Adapter for Oracle Applicationsの主要なコンポーネントです。Oracle Integration Repositoryを介して使用できるインタフェース以外に、Adapter for Oracle Applicationsを使用すると、ビジネス・イベントおよびビジネス・イベント・グループ、カスタムPL/SQL API、カスタムXML Gatewayマップおよび選択したコンカレント・プログラムを使用できますが、これらはすべて、Oracle Applicationsモジュール・ブラウザを使用して参照できます。

パートナ・リンクの定義に必要なインタフェースを選択するには、モジュール・ブラウザを使用します。次のように使用して、目的のインタフェースを見つけることができます。

インタフェースの検索

目的のインタフェース名またはワイルドカード文字を含む部分値を「オブジェクト名」フィールドに入力し、「検索」をクリックして、目的のインタフェースをModule Browser上で見つけます。

Oracle Applicationsモジュール・ブラウザを介したインタフェース検索

図の説明は本文にあります。

ツリー構造を介したインタフェース参照

モジュール・ブラウザは、Oracle統合リポジトリからのインタフェース・データを、Adapter for Oracle Applicationsでサポートされるその他のインタフェースに関する情報と組み合せます。

ツリー構造の展開によるインタフェース参照

図の説明は本文にあります。

サポートされているインタフェースは、次のようなツリー階層に整理されます。

ProductFamilies
 |-[product_family]
 |  |-[product]
 |     |-[business_entity]
 |        |-XML Gateway ([n])
 |        |-EDI ([n])
 |        |-PLSQL ([n])
 |        |  |-[package_name]
 |        |-OpenInterfaces ([n])
 |           |-[OpenInterface_name]
 |              |-Tables ([n])
 |              |-Views ([n])
 |              |-ConcurrentPrograms ([n])
 |-Other Interfaces
    |-Business Events
       |-Inbound
       |-Outbound
          |-Groups
            |-[business event name]
    |-Custom Objects
       |-PLSQL APIs
       |  |-[package_name]
       |-XMLGateway Maps
          |-Inbound
          |-Outbound

製品ファミリによるインタフェース参照

Oracle Integration Repositoryインタフェース・データは、[product_family]セクションを移入し、所属する製品およびビジネス・エンティティに従ってグループ化します。

製品ファミリによるインタフェース参照

図の説明は本文にあります。

「その他インタフェース」以下でのビジネス・イベントとカスタム・インタフェースの参照

ビジネス・イベントとカスタム・インタフェースは、「その他インタフェース」ノードの下に表示されます。

その他インタフェースの参照

図の説明は本文にあります。

目次   |   前   |   ページの先頭   |   次

Oracleロゴ
Copyright © 2005, 2011, Oracle and/or its affiliates.All rights reserved.