ヘッダーをスキップ

Oracle Fusion Middleware Adapter for Oracle Applicationsユーザーズ・ガイド
11g リリース1（11.1.1）
B61389-01		目次へ
目次		戻る
戻る		次へ
次へ

Adapter for Oracle Applicationsの概念

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

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

アプリケーション・コンテキストは、Oracle Applicationsとの安全なトランザクション処理のために必要です。

アプリケーション・コンテキストは、「ユーザー名」、「職責」、「職責アプリケーション」、「NLS言語」、「セキュリティ・グループ」および「組織ID」を組み合せたものです。これらの要素は、ビジネス・アクティビティで必要となったり、BPELプロセスを完了するのに必要となる値を渡すときに使用されます。

アプリケーション・コンテキストを設定するために、Oracle Applications設定データから組織IDが暗黙的に導出されます。

アプリケーション・コンテキストを理解するには、まず組織IDと複数の組織がどのように関連しているかを理解する必要があります。

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

複数の組織と組織間のリレーションシップは、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）セキュリティ

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

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

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

アクセス権のある営業単位のデータにアクセスまたはレポートするのみのユーザーにセキュリティ保護された方法を設定するため、Adapter for Oracle Applicationsでは、MOACセキュリティ機能を使用して営業単位のアクセス権限を決定し、関連プロファイル値に基づいて組織IDを設定します。

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

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

販売組織階層

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

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

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

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

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

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

次の図は、Oracle Applicationsが複数組織環境でプロファイル・オプションをどのように使用するかを示しています。

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

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

  1. システム・インテグレータが実行されると、プロセスがPL/SQL APIを使用してOracle Applicationsとの統合を実行します。

  2. アプリケーション・コンテキストは、「ユーザー名」、「職責」、「職責アプリケーション」、「セキュリティ・グループ」および「NLS言語」の各ヘッダー・プロパティに渡される値を考慮して設定されます。新しいヘッダー・プロパティ「職責アプリケーション」、「セキュリティ・グループ」および「NLS言語」の値が渡されない場合、コンテキスト情報は「ユーザー名」と「職責」に基づいて判断されます。

  3. これらのパラメータを使用して、その職責に割り当てられたシステム・プロファイル値の参照が行われ、複数組織環境内での営業単位が決定されます。

  4. 営業単位は、セキュリティ・プロファイル値から生成されたシステム・プロファイル値の組織IDとしてモデル化されます。

  5. 「ユーザー名」、「職責」、「職責アプリケーション」、「セキュリティ・グループ」、「NLS言語」および「組織ID」の各パラメータを使用して、Oracle Applicationsとの間でデータの読取りと書込みが行われます。

ビジネス・プロセスを統合したり、BPELプロセスを起動する場合は、BPELプロセスを完了し、統合ニーズが満たされるように、個別のコンテキスト値をそれぞれ必要に応じて効果的に設定して渡すことができる柔軟なメカニズムを使用して、これらのアプリケーション・コンテキスト値やメッセージを伝播することが重要です。

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

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

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

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

次のヘッダー・メッセージ・プロパティは、ビジネス・アクティビティに必要であったりBPELプロセスを完了するのに必要なアプリケーション・コンテキストを設定するのに使用されます。

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

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

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

「NLS言語」および「組織ID」のプロパティ値は、アプリケーション・コンテキストをサポートするためのメッセージの正規化に含まれているため、Adapter for Oracle Applicationsでは、アプリケーション・コンテキストの概念に基づく次の機能もサポートされています。

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

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

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

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

注意: 実行時、XML Gatewayのメッセージ・プロパティはAQアダプタを起動する前に処理する必要があります。

  1. 新規BPELプロジェクトの作成

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

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

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

複数組織設定のサポート

複数組織設定をサポートするために、Adapter for Oracle Applicationsでは、Oracle Applications設定時に組織情報をプロファイル値から暗黙的に導出するかわりに、メッセージの正規化機能に基づいて設計時にinvokeアクティビティの「プロパティ」タブを使用して組織ID情報を直接入力できます。

Adapter for Oracle Applicationsでは、ヘッダー・プロパティを使用して「ユーザー名」、「職責」、「職責アプリケーション」、「NLS言語」、「セキュリティ・グループ」および「組織ID」を組み込みます。これらはアプリケーション・コンテキストに不可欠な要素です。PL/SQL APIまたはアプリケーション・コンテキストの設定を必要とするインタフェースを介してビジネス・アクティビティ用のヘッダーに含まれるメッセージ・プロパティを設定すると、ヘッダー内のこれらの値がBPELプロセスの残りのアクティビティに渡されて、入力として使用されます。

注意: アプリケーション・コンテキストの設定を必要とする統合インタフェース・タイプは、PL/SQL API、コンカレント・プログラムおよびEDIプログラムです。

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

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

