Applicationの基本的な概念について説明します。アプリケーションのコンテキスト、セキュリティ、ロギングおよびフレックスフィールドがどのように使用またはサポートされるかと、エラーと例外がどのように処理されるかについて、基本的な知識を提供します。この章で詳細を説明する概念は次のとおりです。Applicationsとのインタフェースを起動するには、アプリケーションのコンテキストが必要です。アプリケーション」および「セキュリティ・グループ」を組み合せたものです。Applicationsとのインタフェースを正しく確立するために必要になることがあります。Applicationsの単一インストールで定義できます。これらの組織には、会計帳簿、ビジネス・グループ、法的エンティティ、営業単位または在庫組織があります。各階層の最上位のビジネス・グループを使用して、複数レベルの組織階層を定義できます。新しい組織を定義すると、現在のセッションに関連付けられたビジネス・グループに自動的に割り当てられます。各組織はビジネス・グループに属しています。通常、ビジネス・グループは企業の組織図の最上部にあるボックスです。エンティティおよび会計帳簿間のリレーションシップを定義します。複数組織トランザクションフランスの営業所とドイツの倉庫という、社内の2つの異なる組織を考えてみましょう。顧客からの発注トランザクションが存在します。この図は発注から搬送までの全体的なプロセスを示しています。顧客がフランスの営業所に発注します。ドイツの倉庫が顧客へ製品出荷を行います。ドイツの倉庫がフランスの営業所に会社間請求書を発行します。フランスの営業所がドイツの倉庫に会社間支払を実行します。フランスの営業所が顧客に顧客請求書を送付します。顧客がフランスの営業所に支払を実行します。データベース・アーキテクチャは、複数組織インストールでも非複数組織インストールでも同じであり、標準のインストール・ツール機能が使用されます。この機能により、ベース製品表ごとにAPPSスキーマにシノニムが自動的に作成され、ベース製品表と同じ名前を使用してこれらのシノニムが定義されます。OracleスキーマにはPO_HEADERS_ALLという名前の表があり、APPSスキーマには同じ名前の対応するシノニムPO_HEADERS_ALLがあります。PO_HEADERS_ALLシノニムを使用すると、パーティション化されていないデータにアクセスできます。アクセス制御(MOAC)セキュリティシステム・プロファイル値の設定時、ユーザー名と職責は組織単位または営業単位と関連付けます。Applicationsの多くのインタフェースではMOACセキュリティ機能を使用して営業単位のアクセス権限を決定し、関連プロファイル値に基づいて組織IDを設定します。Applicationsは必須のMOAC設定を暗黙的に実行できます。Profileを使用して、セキュリティ・プロファイルを職責に関連付けます。この方法を使用することにより、複数営業単位がセキュリティ・プロファイルと関連付けられ、そのセキュリティ・プロファイルが職責に割り当てられます。したがって、ユーザーはセキュリティ・プロファイルのアクセス制御を介して職責を変更することなく、複数営業単位のデータにアクセスできます。セキュリティ・プロファイルは、組織階層に基づいて定義します。アメリカとイギリスの営業単位で構成される販売会社があるとします。アメリカの販売会社には西部地域販売と東部地域販売があります。販売統括者はアメリカとイギリスの両方の販売に職責があり、管理者はアメリカまたはイギリスのいずれかに職責があり、販売担当は指定された販売地域にのみ職責があります。販売データをセキュリティ保護するために、事前定義済のセキュリティ・プロファイルに関連営業単位を関連付けできます。Salesセキュリティ・プロファイルにグループ化されています。アメリカ販売セキュリティ・プロファイルはアメリカ関連データ用に作成され、地域セキュリティ・プロファイルは指定地域データ用に作成されています。システム管理者は、複数の営業単位を含むこれらのセキュリティ・プロファイルを適切な職責を介してユーザーに関連付けることができます。したがって、販売管理者は、その職責を変更することなく東部または西部地域の販売データに容易にアクセスできます。次の図は、この販売会社のセキュリティ・プロファイル、職責および営業単位間の関係を示しています。職責は、その関連付けられているセキュリティ・プロファイルが営業単位にリンクしているため、どの営業単位にアクセス権があるかは職責がキーとなって決まります。アプリケーション」および「セキュリティ・グループ」の各ヘッダー・プロパティに渡される値に基づいて設定されます。下位互換性維持のため、「職責アプリケーション」、「セキュリティ・グループ」または「NLS言語」ヘッダー・プロパティが渡された場合を除いて、コンテキスト関連の例外またはエラーはスローされません。MOAC設定は、ユーザーが所属する「職責アプリケーション」に基づいて行われます。IDを渡すと、組織のアクセスは渡された組織に設定されます。ユーザーが希望の言語でインタフェースを起動する必要がある場合は、ヘッダー・プロパティ「NLS言語」を渡すことができます。Applications内のユーザーのプリファレンスで指定された言語です。Applicationsがヘッダー・プロパティを通じて提供する柔軟なメカニズムによって伝播することが重要です。この項の内容は、次のとおりです。Applicationsには柔軟なメカニズムが備えられています。それぞれのコンテキスト値やヘッダー変数はこのメカニズムによって設定され、invokeアクティビティによってアダプタ・ユーザー・インタフェースに直接渡されます。このメッセージの正規化機能により、ヘッダー・サポート上の柔軟なソリューションが提供されるだけでなく、ヘッダー値を渡すときにassignアクティビティを使用しないことによって設計時タスクが簡易化されます。次のヘッダー・プロパティは、PL/SQLおよびコンカレント・プログラムのインタフェースでアプリケーションのコンテキストを設定するために使用します。以前のリリースで使用されている既存のヘッダー・プロパティは、入力として「職責キー」および「職責名」を使用できるようになりました。ヘッダー・プロパティjca.apps.NLSLanguageが設定されており、かつ「職責名」が渡される場合、jca.apps.Responsibilityに渡される値は同じ言語で記述されていることが想定されます。「職責キー」およびその他のヘッダー・プロパティは言語非依存です。アプリケーション・コンテキストを設定するために、これらのすべてのヘッダー・プロパティを同時に使用する場合があります。「ユーザー名」および「職責」のみを渡すと、以前のリリースと同様に処理されます。NULLまたは空の値の場合は、デフォルトの「ユーザー名」は「SYSADMIN」、デフォルトの「職責」は「システム管理者」、デフォルトの「セキュリティ・グループ・キー」は「標準」およびデフォルトの「NLS言語」は「US」となります。Gateway情報の設定には、次のヘッダー・メッセージ・プロパティが使用されます。Applicationsでは、次の手順に従って、メッセージの正規化をサポートするための設計時タスクを完了します。BPELプロセスを使用した新しいSOAコンポジット・アプリケーションの作成パートナ・リンクの作成invokeアクティビティの構成このアクティビティでは、次のタスクを実行します。「一般」タブでの基本情報の構成:invokeアクティビティを、作成したパートナ・リンクにリンクすることで構成します。これにより、「Invokeの編集」ダイアログ・ボックスの「一般」タブが開きます。このタブに、「パートナ・リンク」および「操作」情報が移入されています。invokeアクティビティの入力変数と出力変数を作成できます。指示の詳細は、「一般」タブでの基本情報の構成を参照してください。「プロパティ」タブでのヘッダー・メッセージ・プロパティの設定:これにより、次の目的のために必要なメッセージ・プロパティを設定できます。Gatewayのヘッダー変数を設定します。Gatewayのヘッダー・プロパティjca.apps.ecx.TransactionTypeを見つけて、選択したプロパティに対する値('PO'など)を入力します。指示の詳細は、「ECXヘッダー・メッセージ・プロパティの設定」を参照してください。Applicationsのアプリケーション・コンテキストを設定します。jca.apps.Usernameプロパティをプロパティ・リストから見つけて、プロパティ値として'OPERATIONS'と入力します。指示の詳細は、「アプリケーション・コンテキストのヘッダー・プロパティの設定」を参照してください。IDを、invokeアクティビティの「プロパティ」タブのjca.apps.ORG_IDとして設計時に使用可能なヘッダー・プロパティとして渡すことができます。Name>)コールを使用して自動的に行われます。<ORG_ID>)へのコールが行われます。「複数組織の設定の例」に示した例では、フランスの営業所で変更オーダーが処理されると、フランス営業所の営業マネージャがシステムにログオンしてオーダーを更新します。ヘッダーに含まれる組織IDにプロパティ値(フランス営業所を表す207など)が割り当てられていれば、営業マネージャに関連付けられている組織IDがフランス営業所に設定され、APIの起動に使用されます。Applicationsには、適切な言語を実行時に動的に設定できる包括的な言語サポート・メカニズムが備えられています。「NLS言語」プロパティ値の優先アプリケーション・ユーザーがAPIの実行中にシステムからトランザクション・データを取得したり、エラー・メッセージを受信すると、データやエラー・メッセージのセッション言語は次の条件に基づいて決定されます。「NLS言語」の値は、ヘッダー・プロパティjca.apps.NLSLanguageを使用して設定できます。Suiteインスタンスで有効化されている)場合、セッション言語は対応する言語に設定されます。「NLS言語」ヘッダー・プロパティが渡されない場合は、セッション言語を設定するために、ユーザー作業環境に基づくユーザーのデフォルト言語が使用されます。ユーザーのデフォルト言語が見つからないか、または設定されていない場合、「NLS言語」(jca.apps.NLSLanguage)プロパティ値は「US」(アメリカ)に設定されます。このメカニズムにより、適切なセッション言語が最初に「NLS言語」プロパティ値に基づいて実行時に動的に設定され、その後、ユーザーのデフォルト言語に基づいて設定されて、最後にデフォルトの「NLS言語」プロパティ値「US」によって決定されます。jca.apps.NLSLanguageを使用した「NLS言語」プロパティ値の設定方法は、「正規化されたメッセージ・プロパティのサポート」を参照してください。Languageプロファイル・オプションを調べます。Support(NLS)パラメータからNLS_LANGUAGEパラメータをとります。セッションで初期化されているNLSパラメータは次のとおりです。Applicationsでは、最初に「NLS言語」プロパティ値が渡されているかどうかが検査されます。有効な言語が渡される場合、セッション言語は、デフォルト言語に関係なく、渡された値に基づいて設定されます。Applicationsでは、セッション言語がユーザー優先言語またはデフォルト言語に設定されます。それらの言語が見つからない場合、言語は「US」(アメリカ)となります。Applicationsの「一般作業環境」ページで設定します。Languageプロファイル・オプションが更新されます。アプリケーション・コンテキストが設定されている場合、ユーザー作業環境(日付書式やタイムゾーンなど)が自動的に考慮される場合があります。Suiteスタート・ガイド」の章にあるプリファレンス設定に関する項を参照してください。Applicationsのセキュリティについてセキュリティは、アプリケーション・コンテンツを不正アクセスから保護するように設計された、最も重要な機能です。Applicationsを更新するAPIの実行を、認証済権限のあるユーザーのみに許可するセキュリティ機能を提供できます。Interface(API)が保護されます。Applicationsにおける基本的なアクセス制御です。システム内の個々のメニューとメニュー・オプションへのユーザー・アクセスを、行内にどのアプリケーション・データがあるかに関係なく制限します。Applicationsへのデータの挿入および更新を可能にするストアド・プロシージャであるため、機能セキュリティ・レイヤーにAPIへのアクセスを強制されるとき、実際に暗黙的にデータ・アクセスをアプリケーションに制限します。データ・セキュリティは機能セキュリティ上に構築され、特定のデータ・レコードのセキュリティをモデリングまたは強制するためにセキュリティ制御の追加のレイヤーを提供します。言い換えると、データ・セキュリティは、アプリケーションのレコードへのアクセスのセキュリティをさらにデータ・レベルにまで細かくします。ApplicationsではOracleユーザー管理のロールベースのアクセス制御セキュリティ(RBAC)を利用して、ユーザー・ロールを介することで機能セキュリティを強化します。ユーザーがAPIにアクセスできるかどうかは、ユーザーに付与されたロールで決まります。このアプローチはデータ・セキュリティと機能セキュリティを踏まえたものですが、その両方の範囲を超えた内容になっています。Applicationsにおけるセキュリティのしくみについて理解を深めるため、このセクションには次のトピックが含まれています。APIのアクセス制御を扱う方法が提供されるようになりました。この機能は統合リポジトリのユーザー・インタフェースから作成された権限付与と連動し、どのプロファイル・オプションにも依存しません。このセキュリティ・サポートは、統合リポジトリ内で使用可能なすべてのインタフェースで機能します。その他のインタフェースについては、「プロファイル・オプションを介した機能セキュリティのサポート」で説明するプロファイル・オプションを使用して、機能セキュリティを有効にする必要があります。このため、2つの新しいJCAプロパティが導入されています。DataSecurityCheckIRepOverloadSeqユーザーが機能セキュリティ認可チェックの実行を希望する場合、次のプロパティ情報をWSDLファイル(XX_apps.jca)に追加する必要があります。Applicationsによって自動的に導出されます。これらの2つのプロパティに基づき、ヘッダー・プロパティとして渡されるユーザー名に対して機能セキュリティ・チェックが実行されます。統合リポジトリを介したセキュリティ権限付与の作成オーバーロードされた機能に対するこのタイプのデータ・セキュリティ・チェックは、統合リポジトリのユーザー・インタフェースで作成されたセキュリティ権限付与と連動します。このセキュリティ権限付与を特定のインタフェース・タイプについて「付与の作成」ページで実行すると、メソッドを非常に粒度の高いレベルで制御できます。APIで1つ以上のメソッドを選択してから、選択したメソッドをユーザー、ユーザー・グループまたはすべてのユーザーが実行できるように、適切なセキュリティ権限付与を作成して認証できます。統合リポジトリのユーザー・インタフェースでは、インタフェースに含まれるオーバーロードされた機能はそれぞれ、「付与の作成」機能を使用して特定のユーザー、ユーザー・グループまたはすべてのユーザーに個別に付与できます。「プロシージャとファンクション」領域(または「メソッド」領域)で2つ以上のオーバーロードされた機能を選択した場合、「付与の作成」ページで選択したメソッドのテーブルに「過負荷」列が表示され、2つ以上のオーバーロードされた機能が付与用に選択されていることを示します。Suite統合ゲートウェイ実装ガイドの「ネイティブ統合インタフェースとサービスの管理」の章にあるセキュリティ権限付与の管理に関する項を参照してください。プロファイル・オプションを介した機能セキュリティのサポートセキュリティ・アクセス制御は、ロールベースのアクセス制御セキュリティ(RBAC)における機能セキュリティに基づいてユーザー・ロールを介して定義され、ユーザーがAPIにアクセスできるかどうかがユーザーに付与されたロールで決まります。ロールは、ユーザーが特定の機能を実行するために必要な職責、権限、権限セットおよび機能セキュリティ・ポリシーを一元管理するように構成できます。これにより、ユーザー権限の一括更新が簡素化されます。新しい権限セットを自動継承するロールを使用することで、変更を実施できるためです。ジョブ機能に基づいて、各ロールに特定の権限(または必要な場合は権限セット)を割当てできます。調達組織には「購買担当」ロール、「購買管理者」ロールおよび「購買サポート」ロールなどを組み込むことができます。「購買管理者」ロールには発注(PO)作成、発注変更および契約発注関連のAPIすべてを含む権限セットを組み込み、「購買担当」ロールや「サポート」ロールにはアクセス権限を与えないジョブ機能の実行をこのロールに許可するなどが可能です。Repositoryにある注釈付きのAPIはFND_FORM_FUNCTIONS表に登録されており、機能セキュリティ(FND_FORM_FUNCTIONS)が適用可能です。これにより、各APIについて、セキュリティ保護された機能を作成できます。Applicationsでは、権限セットの概念を使用して、関連するAPIを1つの権限セット下にまとめ、順序付けできます。各権限セットを機能ロールに関連付け、セキュリティ権限付与を介してユーザーに割り当てることができます。Applicationsでは、このセキュリティ・サポートをオプション機能として提供しています。すべてのログイン・ユーザーがセキュリティ・チェックなしでAPIにアクセスし実行できるようにする場合は、「BPEL用EBSアダプタ、機能セキュリティ使用可能(EBS_ADAPTER_FUNCTION_SEC_ENABLED)」プロファイル・オプションを使用して、この機能を無効にできます。セキュリティ権限付与を作成することは容易で、どのプロファイル・オプションにも依存しないため、統合リポジトリにリストされたインタフェースに対して推奨する方法は、オーバーロードされた機能に前述の「DataSecurityCheck」を使用することです。Gatewayおよびコンカレント・プログラムに対するすべてのAPIコールは、実行される前にユーザー・セキュリティがチェックされます。「N」(デフォルト値)に設定すると、機能セキュリティ機能が無効になります。APIコールの実行中はセキュリティ・チェックは実行されません。Suite内のAPIを起動しようとした場合、機能セキュリティ・プロファイルが有効になっていると、API上で認証権限の検証が完了した後で初めてAPIが起動されます。APIを起動しようとすると、BPELプロセスの実行は失敗します。APIの権限がないことが示されます。11g』を参照してください。セキュリティを参照してください。Applicationsで次の手順を実行して、ユーザー・ロールを介してユーザーにセキュリティ権限付与を作成する必要があります。権限セットは、次の手順を使用して作成します。E-Businessにログインします。「ナビゲータ」から「アプリケーション・メニュー」を選択して「メニュー」ウィンドウにアクセスします。次のメニュー情報を入力します。メニュー名(OE_PROCESS_LINE_PSなど)を入力します。メニュー名(「オーダー・マネージャ明細処理権限セット」など)を入力します。このメニューの説明を入力します。「順序」と「機能」の値を入力して、この権限セットにグループ化する機能をすべて追加します。「順序」フィールドに入力します。「機能」の列で、この権限セットに割り当てる機能を検索します。「機能」ウィンドウで検索を実行して機能名を選択します。「検索」フィールドに%PLSQL:OE%と入力し、「検索」をクリックして検索を実行します。機能の検索コンポジット・アプリケーションに基づいて機能を選択し、BPELプロセスまたはMediatorから起動するAPIに権限を付与します。APIに含まれている受注明細変更関連の機能を選択して権限セットとしてグループ化し、ロールを介して該当するユーザーにその権限セットを付与します。権限セットを保存します。権限セットはユーザー・ロールを介して付与されます。したがって、最初にロールを作成してからユーザーにそのロールを割り当てる必要があります。ユーザー・ロールは、次の手順を使用して作成します。E-Businessにログインします。「ナビゲータ」から「ロールおよびロール継承」を選択し、「ロールおよびロール継承」ページにアクセスします。「ロールの作成」をクリックして、「ロールの作成」ページにアクセスします。次の情報を入力してユーザー・ロールを作成します。ドロップダウン・リストから「その他」を選択します。該当するロール・コード(EBS_ADAPTER_ROLEなど)を入力します。表示名の情報(「EBSアダプタ・ロール」など)を入力します。説明の情報(「EBSアダプタ・ロール」など)を入力します。Libraryなど)を選択します。ロールがすぐに有効になるように当日またはそれより前の日付を入力します。情報を保存して「付与の作成」をクリックします。付与の定義」ページに次の情報を入力します。名前(「EBS_ADAPTER_GRANT」など)を入力します。この付与の説明を入力します。「次」をクリックします。オブジェクト・パラメータの定義およびセットの選択」ページで、「権限セットの作成」項で作成した権限セットを選択し、「次」をクリックします。「終了」をクリックします。ロールを介したユーザーへの権限セットの付与ロールを介してユーザーに権限セットを付与するには、次の手順を使用します。E-Businessにログインします。「ナビゲータ」から「ユーザー」を選択して「ユーザー保守」ページにアクセスします。ロールを割り当てるユーザーを検索して「移動」をクリックします。ロールを割り当てるユーザー名の隣にある「更新」アイコンを選択します。「ユーザーの更新」ページで「ロールの割当」をクリックすると「検索」ウィンドウが移入され、以前に作成したロールが検索できます。ロール(EBS_ADAPTER_ROLEなど)を選択して更新内容を保存します。APIでフレックスフィールドを使用できるようにします。PL/SQLインタフェースがフレックスフィールドを含むように構成されている場合、フレックスフィールド・データやマッピングなどのフレックスフィールド情報が設計時に表示されるのみでなく、XSDにも含められます。Applicationsのランタイムがフレックスフィールドのコンテキスト内で動作できます。以前のリリースでは設計時にフレックスフィールド情報が表示されず、かわりに汎用APIパラメータ名が表示されていたことに注意してください。ペイロードのXSDにもフレックスフィールド情報のかわりに汎用パラメータ名が表示されていました。Suiteリリース12以上のみです。Suiteの基本機能の1つです。オブジェクトを表したり、必要な場合にのみ表示されるコンテキスト依存フィールドを実装するための柔軟な手段を提供します。フレックスフィールドはサブフィールド、つまりセグメントで構成されます。Suiteの機能をカスタマイズできます。APIのためのフレックスフィールド・サポートを提供しています。Applicationsモジュール・ブラウザの右側のペインに表示されます。APIをフレックスフィールドを含むように構成せずにパートナ・リンクの作成を続行することもできます。Applicationsでフレックスフィールド・データを構成するには、以前に作成された既存のフレックスフィールド・マッピングを使用するか、必要に応じて新規のマッピングを作成できます。新規のマッピングを作成する場合は、フレックスフィールド・マッピング・ウィザードが表示され、各構成ページで、選択したAPIと望みどおりにマッピングされたキー・フレックスフィールドや付加フレックスフィールドを追加できます。Applicationsが提供する主なフレックスフィールド機能は次のとおりです。Applicationsモジュール・ブラウザで表示できます。キー・フレックスフィールドと付加フレックスフィールドの両方を構成および変更できます。選択されたAPIに対して、新規のマッピングを構成することも作成済のマッピングをインポートして再利用することもできる柔軟なマッピング・サポート・メカニズムを提供します。APIに対して1回のみです。重複するフレックスフィールドは使用できません。フレックスフィールドのマッピングが完了してパートナ・リンクが作成されると、汎用パラメータ名のかわりにフレックスフィールド名を使用して拡張スキーマ(XSD)が生成されます。Databaseアダプタからのサポートと連携させて拡張スキーマを処理できます。Applicationsは、APIから参照されるキー・フレックスフィールドと付加フレックスフィールドを両方ともサポートします。キー・フレックスフィールドキー・フレックスフィールドはエンティティの識別子として使用します。一般に、キー・フレックスフィールドを使用して作成する識別子はアプリケーションにとって必要な識別子です。勘定科目番号の作成と表示には会計フレックスフィールドが使用されます。Ledgerによって所有されますが、その値は他の多くのアプリケーションで使用できます。通常、キー・フレックスフィールド構造は複数のセグメントで構成され、各セグメントには意味のある情報が格納されます。5つのセグメントで構成できます。付加フレックスフィールド付加フレックスフィールドは、ビジネスに必要な専門的かつ重要な固有の情報を収集するために使用します。Suiteの収集範囲を超える情報収集に使用されるのです。通常、付加フレックスフィールドでは複数の構造が使用されます。各構造は、それぞれ異なるデータを収集するために異なるセグメントで構成できます。各セグメントの値は、アプリケーションのベース表内の列に格納されます。列名は格納されるフレックスフィールド・データのタイプを反映します。一般に、キー・フレックスフィールドではSEGMENTnと呼ばれる列にデータが格納され、付加フレックスフィールドではATTRIBUTEnと呼ばれる列にデータが格納されます(nは番号です)。Suiteで必要とされる情報の範囲を超えてビジネス・エンティティに関する追加情報を収集するために使用します。Suiteフレックスフィールド・ガイドを参照してください。フレックスフィールドのマッピングの概念すべてのフレックスフィールドには、そのタイプに関係なく所有アプリケーションがあります。Ledgerアプリケーションに所有されています。Ledgerなど)に含まれるフレックスフィールド名(会計フレックスフィールドなど)を選択する必要があります。次の図は、キー・フレックスフィールドのマッピングの高レベルの概念を示しています。フレックスフィールド構成作業の中核はマッピングです。(AOL)フレックスフィールド表から導出されます。APIパラメータは、選択されたデータ・タイプ(親タイプまたはレコード・タイプ)に基づいて表示されます。APIパラメータとフレックスフィールド表の列は、手作業でマップすることも自動マップ機能を使用して自動的にマップすることもできます。親タイプは、プロシージャ・レベルですべてのスカラー・パラメータをマッピングに含めるための疑似タイプです。スカラー・パラメータのみを含む単純なAPIに使用できます。レコード・タイプは、スカラー・タイプに加えてレコード・タイプも含んでいる複雑なAPIに対して選択できます。API内で1つのレコード・タイプが複数回出現する場合は、参照のためにパスのリストが表示されます。レコード・タイプからのパラメータがフレックスフィールド表の列にマップされた場合、それが出現したすべてのパスに同じマッピングを適用できます。サポートされるレコード・タイプとしては、配列、ネストされた表、関連配列などがあります。自動マップ機能では、表のすべての列が、パラメータ名の一部に列名を含むパラメータにマップされます。パラメータP_ATTRIBUTE1はATTRIBUTE1という名前の列にマップされ、パラメータP_ATTRIBUTE2はATTRIBUTE2という名前の列にマップされます。マッピングが完了したら、キー・フレックスフィールドのフレックスフィールド構造を選択する必要があります。フレックスフィールド構造は、セグメントの特定の構成です。セグメントを追加または削除したり、フレックスフィールド内のセグメントの順序を並べ替えると、別の構造になります。特定の構造を構成する各セグメントは、論理的または機能的に関連しています。付加フレックスフィールドの場合は、さらにコンテキスト列のマッピングも必要です。コンテキスト列も含めた表のすべての列を、1つのレコード・タイプまたは親タイプに属するスカラー・パラメータにマップする必要があります。マッピングが完了したら、付加フレックスフィールドの選択したコンテキスト列に対してコンテキスト値を少なくとも1つ選択してください。チリ(Chile)では小区域や比較的狭い場所を地理的に表現するために、州および郡に加えてRegionとComunaを使用します。同様に、エクアドル(Ecuador)の地理ではそれぞれ異なる境界を記述するためにZonaとParroquiaを使用します。これは、アプリケーションをビジネス・ニーズに合せてカスタマイズするために付加フレックスフィールドを使用する格好の例です。Informationを定義するときのコンテキスト値です。(またはATTRIBUTE2)にマップされ、その値は選択されたコンテキスト値(ChileまたはEcuador)によって決まります。付加フレックスフィールドの場合、APIパラメータを通じてランタイムがコンテキスト値を使用できるようにする必要があります。Applicationsモジュール・ブラウザから定義されたフレックスフィールド・マッピングを使用します。このXSDには、設計時に選択されたマッピングに基づくフレックスフィールド・セグメント名が含まれます。Databaseアダプタと連携して拡張スキーマ・ファイルを処理します。フレックスフィールド構造とコンテキスト値の定義に関するガイドライン次のいずれかの条件が満たされた場合、付加フレックスフィールドのコンテキスト値またはキー・フレックスフィールドの構造を選択することはできません。コンテキストまたは構造にセグメントもセグメント・マッピングもない。少なくとも1つのセグメントを持つコンテキスト値または構造値のみ選択できる。コンテキストまたは構造にセグメントがあるが、いずれのセグメントもマッピング・ページでマップされた表のどの列とも一致しない。Suiteで無効にされている。Suiteで無効にされている。フレックスフィールドの構成)では、有効なコンテキストまたは構造のみ表示されます。フレックスフィールドのマッピングは、拡張スキーマまたはXSDファイルの生成に使用されます。重複するフレックスフィールドは使用できません。APIに対して1回のみです。範囲キー・フレックスフィールドはサポートされません。値セットと修飾子はサポートされません。1つのフレックスフィールドを構成するすべてのフレックスフィールド・セグメントに対するフレックスフィールド・マッピングは、親レベルで、または1つのレコード・タイプ内で行う必要があります。コンテキスト列のマッピングは、セグメントがマップされたレベルのパラメータと対応する必要があります。付加フレックスフィールドのセグメントが選択されたデータ・タイプ(レコード・タイプまたは親タイプ)にマップされた場合、コンテキスト列のマッピングも同じデータ・タイプとの間で行う必要があります。Applicationsモジュール・ブラウザの右側のペインに表示されます。API」ノードの下にリストされたHZ_AIA_CUSTOM_PKGから選択できます。Applicationsモジュール・ブラウザに表示されます。Applicationsモジュール・ブラウザの次の各領域に表示して構成することができます。Applicationsでは、単にブラウザで「OK」をクリックしてパートナ・リンクの作成を進めるのみで、選択したAPIについてフレックスフィールドの構成または変更をバイパスすることもできます。「パラメータと対応するフレックスフィールドのマッピング」領域この領域には、選択したAPIのパラメータと、対応するAPIパラメータからフレックスフィールド表の列へのマッピング情報が表示されます。選択したAPIの中のパラメータを簡単に見つけられるように、レコード・タイプのパラメータは表内のツリーとして表示されます。「フレックスフィールドの構成」領域この領域では次のタスクを実行できます。選択したAPIがカスタムAPIであってもシードされたAPIであっても、フレックスフィールド・マッピング情報が一度ブラウザに表示されたら、付加フレックスフィールドのコンテキスト値とキー・フレックスフィールドの構造を変更できるようになります。Applicationsモジュール・ブラウザからのフレックスフィールド定義を使用して拡張XSDを生成します。このXSDには、設計時にマッピング情報に基づいて選択されたフレックスフィールド・セグメント名がAPIパラメータ名とともに含められます。フレックスフィールドを変更する方法の詳細は、「フレックスフィールド定義の変更」を参照してください。選択したAPIに新しいマッピングを作成するには、「フレックスフィールド・メタデータ」セクションで「マッピングの追加」を選択します。Suiteインスタンスで定義されたフレックスフィールドとの間のフレックスフィールド・マッピングを構成することができます。「新しいマッピングの追加または構成」を参照してください。「ファイルからインポート」を選択して作成された既存のマッピングを使用できます。これにより選択したAPIに対して希望するフレックスフィールド・マッピングを選択できます。希望するマッピングがインポートされたら、必要に応じて付加フレックスフィールドのコンテキスト値を変更したり、キー・フレックスフィールドの構造を変更できます。「既存のフレックスフィールド・マッピングのインポート」の項を参照してください。フレックスフィールド構成ファイルの確認パートナ・リンクを作成すると、拡張XSDファイルとフレックスフィールド構成ファイルおよびマッピング・ファイルが生成されます。これらのファイルを見て、フレックスフィールドの詳細を確認できます。「フレックスフィールドの構成の確認」を参照してください。Applicationsモジュール・ブラウザに表示されるAPIのリストを通じて検索または参照を実行した後、選択したPL/SQLインタフェースがフレックスフィールドを含むように構成されている場合、そのAPI内のフレックスフィールド情報がウィンドウの右側のペインに表示されます。選択したAPIについて新しいマッピングを追加または構成するには、「フレックスフィールドの構成」領域にある「マッピングの追加」をクリックします。ウィザードで表示される一連のフレックスフィールド選択ページの指示に従って、選択したAPIの新しいマッピングを構成できます。ようこそ「ようこそ」ページの「次へ」をクリックすると、「フレックスフィールド・タイプの選択」ページが表示され、構成または追加するフレックスフィールドとしてキー・フレックスフィールドまたは付加フレックスフィールドを選択できます。構成するフレックスフィールドのタイプとして、「キー・フレックスフィールド」または「付加フレックスフィールド」ラジオ・ボタンを選択します。選択したAPIについて、ビジネスのニーズに合せて複数のキー・フレックスフィールドまたは付加フレックスフィールドを構成できることに注意してください。次を参照してください。APIを例に取り、フレックスフィールド・データを使用したインバウンドWebサービスの作成について説明します。APIのINV_EBI_ITEM_PUB.PROCESS_ITEM_LISTが起動されます。更新されたデータは、レスポンス・メッセージとしてクライアントに渡されます。次の図は、サービス起動プロセスの流れを示しています。Suiteアプリケーションから在庫品目リストに対する問合せを直接行うことで、プロセスを検証できます。取得された品目データは、ペイロードからの入力と同じであるはずです。パートナ・リンク作成の一環としてのキー・フレックスフィールドの構成APIとして選択したINV_EBI_ITEM_PUB.PROCESS_ITEM_LISTについてキー・フレックスフィールドを構成するには、「フレックスフィールドの構成」領域にある「マッピングの追加」をクリックします。ウィザードで表示される一連のフレックスフィールド選択ページの指示に従って、選択したAPIの新しいマッピングを構成できます。「ようこそ」ページで「次へ」をクリックします。「フレックスフィールド・タイプの選択」ページが表示されます。フレックスフィールド・タイプの選択キー・フレックスフィールドを構成するには、次の手順を実行します。「フレックスフィールド・タイプの選択」ページで「キー・フレックスフィールド」ラジオ・ボタンを選択します。「次」をクリックします。「フレックスフィールド・アプリケーションの選択」ページが表示されます。目的のアプリケーション名を見つけるには、検索キーワード(%App%など)を入力して「問合せ」をクリックし、検索を実行します。検索基準と一致したエントリがすべて表示されます。フレックスフィールドが所属するアプリケーションの名前として、「Inventory」ラジオ・ボタンを選択します。フレックスフィールド・アプリケーションの選択または、直接「問合せ」をクリックして検索キーワードなしの空白検索を実行します。この場合は、すべてのフレックスフィールド・アプリケーション名が選択肢として表示されます。「次」をクリックします。「フレックスフィールドの選択」ページで、検索キーワードを入力し(必要な場合)、「問合せ」をクリックして検索を実行します。一致したキー・フレックスフィールドがすべて選択肢として表示されます。目的のキー・フレックスフィールドのラジオ・ボタンを選択します。「次」をクリックして処理を続行してください。「データ型の選択とマッピングの構成」ページが表示され、そこでキー・フレックスフィールドのマッピングを選択できます。選択したキー・フレックスフィールド名が自動的にフレックスフィールド名として表示されます。データ型の選択とマッピングの構成レコード・タイプを持たない単純なAPIの場合、フレックスフィールド・マッピングを構成するには、「データ型の選択」ドロップダウン・リストから<Parent_type>を選択します。Suiteデータベースから取得され、親レベルのパラメータがマッピングのために表示されます。Parent_typeは、プロシージャ・レベルですべてのスカラー・パラメータをマッピングに含めるための疑似タイプです。複雑なAPIの場合は、レコード・タイプを選択することもできます。API内で1つのレコード・タイプが複数回出現する場合は、参照のためにパスのリストが表示されます。レコード・タイプからのパラメータがフレックスフィールド表の列にマップされた場合、それが出現したすべてのパスに同じマッピングを適用できます。このマッピング・ページでは、手作業でマッピングすることも、自動マップ機能を使用することもできます。自動マップ機能はすべてのセグメントを、パラメータ名の一部に列名を含むパラメータにマップします。表のSEGMENT1列はパラメータSEGMENT1にマップされます。パラメータ名と表の列名のセットが複数ある場合は、接頭辞を指定できます。(nは番号)のようなP_で始まるパラメータをすべて取得するには、接頭辞としてP_を入力します。「自動マップ」をクリックすると、接頭辞P_で始まるすべてのパラメータが、自動マップされた表の列名とともに表示されます。フレックスフィールドの値は、アプリケーションのデータベース表に格納されます。一般に、キー・フレックスフィールドではSEGMENTnと呼ばれる列にデータが格納され、付加フレックスフィールドではATTRIBUTEnと呼ばれる列にデータが格納されます(nは番号です)。手動マップでは、対応するパラメータに対してマップする表の列を選択できます。パラメータがすでに表の列にマップされている場合、そのパラメータを別の列に再マップすることはできません。この場合は、マップされたパラメータのかわりに「マップ済」と表示されます。現在のマッピングをクリアするには、「マッピングのクリア」をクリックします。「マップ済」のマークが付いているマップ済の列はすべて、システムから削除されません。「次」をクリックして処理を続行してください。フレックスフィールドの構成は、キー・フレックスフィールドの構造と付加フレックスフィールドの最低1つのコンテキスト値がないと完了しません。「フレックスフィールドの構成」ページで、必要に応じて「構造」フィールドに検索キーワードを入力するか、単に「問合せ」をクリックして空白検索を実行します。選択したキー・フレックスフィールドに対して一致した構造がすべて表示されます。構造は1つのみ選択します(SYSTEM_ITEMSなど)。望みどおりの構造が選択肢としてウィザードに表示されるようにするには、特定の基準を満たす必要があることに注意してください。「フレックスフィールド構造とコンテキスト値の定義に関するガイドライン」を参照してください。フレックスフィールド・マッピングに含められるキー・フレックスフィールドの構造は1つのみです。付加フレックスフィールドの場合は、複数のコンテキスト値をマッピングに含めることができます。「終了」をクリックします。Applicationsモジュール・ブラウザ」ウィンドウが表示されます。新しく追加したキー・フレックスフィールド構造と、マップされたパラメータが「パラメータと対応するフレックスフィールドのマッピング」領域に表示されます。キー・フレックスフィールドの情報も、「フレックスフィールド定義」セクションに表示されます。「OK」をクリックします。「アプリケーション・インタフェース」ページが開き、選択したAPIが表示されます。「次へ」をクリックし、「終了」をクリックします。パートナ・リンクに対応するWSDLファイルが生成されます。拡張XSDファイル(たとえばProcessItem_KFF_flex.xsd)も作成されます。このXSDファイルには、フレックスフィールドのセグメント名で置き換えられたパラメータを表す要素を使用してプロシージャの引数を記述するスキーマが収められています。「適用」をクリックし、「OK」をクリックします。構成ファイルとフレックスフィールド・マッピング・ファイルも作成されます。これらのファイルの詳細は、「フレックスフィールドの構成の確認」を参照してください。選択したAPIについて付加フレックスフィールドを追加する方法は、「付加フレックスフィールドの構成」を参照してください。設計時のマップされたキー・フレックスフィールドの表示パートナ・リンクの作成時に構成されたキー・フレックスフィールドのマッピング・データを、設計時に表示できます。次の例では、SOAコンポジットのBPELプロセスにおけるキー・フレックスフィールドのマッピングについて説明します。BPELプロセスを持つ新しいSOAコンポジット・アプリケーションを作成します。APIに対して構成したキー・フレックスフィールド・マッピングを使用するProcesItem_KFFと呼ばれるパートナ・リンク・サービスを追加します。キー・フレックスフィールドを構成する方法の詳細は、「キー・フレックスフィールドの構成」を参照してください。サービス起動用のフレックスフィールド・データを含む入力ペイロードを読み取るために、ファイル・アダプタのパートナ・リンクを追加します。「ファイル・ディレクトリ」ダイアログで、入力ペイロードxmlファイル(たとえばinput_payload.xml)が存在する物理ディレクトリ(たとえば/usr/tmp)を入力します。「メッセージ」ダイアログで、「URL」フィールドの横にある「スキーマ・ファイルを参照」アイコンを選択して「タイプ・チューザ」を開きます。「タイプ・エクスプローラ」をクリックして、「プロジェクトのスキーマ・ファイル」→「ProcessItem_KFF_sp.xsd」→「ProcessItem_KFF_flex.xsd」→「InputParameters」を選択します。「OK」をクリックします。選択したスキーマ情報は、「URL」フィールドと「スキーマ要素」フィールドに自動的に移入されます。2つのinvokeアクティビティを構成します。最初のinvokeアクティビティは、入力ペイロードのデータを同期的に読み取るために、ファイル・アダプタのパートナ・リンクと関連付けます。2番目のinvokeアクティビティは、サービスを起動するために、フレックスフィールド・マッピングを含んでいるパートナ・リンクProcessItem_KFFと関連付けます。ファイル・アダプタから受け取った入力ペイロードを、サービス起動用に2番目のinvokeアクティビティに渡すために、assignアクティビティを追加します。Suiteで定義された一致するフレックスフィールド・セグメントに対応する、マップされたキー・フレックスフィールドの列名が、assignアクティビティに表示されます。「assignアクティビティでのキー・フレックスフィールドを使用したパラメータの割当て」を参照してください。APIに関する設計時タスク」を参照してください。システム品目」ウィンドウでSEGMENT1のみが品目(Item)として指定されます。Suiteで定義された実際のセグメントとの関係を示しています。Applicationsモジュール・ブラウザに表示されます。この場合は、SEGMENT1内の対応する列名であるItemのみが表示されます。Suiteフレックスフィールド・ガイドの「キー・フレックスフィールドの計画と定義」を参照してください。JDeveloperで拡張XSDファイル(たとえばProcessItem_KFF_flex.xsd)を選択し、マップされたキー・フレックスフィールド列(Item)が、フレックスフィールド名System_Itemsの下にflex型として表示されていることを確認します。assignアクティビティでのキー・フレックスフィールドを使用したパラメータの割当てSOAコンポジット・アプリケーション内のBPELプロセス・ダイアグラムのassignアクティビティに、マップされたキー・フレックスフィールドを表示して、ペイロードからの入力変数を2番目のinvokeアクティビティに渡してサービスを起動するために使用できます。assignアクティビティでのマップされたキー・フレックスフィールドの表示assignアクティビティを使用して、入力ペイロード情報をターゲット・パラメータのItemオブジェクトに渡します。(ns2:System_Itemsの下)に変換されてassignアクティビティの中に表示されています。Item」を選択します。Item」を選択します。Item)にドラッグして接続します。これでソース・ノードとターゲット・ノードを接続する線が作成されます。コピー・ルールは、「Assignの編集」ダイアログ・ボックスの下部にある「From」セクションと「To」セクションに表示されます。「適用」をクリックして「OK」をクリックし、assignアクティビティの構成を完了します。ソースとターゲットのns2:InputParameters変数はどちらも同じものなので、単にソース・ノード(ns2:InputParameters)をターゲット・ノード(ns2:InputParameters)にドラッグして接続するという方法で、assignアクティビティを完成させることもできます。invokeアクティビティへの入力変数の割当てここに表示されているデータ型INV_EBI_ITEM_MAIN_OBJが、「データ型の選択とマッピングの構成」ページでドロップダウン・リストから指定されたデータ型(INV_EBI_ITEM_PUB:INV_EBI_ITEM_MAIN_OBJ)とまったく同じであることに注意してください。選択したデータ型のパスとしてP_ITEMがリストされます。WebLogic管理対象サーバー(たとえばsoa-server1)にデプロイすると、前述のように構成したキー・フレックスフィールドがsoa-server1サーバーに表示され(http://<servername>:<portnumber>/soa-infra)、ペイロード・データを指定してサービスの起動をテストできます。Controlコンソールからも実行できることに注意してください。この例では、マップされたキー・フレックスフィールドが、最上位レベルから複数のサブレベルにネストされた入力ペイロードの一部として使用されています。これは、マップされたキー・フレックスフィールドItemに到達するためには、最上位レベルからいくつものパラメータ・ノードを展開する必要があることを意味します(「ペイロード」→「P_ITEM」→「P_ITEM_ITEM」→「MAIN_OBJ_TYPE」)。Controlコンソールでのペイロード・パラメータの表示には一定の制限があります。したがって、この場合は、マップしたキー・フレックスフィールドにsoa-server1サーバー内のsoa-infraから直接アクセスします。Controlコンソールからサービスの起動をテストする方法の詳細は、「BPELプロセスを使用したデプロイ済SOAコンポジット・アプリケーションのテスト」を参照してください。FlexfieldKFFプロジェクト(「Test_bpelprocess2_client_ep」リンク)をクリックして、ペイロード情報をHTMLで表示します。「P_ITEM」→「P_ITEM_ITEM」→「MAIN_OBJ_TYPE」→「System_Items」を展開します。マップされたキー・フレックスフィールドItemがペイロードの一部として表示されます。適切なデータをペイロードとして入力し、「起動」をクリックしてサービスを起動します。APIを例に取り、フレックスフィールド・データを使用したインバウンドWebサービスの作成について説明します。APIのHZ_AIA_CUSTOM_PKG.SYNC_ACCT_ORDERTが起動されます。同期された顧客データは、レスポンス・メッセージとしてクライアントに渡されます。次の図は、サービス起動プロセスの流れを示しています。Onlineアプリケーションから顧客データの問合せを直接行うことで、プロセスを検証できます。取得された顧客データは、ペイロードからの入力と同じであるはずです。選択したAPIであるHZ_AIA_CUSTOM_PKG.SYNC_ACCT_ORDERについて付加フレックスフィールドを構成するには、「フレックスフィールドの構成」領域にある「マッピングの追加」をクリックします。ウィザードで表示される一連のフレックスフィールド選択ページの指示に従って、選択したAPIの新しいマッピングを構成できます。「ようこそ」ページで「次へ」をクリックします。「フレックスフィールド・タイプの選択」ページが表示されます。付加フレックスフィールドを構成するには、次の手順を実行します。「フレックスフィールド・タイプの選択」ページで「付加フレックスフィールド」ラジオ・ボタンを選択し、フレックスフィールド・マッピング・ウィザードで前述のキー・フレックスフィールドの場合と同様のアプローチを使用します。「フレックスフィールド・タイプの選択」ページで「次へ」をクリックします。「フレックスフィールド・アプリケーションの選択」ページが表示されます。目的のアプリケーションを見つけるには、検索キーワード(%App%など)を入力するか単に「問合せ」をクリックして、検索を実行します。付加フレックスフィールドに対して一致したアプリケーションがすべて表示されます。付加フレックスフィールドが所属するアプリケーションの名前として、「Receivables」ラジオ・ボタンを選択します。「次」をクリックします。「フレックスフィールドの選択」ページで、必要に応じて検索キーワード(たとえばHZ%)を入力し、「問合せ」をクリックして検索を実行します。一致した付加フレックスフィールドがすべて選択肢として表示されます。目的の付加フレックスフィールド(たとえばHZ_LOCATIONS)を選択し、「次へ」をクリックします。「データ型の選択とマッピングの構成」ページが表示され、そこで付加フレックスフィールドのマッピングを選択できます。選択した付加フレックスフィールド名HZ_LOCATIONSが自動的にフレックスフィールド名として表示されます。データ型の選択とマッピングの構成フレックスフィールド・マッピングを構成するには、「データ型の選択」ドロップダウン・リストから目的のデータ型を選択します。Suiteデータベースから取得され、親レベルのパラメータがマッピングのために表示されます。親タイプは、プロシージャ・レベルですべてのスカラー・パラメータをマッピングに含めるための疑似タイプです。スカラー・パラメータのみを含む単純なAPIに使用できます。レコード・タイプは、スカラー・タイプに加えてレコード・タイプも含んでいる複雑なAPIに対して選択できます。付加フレックスフィールドの場合は、コンテキスト列に関する追加のマッピングを実行する必要があります。これは、フレックスフィールド・マッピングがレコードのタイプ間を超えられないためです。コンテキスト列も含めた表のすべての列を、1つのレコード・タイプまたは親タイプに属するスカラー・パラメータにマップする必要があります。ATTRIBUTE_CATEGORY」フィールドで、マッピング情報を表示するカテゴリの名前をドロップダウン・リストから選択します。ドロップダウン・リストからATTRIBUTE_CATEGORYを選択します。パラメータがすでに表の列にマップされている場合、そのパラメータを別の列に再マップすることはできません。この場合は、マップされたパラメータのかわりに「マップ済」と表示されます。キー・フレックスフィールドの場合と同様に、マッピングは手作業で行うことも、「自動マップ」をクリックして自動マップ機能を利用することもできます。自動マップ機能は表のすべての列を、パラメータ名の一部に列名を含むパラメータにマップします。ATTRIBUTE1からATTRIBUTE20までの表列名が自動的に表示され、自動マップ機能によってそれぞれATTRIBUTE1からATTRIBUTE20までのパラメータにマップされます。パラメータ名と表の列名のセットが複数ある場合は、自動マッピングのために接頭辞を指定する必要があります。これにより、マッピングの対象とみなす必要がある潜在的パラメータがマップされます。自動マッピングの対象にするパラメータを見つけるために、パラメータ接頭辞(たとえばINDUSTRY_)を入力します。次に、「自動マップ」をクリックします。接頭辞INDUSTRY_で始まるすべてのパラメータが、自動マップされた表の列名とともに表示されます。パラメータINDUSTRY_ATTRIBUTE1はATTRIBUTE1列にマップされ、パラメータINDUSTRY_ATTRIBUTEnはATTRIBUTEn列にマップされます。自動マップ機能を使用するかわりに、フレックスフィールド・マッピングで対応するパラメータにマップする表の列名をドロップダウン・リストから手作業で選択することもできます。現在表の列に設定されているマッピングのみをクリアするには、「マッピングのクリア」をクリックします。「マップ済」のマークが付いているマップ済の列はすべて、システムから削除されません。「次へ」をクリックして、次のページに進みます。「フレックスフィールドの構成」ページで、選択した付加フレックスフィールドに対して少なくとも1つのコンテキスト値を選択します。希望するコンテキスト値(ChileやEcuadorなど)を選択します。選択の前に、「コンテキスト」フィールドに検索キーワードを入力するか、単に「問合せ」をクリックして、検索を実行できます。付加フレックスフィールドの場合、APIパラメータを通じてランタイムがコンテキスト値を使用できるようにする必要があります。望みどおりのコンテキスト値が選択肢としてウィザードに表示されるようにするには、特定の基準を満たす必要があることに注意してください。「フレックスフィールド構造とコンテキスト値の定義に関するガイドライン」を参照してください。「終了」をクリックしてフレックスフィールドの構成を完了します。Applicationsモジュール・ブラウザ」ウィンドウが表示されます。新しく追加した付加フレックスフィールド情報が、選択したコンテキスト値のセグメント値も含めて、ウィンドウの右側のペインに表示されます。「OK」をクリックします。「アプリケーション・インタフェース」ページが開き、選択したAPIが表示されます。「次へ」をクリックし、「終了」をクリックします。パートナ・リンクに対応するWSDLファイルが生成されます。拡張XSDファイル(たとえばSynAccOrder_flex.xsd)も作成されます。このXSDファイルには、フレックスフィールドのセグメント名で置き換えられたパラメータを表す要素を使用してプロシージャの引数を記述するスキーマが収められています。「適用」をクリックし、「OK」をクリックします。構成ファイルとフレックスフィールド・マッピング・ファイルも作成されます。これらのファイルの詳細は、「フレックスフィールドの構成の確認」を参照してください。新しいフレックスフィールド・マッピングを構成または追加した後、変更が必要になった場合は、まず変更対象のフレックスフィールド・タイプを選択して、必要な変更を行います。選択したマッピングの詳細を変更する方法の詳細は、「フレックスフィールド定義の変更」を参照してください。設計時のマップされた付加フレックスフィールドの表示キー・フレックスフィールドの場合と同様に、パートナ・リンクの作成時に構成された付加フレックスフィールドのマッピング・データは、SOAコンポジット内のBPELプロセスにまとめられた次のアクティビティとともに設計時に表示できます。次の例では、SOAコンポジットのBPELプロセスにおける付加フレックスフィールドのマッピングについて説明します。BPELプロセスを持つ新しいSOAコンポジット・アプリケーションを作成します。APIに対して構成した前述の付加フレックスフィールド・マッピングを使用するSynAccOrderと呼ばれるパートナ・リンク・サービスを追加します。付加フレックスフィールドを構成する方法の詳細は、「付加フレックスフィールドの構成」を参照してください。サービス起動用のフレックスフィールド・データを含む入力ペイロードを読み取るために、ファイル・アダプタのパートナ・リンクを追加します。「ファイル・ディレクトリ」ダイアログで、入力ペイロードxmlファイル(たとえばinput_payload.xml)が存在する物理ディレクトリ(たとえば/usr/tmp)を入力します。「メッセージ」ダイアログで、「URL」フィールドの横にある「スキーマ・ファイルを参照」アイコンを選択して「タイプ・チューザ」を開きます。「タイプ・エクスプローラ」をクリックして、「プロジェクトのスキーマ・ファイル」→「SynAccOrder_sp.xsd」→「SynAccOrder_flex.xsd」→「InputParameters」を選択します。「OK」をクリックします。選択したスキーマ情報は、「URL」フィールドと「スキーマ要素」フィールドに自動的に移入されます。2つのinvokeアクティビティを構成します。最初のinvokeアクティビティは、入力ペイロードのデータを同期的に読み取るために、ファイル・アダプタのパートナ・リンクと関連付けます。2番目のinvokeアクティビティは、サービスを起動するために、フレックスフィールド・マッピングを含んでいるパートナ・リンクSynAccOrderと関連付けます。ファイル・アダプタから受け取った入力ペイロードを、サービス起動用に2番目のinvokeアクティビティに渡すために、assignアクティビティを追加します。Suiteで定義された一致するフレックスフィールド・セグメントに対応する、マップされた付加フレックスフィールドの列名が、assignアクティビティに表示されます。「assignアクティビティでの付加フレックスフィールドを使用したパラメータの割当て」を参照してください。APIに関する設計時タスク」を参照してください。(HZ_LOCATIONS)の付加フレックスフィールド属性を定義すると(アプリケーション開発者職責)、コンテキスト値に基づいて次の属性が指定されます。JDeveloperで拡張XSDファイル(たとえばSynAccOrder_flex.xsd)を選択し、マップされた付加フレックスフィールドが、HZ_LOCATIONSフレックスフィールドの下にflex型のスキーマの一部として表示されていることを確認します。マップされた表の列名(Region、Comuna、Zona、Parroquia)は、ツリー構造内にリストされたコンテキスト値(ChileとEcuador)によってグループ分けされています。コンテキスト値のノード間は「<choice>」アイコンによって接続されており、いずれか1つのコンテキスト値とそれに関連付けられた表列のみが選択可能であることを示しています。assignアクティビティでの付加フレックスフィールドを使用したパラメータの割当てSOAコンポジット・アプリケーション内のBPELプロセス・ダイアグラムのassignアクティビティに、マップされた付加フレックスフィールドを表示して、ペイロードから受け取った入力変数をinvokeアクティビティに渡してSynAccOrderサービスを起動するために使用できます。Locationオブジェクトに渡します。ターゲット・パラメータns2:ATTRIBUTE1は、前述のフレックスフィールド構成時に次の付加フレックスフィールド列にマップされています。(コンテキスト値<sequence(Ecuador)>の下)ターゲット・パラメータns2:ATTRIBUTE2は、前述のフレックスフィールド構成時に次の付加フレックスフィールド列にマップされています。(コンテキスト値<sequence(Ecuador)>の下)コンテキスト値によってグループ分けされたこれらの付加フレックスフィールド列が、assignアクティビティ内に表示されます。「From」ナビゲーション・ツリーで、「変数」→「プロセス」→「変数」→「Invoke_SynchRead_OutputVariable」→「本文」→「ns2:InputParameters」→「ns2:P_ORG_CUST_OBJ」→「ns2:ORGANIZATION_OBJ」→「ns2:PARTY_SITE_OBJS」→「ns2:PARTY_SITE_OBJS_ITEM」→「ns2:LOCATION_OBJ」→「ns2:HZ_LOCATIONS」→「ns3:ATTRIBUTE_CATEGORY」にナビゲートし、「<choice>」アイコンを展開して、選択したコンテキスト値ns3:Chileについてマップした付加フレックスフィールド列ns3:Regionおよびns3:Comunaを見つけます(または、選択したコンテキスト値ns3:Ecuadorに対してns3:Zonaとns3:Parroquiaを選択します)。「To」ナビゲーション・ツリーで、「Invoke_SyncOrder_InputVariable」→「InputParameters」→「ns2:InputParameters」→「ns2:P_ORG_CUST_OBJ」→「ns2:ORGANIZATION_OBJ」→「ns2:PARTY_SITE_OBJS」→「ns2:PARTY_SITE_OBJS_ITEM」→「ns2:LOCATION_OBJ」→「ns2:HZ_LOCATIONS」→「ns3:ATTRIBUTE_CATEGORY」にナビゲートし、「<choice>」アイコンを展開して、選択したコンテキスト値ns3:Chileについてマップした付加フレックスフィールド列ns3:Regionおよびns3:Comunaを見つけます(または、選択したコンテキスト値ns3:Ecuadorに対してns3:Zonaとns3:Parroquiaを選択します)。assignアクティビティ内の付加フレックスフィールドにパラメータを割り当てるには、ソース・ノード(ns3:Region)をドラッグして、前述の操作で指定した最初のターゲット・ノード(ns3:Region)に接続します。これでソース・ノードとターゲット・ノードを接続する線が作成されます。コピー・ルールは、「Assignの編集」ダイアログ・ボックスの下部にある「From」セクションと「To」セクションに表示されます。同じ手順を繰り返し、同じソース・ノード(ns3:Comuna)をドラッグして2番目のターゲット・ノード(ns3:Comuna)に接続し、2番目のパラメータを割り当てます。2番目のコピー・ルールは、「Assignの編集」ダイアログ・ボックスの下部にある「From」セクションと「To」セクションに表示されます。「適用」をクリックして「OK」をクリックし、assignアクティビティの構成を完了します。ソースとターゲットのns2:InputParameters変数はどちらも同じものなので、単にソース・ノード(ns2:InputParameters)をターゲット・ノード(ns2:InputParameters)にドラッグして接続するという方法で、assignアクティビティを完成させることもできます。WebLogic管理対象サーバー(たとえばsoa-server1)にデプロイすると、前述のように構成した付加フレックスフィールドがsoa-server1サーバーに表示され(http://<servername>:<portnumber>/soa-infra)、ペイロード・データを指定してサービスの起動をテストできます。Controlコンソールからも実行できることに注意してください。Controlコンソールからも実行できることに注意してください。この例では、マップされた付加フレックスフィールドが、最上位レベルから複数のサブレベルにネストされた入力ペイロードの一部として使用されています。これは、マップされた付加フレックスフィールド(RegionとComuna)に到達して表示するためには、最上位レベルからいくつものパラメータ・ノードを展開する必要があることを意味します(「ペイロード」→「P_ORG_CUST_OBJ」→「ORGANIZATION_OBJ」→「PARTY_SITE_OBJS」→「PARTY_SITE_OBJS_ITEM」→「LOCATION_OBJ」→「HZ_LOCATIONS」→「ATTRIBUTE_CATEGORY」→「HZ_LOCATIONS_1」)。Controlコンソールでのペイロード・パラメータの表示には一定の制限があります。したがって、この場合は、マップした付加フレックスフィールドにsoa-server1サーバー内のsoa-infraから直接アクセスします。Controlコンソールからサービスの起動をテストする方法の詳細は、「BPELプロセスを使用したデプロイ済SOAコンポジット・アプリケーションのテスト」を参照してください。DescFlexプロジェクト(「Test_bpelprocess1_client_ep」リンク)をクリックして、BPELプロセス情報をHTMLで表示します。「ペイロード」セクションでP_ORG_CUST_OBJノードを展開し、「ORGANIZATION_OBJ」→「PARTY_SITE_OBJS」→「PARTY_SITE_OBJS_ITEM」→「LOCATION_OBJ」→「HZ_LOCATIONS」→「ATTRIBUTE_CATEGORY」→「HZ_LOCATIONS_1」にナビゲートします。前述の設計時に構成した付加フレックスフィールドの2つのセットが、実行時に表示されるようになりました。(設計時にassignアクティビティに構成したデフォルトの選択肢)RegionComunaHZ_LOCATIONS_1_1ZonaParroquia適切なデータをペイロードとして入力し、「起動」をクリックしてサービスを起動します。既存のフレックスフィールド・マッピングのインポート新しいマッピングを構成するかわりに、選択したAPIのために単に既存のマッピングをインポートすることもできます。構成済のマッピングを使用すれば、APIのフレックスフィールド・マッピングを短時間で確立したり、構成済のマッピングを土台として必要に応じた変更を加えることができます。既存のマッピングをインポートするには、「フレックスフィールドの構成」領域で「ファイルからインポート」をクリックします。「オープン」ウィンドウが表示され、目的のフレックスフィールド・マッピングを選択できます。目的のフレックスフィールド・マッピングの選択インポートするマッピングを選択したら、「オープン」をクリックします。選択したマッピング・ファイルが「フレックスフィールド・データのインポート」のプロジェクト・フィールドに自動的に表示されます。OE_ORDER_PUB_PROCESS_LINE_mapping.xmlファイルを選択すると、選択したAPIに対してインポートされたマッピングが、選択したマッピング・ファイル名とともに自動的に「パラメータと対応するフレックスフィールドのマッピング」領域に表示されます。選択したAPIに対して希望するマッピングをインポートするときには、キー・フレックスフィールドの構造と付加フレックスフィールドのコンテキスト値を選択する必要があります。「フレックスフィールド定義」セクションで変更が必要なキー・フレックスフィールドまたは付加フレックスフィールドを選択し、「編集」をクリックします。ようこそ」ページが表示されます。「次へ」をクリックし、付加フレックスフィールドの場合は希望するフレックスフィールド・コンテキスト値を選択します。「終了」をクリックして、付加フレックスフィールドのマッピング情報を完成させます。更新された付加フィールド・コンテキスト値(SSE_Country)が、「パラメータと対応するフレックスフィールドのマッピング」領域と「フレックスフィールド定義」セクションの両方に追加されます。「OK」をクリックする前に、同じアプローチを使用して、構造情報を必要とするキー・フレックスフィールドを更新します。選択したマッピングの詳細を変更する方法の詳細は、「フレックスフィールド定義の変更」を参照してください。Applicationsでは、キー・フレックスフィールドと付加フレックスフィールドの両方について、必要に応じて何回でもフレックスフィールド定義を変更できます。変更できるのは付加フレックスフィールドのコンテキスト値とキー・フレックスフィールドの構造のみです。構造またはコンテキスト値の変更以上の更新が必要な場合は、まずそのフレックスフィールド・マッピングを削除してから新しいフレックスフィールド・マッピングを構成する必要があります。フレックスフィールド・データの変更フレックスフィールド・データを変更するには、「フレックスフィールド定義」セクションで変更するキー・フレックスフィールドまたは付加フレックスフィールドを選択し、「編集」をクリックします。選択したフレックスフィールド・タイプに対応する適切なフレックスフィールド・ページが表示され、そこでフレックスフィールドの詳細を変更できます。フレックスフィールドのマッピング・データの変更たとえば、付加フレックスフィールド(HZ_LOCATIONS)の構造を変更します。ようこそウィザードで「次へ」をクリックすると、「フレックスフィールドの構成」ウィンドウが表示されます。「問合せ」をクリックし、コンテキスト値として「Ecuador」チェック・ボックスのみを選択します。「終了」をクリックして変更を完了します。更新されたフレックスフィールド情報が、「フレックスフィールド定義」セクションに反映されます。変更したフレックスフィールド・マッピング・データの検証フレックスフィールド構成xmlファイル(<projectname>_flex-config.xml)で変更を検証することもできます。「フレックスフィールドの構成の確認」を参照してください。それぞれの「フレックスフィールドのサブフロー」ウィンドウの構成または追加方法の詳細は、「新しいマッピングの追加または構成」を参照してください。フレックスフィールド・データの削除フレックスフィールド・データを削除するには、削除するキー・フレックスフィールドまたは付加フレックスフィールドを選択して「削除」をクリックします。選択したフレックスフィールド・データとそれに関連付けられた構造または値がデータベースから削除されます。複数のフレックスフィールドを削除対象として選択するには、[Control]キーや[Shift]キーを使用します。Contentフォルダを展開して拡張XSDファイル(たとえばProcessItem_KFF_flex.xsd)を選択し、前述の構成または更新したフレックスフィールド情報を検証します。設計時に選択されたマッピングに基づいて、拡張スキーマ情報がフレックスフィールド・セグメント名とともに表示されます。拡張XSDファイルの表示さらに、XSDファイルに加えて次の2つのxmlファイルが作成されます。マッピングxmlファイル(たとえばINV_EBI_ITEM_PUB_PROCESS_ITEM_LIST_ProcessItem_KFF_mapping.xml)には、マッピング・ウィザード・パネルで取得されたマッピング情報が格納されます。この情報は、同じAPIのために再利用したり、別のパートナ・リンクからインポートすることができます。選択したAPIに対してフレックスフィールド・マッピングをインポートする方法の詳細は、「既存のフレックスフィールド・マッピングのインポート」を参照してください。(たとえばOE_ORDER_PUB_PROCESS_LINE_GL_Flexfield_flex-config.xml)には、キー・フレックスフィールドおよび付加フレックスフィールドの両方を含む(両方が構成されている場合)フレックスフィールド情報が格納されます。これは再利用できません。構成xmlはパートナ・リンク内のファイルであり、編集も再利用もできないことに注意してください。Suiteのロギング・フレームワークを実装し、診断ログ・ファイルをテキスト形式で記述します。Suiteサービスを起動すると、必ずシステム管理者がアクセスできるログ・メッセージが記録されます。Applicationsの実行時に、サービスを起動する際の問題を追跡できるようになります。Logging(ODL)形式でsoa-diagnostic.logファイルにリダイレクトされます。これらのログ・ファイルは、すべてのタイプのイベント(起動と停止の情報、エラーと警告メッセージ、HTTPリクエストへのアクセス情報、追加情報など)を記録します。これによって、発生する可能性のある問題を管理者が効率的に特定して解決するために役立つ、起動プロセスについてのインサイド・アウトのクイック・ビューが表示されます。Applicationsおよびテクノロジ・アダプタの実行時に単一ファイルに書き込まれたODLレベルのログ・ファイルを表示できます。ロギング・メカニズムがどのように動作するかについては、この章の次の項で説明します。Suite管理者ガイド』を参照してください。Logging(ODL)形式でリダイレクトされます。Controlコンソールを使用して、適切なメッセージ・タイプとそれに関連付けられたログ・レベルをログ出力oracle.soa.adapter用に設定し、有効にする必要があります。Suiteレベルでログ設定が有効になります。JCAアダプタに対応するログ出力名はoracle.soa.adapterと呼ばれます。次の表に、診断メッセージ・タイプとログ・レベルを示します。各メッセージ・タイプで、メッセージ・レベルに設定できる値は1(重大度が最も高い)から32(重大度が最も低い)です。各メッセージ・タイプに一部のレベルだけがサポートされているコンポーネントもあります。一般に、タイプだけで指定する必要があり、レベルを指定する必要はありません。各ログ出力のデフォルトのメッセージ・タイプは、NOTIFICATION、レベル1に設定されています。製品の不具合によって発生し、Oracleサポートに報告する必要のある深刻な問題。リカバリ不能なエラーなどの深刻な問題があります。管理者が注意する必要があるが、製品の不具合によって発生するものではない深刻な問題。Middlewareではログ・ファイルを処理できないが、ドキュメントに対する権限を修正することで問題を解決できる場合などが、これに該当します。管理者による確認を要する、潜在的な問題。プライマリ・サブコンポーネントや機能のアクティブ化や非アクティブ化などの主要なライフサイクル・イベント。通常のイベントをレポートする粒度の詳細なレベル。パブリックAPIエントリや終了ポイントなど、管理者に重要なイベントに関するトレースまたはデバッグ情報。特定のサブシステムにおける問題を診断するためにOracleサポート・サービスが利用できる詳細トレース情報または詳細デバッグ情報。特定のサブシステムにおける問題を診断するためにOracleサポート・サービスが利用できるきわめて詳細なトレース情報またはデバッグ情報。Applicationsに診断メッセージ・タイプとログ・レベルを設定する手順:次の手順に従って、メッセージ・タイプとそれに関連付けられたログ・レベルを設定します。http://<servername>:<portnumber>/emに移動します。Controlコンソールのホーム・ページが表示されます。ユーザー名とパスワードを入力して、コンソールにログオンします。「ナビゲータ」ツリーで「SOA」フォルダの「soa-infra」を右クリックします。ポップアップ・メニューから「ログ」>「ログ構成」を選択します。SOAインフラストラクチャ」メニューをクリックして、ドロップダウン・メニューから「ログ」>「ログ構成」を選択しても、「ログ構成」ページにアクセスできます。Logging(ODL)レベルを構成できる「ログ構成」ページが開きます。「ログ・レベル」タブを選択します。「表示」ドロップダウン・リストから次のいずれかの値を選択します。ランタイム出力は、実行時に自動的に作成され、サービスの実行時にアクティブになります。oracle.soa.b2bまたはoracle.soa.bpelはランタイム出力です。ランタイム出力のログ・レベルは、コンポーネントを再起動するとリセットされます。永続ログ出力は、構成ファイルに保存され、コンポーネントの起動時にアクティブになるログ出力です。これらのログ出力のログ・レベルは、コンポーネントを再起動しても保持されます。デフォルトでは、ログ・レベルはランタイム出力用に設定されています。ランタイム出力は、コンポーネントを再起動するとリセットされます。コンポーネントを再起動してもログ・レベルが保持されるようにするには、「表示」リストから「永続ログ・レベル状態のログ出力」を選択します。oracle.soaノードを展開し、「ログ出力名」リストでoracle.soa.adapterランタイム・ログ出力を検索します。Diagnosticの「ログ・レベル」ドロップダウン・リストからログ出力レベルを選択します。(FINEST)」を選択します。「適用」をクリックします。「ログ・ファイル」列に表示されるログ・ヘッダー・リンクをクリックして、特定のログ・ファイルを編集できます。基本的な構成設定や詳細なログ設定を構成できる「ログ・ファイル」タブが開きます。これらの設定には、ハンドラ名、ログ・メッセージが記録されるログ・ファイル、ログ・メッセージの処理機、使用されるローテーション・ポリシー、ログ・ファイル構成クラスに基づくその他のパラメータが含まれます。表からログ・ハンドラを選択し、「構成の編集」を選択します。「ログ・ファイルの編集」ダイアログ・ボックスが表示されます。ログ・ファイルの場所を変更するには、「ログ・パス」フィールドで新しいパスを入力します。メッセージ・レベルを構成するには、「ログ・レベル」ドロップダウン・リストからロギング・レベルを選択します。(FINEST)」を選択します。ログ・ファイル・ローテーションを構成するには、「ローテーション・ポリシー」セクションで、適切な情報を指定して、「サイズ・ベース」または「時間ベース」のログ・ファイルを選択します。Middleware管理者ガイド』の「ログ・ファイルと診断データの管理」の章を参照してください。Suite管理者ガイド』を参照してください。APIおよびコンカレント・プログラムのインタフェースが起動されている間、これらのインタフェースのロギングを自動的に制御または有効化できます。Suite側でFNDロギング・フレームワークを別途有効化する必要はありません。Suiteリリース12.1.3以上のみです。Suiteのログ・レベルのマッピングを次の表に示します。Logging(ODL)フォーマットで実行時に単一ファイルに書き込まれたログ・ファイルがリダイレクトされます。アウトバウンドとインバウンドの両方の相互作用で、ログ・ファイルは単一ファイルsoa-diagnostic.logにリダイレクトされます。Suiteのログ・ファイルは、MW_HOME/user_projects/domains/<domain_name>/servers/server-soa/logs/soa-diagnostic.logに格納されます。displayLogsコマンドライン・ツールを使用するか、またはローカル・クライアントにログ・ファイルをダウンロードして、別のツール(テキスト・エディタや別のファイル表示ユーティリティなど)を使用して表示します。Middleware管理者ガイド』の「ログ・ファイルおよび診断データの管理」の章を参照してください。Controlコンソールからアダプタ・ログを検索します。http://<servername>:<portnumber>/emに移動します。Controlコンソールのホーム・ページが表示されます。ユーザー名とパスワードを入力して、コンソールにログオンします。左側のペインにある「ナビゲータ」ツリーから「ログ・メッセージ」ページにアクセスするには、次の2つの方法があります。「SOA」フォルダから「soa-infra」を右クリックします。「SOA」フォルダからのナビゲート「WebLogicドメイン」フォルダから「soainfra」を右クリックします。「WebLogicドメイン」フォルダからのナビゲートポップアップ・メニューから「ログ」>「ログ・メッセージの表示」を選択します。「ログ・メッセージ」ページに、「検索」セクションとデフォルトの検索基準が表示されたメッセージのサマリーが表示された表が表示されます。Applicationsのログ・メッセージを検索するための検索基準を入力します。ドロップダウン・リストから値を選択し、適切な数値を入力します。「最新」として6時間などです。ドロップダウン・リストから「時間間隔」を選択する場合は、カレンダ・アイコンで「開始日」を選択した後、日付と時間を選択します。同様に、カレンダ・アイコンで「終了日」を選択した後、日付と時間を選択します。1つ以上のメッセージ・タイプを選択します。Applications用に以前に構成されているメッセージ・タイプの場合は、「トレース」チェック・ボックスを選択します。Adapterと入力します。必要に応じて、「検索」セクションに追加の検索基準を指定します。「フィールドの追加」をクリックして、さらに検索基準を追加することもできます。この操作によって、ホストなどさらに基準を追加でき、検索結果を特定のホストに絞り込むことができます。その後、「追加」をクリックします。「検索」をクリックして、検索を実行します。検索基準に一致するすべてのメッセージが検索され、表に表示されます。これらのメッセージはメッセージとして表示することも、「表示」フィールドで選択した値に応じて、メッセージ・タイプやメッセージIDごとにグループ分けすることもできます。表からいずれかのログ・メッセージをクリックします。ID)、関係ID、実際のメッセージなどのメッセージの詳細がメッセージ表の下に表示されます。「ECID」リンクをクリックすると、「ECIDごとの関連メッセージ」ページに同じECIDを持つ関連メッセージが検索されます。関連メッセージの詳細は、「ログ・ファイルとコンポーネント間のメッセージの関連付け」を参照してください。Diagnosticログ・テキスト・ファイル(.txt)、XMLファイル(.xml)またはカンマ区切りリスト(.csv)ファイルとしてエクスポートする場合は、「メッセージをファイルにエクスポート」ドロップダウン・リストから適切な出力オプションを選択します。「ターゲット・ログ・ファイル」をクリックして、管理対象サーバー(server-soa)に関連するログ・ファイルのリストが表示される「ログ・ファイル」ページを開きます。「ログ・ファイル」ページファイルを選択して「ログ・ファイルの表示」をクリックします。選択したログ・ファイルの「ログ・ファイルの表示」ページが表示され、このログに含まれるメッセージのリストを表示できます。「ログ・ファイルの表示」ページメッセージの詳細を表示するには、メッセージを選択します。メッセージ・レベル、コンポーネント、ECID、関係ID、実際のメッセージなどのメッセージの詳細が、メッセージ表の下に表示されます。時間またはECIDを基準にして関連メッセージを表示するには、「関連メッセージの表示」をクリックして、「時間ごと」または「ECID(実行コンテキストID)ごと」を選択します。メッセージの詳細から「ECID」リンクを直接クリックしても、「ECIDごとの関連メッセージ」ページに同じECIDを持つ関連メッセージを検索できます。Middlewareコンポーネントは、診断メッセージにメッセージ相関情報を提供します。メッセージ相関情報は、診断メッセージを表示したユーザーがコンポーネント間のメッセージの関係を判定する際に役立ちます。診断メッセージのそれぞれに、実行コンテキストID(ECID)と関係IDが組み込まれています。ECIDは、特定のリクエストの実行に関連付けられたグローバルに一意の識別子です。ECIDは、リクエストが最初に処理されるときに生成されます。関係IDは、同じリクエストのかわりに、あるプロセスの1つのスレッドで実行された作業と、このプロセスまたは他のプロセスの別のスレッドで実行された作業を区別します。Controlコンソールにログ・メッセージを表示した状態で、ログ・メッセージを選択した後、「関連メッセージの表示」ドロップダウン・リストから次のいずれかの値を選択すると、関連するメッセージを表示することができます。選択されているときだけ選択できます。「表示」フィールドで「メッセージ・タイプ別グループ」または「メッセージID別グループ」が選択されていると、一致するすべてのメッセージがメッセージ・タイプまたはメッセージIDごとにグループ分けされて表示されます。この場合、「関連メッセージの表示」フィールドは使用できません。「時間ごとの関連メッセージ」ページが表示され、選択したメッセージと同じタイムスタンプを持つすべてのメッセージが表示されます。「ECID(実行コンテキストID)ごと」ページが表示され、選択したメッセージと同じECIDを持つすべてのメッセージが表示されます。「ECIDごとの関連メッセージ」ページメッセージの関連付け情報を使用して関連メッセージを検索して、複数のメッセージを調査し、最初に問題が発生したコンポーネントを識別できます。メッセージ相関データは、コンポーネント間で診断メッセージのクリア・パスを確立する際に役立ち、これによって、エラーおよびそれに関連した動作を理解できます。Applicationsでは、わかりやすく説明的な例外やエラー・メッセージを生成するようになりました。APIまたはコンカレント・プログラムの起動中に使用できます。APIが生成した機能エラーを、取得するために追加のコールを行う必要なくいつでも取得できます。これらのメッセージにより、ランタイムにおける障害の原因を特定しやすくなります。Applicationsに関するすべてのエラーと例外およびデバッグ情報がロギングされます。これにより、実行中に発生したことを管理者や開発者が把握し、問題解決に必要な行動を取りやすくなります。注文番号が存在しません)がスローされ、このようなエラーに機能エラーが含まれます。このタイプの例外は、API実行中の機能的な問題な問題を報告するために幅広く使用されます。APIでは、機能エラーはAdapterのランタイム・エンジンによって捕捉されたSQLExceptionとして、コードとメッセージとともに、あるいはAPI出力パラメータの一部としてスローできます。APIは実行中に機能エラーをスローせず、メモリ・スタックに蓄積し続けます。エラーをフェッチする責任は、APIのコール元に繰延べられます。APIは、FND_MSG_PUB.putパッケージを使用して、FND_MESSAGEスタックに機能エラーを配置します。APIコールが完了したら、コール元はFND_MSG_PUB.GET()メソッドを使用して、このスタックから明示的にエラーをフェッチする必要があります。このリリースでは、エラー・メッセージはスタックFND_MSG_PUBからのみ取得できます。明示的な処理が必要なAPI用には、APIErrorHandlerという新しいJCAプロパティが導入され、FND_MESSAGEメモリ・スタックから機能エラーをフェッチできるようになりました。このプロパティがエラーのフェッチ用インジケータとして機能することで、コール元は明示的に取得するためのコールを行う必要なくエラーを取得できます。ApplicationsはJCAプロパティAPIErrorHandlerの存在をチェックします。APIの実行直後にエラー・ハンドラが呼び出されます。このようなAPIの機能エラーをフェッチするには、次の機能エラー処理パラメータをWSDLファイル(XX_apps.jca)に追加する必要があることに注意してください。Suite間の保護された接続に対してJ2EEデータ・ソースを実装することには、2つの明確な利点があります。Applicationsのユーザー名とパスワードの概念)のみを使用して、安全に接続できることです。2つ目は、パスワードがミドルウェアに保存されないことです。Suite間で同期して保持する必要がありません。Suiteデータベースに接続します。この新しいメカニズムにより、データベース接続の構成の一環として必要なアプリケーション・ログインのユーザー名およびパスワードなどのアカウントの詳細情報が、J2EEデータ・ソース作成時に入力パラメータとしてdbcファイルの位置とともに追加されます。SuiteデータベースへのJ2EEデータ・ソース接続を定義します。Suite環境にサービス指向アーキテクチャ(SOA)スイート中間層ノードを登録し、接続をインスタンス化するためのデータ・ソース実装で使用されるdbcファイルを生成します。SOAスイート・サーバーが稼動する中間層サーバーにdbcファイルをコピーし、SOAスイートの所有者がアクセス権を持つファイル・システム上の場所に配置します。接続プールを作成します。ここには、コネクション・ファクトリのプロパティとしてアプリケーションのログイン・ユーザー名、パスワードおよびdbcファイルの場所を入力する必要があります。アプリケーション・データ・ソースを作成します。Interface(JNDI)名と関連付けます。Suiteリリース12は12.0.4リリースであることが必要です。Suiteと外部アプリケーション・サーバー間の接続を有効化するのに必要なパッチを適用する必要があります。11g』を参照してください。Applicationsの主要なコンポーネントです。Applicationsモジュール・ブラウザを使用して参照できます。パートナ・リンクの定義に必要なインタフェースを選択するには、モジュール・ブラウザを使用します。次のように使用して、目的のインタフェースを見つけることができます。Browser上で見つけます。Applicationsでサポートされるその他のインタフェースに関する情報と組み合せます。ツリー構造の展開によるインタフェース参照サポートされているインタフェースは、次のようなツリー階層に整理されます。Repositoryを介して使用することはできません。11.5.10インスタンスが使用されている場合にのみ表示されます。Suiteリリース11.5.9やリリース12のインスタンスに接続している場合には表示されません。Repositoryインタフェース・データは、[product_family]セクションを移入し、所属する製品およびビジネス・エンティティに従ってグループ化します。「その他インタフェース」以下でのビジネス・イベントとカスタム・インタフェースの参照ビジネス・イベントとカスタム・インタフェースは、「その他インタフェース」ノードの下に表示されます。Applicationsモジュール・ブラウザ」の「その他インタフェース」ノードの下に表示されます。ビジネス・イベント・グループは、個別のビジネス・イベントのセットが含まれるイベント・タイプです。「その他インタフェース」→「ビジネス・イベント」→「アウトバウンド」→「グループ」ノードをクリックすると、ビジネス・イベント・グループが表示されます。Applicationsモジュール・ブラウザで「その他インタフェース」→「カスタム・オブジェクト」ノードの下に表示されます。カスタム・インタフェースの参照サポートされているカスタム・インタフェースは、次のようにリストされます。APIは、2箇所に表示されます。Repositoryを介してすでに公開されているパッケージ内のプロシージャは、製品ファミリ階層内のパッケージ名の下に表示されます。完全に新しいパッケージ内のプロシージャは、「その他インタフェース」→「カスタム・オブジェクト」の下のパッケージ名の下に表示されます。Gatewayマップはインバウンドとアウトバウンドのいずれかに分類されます。Gatewayマップを表示するには、いずれかのノードを選択します。カスタマイズされたコンカレント・プログラム「カスタム・オブジェクト」ノードの下にある「コンカレント・プログラム」ノードをクリックすると、すべてのカスタム・コンカレント・プログラムが表示されます。