このヘッダー・メッセージ・プロパティのメカニズムを複数組織設定のサポートに使用するメリットは、組織ID値がヘッダーで指定されている場合に、1つの単一BPELプロセスのみで組織情報をOracle E-Business Suite内の複数の組織に容易に配置できることです。以前のリリースでは、組織IDはアプリケーション・ログオン・ユーザーのユーザー名と職責に基づいてプロファイル値から暗黙的に導出されていたため、挿入できるのはデプロイ済BPELプロセスの起動に関連した組織のみでした。

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

注意: Oracle E-Business Suiteリリース12では、「組織ID」がその他のアプリケーション・コンテキスト要素とともに自動的にヘッダーに追加されます。リリース11.5.10の場合、ヘッダーに「組織ID」を表示するには、Oracle Applicationsインスタンスに11i.ATG_PF.H.delta.5（RUP5）（パッチ5473858）を適用する必要があります。

複数言語のサポート

前に説明したメッセージの正規化機能および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: 言語」プロファイル値が検査されます。このプロファイルがどのレベルでも設定されていなければ、データベース・インスタンスの各国語サポート（NLS）パラメータからNLS_LANGUAGEパラメータが使用されます。セッション中に初期化されるNLSパラメータは、次のとおりです。

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

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

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

ユーザー作業環境の設定方法は、『Oracle Applicationsユーザーズ・ガイド』の「Oracle Applicationsのスタート・ガイド」、作業環境の設定に関する項を参照してください。

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

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

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

注意: この機能の詳細は、My Oracle Support Knowledge Document 787637.1『Oracle Fusion Middleware Adapter for Oracle Applications, Release 11g』を参照してください。

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

Adapter for Oracle Applications対応の機能セキュリティ

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

APIの実行を正しい権限を持つ適切なユーザーに許可するようにするために、Adapter for Oracle ApplicationsではOracleユーザー管理のロールベースのアクセス制御セキュリティ（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つの権限セット下にまとめ、順序付けできます。各権限セットを機能ロールに関連付け、セキュリティ権限付与を介してユーザーに割り当てることができます。ユーザーがOracle E-Business SuiteにログインしてBPELプロセスで公開されているAPIにアクセスしようとすると、セキュリティ機能が有効になっている場合は機能セキュリティAPIが起動され、そのユーザーが、そのAPIの実行権限を持つことが認証されるユーザーであるかどうかが検証されます。

たとえば、BPELプロセスで公開されているPL/SQL APIに対するアクセス権限がユーザーにない場合、PL/SQL APIを起動しようとすると、BPELプロセスの実行は失敗します。

認証済権限がなければ、機能セキュリティ検証例外メッセージが生成され、ユーザーにそのPL/SQL APIの権限がないことが示されます。

機能セキュリティとRBACセキュリティ・モデルの詳細は、『Oracle Applicationsシステム管理者ガイド - セキュリティ』を参照してください。

セキュリティ権限付与の作成

APIの起動を適切な実行権限のあるユーザーにのみ許可するようセキュリティ保護するため、Adapter for 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プロセスに基づいて機能を選択し、BPELプロセスから起動する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など）を選択して更新内容を保存します。

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

Oracle E-Business SuiteとOracle SOA Suite間の保護された接続に対してJ2EEデータ・ソースを実装することには、2つの明確な利点があります。1つ目は、データベース管理者のユーザー名やパスワードを必要としない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 Integration Repositoryを介して使用できるインタフェース以外に、Adapter for Oracle Applicationsを使用すると、ビジネス・イベント、カスタマイズされたPL/SQL API、カスタマイズされたXML Gatewayマップおよび選択したコンカレント・プログラムを使用できます。これらはすべて、Oracle Applicationsモジュール・ブラウザを使用して参照できます。

Oracle Applicationsモジュール・ブラウザ

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

Oracle Applicationsモジュール・ブラウザは、Adapter for Oracle Applicationsの主要なコンポーネントです。パートナ・リンクの定義に必要なインタフェースを選択するには、モジュール・ブラウザを使用します。モジュール・ブラウザは、Oracle Integration Repositoryからのインタフェース・データを、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
    |-Custom Objects
       |-PLSQL APIs
       |  |-[package_name]
       |-XMLGateway Maps
          |-Inbound
          |-Outbound

Oracle Integration Repositoryインタフェース・データは、[product_family]セクションを移入し、所属する製品およびビジネス・エンティティに従ってグループ化します。各インタフェース・タイプ・ヘッダーの後には、そのタイプがそのセクションの何番目にリストされているかを示す数値[n]が続きます。

ビジネス・イベントは、「その他インタフェース」の下に表示されます。カスタマイズされたXML Gatewayマップは、インバウンドまたはアウトバウンドとして分類され、「その他インタフェース」→カスタム・オブジェクトの下に表示されます。

カスタマイズされたPL/SQL APIは、2箇所に表示されます。

目次   |   戻る   |   先頭へ   |   次へ

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