4 カスタム属性のフレックスフィールド

この章は、次のように構成されています。

フレックスフィールド: 概要

フレックスフィールドは、ビジネス・オブジェクトに関連する拡張可能なプレースホルダ・フィールドのセットであり、アプリケーション・ページ上に配置されます。フレックスフィールドを使用することで、データ・モデルを変更したりデータベース・プログラミングを実行したりせずに、ビジネス・オブジェクトを拡張し、企業のデータ管理要件を満たすことができます。フレックスフィールドにより、同じデータベース表上の様々なデータを取得できます。

たとえば、航空機製造業者は、事前定義されていない固有の属性をそのオーダーで必要とする場合があります。オーダー・ビジネス・オブジェクトにフレックスフィールドを使用すると、必要な属性を作成して構成できます。

アプリケーション・ページに表示されるフレックスフィールドは、事前定義されています。ただし、フレックスフィールドは構成や拡張が可能であり、そのプロパティを変更することもできます。ユーザーにはそれらのフレックスフィールドは、UIページ上のフィールド属性または情報属性として表示されます。フレックスフィールドを使用するには、「設定および保守」作業領域にある「フレックスフィールドの定義」タスク・リストを検索して開きます。その中に含まれている次のタスクを使用できます。

  • 付加フレックスフィールドの管理: アプリケーション・ページ上で、ビジネスに固有の重要な追加情報に対応するフォームを展開します。請求書を表示するページ上でカスタム請求書詳細を収集するために、付加フレックスフィールドを使用できます。

  • 拡張可能フレックスフィールドの管理: 1対多のデータ関係を確立し、アプリケーション・データをコンテキスト依存にします。フレックスフィールドは、コンテキスト・データ条件が満たされている場合にのみ表示されます。したがって、拡張可能フレックスフィールドの方が、付加フレックスフィールドよりも高い柔軟性があります。

  • キー・フレックスフィールドの管理: 番号の組合せなど、いくつかの値を組み合せた情報を格納します。キー・フレックスフィールドは、会計コードや資産カテゴリなどのオブジェクトを表します。

  • 値セットの管理: 値のグループを使用して、フレックスフィールドに入力されたデータを検証します。

    注意: 「付加フレックスフィールドの管理」タスクまたは「拡張可能フレックスフィールドの管理」タスク内の値セットは管理できます。

特定の事前定義されたフレックスフィールドの詳細を参照するには、「設定および保守」作業領域を開き、「フレックスフィールドの定義」タスク・リスト内のタスクを使用します。

フレックスフィールドのタイプ

次の3タイプのフレックスフィールドは、プログラミングなしでアプリケーションの機能をカスタマイズする手段となります。

  • 付加

  • 拡張可能

  • キー

関連トピック

フレックスフィールドの構成: 概要

フレックスフィールドの構成は、カスタム属性があるビジネス・オブジェクトの拡張の必要性を識別することから始まり、カスタム属性をデプロイメント内に統合することで終わります。キー・フレックスフィールドの場合、フレックスフィールドの構成には、値セットの割当てを識別し、セグメント構造を判別することが関係します。

カスタム属性の構成のための総合プロセス

付加および拡張可能のフレックスフィールドの場合、総合的な構成プロセスには次の作業が伴います。

  1. 「管理」メニューからフレックスフィールドの強調表示機能を使用して、ページ上でビジネス・オブジェクトに関連するフレックスフィールドを検出します。

  2. フレックスフィールドの構成を計画します。

  3. フレックスフィールドの検証を計画します。

  4. フレックスフィールド・セグメントを構成することで、属性を定義します。

    1. 「付加フレックスフィールドの管理」タスクまたは「拡張可能フレックスフィールドの管理」タスクを使用するか、あるいはフレックスフィールドが強調表示されているページ上でフレックスフィールドの構成アイコン・ボタンを直接使用します。単純な構成の場合、フレックスフィールドが強調表示されているページ上で直接、セグメントの追加、コンテキスト値の追加、およびセグメントの編集アイコン・ボタンを使用します。

    2. オプションで、フレックスフィールド構成を検証します。

    3. オプションで、フレックスフィールドを初期テスト用にサンドボックスにデプロイします。

  5. フレックスフィールドをメインライン・メタデータにデプロイして、アプリケーション・ページ上にカスタム属性を表示し、それらをOracle Business Intelligenceなどの他のツールとの統合に使用できるようにします。

  6. カスタム属性をテクノロジ・スタックに統合するために必要な手順を実行します。

単純な構成は、フォーマット専用フィールドの追加や、値の基本リストがあるフィールドの追加などのアクションに限定されます。

カスタム・キーの構成のための総合プロセス

キー・フレックスフィールドを使用すると、ビジネス・プラクティスに従い、有意義な部分を含むインテリジェント・キー・コードを構成できます。キー・フレックスフィールドは、キー・コードを構成する各部分に対して1つのセグメントを持つように構成します。

キー・フレックスフィールドの場合、総合的な構成プロセスには次の項目が関係します。

  1. 「管理」メニューからフレックスフィールドの強調表示機能を使用して、ページ上でビジネス・オブジェクトに関連するフレックスフィールドを検出します。

  2. フレックスフィールドの構成を計画します。

  3. フレックスフィールドの検証を計画します。

  4. キー・フィールド・セグメントを構成する前に、「値セットの管理」タスクに移動して、値セットを定義します。

  5. キー・フレックスフィールド構成とそのセグメントを定義し、各構成の構成インスタンスを定義します。

    1. 「キー・フレックスフィールドの管理」タスクを使用するか、またはフレックスフィールドが強調表示されているページ上でフレックスフィールドの構成アイコン・ボタンを直接使用します。

    2. オプションで、フレックスフィールド構成を検証します。

    3. オプションで、フレックスフィールドを初期テスト用にサンドボックスにデプロイします。

  6. フレックスフィールドをメインライン・メタデータにデプロイしてアプリケーション・ページ上に表示し、Oracle Business Intelligenceなどの他のツールとの統合に使用できるようにします。

  7. フレックスフィールドをテクノロジ・スタックに統合するために必要な手順を実行します。

フレックスフィールドのコンポーネント: 説明

フレックスフィールドは、フレックスフィールド構成に関係する情報を格納およびレンダリングする、いくつかのデータ・エンティティで構成されます。

フレックスフィールドは、次のコンポーネントで構成されます。

  • セグメント

  • 値セット

  • コンテキスト

  • 構成

セグメント

セグメントはフレックスフィールド内のフィールドであり、データベースの単一の表列を表します。フレックスフィールドを構成するときは、個々のセグメントの外観と意味を定義します。セグメントは、情報の属性を表します。セグメントは、フレックスフィールドが実装されている場所であればどこでもグローバルに、または構成やコンテキストに基づいて表示できます。各セグメントは、単一のアトミック値を取得し、情報の属性を表します。

セグメントの特性は、それが使用されているフレックスフィールドのタイプによって異なります。

  • キー・フレックスフィールドでは、セグメントはエンティティの特性を記述します。これはたとえば、アイテムのタイプ、色およびサイズに関する詳細を含む部品番号などです。

  • 付加フレックスフィールドまたは拡張可能フレックスフィールドでは、セグメントはアプリケーション・ページ上の情報属性を表します。これはたとえば、一部がグローバルで、残りがデバイスのカテゴリにコンテキスト依存するコンポーネントを含むデバイスに関する詳細などです。

値セット

ユーザーはアプリケーションの使用時に、セグメントに値を入力します。値セットは、フレックスフィールド・セグメントの内容を検証する、値の名前付きグループです。フレックスフィールド・セグメントを値セットで構成して、そのセグメントに有効な値のみが入力されるようにします。

構成には、次のタスクが関係します。

  • 値セットの値の定義。これには値の長さやフォーマットなどの特性が含まれます。

  • アプリケーションの表または事前定義リストからのフォーマット設定ルールまたは値の指定。

1つまたは複数のフレックスフィールド内の複数のセグメントで、単一の値セットを共有できます。

コンテキスト

コンテキスト依存のフレックスフィールド・セグメントは、コンテキスト値に基づいてアプリケーションで使用できます。コンテキストは、フレックスフィールドの構成プロセスの一部として定義します。ユーザーには、グローバル・セグメントと、選択したコンテキスト値に適用されるコンテキスト依存セグメントが表示されます。

付加フレックスフィールドと拡張可能フレックスフィールドでは、複数のコンテキストで、データベースの列に基づくコンテキスト依存セグメントを再利用できます。

構成

キー・フレックスフィールドには構成があります。各キー・フレックスフィールド構成は、セグメントの具体的な構成です。セグメントの追加または削除、あるいはその順序の再配列により、異なる構成が作成されます。複数の構成で、データベースの列に基づくセグメントを再利用できます。

注意: これらすべてのフレックスフィールド・コンポーネントは、アプリケーションの言語セッションを変更しなくても優先言語に翻訳できます。すべての有効な言語行で翻訳を指定するには、それぞれの編集ページで翻訳エディタ・オプションを使用します。更新が行われると、ユーザーは実行時に特定のフレックスフィールド・コンポーネントの翻訳済テキストを表示できます。

ランタイムのフレックスフィールド: 説明

ビジネス・オブジェクトには、付加フレックスフィールドまたは拡張可能フレックスフィールドが関連付けられています。これらを使用して、ランタイムにビジネス・オブジェクトに対するカスタム属性を作成できます。一部のビジネス・オブジェクトには、柔軟な複数の部分キーを構成するための関連するキー・フレックスフィールドがあります。

ページ上のフレックスフィールドの検出

フレックスフィールド・セグメントとして定義したカスタム属性は、ランタイムでは他の属性と同じようにアプリケーション・ページに表示されます。ただし、フレックスフィールドのタイプごとに表示方法が異なります。

次に示す特性は、アプリケーション・ページ上のフレックスフィールドのタイプを判別するのに役立ちます。

  • 付加フレックスフィールド・セグメントは、ラベルとフィールドのペアとして、または列ヘッダーに対応するフィールドのテーブルとして表示されます。フィールドはフレックスフィールド・セグメントを表し、セグメントに割り当てられた値セットから導出される値を受け入れます。

  • 拡張可能フレックスフィールド・セグメントは、ラベルが付けられたリージョン内でグループ化されて表示されます。各グループはコンテキストであり、リージョン・ラベルはコンテキスト名です。

  • キー・フレックスフィールドは、アプリケーション・ページではキー・フレックスフィールド・アイコンが付いたフィールドとして表示されます。そのフィールドの値はセグメントのコレクションです。

ページ上でフレックスフィールドを見つけるには、グローバル・ヘッダーで、自分のユーザー名を選択し、「設定およびアクション」メニューで、フレックスフィールドの強調表示を選択します。ページは特殊モードでレンダリングされ、ページ上にフレックスフィールドがあれば、その位置が示されます。以下を実行します。

  • 情報アイコンにカーソルを合わせ、フレックスフィールドの詳細を表示します。

  • フレックスフィールドの構成アイコンをクリックし、フレックスフィールドの管理タスクを使用してフレックスフィールドを管理します。

  • コンテキスト値の追加、セグメントの追加、またはセグメントの編集アイコンをクリックして、コンテキスト値を追加するか、またはグローバルあるいはコンテキスト依存のフレックスフィールド・セグメントを編集します。これは、付加フレックスフィールドと拡張可能フレックスフィールドの両方に適用されます。

注意: すべてのフレックスフィールドがカスタム属性の作成に使用できるわけではありません。たとえば、一部のフレックスフィールドは保護されており、その構成をまったく編集できないか、または限定的な変更しかできません。製品固有資料を参照して、フレックスフィールドの使用に関する制限があるかどうかを確認してください。

単一のフレックスフィールドのすべてのセグメントは、デフォルトではまとめてグループ化されています。フレックスフィールド・セグメントのレイアウトと位置は、アプリケーション開発者によるページ上でのフレックスフィールドの配置に依存します。フレックスフィールドは、ページの別セクション、表内、独自のページまたはダイアログ・ボックスに表示することもできます。フレックスフィールド・セグメントのレイアウト、位置または他の表示機能の編集には、Oracle Composerを使用できます。

ページ上にフレックスフィールドを表示する必要がなくなったら、「管理」メニューでフレックスフィールドの強調表示解除を選択します。

ページ・コンポーザを使用したフレックスフィールドのカスタマイズ: 説明

ページ・コンポーザを使用して、ページに固有の、フレックスフィールドへのカスタマイズを作成できます。

ページ・コンポーザで、次のようにカスタマイズします。

  • 拡張可能フレックスフィールドの場合、「ソース」ビューでページを開き、EffContextsPageContainerタスク・フローにバインドされたリージョンを探します。これは、拡張可能フレックスフィールド属性とコンテキストのコンテナです。フレックスフィールド・コードと識別情報を表示するには、リージョンのプロパティ・パネルを開きます。リージョン内のコンポーネントをカスタマイズするには、目的のタグを選択して、「編集」をクリックします。

  • 付加フレックスフィールドの場合、「ソース」ビューでページを開き、<descriptiveFlexfield>要素を探します。要素のプロパティ・パネルを開き、フレックスフィールド・コードと識別情報を表示します。プロパティ・パネル内では、グローバルおよびコンテキスト依存セグメントのプロパティをカスタマイズしたり、ページ上のセグメントを並べ替えたりできます。

フレックスフィールドとOracle Applications Cloudのアーキテクチャ: 連携方法

追加データを取得するために、管理者または実装者は、ビジネス・オブジェクトの属性を表すフレックスフィールド・セグメントを構成します。ビジネス・オブジェクトは、付加フレックスフィールドと拡張可能フレックスフィールドの両方に対応しています。

次の図は、フレックスフィールドの構成に関係したレイヤーを示しています。

  • データベース内のビジネス・エンティティ表およびメタデータ。

  • ADFビジネス・コンポーネント・オブジェクト。これらはメタデータから導出され、Oracle Metadata Services (MDS)リポジトリに格納されます。

  • フレックスフィールド・セグメントにより定義されたフィールドがレンダリングされるユーザー・インタフェース。

次の図に、構成時に定義されたすべてのメタデータで構成され、データベースに格納されたフレックスフィールド定義を示します。

図は、アプリケーション開発でフレックスフィールド・セグメントを有効にするために、フレックスフィールドを定義し、データベースに容量を追加するワークフローを示しています。フレックスフィールドが作成されて登録されたら、管理者は定義がデータベースに格納されるようにそのフレックスフィールドを構成します。関連するビジネス・コンポーネントは、Metadata Servicesリポジトリにデプロイされます。結果として、フレックスフィールドを表す属性がユーザー・インタフェースで使用できるようになり、それらのビジネス・コンポーネントはアクセス可能になります。

アプリケーション開発者は、フレックスフィールドを作成して登録し、構成に使用できるようにします。管理者と実装コンサルタントは、使用可能なフレックスフィールドのセグメントや他のプロパティを構成します。この情報は、データベース内に追加のフレックスフィールド・メタデータとして格納されます。フレックスフィールドをデプロイすると、データベース内のフレックスフィールド・メタデータに基づいて、ADFビジネス・コンポーネントが生成されます。

フレックスフィールドとOracle Applications Cloudアーキテクチャの連携方法を理解するためには、次の側面が重要です。

  • 統合

  • デプロイメント

  • インポートとエクスポート

  • ランタイム

  • パッチ適用

統合

フレックスフィールドを構成して追加した属性は、Oracle Fusion Middlewareテクノロジ・スタック全体で使用できます。フレックスフィールド・セグメントのアプリケーション・プログラミング・インタフェース(API)を使用して、セグメントを特定し、次の項目にフレックスフィールドを統合できます。

  • ユーザー・インタフェース・ページ

  • サービス指向アーキテクチャ(SOA)インフラストラクチャ

  • Oracle Business Intelligence

  • ESSbase (Extended Spread Sheet Database)

フレックスフィールドの構成は、アプリケーションの更新後も保持されます。

デプロイメント

構成変更を保存するとすぐに、フレックスフィールドのメタデータはアプリケーション・データベースに格納されます。フレックスフィールドをデプロイすると、ADFビジネス・コンポーネントが生成されるので、ランタイム・ユーザー・インタフェースは、メタデータ内の最新のフレックスフィールド定義を反映します。

インポートとエクスポート

「設定および保守」作業領域を使用して、実装サイト全体でフレックスフィールドをインポートおよびエクスポートできます。デプロイメント・ステータスは、デプロイ済またはサンドボックスにデプロイ済のいずれかでなければなりません。したがって、移行を試行する前に、フレックスフィールドが正常にデプロイされていることを検証して確認してください。

ランタイム

フレックスフィールドの最新の定義は、フレックスフィールドがデプロイされていれば、ランタイムのユーザー・インタフェースに反映されます。ユーザー・インタフェースがビジネス・オブジェクトにアクセスするときに、デプロイされたフレックスフィールド定義により、取得された値に関連する属性が特定されます。ページ上で、Oracle Composerを使用してフレックスフィールドの表示カスタマイズを追加した場合、同じフレックスフィールド・セグメントがページごとに異なって表示される可能性があります。

パッチ適用

フレックスフィールドの構成は、パッチ適用やアップグレードの後も保持されます。

フレックスフィールドと値セット: ハイライト

フレックスフィールドを使用してカスタム属性を作成する前に、Oracle Applications Cloudのカスタマイズ・レイヤーとカスタマイズ・ライフ・サイクルについてよく理解しておく必要があります。フレックスフィールドの構成に関して入手できる幅広いヘルプ・コンテンツに加え、ビジネス・コンポーネントへのフレックスフィールドの追加や、フレックスフィールドを有効にできない場合にフレックスフィールドのかわりに使用できるものについて、次の資料を検討してください。

特定の事前定義されたフレックスフィールドの詳細を参照するには、「設定および保守」作業領域を開き、「フレックスフィールドの定義」タスク・リスト内のタスクを使用します。タスクおよびユーザー・インタフェース・ページでは実行できないカスタマイズについては、My Oracle Supportにお問い合せください。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc=infoまたはhttp://www.oracle.com/pls/topic/lookup?ctx=acc=trsl(聴覚に障害がある場合)にアクセスしてください。

注意: フレックスフィールドのカスタマイズにはOracle JDeveloperを使用しないでください。

フレックスフィールドの構成前

フレックスフィールドが開発者によりビジネス・オブジェクトに対して登録されていれば、フレックスフィールドを使用してカスタム属性をビジネス・オブジェクトに追加できます。

  • Oracle Sales Cloudの場合は、付加フレックスフィールドおよび拡張可能フレックスフィールドを使用するかわりに、アプリケーション・コンポーザを使用してカスタム属性を追加します。

フレックスフィールドのデプロイ

  • 各SOAアプリケーション用のMDSリポジトリにある更新されたXMLスキーマ定義(XSD)ファイルの同期については、Oracle Fusion Applications Extensibility Guide for Developersを参照してください。

    参照: SOAコンポジット・アプリケーションのカスタマイズ

    • SOAコンポジットにより使用されるOracle ADFサービスは、デプロイされたフレックスフィールドが格納されるているWebサービス記述言語(WSDL)スキーマを公開します。

Oracle Business Intelligence

関連トピック

フレックスフィールドの管理

フレックスフィールドの管理: 考慮事項

フレックスフィールドの管理には、フレックスフィールドの登録、計画および構成が含まれます。

アプリケーション開発者によりアプリケーションで提供される登録済フレックスフィールドを、計画および構成します。フレックスフィールド・セグメントの構成方法により、フレックスフィールド・セグメントがユーザーにどのように表示されるかが決まります。オプションで、UIページをカスタマイズして、そのページ上でフレックスフィールド・セグメントがユーザーにどのように表示されるかを変更できます。

次の図は、フレックスフィールドをユーザーが使用できるようにするためのプロセスを示しています。「フレックスフィールドの定義」アクティビティのタスクにより、管理者はフレックスフィールドを構成してデプロイできます。フレックスフィールドを構成してサンドボックスにデプロイした後、それをメインライン・メタデータに再度デプロイして、ユーザーが使用できるようにします。

図では、計画からフレックスフィールドをユーザーが使用できるようにするまでのワークフローを示しています。構成とデプロイは、「フレックスフィールドの定義」アクティビティのタスクの範囲内で行われます

フレックスフィールドの管理について、次の面を考慮してください。

  • フレックスフィールドの登録

  • フレックスフィールドの計画

  • フレックスフィールドの構成

  • ビジネス・インテリジェンスに対するフレックスフィールド・セグメントの有効化

  • フレックスフィールドのデプロイ

  • オプションで、ユーザー・インタフェース・ページでのフレックスフィールド・セグメントの外観の変更

  • ランタイム・ページ上のフレックスフィールドの特定およびトラブルシューティング

フレックスフィールドの登録

フレックスフィールドは、構成する前に登録する必要があります。したがって、アプリケーション開発では、フレックスフィールドを登録し、管理者や実装コンサルタントが構成できるようにします。登録には、フレックスフィールドで使用するエンティティ表の列を予約することが関係します。フレックスフィールドの登録の詳細は、Oracle Fusion Applications開発者ガイドを参照してください。

フレックスフィールドの計画

フレックスフィールドの計画を開始する前に、どのタイプがニーズに適しているか、およびどのビジネス・オブジェクトがフレックスフィールドのカスタマイズに使用できるかを判別します。すべてのフレックスフィールドは、エンティティの属性を表すセグメントで構成されます。属性に対してユーザーが入力する値が、エンティティ表の列に格納されます。フレックスフィールドは、構成する前に慎重に計画してください。フレックスフィールドの新しいセグメントを構成する前に、必ずその実装について注意深く計画してください。

ビジネス・オブジェクトでフレックスフィールドをサポートすることを決定しており、それらのフレックスフィールドが登録済である場合は、その構成の計画を開始できます。構成する予定のフレックスフィールドのコード名を書き留めて、「フレックスフィールドの定義」アクティビティですぐに参照できるようにしておきます。場合によっては、ページ上でのフレックスフィールドの表示方法をカスタマイズできます。製品固有のフレックスフィールドの使用に関する制限事項を確認するには、具体的な製品についてOracle Applications Cloudのヘルプを参照してください。

フレックスフィールドの構成

管理者または実装者は、企業のニーズを満たすようにフレックスフィールドを構成します。一部のフレックスフィールドでは、アプリケーションが正しく動作するための構成が必要です。フレックスフィールドは、次の方式を使用して構成できます。

  • 「設定および保守」作業領域にある、フレックスフィールドの管理タスクに移動する。

  • ランタイム・ページの表示中に、「管理」メニューのフレックスフィールドの強調表示コマンドを使用する。

    • フレックスフィールドの構成アイコン・ボタンを使用して、フレックスフィールドのすべての面を管理します。これにはセグメントの順序番号の変更や、フレックスフィールド・セグメントのビジネス・インテリジェンス・ラベルの構成などが含まれます。

    • セグメントの追加およびセグメントの編集アイコン・ボタンを使用して、単純な構成の付加および拡張可能フレックスフィールド・セグメントを追加および編集します。

    • コンテキストの追加アイコン・ボタンを使用して、付加または拡張可能フレックスフィールドのコンテキスト値を追加します。

フレックスフィールドの構成には、次が含まれます。

  • ユーザーが入力した値を突き合わせて検証する値セットの定義

  • フレックスフィールド内のセグメントの構成またはコンテキストの定義

  • 各セグメントの識別情報の指定

  • 表示プロパティ(各フレックスフィールド・セグメントのプロンプ、長さ、データ型など)の指定

  • 各セグメントの有効な値と、アプリケーション内での各値の意味の指定

ヒント: 値セットの作成は、付加フレックスフィールドおよび拡張可能フレックスフィールドの作成時に実行できます。ただし、値セットの定義は、それを使用するキー・フレックスフィールド・セグメントの構成前に実行してください。キー・フレックスフィールド・セグメントの構成時に、既存の値セットを割り当てるためです。

付加フレックスフィールドおよび拡張可能フレックスフィールドのセグメントの作成時に、表検証、独立、従属またはサブセットの値セットを作成する場合は、オプションで、選択した値の説明をランタイムにセグメントの横に表示するように指定できます。連番の順序番号を、グローバル・セグメントと、各コンテキスト内のコンテキスト依存セグメントに割り当てることができます。セグメント表示は、セグメントの順序番号に基づいて必ず固定順序になります。セグメントに対して別のセグメントですでに使用されている番号を入力することはできません。したがって、新しい属性を挿入しやすくするために、4、5または10などの倍数でセグメントを採番することを検討してください。

フレックスフィールド列は新規セグメントに自動的に割り当てられますが、この割当てはセグメントを保存する前に変更できます。セグメントに対して特定の列割当てを設定する必要がある場合は、まずそのセグメントを作成し、目的の列が別のセグメントに自動的に割り当てられないようにします。

ビジネス・インテリジェンスに対するフレックスフィールド・セグメントの有効化

フレックスフィールドがOracle Business Intelligence対応フレックスフィールドとしてデータベース内に登録されている場合、そのフレックスフィールド・セグメントをビジネス・インテリジェンス用にを有効にできます。ビジネス・インテリジェンス用にセグメントを有効にすることの詳細は、ビジネス・インテリジェンス用に付加、拡張可能、およびキーのフレックスフィールド・セグメントを有効にするときの考慮事項を参照してください。拡張可能フレックスフィールド・セグメントの場合、意味的に等しいコンテキスト間でセグメントを均質化するためにラベルを割り当てることはできません。

フレックスフィールドのデプロイ

フレックスフィールドを構成したら、それをデプロイして、最新の定義をランタイム・ユーザーが使用できるようにする必要があります。「フレックスフィールドの定義」タスクで、次のいずれかのコマンドを使用してフレックスフィールドをデプロイできます。

  • フレックスフィールドのデプロイコマンドは、フレックスフィールドをメインライン・メタデータにデプロイします。このコマンドは、テストまたは本番環境での汎用コマンドです。

  • サンドボックスにデプロイコマンドは、フレックスフィールドをサンドボックスにデプロイします。このコマンドは、フレックスフィールドがメインライン・メタデータにデプロイされる前に正しく構成されていることを確認するためのものです。

フレックスフィールドの強調表示モードで、次を使用するとします。

  • 拡張可能フレックスフィールドでコンテキストの追加、セグメントの追加およびセグメントの編集ツールを使用する場合は、「保存」コマンドを使用して変更を保存します。次にデプロイコマンドを使用して、フレックスフィールドをメインライン・メタデータにデプロイします

  • 付加フレックスフィールドでセグメントの追加およびセグメントの編集ツールを使用する場合は、保存およびデプロイコマンドを使用して変更を保存します。次にフレックスフィールドをメインライン・メタデータにデプロイします

デプロイ後には、デプロイメント・ステータスは、最後にデプロイされた定義と比較した現在の構成済フレックスフィールドの状態を示します。

フレックスフィールド・セグメントの外観の変更(オプション)

定義したフレックスフィールド属性は、ユーザー・インタフェース・ページに統合され、ユーザーはそこから属性のビジネス・オブジェクトにアクセスします。アプリケーション開発では、ビジネス・オブジェクトを表示するUIページと、フレックスフィールド・セグメントをレンダリングするためにデフォルトで使用する表示パターンを決定します。

フレックスフィールドがメインラインMDSリポジトリにデプロイされ、アプリケーション・ページに表示されるようになったら、ページ・コンポーザを使用してページごとにカスタマイズできます。たとえば、セグメントを非表示にしたり、そのプロンプトや他のプロパティを変更したり、カスタム・グローバル属性を順序変更して同じ親レイアウト内のコア属性の間に組み込まれるようにしたりできます。フレックスフィールドがメインライン・メタデータにデプロイされると、ページ・コンポーザを使用してUIページでの付加および拡張可能フレックスフィールド・セグメントの外観をカスタマイズできます。

アプリケーションがいくつかの異なるロケールで実行している場合は、プロンプトや説明などの翻訳可能テキスト用に別々の翻訳を指定できます。翻訳されたテキストを必要とするロケールを使用して翻訳を入力します。グローバル・ヘッダーで、自分のユーザー名をクリックし、「設定およびアクション」メニューで、「プリファレンスの設定」を選択します。次にテキストを、そのロケール用の翻訳済テキストに変更します。

ランタイム・ページ上のフレックスフィールドの特定

「設定および保守」作業領域の「管理」メニューにあるフレックスフィールドの強調表示コマンドにより、各フレックスフィールドに関する詳細にアクセスするための情報アイコン・ボタンを表示することで、ランタイム・ページ上のフレックスフィールドの位置を特定できます。

付加フレックスフィールドまたは拡張可能フレックスフィールドがまだデプロイされておらず、通常ビューのランタイム・ページにセグメントが表示されていない場合でも、フレックスフィールドはそのページのフレックスフィールドの強調表示ビューに表示されます。付加フレックスフィールドの場合、最後のデプロイメント時点でのセグメントが表示されます。拡張可能フレックスフィールドの場合、保存されているもののデプロイされていないすべてのセグメントとコンテキストも、無効と示されて表示されます。

フレックスフィールドの強調表示は、現在のフレックスフィールド・メタデータ定義にアクセスします。強調表示されたフレックスフィールドのフレックスフィールドの構成アイコン・ボタンを使用して、フレックスフィールドを直接管理します。または、強調表示されたフレックスフィールドの名前を書き留めて、フレックスフィールドの管理タスクでその名前を検索します。

フレックスフィールドの作成とそれらをUIページに追加することの詳細は、Oracle Fusion Applications開発者ガイドを参照してください。ページ・コンポーザによるフレックスフィールド・セグメントの外観のカスタマイズの詳細は、Oracle Fusion Applications拡張ガイドにある既存ページのカスタマイズのガイダンスを参照してください。

フレックスフィールド・セグメントのプロパティ: 説明

セグメントに割り当てられた値セットに関係なく、セグメントにはその表示方法や動作に影響を与えるプロパティを設定できます。

次に示す側面を理解することが重要です

  • 表示プロパティ

  • セグメント値に関連したプロパティ

  • 検索に関連したプロパティ

  • セグメントの範囲検証

  • セグメント値のルール検証

  • 命名規則

表示プロパティ

次の表では、表示プロパティについてまとめています。

プロパティ 説明

使用可能

セグメントが使用可能かどうか。

順序

他の構成済セグメントとの関連でセグメントが表示される順序。

プロンプト

ユーザー・インタフェースでセグメントのラベルに使用される文字列。

表示タイプ

セグメントを表示するフィールドのタイプ。

選択および選択の解除値

表示タイプがチェック・ボックスの場合の、保存される実際の値。たとえば、YとNまたは0と1などです。

表示サイズ

フィールドの文字幅。

表示の高さ

表示タイプがテキスト領域の場合に、表示される行数で測定されるフィールドの高さ。

読取り専用

フィールドを、編集可能テキストではなく読取り専用として表示するかどうか。

説明ヘルプ・テキスト

フィールドに表示する、フィールド・レベルの説明ヘルプ・テキスト。説明ヘルプ・テキストは、フィールド用に備えられたプロンプトを詳しく説明するまたは明快にするフィールド・レベルの説明を表示するために使用します。

説明ヘルプ・テキストが指定されている場合、「ヘルプ」アイコン・ボタンがランタイム・アプリケーションのフィールドの横に表示されます。ユーザーが「ヘルプ」アイコン・ボタンの上にカーソルを移動させると、説明ヘルプ・テキストが表示されます。

手順ヘルプ・テキスト

フィールドに表示する、フィールド・レベルの手順ヘルプ・テキスト。

手順ヘルプ・テキストは、フィールドの使用に関する指示を示すために使用します。手順ヘルプ・テキストを指定すると、ユーザーがフィールドにカーソルを移動すると表示されるフィールド内ヘルプ・ノート・ウィンドウに表示されます。

検索に関連したプロパティ

拡張可能フレックスフィールド・セグメントは、索引付きプロパティを使用した検索で、選択的に必須としてマークを付けることができます。索引付きプロパティでは、索引付きセグメントにより表される属性に対して検索を実行する前に、ユーザーが値を入力する必要があります。データベース管理者は、索引付き属性を表すセグメント列に対して索引を作成する必要があります。

セグメントの範囲検証

範囲検証により、フレックスフィールドの2つのセグメント間で算術的な相違を強制できます。たとえば、製品は出荷前にオーダーされる必要があります。したがって、オーダー日は出荷日当日またはそれより前でなければなりません。また、オーダー日のセグメント値は、出荷日のセグメント値以下でなければなりません。この関係を確認するために範囲検証を使用できます。

範囲検証の条件は次のとおりです。

  • セグメントは、低い値のセグメントと高い値のセグメントのペアで範囲検証に対して構成する必要があります。

  • 両方のセグメントは同じデータ型にする必要があります。

  • 両方のセグメントは、キー・フレックスフィールド内の同じ構成の部分、または付加フレックスフィールドあるいは拡張可能フレックスフィールド内の同じコンテキストの部分である必要があります。

  • 低い値のセグメントは、高い値のセグメントよりも低い順序番号である必要があります。

  • 範囲検証の対象でないセグメントが範囲検証のペアの間に存在できますが、範囲検証のペアを重複させたりネストさせたりすることはできません。

同じフレックスフィールド内に、必要な数だけ範囲検証のペアを構成できます。アプリケーションは範囲検証を自動的に検出して、定義したセグメントのペアに順序どおり適用します。低い値のセグメントがまず検出され、検出される次の範囲検証セグメントが高い値のセグメントでなければなりません。これら2つのセグメントが対応するペアと見なされます。低い値と高い値は等しくてもかまいません。

セグメント値のルール検証

付加および拡張可能フレックスフィールド・セグメントの検証ルールにより、属性の検証方法が決まります。ビジネス・オブジェクトの属性に入力される値は、指定されたフォーマットに一致する必要がある場合や、値のリストに制限される必要がある場合があります。検証ルールを指定するには、値セットを使用します。

値セット検証は、グローバル・セグメントとコンテキスト依存セグメントの場合は必須であり、コンテキスト・セグメントの場合はオプションです。コンテキスト・セグメントの場合、アプリケーションは、コンテキスト・セグメントに照らして値を検証する値セットのかわりに、値を検証することもできます。ただし、アプリケーションで入力された値は、有効なコンテキスト・セグメント値に厳密に一致している必要があります。コンテキスト・セグメント値が入力値のスーパーセットまたはサブセットである場合、コンテキスト値を検証するには、表検証の値セットまたは独立の値セットを割り当てる必要があります。

付加フレックスフィールド・セグメントを構成する場合、初期値の設定に使用する定数を指定できます。初期値は、使用可能なパラメータにすることができます。計画済のすべてのセグメントに対して、初期値に使用する定数値またはパラメータがあればそれらをリストします。

命名規則

セグメントの固有のコード、名前および説明を入力します。これらのプロパティは内部で使用するためのものであり、エンド・ユーザーには表示されません。セグメントの作成後には、コードは変更できません。

アプリケーション・プログラミング・インタフェース(API)名は、ユーザーに公開されないセグメントの名前です。API名は、Webサービス、ルール、ビジネス・インテリジェンスを含む様々な統合ポイント内でセグメントを識別するために使用されます。先頭文字には英数文字のみを使用します。たとえば、A-Z、a-z、0-9の文字で構成された、数字以外の先頭文字を持つコードを入力します。スペース、アンダースコア、マルチバイト文字および数字の先頭文字の使用は許可されません。セグメントの作成後には、API名は変更できません。

フレックスフィールド・セグメント: レンダリング方法

フレックスフィールド・セグメントは、ページ上にビジネス・オブジェクトの属性として表示されます。

フレックスフィールド・セグメントの表示に影響を与える設定

フレックスフィールド・セグメントを構成するときに、セグメントの表示タイプに入力する値は、セグメントがランタイムに表示される方法を決定します。

表示タイプの値の表示方法

次の一連の図(AからK)は、ランタイムで表示タイプがUI上でどのようにレンダリングされるかを示しています。各表示タイプのスクリーンショットには、表内の表示タイプとその説明に対応する英字が割り当てられています。

次の図には、チェック・ボックス、ドロップダウン・リスト、値のリストおよび検索が有効になった値リストの表現が含まれています。

図は、次の4つの表示タイプで構成されています: A. チェック・ボックス、B. ドロップダウン・リスト、C. 値リスト、D. 検索が有効になった値リスト

次の図には、ラジオ・ボタン・グループ、テキスト領域、テキスト・ボックス、日時およびリッチ・テキスト・エディタの表現が含まれています。

図は、次の5つの表示タイプで構成されています: E. ラジオ・ボタン・グループ、F. テキスト領域、G. テキスト・ボックス、H. 日時、I. リッチ・テキスト・エディタ

この図には、カラー・パレットと静的URLフィールドの表現が含まれています。

図は、次の2つの表示タイプで構成されています: J.カラー、K.静的URL

次の表は、各表示タイプを説明しています。

図の参照 表示タイプ 説明

A

チェック・ボックス

このフィールドはチェック・ボックスとして表示されます。ユーザーがチェック・ボックスを選択した場合、チェックを付けた値が使用されます。選択しない場合、選択解除されている値が使用されます。

B

ドロップダウン・リスト

このフィールドは、ユーザーが選択できる値のリストとして表示されます。

C

値のリスト

このフィールドは、ユーザーが選択できる値のリストとして表示されます。ユーザーは「検索」をクリックしてさらに値を探すこともできます。

D

検索が有効になった値リスト

このフィールドは、「検索」アイコン・ボタンがあるテキスト・フィールドとして表示されます。ユーザーはテキスト・フィールドに値を入力したり、「検索」アイコン・ボタンをクリックして検索用の別ウィンドウを開いたりできます。

E

ラジオ・ボタン・グループ

このフィールドは、ラジオ・ボタンのセットとして表示されます。ユーザーは1つのボタンを選択できます。ボタンを選択すると、セット内の前に選択したボタンは選択解除されます。

F

テキスト領域

このフィールドは、ユーザーが複数行のテキストを入力できるテキスト領域として表示されます。表示の幅と高さはそれぞれ、テキスト領域での表示可能な幅と行数を指定します。

G

テキスト・ボックス

このフィールドは、ユーザーが単一行のテキストを入力できるテキスト・フィールドとして表示されます。表示幅は、テキスト・ボックスの幅を制御します。

H

日時

このフィールドでユーザーは、データ型が日付の場合は日付を、日時の場合は日付と時刻を入力できます。ユーザーは日付をカレンダから選択できます。データ型が日時の場合、フィールドには、時、分、秒、AM/ＰMおよびタイム・ゾーンを指定するためのフィールドも表示されます。

I

リッチ・テキスト・エディタ

このフィールドは、ユーザーが複数行の書式設定テキストを入力して編集できるテキスト領域として表示されます。表示の幅と高さはそれぞれ、リッチ・テキスト・エディタでの表示可能な幅と行数を指定します。

注意: この表示タイプは、拡張可能フレックスフィールドでのみ使用できます。

J

カラー

このフィールドには、ユーザーがランタイムにカラーを選択してセグメントに割り当てるためのカラー・パレットが表示されます。設定時に、この表示タイプは、次の場合にのみ選択のリストに表示されます。

  • 拡張可能フレックスフィールド・セグメントで作業している場合。

  • セグメントの値セットがORA_FND_COLOR_#RRGGBBに設定されている場合。

K

静的URL

このフィールドは、クリックするとWebページが開く固定URLをユーザーが入力できるテキスト・フィールドとして表示されます。

注意: URLの長さは255文字を超えてはなりません。

図の参照はありません

非表示

このフィールドは表示されません。

フレックスフィールドと値セット: 連携方法

値セットは企業に固有のものです。フレックスフィールドを使用して情報を収集するときに、企業の値セットは、値セットの定義方法に基づいて、ユーザーが入力する値を検証します。

値セットは、同じフレックスフィールド内または異なるフレックスフィールド内の任意の数のフレックスフィールド・セグメントに割り当てることができます。値セットの使用状況情報は、どのフレックスフィールドが値セットを使用しているかを示します。

フレックスフィールドと値セットの連携方法を理解するためには、次の側面が重要です。

  • 値セットの定義

  • 共有値セット

  • デプロイメント

値セットの定義

キー・フレックスフィールドのガイドラインとして、フレックスフィールドの構成時には値セットを各セグメントに割り当てることになるため、値セットはフレックスフィールドの構成前に定義してください。付加フレックスフィールドおよび拡張可能フレックスフィールドを使用して、セグメントの追加または編集時に値セットを定義できます。

注意: 共有値セットへの変更が、その値セットを使用するすべてのフレックスフィールド・セグメントと互換性があることを確認してください。

共有値セット

共有値セットの値を変更すると、変更はその値セットを使用するすべてのフレックスフィールドの値セットに影響を与えます。共有値セットの利点として、単一の変更ですべての使用にその変更が伝播されます。デメリットは、使用全体で共有される変更が、どのケースにも適しているわけではない場合があるということです。

値セットの値

「値セットの管理」タスクの値セットの値画面で取得されるカスタム属性を構成するには、値セットの値付加フレックスフィールドを構成します。オブジェクトのコードはFND_VS_VALUES_Bです。このフレックスフィールドは、値セット・コードに対応するコンテキスト・コードを必要とします。各値セットに対して、コードが値セットのコードであり、コンテキスト依存セグメントがその値セットの値に表示されるコンテキストを定義できます。デフォルトでは、コンテキスト・セグメントは値セット・コードにマップされ、変更が予期されないため、非表示になります。

すべての値セットに表示されるグローバル・セグメントも定義できます。ただし、これはすべての値セットのすべての値の属性を取得することを意味するため、かなりまれな処理です。

デプロイメント

フレックスフィールドをデプロイすると、フレックスフィールドのセグメントに割り当てられた値セットは、そのセグメントによって表される属性の有効な値をユーザーに提供します。

セグメント値のデフォルト設定と導出: 説明

行の作成時にフレックスフィールド・セグメントにデフォルト値を移入するには、定数またはパラメータのデフォルト・タイプとデフォルト値を指定します。

セグメントの値と別のフィールドの値を変更時に同期させるには、属性の値の導出元のフレックスフィールド・パラメータとなるように導出値を指定します。パラメータ値が変更されるたびに、属性の値も対応するように変更されます。パラメータ値が変更されるとユーザーが入力した値は失われてしまうため、パラメータから属性を導出する場合は、属性を読取り専用とすることを検討してください。デフォルト値を設定する場合またはパラメータからデフォルト値を導出する場合、開発によりパラメータとして指定された属性のみを選択できます。セグメントを読取り専用または編集可能にすることと、デフォルト値または導出値(あるいはその両方)とを様々に組み合せることで、様々な効果が得られます。

初期ランタイム・アクションは、エンティティ表で作成される属性値の行に対応します。デフォルト値が読取り専用である場合、その後ユーザー・インタフェースで変更することはできません。デフォルト値が読取り専用でない場合には、変更できます。ただし、セグメント値が導出値である場合、ユーザーが変更したセグメント値は、導出値が変更されると上書きされます。

デフォルト・タイプ デフォルト値の指定 導出値の指定 初期ランタイム・アクション パラメータ変更後のランタイム・アクション

なし

なし

あり

初期セグメント値なし

変更されたパラメータ導出値でセグメント値が更新されます

定数

あり

なし

デフォルトのセグメント値

該当しない

定数

あり

あり

デフォルトのセグメント値

変更されたパラメータ導出値でセグメント値が更新されます

パラメータ

あり

なし

デフォルトのセグメント値がパラメータのデフォルト値です

該当しない

パラメータ

あり

あり(デフォルト値と同じ)

デフォルトのセグメント値がパラメータのデフォルト値および導出値です

変更されたパラメータ導出値でセグメント値が更新されます

パラメータ

あり

あり(デフォルト値と異なる)

デフォルトのセグメント値がパラメータのデフォルト値です

変更されたパラメータのデフォルト値でセグメント値は更新されません。変更された導出値でのみセグメント値が更新されます。

フレックスフィールドの使用方法: 説明

フレックスフィールドの使用方法は、フレックスフィールドとそのセグメントが関連付けられる表を指定します。フレックスフィールドは複数の使用方法を持つ場合があります。ただし、フレックスフィールドに登録される最初の表が、マスター使用方法を示します。セグメントは、マスター使用方法に基づきます。同じフレックスフィールドの同じ表の他の使用方法も、同じセグメントの設定を使用します。ただし列名は区別するためのプリフィクスが付いている場合があります。

「付加フレックスフィールドの管理」および「拡張可能フレックスフィールドの管理」ページで、特定のフレックスフィールドのエンティティ使用方法の表示アイコンをクリックして、そのエンティティ使用方法を表示します。「値セットの管理」ページで、選択した値セットのフレックスフィールド使用方法を表示できます。

拡張可能フレックスフィールド

拡張可能フレックスフィールド・コンテキストの場合、別の使用方法を構成できます。拡張可能フレックスフィールド・コンテキストの使用方法により、ユーザーに対してコンテキストのセグメントが表示されるシナリオまたはユーザー・インタフェースが決まります。たとえば、「サプライヤ」ページには、拡張可能フレックスフィールドのサプライヤ使用方法が表示され、同じフレックスフィールドの「バイヤー」ページには、バイヤーの使用方法が表示されます。次に、サプライヤの使用方法にのみ関連付けられているコンテキストは、「サプライヤ」ページにのみ表示され、「バイヤー」ページには表示されません。

値セット

値セットの使用方法は、特定の値セットが割り当てられているセグメントを持つフレックスフィールドを指定します。

フレックスフィールド管理のFAQ

事前定義済フレックスフィールドにはどのようにアクセスできますか。

「フレックスフィールドの定義」タスク・リストを使用して、事前定義済フレックスフィールドを検索します。

  1. 「設定および保守」作業領域で、「フレックスフィールドの定義」タスク・リストを検索して展開し、タスクを表示します。

  2. 検索しているフレックスフィールドに対応するタスクを開きます。

  3. 任意の検索パラメータを入力して、「検索」をクリックします。

    ヒント: フレックスフィールド名またはコードがわからない場合は、「モジュール」フィールドを使用して検索結果をフィルタします。

  4. フレックスフィールドをクリックして詳細を表示します。

フレックスフィールドまたは値セット構成を編集できないのはなぜですか。

フレックスフィールドまたは値セット構成は保護されている可能性があります。アプリケーション開発者は一部の構成に保護のマークを付け、それらが編集不可であることを示します。

保護される可能性がある構成の例として、次のものがあります。

  • 付加フレックスフィールド

  • 拡張可能フレックスフィールド・コンテキスト

  • 拡張可能フレックスフィールド・ページ

  • 値セット

ページにフレックスフィールドがまったく表示されないのはなぜですか。

ページでフレックスフィールドを使用できるようにするには、開発者による登録とデプロイが必要です。フレックスフィールドを正常にデプロイしてからでないと、セグメントをページ上に表示することはできません。

フレックスフィールドのデプロイメント・ステータスは、ユーザーがフレックスフィールド・セグメントを使用できるかどうかを示します。ランタイムでユーザーに表示されるフレックスフィールド・セグメントは、最後に正常にデプロイされたフレックスフィールド定義に対応します。

フレックスフィールドの登録については、Oracle Fusion Applications開発者ガイドを参照してください。一部のビジネス・オブジェクトは、フレックスフィールドをサポートするようには設計されていません。フレックスフィールド機能を持つビジネス・オブジェクトを有効にする方法については、Oracle Fusion Applications開発者ガイドでフレックスフィールド・スタート・ガイドを参照してください。

注意: Oracle Sales Cloudはフレックスフィールドをサポートしていません。

カスタム属性をこれらのアプリケーションに追加するには、アプリケーション・コンポーザを使用できます。詳細は、製品固有の資料を参照してください。

フレックスフィールドに加えた変更がランタイムUIに表示されないのはなぜですか。

フレックスフィールドのデプロイ時にOracle Metadata Services (MDS)リポジトリ内に生成されるフレックスフィールドのADFビジネス・コンポーネントまたはアーティファクトは、1ユーザー・セッション内はキャッシュに入れられます。ランタイム・アプリケーションのユーザー・インタフェース・ページに反映されたフレックスフィールド定義の変更を表示するには、サインアウトしてサインインしなおす必要があります。

Oracle Social Network Cloud Serviceのフレックスフィールド・セグメントはどのように有効にできますか。

設定および保守中にOracle Social Network Objectsを管理するときに、付加フレックスフィールドを含むビジネス・オブジェクトを検索します。フレックスフィールド・セグメントとして定義されている属性を選択し、それらを有効にします。

フレックスフィールドのデプロイメント

フレックスフィールドのデプロイメント: 説明

デプロイメントにより、ユーザー・インタフェースにフレックスフィールドをレンダリングするアプリケーション開発フレームワーク(ADF)ビジネス・コンポーネント・オブジェクトが生成またはリフレッシュされます。デプロイメント・プロセスにより、Oracle ADFサービスにより公開され、SOAコンポジットにより使用されるWebサービス記述言語(WSDL)スキーマに、カスタム属性が追加されます。フレックスフィールドは、最初はアプリケーション・プロビジョニング・プロセス中にデプロイされます。フレックスフィールドを構成または変更したら、それをデプロイして、最新の定義をユーザーが使用できるようにする必要があります。

付加フレックスフィールドがビジネス・インテリジェンスに対して有効になっている場合、デプロイメント・プロセスはフレックスフィールドのビジネス・インテリジェンス・アーティファクトを再デプロイします。

フレックスフィールドは、テスト目的でサンドボックスに、またはテストや本番ランタイム環境での使用目的でメインライン・メタデータにデプロイできます。拡張可能フレックスフィールドは、バックグラウンド・プロセスとしてデプロイできます。

デプロイメント後には、カスタム属性は、ビジネス・プロセスやビジネス・ルール統合などのSOAインフラストラクチャに組み込むことができます。たとえば、カスタム属性に応じたビジネス・ルールを作成できるようになります。デプロイした変更をランタイムに表示するには、Oracle Applications Cloudからサインアウトして、サインインしなおす必要があります。

フレックスフィールドのデプロイメントを理解するためには次の側面が重要です。

  • デプロイメント・ステータス

  • 初期デプロイメント・ステータス

  • メタデータ検証

  • メタデータ同期

  • バックグラウンド・プロセスとしてのデプロイメント

  • フレックスフィールドMDSからのアーティファクトのエクスポート

デプロイメント・ステータス

すべてのフレックスフィールドには、デプロイメント・ステータスがあります。次の表は、様々なデプロイメント・ステータスを示しています。

デプロイメント・ステータス 意味

編集済

フレックスフィールド・メタデータ定義はまだデプロイされていません。メタデータ定義の更新は、ランタイム環境でまだ適用されていません。

パッチ適用済

フレックスフィールド・メタデータ定義はパッチまたはデータ移行アクションによって変更されていますが、フレックスフィールドはまだデプロイされていません。そのため、更新された定義はランタイム環境に反映されていません。

サンドボックスにデプロイ済

フレックスフィールドの現在のメタデータはADFアーティファクトにデプロイされ、フレックスフィールド対応サンドボックスとして使用できます。サンドボックスのステータスは、「設定および保守」作業領域の「管理」メニューから使用できるサンドボックスの管理タスクにより管理されます。

デプロイ済

フレックスフィールドの現在のメタデータはADFアーティファクトにデプロイされ、ユーザーが使用できます。メインライン・メタデータにデプロイされた後は、フレックスフィールドに変更は加えられていません。

エラー

メインライン・メタデータでのデプロイメントの試行は失敗しました。

注意: 値セット定義が変更されるたびに、その値セットを使用するフレックスフィールドのデプロイメント・ステータスは編集済に変更されます。変更がパッチ適用の結果である場合、フレックスフィールドのデプロイメント・ステータスはパッチ適用済に変更されます。

フレックスフィールドの初期デプロイメント・ステータス

Oracle Applications Cloudの実装では、フレックスフィールド・メタデータがデータベースにロードされます。この初期ロードでは、フレックスフィールドのステータスは編集済に設定されます。インストール時に、アプリケーション・プロビジョニング・プロセスによりプロビジョニング対象アプリケーションのフレックスフィールドがデプロイされ、エラーが発生しなければそのステータスがデプロイ済に設定されます。

プロビジョニングされたアプリケーションでは、デプロイされたフレックスフィールドはすぐに使用できます。場合によっては、ランタイムでフレックスフィールドを使用できるようにするには、キー・フレックスフィールドの定義などの設定が必要です。

メタデータ検証

フレックスフィールドのデプロイを試行する前に、メタデータの検証コマンドを使用して、メタデータ・エラーがあれば確認できます。メタデータ検証は、すべてのフレックスフィールド・デプロイメント・コマンドの初期フェーズです。デプロイメント・コマンドを実行する前にメタデータを適正に検証することで、デプロイメントの試行時にメタデータ検証フェーズでエラーが発生することを避けられます。メタデータ検証フェーズでエラーが発生すると、デプロイメント・プロセスは終了します。メタデータ検証の結果は、フレックスフィールドのデプロイメント・ステータスには影響しません。

メタデータ同期

拡張可能フレックスフィールドまたは付加フレックスフィールドがデプロイされると、デプロイメント・プロセスによりXMLスキーマ定義(XSD)が再生成されます。その結果、カスタム属性がWebサービスとSOAアーキテクチャで使用できるようになります。

フレックスフィールド構成のデプロイ後に、各SOAアプリケーションに対して、MDSリポジトリ内の更新済XMLスキーマ定義(XSD)ファイルを同期する必要があります。

注意: Oracle Cloud実装のMDSリポジトリ内で更新済XSDファイルを同期するには、My Oracle Support(http://support.com/)を利用してサービス要求をログに記録してください。

バックグラウンド・プロセスとしてのデプロイメント

拡張可能フレックスフィールドは、オフラインでバックグラウンド・プロセスとしてデプロイでき、デプロイメントの完了を待機する必要なくセッションで作業を続行できます。複数の拡張可能フレックスフィールドをキューイングして、バックグラウンド・プロセスとしてデプロイできます。フレックスフィールドは、一度に1つずつ、キューにデプロイした順序でデプロイされます。30を超えるカテゴリを持つ拡張可能フレックスフィールドは、バックグラウンド・プロセスとしてデプロイする必要があります。

バックグラウンド・デプロイメントの取消しコマンドを使用してデプロイメント・キューから拡張可能フレックスフィールドを削除できます。拡張可能フレックスフィールドがバックグラウンド・プロセスでデプロイされると、そのオフライン・ステータスにより、フレックスフィールドがバックグラウンド・デプロイメント処理中であることが示されます。バックグラウンド・デプロイメント・プロセスが完了すると、フレックスフィールドのオフライン・ステータスはクリアされ、そのデプロイメント・ステータスは更新されます。

フレックスフィールドMDSからのアーティファクトのエクスポート

主にフレックスフィールドの問題のトラブルシューティングで使用することを目的に、付加、拡張可能またはキー・フレックスフィールドのMDSからビジネス・コンポーネントをエクスポートできます。フレックスフィールドの管理ページ上のフレックスフィールド・アーカイブのダウンロードを使用して、選択したフレックスフィールドのMDSアーティファクトをエクスポートし、ローカル・コンピュータ上のアーカイブにインポートします。フレックスフィールドのそれらのアーカイブ済ビジネス・コンポーネントは、トラブルシューティング目的で使用できます。

別の方法として、exportMetadata WLSTを使用してデプロイ済アーティファクトをエクスポートします。

フレックスフィールド・デプロイメント・ステータス: 計算方法

フレックスフィールド・デプロイメント・ステータスは、Oracle Applications Cloudデータベース内のフレックスフィールド・メタデータ定義が、Oracle Metadata Services (MDS)リポジトリ内に常駐するApplication Development Framework (ADF)ビジネス・コンポーネントにどのように関連するかを示します。

フレックスフィールド・デプロイメント・ステータスの計算方法を理解するためには、次の側面が重要です。

  • フレックスフィールド・デプロイメント・ステータスに影響を与える設定

  • デプロイメント・ステータスの計算方法

フレックスフィールド・デプロイメント・ステータスに影響を与える設定

フレックスフィールドに変更を加え、デプロイメント・ステータスが変更されることを予期している場合は、変更が保存されていることを確認します。フレックスフィールド・デプロイメント・ステータスに影響を与える設定はありません。

デプロイメント・ステータスの計算方法

フレックスフィールド定義が「フレックスフィールドの定義」アクティビティ・タスク・フローにより編集された場合、ステータスは編集済になります。最新のフレックスフィールド・メタデータ定義は、デプロイされた最新のフレックスフィールド定義とは異なります。フレックスフィールドで使用される値セットの変更を含め、あらゆる変更によってデプロイメント・ステータスは編集済に変更されます。デプロイされたことのないフレックスフィールドのステータスは編集済です。

注意: アプリケーションがプロビジョニングされると、プロビジョニング・フレームワークはそのアプリケーション内のすべてのフレックスフィールドのデプロイを試行します。

フレックスフィールドがサンドボックスに正常にデプロイされると、ステータスはサンドボックスにデプロイ済になります。アプリケーションの最新のフレックスフィールド・メタデータ定義は、サンドボックスMDSリポジトリ内にADFビジネス・コンポーネントを生成したメタデータ定義と一致します。サンドボックスがアクティブであるかどうかは、デプロイメント・ステータスに影響を与えません。フレックスフィールドがサンドボックスにデプロイされ、それ以降は編集されたりメインライン・メタデータに再デプロイされたりしていない場合、サンドボックスがアクティブであるかどうかに関係なく、またはどのユーザーがステータスを表示しているかに関係なく、ステータスはサンドボックスにデプロイ済のままになります。

フレックスフィールドがメインライン・メタデータに正常にデプロイされると、ステータスはデプロイ済になります。アプリケーションの最新のフレックスフィールド・メタデータ定義は、メインラインMDSリポジトリ内にADFビジネス・コンポーネントを生成したメタデータ定義と一致します。フレックスフィールドがメインライン・メタデータに正常にデプロイされると、変更通知が送信されます。いずれかのタイプのデプロイメントが失敗し、現在のフレックスフィールド定義がデプロイされていない場合、ステータスは「エラー」になります。デプロイメント・エラー・メッセージでエラーの詳細が示されます。アプリケーションの最新のフレックスフィールド・メタデータ定義は、正常にデプロイされた最新のフレックスフィールド定義とは異なる場合があります。

フレックスフィールド定義がパッチにより変更されている場合、ステータスはパッチ適用済になります。アプリケーションの最新のフレックスフィールド・メタデータ定義は、デプロイされた最新のフレックスフィールド定義とは異なります。パッチ適用前のフレックスフィールド定義がデプロイ済であり、そこでパッチが適用されると、ステータスはパッチ適用済に変わります。パッチ適用前のフレックスフィールド定義が編集済であり、そこでパッチが適用された場合に、まだ有効でない(パッチ外の)変更があることを反映してステータスは編集済のままとなります。

デプロイメントの試行が失敗した場合は、デプロイメント・エラー・メッセージにアクセスして詳細を確認できます。

フレックスフィールド対応サンドボックスのデプロイ: メインライン・メタデータの処理

サンドボックス内のフレックスフィールド定義は、フレックスフィールドがサンドボックスにデプロイされた時点での、Oracle Fusion Applicationsデータベース内のフレックスフィールド・メタデータ定義に対応します。フレックスフィールドは、エンド・ユーザーが使用できるようになったら、メインライン・メタデータにデプロイする必要があります。

フレックスフィールド対応サンドボックスは、次のコンポーネントを使用します。

  • Oracle Applications Cloudデータベース内のフレックスフィールド・メタデータ

  • サンドボックスOracle Metadata Services (MDS)リポジトリ内のフレックスフィールド・ビジネス・コンポーネント

  • メインラインMDSリポジトリ内のフレックスフィールドのユーザー・インタフェース・カスタマイズ

次の図では、「フレックスフィールドの定義」アクティビティの「フレックスフィールドの管理」タスクで使用できる2タイプのデプロイメントを示しています。フレックスフィールドをサンドボックスにデプロイすると、フレックスフィールドの動作テストのみを目的として、サンドボックスMDSリポジトリが作成されます。サンドボックスはそれをアクティブ化してアクセスする管理者のみがアクセス可能であり、一般のユーザーはアクセスできません。フレックスフィールドをメインライン・メタデータにデプロイすることで、フレックスフィールド定義はメインラインMDSリポジトリに適用され、そこからエンド・ユーザーが使用できるようになります。フレックスフィールドをメインライン・メタデータにデプロイした後、フレックスフィールド・セグメントが表示されるページをカスタマイズします。サンドボックスMDSリポジトリ内のページのカスタマイズは、メインラインMDSリポジトリには公開できません。

この図は、「フレックスフィールドの定義」アクティビティのフローを示しています。これには、サンドボックス内のフレックスフィールドのテストと、場合によってはユーザーのアクセスのためにフレックスフィールドをメインライン・メタデータにデプロイした後にOracle ComposerでMDSデータに変更を加えることも含まれます。

サンドボックス・メタデータ・サービスのリポジトリ・データ

フレックスフィールドをサンドボックスにデプロイすると、分離したテストを目的として、サンドボックスMDSリポジトリ内に、フレックスフィールドのアプリケーション開発フレームワーク(ADF)ビジネス・コンポーネントが生成されます。

注意: フレックスフィールド対応サンドボックスでページ・コンポーザを使用してフレックスフィールド・セグメント表示プロパティをカスタマイズしないでください。その変更は、フレックスフィールドをメインライン・メタデータにデプロイするときに失われます。

メインライン・メタデータ・サービスのリポジトリ・データ

Oracle Fusion Applicationsデータベースは、フレックスフィールドに関する唯一の正しい情報源を格納しています。フレックスフィールドがデプロイされると、ランタイム・ユーザー・インタフェースにフレックスフィールドを実装するADFビジネス・コンポーネント・オブジェクトが、この情報源からのメインラインMDSリポジトリ内に生成されます。

関連トピック

サンドボックスへのフレックスフィールドのデプロイ: 考慮事項

フレックスフィールドをサンドボックスにデプロイすると、フレックスフィールド対応サンドボックスが作成されます。各フレックスフィールド対応サンドボックスには、1つのフレックスフィールドのみが含まれています。

フレックスフィールドのランタイム動作は、フレックスフィールド対応サンドボックス内でテストできます。変更が必要な場合、「フレックスフィールドの定義」定義に戻ってフレックスフィールド定義を変更します。

フレックスフィールドをサンドボックスにデプロイすると、セグメントに関するメタデータがデータベースから読み取られ、フレックスフィールドのアプリケーション開発フレームワーク(ADF)ビジネス・コンポーネント・アーティファクトがその定義に基づいて生成され、定義から導出された生成済アーティファクトのみがサンドボックスに格納されます。

フレックスフィールド・サンドボックスをデプロイすると、フレックスフィールド・サンドボックスの名前が生成され、そのフレックスフィールド・サンドボックスが現在のアクティブなサンドボックスとして設定されます。次にアプリケーションにサインインすると、更新されたフレックスフィールド構成が表示されます。Oracle Applications Cloudグローバル・ヘッダーに現行セッション・サンドボックスが表示されます。

注意: サンドボックスの管理ツールを使用して作成されたスタンドアロンのサンドボックスとは異なり、フレックスフィールド用にデプロイされたサンドボックスには単一のフレックスフィールドのみが含まれます。フレックスフィールド・サンドボックスは、サンドボックスの管理ツールを使用して管理でき、既存のフレックスフィールド・サンドボックスをアクティブとして設定したりそれを削除したりできます。

サンドボックスにデプロイした後にフレックスフィールドをメインライン・メタデータにデプロイすると、サンドボックス対応フレックスフィールドは自動的に削除されます。

サンドボックスMDSリポジトリ・データ

サンドボックス・データにより、ユーザーがアクセスできるメインライン・メタデータに最初にデプロイする前に、フレックスフィールドを分離してテストできます。

注意: フレックスフィールド対応サンドボックスでページ・コンポーザを使用してフレックスフィールド・セグメント表示プロパティをカスタマイズしないでください。その変更は、フレックスフィールドをメインライン・メタデータにデプロイするときに失われます。

フレックスフィールド対応サンドボックスの管理

フレックスフィールドをサンドボックスとしてデプロイすると、そのフレックスフィールド対応サンドボックスはユーザー・セッションで自動的にアクティブ化されます。変更を反映するためにサインインしなおすと、サンドボックスはセッション内でアクティブになっています。

フレックスフィールドは、「フレックスフィールドの定義」タスク・フロー・ページを使用してのみサンドボックスにデプロイできます。

「設定および保守」作業領域の「管理」メニューにあるサンドボックスの管理機能を使用して、フレックスフィールド対応サンドボックスをアクティブ化してアクセスすることもできます。

注意: フレックスフィールド対応サンドボックスにアクセスするために「フレックスフィールドの定義」またはサンドボックスの管理のタスク・フローのいずれを使用する場合でも、ランタイムにデプロイした変更を表示するには、サインアウトしてサインインしなおす必要があります。

サンドボックスからメインライン・メタデータにフレックスフィールドを公開することはできません。メインライン・メタデータのフレックスフィールド構成が唯一の正しい情報源であるため、「フレックスフィールドの定義」タスク・フロー・ページを使用して、メインライン・メタデータのユーザーがアクセスできるようにフレックスフィールドをデプロイする必要があります。

関連トピック

コマンドラインを使用したフレックスフィールドのデプロイ: 説明

フレックスフィールドをデプロイするために、「キー・フレックスフィールドの管理」、「付加フレックスフィールドの管理」および「拡張可能フレックスフィールドの管理」タスクを使用できます。WebLogic Server Tool (WLST)コマンドを使用して、事前定義フレックスフィールド・アーティファクトがあるOracle Metadata Services (MDS)リポジトリの準備や、フレックスフィールドのデプロイを行うこともできます。

次の表では、使用可能なコマンドについて説明しています。

WebLogic Server Toolコマンド 説明 
deployFlexForApp

指定されたエンタープライズ・アプリケーションのすべてのフレックスフィールドをデプロイします。デプロイメント・ステータスに関係なくすべてのフレックスフィールドのデプロイを強制するというオプションが有効になっていないかぎり、ステータスがデプロイ済以外のフレックスフィールドのみがこのコマンドの影響を受けます。

初期アプリケーション・プロビジョニングでこのコマンドを実行して、フレックスフィールド・アーティファクトがあるMDSリポジトリを準備します。

 
deployFlex

デプロイメント・ステータスに関係なく、単一のフレックスフィールドをデプロイします

 
deployPatchedFlex

フレックスフィールドのシード・データ・フレームワーク(SDF)パッチを使用して提供されたフレックスフィールドの変更をデプロイします。パッチ適用済デプロイメント・ステータスのフレックスフィールドをデプロイします。

 
deleteFlexPatchingLabels

パッチ適用ラベルを表示および削除するための、フレックスフィールド変更のMDSラベルを表示します。

 
validateFlexDeploymentStatus

デプロイされていないかまたはデプロイメント失敗のフレックスフィールドを含むリストを表示します。

これらのコマンドを実行すると、コマンドラインにレポートが出力されます。このレポートは、処理されるすべてのフレックスフィールドについての次の情報を提供します。

  • アプリケーションID (APPID)

  • フレックスフィールド・コード

  • デプロイメントの結果(成功またはエラーなど)

エラーの場合、レポートにエラーが発生した使用方法がリストされます。ランタイム例外が発生した場合、出力にはトレースバック情報が表示されます。各WLSTフレックスフィールド・コマンドに対して、reportFormat='xml'引数を追加すると、レポートがXML文字列として返されます。

コマンドライン・デプロイメントの次の面を検討してください。

  • WLSTフレックスフィールド・コマンドの使用の準備

  • deployFlexForAppコマンドの使用

  • deployFlexコマンドの使用

  • deployPatchedFlexコマンドの使用

  • deleteFlexPatchingLabelsコマンドの使用

  • validateFlexDeploymentStatusコマンドの使用

  • WLSTの終了と結果の確認

WLSTフレックスフィールド・コマンドの使用の準備

WLSTフレックスフィールド・コマンドは、Oracle Fusion Middleware Extensions for Oracle Applicationの実行中インスタンスがあるドメインのWebLogic Administration Server上でのみ実行できます。

サーバー・ドメインへのOracle Fusion Middleware Extensions for Oracle Applicationのデプロイの詳細は、Oracle Fusion Applications開発者ガイドを参照してください。

AppMasterDBデータ・ソースがJDBCデータ・ソースとしてWebLogic Administration Serverに登録されており、ApplicationDBデータ・ソースと同じデータベースを指していることを確認します。

現在WebLogic Server Tool (WLST)が実行していなければ、開始します。

UNIX:

sh $JDEV_HOME/oracle_common/common/bin/wlst.sh

Windows:

wlst.cmd

サーバーに接続し、ユーザー名とパスワード引数をWebLogic Serverのユーザー名とパスワードに置き換えます。

connect('wls_username', 'wls_password', 'wls_uri')

値は単一引用符で囲む必要があります。wls_uri値は、通常はT3://localhost:7101です。

WLST スクリプト・ツールの詳細は、『Oracle Fusion Middleware Oracle WebLogic Scripting Tool』を参照してください。

deployFlexForAppコマンドの使用

deployFlexForAppコマンドは、製品アプリケーションの事前定義されたフレックスフィールド・メタデータを、MDSリポジトリ内のアーティファクトに変換します。

注意: このコマンドは、アプリケーションをプロビジョニングすると自動的に実行されます。ただし、アプリケーションをカスタマイズする場合、次に示すタスクの順序に従って手動で実行する必要があります。

  1. MDSリポジトリからフレックスフィールド・アーティファクトを読み取るようにアプリケーションを構成します。

  2. deployFlexForAppコマンドを実行します。

  3. アプリケーションにサインインします。

事前定義されたフレックスフィールド・メタデータがない場合でも、この一連の手順は必須です。

このコマンドは、forceパラメータが'true'に設定されていないかぎり(デフォルトの設定は'false')、ステータスがデプロイ済であるフレックスフィールドをデプロイしません。

構成済フレックスフィールド・アーティファクトがあるMDSパーティションの準備については、Oracle Fusion Applications開発者ガイドを参照してください。

WLSTツールから、次のコマンドを実行してアーティファクトをMDSパーティションにデプロイします。product_application_shortnameは単一引用符で囲んだアプリケーションの短縮名で置き換えます。

deployFlexForApp('product_application_shortname'[, 'enterprise_id'] [,'force'])

マルチテナント環境では、enterprise_idを、フレックスフィールドがマップされるエンタープライズIDで置き換えます。そうしない場合は、'None'で置き換えるか、または2番目の引数を指定しないでおきます。

すべてのフレックスフィールドをそのデプロイメント・ステータスに関係なくデプロイするには、forceを'true'に設定します(デフォルトの設定は'false')。すべてのフレックスフィールドをシングルテナント環境でデプロイするには、enterprise_idを'None'に設定するか、または次の署名を使用できます。

deployFlexForApp(applicationShortName='product_application_shortname',force='true')

アプリケーションの短縮名は、アプリケーションのモジュール名と同じです。アプリケーション・タクソノミの処理については、Oracle Fusion Applications開発者ガイドを参照してください。

deployFlexコマンドの使用

WLSTツールから、次のコマンドを実行してフレックスフィールドをデプロイします。flex_codeはフレックスフィールドを識別するコードで置き換え、flex_typeはフレックスフィールドのタイプ(付加フレックスフィールド、キー・フレックスフィールド、拡張可能フレックスフィールドのいずれか)で置き換えます。値は単一引用符で囲む必要があります。

deployFlex('flex_code', 'flex_type')

オプションで、フレックスフィールドが拡張可能フレックスフィールドであり、すべてのフレックスフィールドの構成をデプロイする場合は、次のコマンドを実行します。

注意: デフォルトでは、拡張可能フレックスフィールドは部分的にデプロイされます。つまり、最近変更が加えられたページ、コンテキスト、またはカテゴリのみがデプロイされます。
deployFlex('flex_code', 'flex_type', ['force_Complete_EFF_Deployment'])
where, forceCompleteEFFDeployment=None

deployPatchedFlexコマンドの使用

アプリケーションがオフラインでパッチ適用されたなど、パッチ適用フレームワークによりコマンドが開始されない状況では、deployPatchedFlexコマンドを使用します。

インストールがマルチテナント対応である場合、このコマンドはすべてのエンタープライズ向けに、パッチ適用されたすべてのフレックスフィールドをデプロイします。このコマンドは手動で開始することは意図されていません。

フレックスフィールドがパッチ適用済デプロイメント・ステータスであることを確認するには、プロビジョニング・チームまたはパッチ適用チームに問い合せるか、フレックスフィールド管理のタスク・フローを使用します。

WLSTツールから、次のコマンドを実行して、アーティファクトをMDSパーティションにデプロイします。

deployPatchedFlex()

次のコマンドを実行して、READYステータスまたはERRORステータスのいずれかであるすべてのフレックスフィールドをデプロイします。

deployPatchedFlex(mode='RETRY')

deleteFlexPatchingLabelsコマンドの使用

フレックスフィールドの変更をdeployPatchedFlex() WLSTコマンドを使用してMDSにデプロイするときはいつでも、MDSラベルがFlexPatchingWatermarkdate+timeの形式で作成されます。これらのラベルを照会および削除するには、deleteFlexPatchingLabelsコマンドを使用します。

WLSTツールから、deleteFlexPatchingLabels () コマンドを引数を指定せずに実行して、フレックスフィールドのパッチ適用ラベルを削除します。

フレックスフィールドのパッチ適用ラベルのリストを出力するには、次のようにコマンドにinfoOnly引数を指定して実行します。

deleteFlexPatchingLabels(infoOnly='true')

validateFlexDeploymentStatusコマンドの使用

validateFlexDeploymentStatus() WLSTコマンドは、Oracle Fusion Applicationsデプロイメント内のすべてのフレックスフィールドのデプロイメント・ステータスを検査します。

validateFlexDeploymentStatus()

このコマンドは、プロビジョニングされたJava EEアプリケーションの現在のインスタンス内のすべてのフレックスフィールドがデプロイ済であることを確認するために使用します。

WLSTの終了と結果の確認

ツールを閉じるには、次のコマンドを実行します: disconnect()。

オプションで、アプリケーションにサインインし、フレックスフィールドが含まれているユーザー・インタフェース・ページを開き、構成(値セット、セグメント、コンテキスト、構成など)が存在するフレックスフィールドの存在を確認します。

値セットの管理

値セット: 説明

値セットは、ビジネス・オブジェクト属性に対して格納される値を制御するための、フレックスフィールド・セグメントに割り当てられる有効な値のグループです。

ユーザーは、アプリケーションの使用時に、ビジネス・オブジェクトの属性に対して値を入力します。フレックスフィールドでは、値セットとして構成され、セグメントに割り当てられた有効な値のセットに照らして値が検証されます。

たとえば、必須のフォーマット(5桁の数字)を定義したり、有効な値のリスト(green、red、blueなど)を定義したりできます。

フレックスフィールド・セグメントは通常は検証され、特定のフレックスフィールド内の各セグメントは一般的には異なる値セットを使用します。単一の値セットを複数のセグメントに割り当てたり、値セットを異なるフレックスフィールド間で共有したりできます。

注意: 共有値セットへの変更が、その値セットを使用するすべてのフレックスフィールド・セグメントと互換性があることを確認してください。

値セットを理解するためには次の側面が重要です。

  • 値セットの管理

  • 検証

  • セキュリティ

  • 精度とスケール

  • 使用方法とデプロイメント

  • 保護された値セット・データ

値セットの管理

「値セットの管理」ページを開くには、「値セットの管理」タスクを使用します。「付加フレックスフィールドの管理」および「拡張可能フレックスフィールドの管理」タスクを使用して、値セットなどのセグメントを構成することもできます。値の管理ページを開くには、「値セットの管理」ページから値セットを選択して、値の管理をクリックします。あるいは、値セットの編集ページから値の管理をクリックします。

検証

値セットには、次のタイプの検証を使用できます。

  • フォーマット限定。この場合、ユーザーはリストから値を選択するのではなく、データを入力します

  • 独立。指定された有効な値で構成される値のリスト

  • 従属。別セグメントの独立した値から有効な値が導出される値のリスト

  • サブセット。値のリストは、既存の独立値セットの値のサブセットになります

  • 表。この場合、値はアプリケーション表の列から導出され、値のリストはWHERE句により制限されます

フォーマット限定の値セットを使用するセグメントは、有効な値のリストをユーザーに表示しません。表検証の値セットを、構成に使用可能な値セットのリストに追加することは、カスタム・タスクと見なされます。

注意: 会計キー・フレックスフィールドの値セットの場合は、独立検証のみを使用する必要があります。他の検証を使用する場合、データ・セキュリティ、レポート、アカウント階層統合などの一部のアカウント機能は使用できなくなります。

セキュリティ

値セットのセキュリティは、フレックスフィールド・セグメント内での使用に関してのみ機能します。値セットを使用するフレックスフィールド・セグメントの値にデータ・セキュリティを適用することを指定できます。ユーザーにプロビジョニングされたロールを基に、データ・セキュリティ・ポリシーにより、フレックスフィールド・セグメントのどの値をユーザーが表示または変更できるかが決定されます。

値セット・セキュリティの適用には、次の条件があります。

  • 値セット・レベル: 値セットは、データ・セキュリティ・ポリシーにより保護されるリソースです。値セットが保護される場合、すべてのフレックスフィールドでのその使用がすべて保護されます。同じ値セットの個々の使用に対してセキュリティを無効にすることはできません。

  • 独立、従属または表検証の値セットに適用されます。

  • 主にデータが作成または更新されるときに、問合せ目的でキー・フレックスフィールド組合せ表に適用されます。値セットのセキュリティでは、問合せ時にどの付加フレックスフィールド・データが表示されるかは決定されません。

  • 値セットに定義されるセキュリティ条件は、必ず表の別名を使用します。フィルタを使用すると、デフォルトでは必ず表の別名が使用されます。データ・セキュリティ条件に対して述語が定義される場合は、述語も必ず表の別名を使用するようにします。

キー・フレックスフィールドの場合、勘定科目組合せID、構成インスタンス番号(SIN)およびデータ・セット番号(DSN)に対応するビュー・オブジェクト内の属性は、一時型にすることはできません。これらはデータベース表に存在している必要があります。キー・フレックスフィールドの場合、SINセグメントは弁別子属性であり、勘定科目組合せセグメントは共通属性です。

精度とスケール

値セットのデータ型がNumberである場合、精度(ユーザーが入力できる最大桁数)またはスケール(小数点以下の最大桁数)を指定できます。

使用方法とデプロイメント

値セットの使用方法は、その値セットが使用されているフレックスフィールドです。値セットが使用されているフレックスフィールドのデプロイメント・ステータスは、値セット・インスタンスのデプロイメント・ステータスを示します。

次の図は、キー・フレックスフィールド内のセグメントと、付加フレックスフィールドのコンテキスト・セグメントにより使用される値セットを示しています。

図は、キー・フレックスフィールドと付加フレックスフィールドの両方により共有される値セットを示しています。

ほとんどの値セットで、値をフレックスフィールド・セグメントに入力する場合には、そのセグメントに割り当てられている値セットにすでに存在している値のみを入力できます。

グローバル・セグメントおよびコンテキスト依存セグメントには、値セットが必要です。値セットを付加フレックスフィールド・コンテキスト・セグメントに割り当てることができます。コンテキストに値セットは指定せず、コンテキスト値のみを指定する場合、有効な値のセットはコンテキスト値のセットと等しくなります。

保護された値セット・データ

アプリケーション開発者は一部の値セットに保護のマークを付け、それらが編集不可であることを示すことができます。

編集できるのは、保護のマークが付けられていない値セットのみです。保護された値セットは、編集も削除もできません。値セットのタイプが値をサポートするものである場合(独立、従属またはサブセットの値セットなど)、値の追加、編集および削除はできません。

注意: 保護された値セットへの参照は制限されません。値セットは、保護されているかどうかに関係なく、任意のフレックスフィールド・セグメントに割り当てることができます。同じように、他の値セットも保護されている値セットを参照できます。たとえば、保護されていない従属値セットは、保護されている独立値セットを参照できます。

関連トピック

値セットの定義: 重要な選択

値セットの検証および使用方法により、フレックスフィールド・セグメントにより表される属性の有効な値にユーザーがアクセスする場所と方法が決定されます。

ヒント: フレックスフィールドのガイドラインとして、フレックスフィールドの構成時には値セットを各セグメントに割り当てることができるため、値セットはフレックスフィールドの構成前に定義してください。付加および拡張可能フレックスフィールド・セグメントを使用すると、フレックスフィールドが表示されるランタイム・ページ上でセグメントを追加または編集するときに、値セットを作成できます。

値セットの定義では次の側面が重要です。

  • コンテキスト・セグメントの値セット

  • フォーマット限定検証

  • 相互依存値セット

  • 表検証

  • 範囲

  • セキュリティ

  • テストと保守

コンテキスト・セグメントの値セット

値セットをコンテキスト・セグメントに割り当てる場合は、表検証値セットまたは独立値セットのみを使用できます。

コンテキスト値の検証には、表値セットおよび独立値セットのみを使用できます。データ型は文字でなければならず、格納される値の最大長は、コンテキストの列長よりも長くしないでください。表の値セットを使用する場合、その値セットは、値セットが割り当てられたフレックスフィールド・セグメントを除き、値セットのWHERE句にあるフレックスフィールド・セグメントは参照できません。

フォーマット限定検証

フォーマット限定検証タイプでは、指定されたフォーマット・ルールを満たしているかぎり、ユーザーは任意の値を入力できます。値は値セットに定義された最大長より長くしてはならず、その値セットに対するすべてのフォーマット要件を満たす必要があります。

たとえば、値セットが数字のみを許可する場合、ユーザーは値456を(最大長が3以上である値セットに)入力できますが、値ABCは入力できません。フォーマット限定の値セットは、ユーザーが入力できる様々な値の範囲を別の方法で制限することはありません。数値の場合、数値をゼロ埋込みする必要があるかどうか、または基数セパレータの後に何桁続ける必要があるかも指定できます。

相互依存値セット

独立値セットを使用して、アプリケーション表に格納されず、別の独立値セットのサブセットに従属しないリストに対してデータを検証します。同じフレックスフィールド内の別のセグメントに適用する独立値セットをまず定義してからでないと、特定のセグメントの従属値セットを指定することはできません。関連する独立セグメントに対してユーザーが定義した値に基づいて特定のセグメントの値リストを制限するには、従属値セットを使用します。従属リストで使用できる値と特定の値の意味は、独立して検証されるセグメントにどの値が選択されたかに応じて決まります。

たとえば、米国の州の独立値セットを、CAやNYなどの値で定義できます。次に米国の都市の従属値セットを、独立値のCAに有効であるSan FranciscoやLos Angelesなどの値で定義します。同様に、New York CityやAlbanyは独立値NYに対して有効です。ユーザー・インタフェースでは、特定の州に対しては有効な都市のみを選択できます。

サブセットの値セットは既存の独立値セットから定義するため、まず独立値セットを定義する必要があります。ユーザーは、サブセットの値セットにアクセスするために別のセグメントの値をまず選択しておく必要はありません。

独立、従属およびサブセットの値セットは、有効な値のカスタマイズ・リストが必要です。値セットの有効な値を作成して管理したり、その表示順序を管理したりするには、値の管理ページを使用します。

ヒント: 「値セットの管理」ページをカスタマイズして、FND_VS_VALUES_B付加フィールドの新規コンテキストにコンテキスト依存セグメントを追加することで、有効な各値の追加属性を取得できます。

表検証

一般に、使用する値がサプライヤ名の表などのアプリケーション表内にすでに保持されている場合は、表検証セットを使用します。有効な値を含む表列を指定します。オプションで、説明とIDの列、セットに使用する値を制限するWHERE句およびORDER BY句を指定できます。

ID列を指定すると、フレックスフィールドは関連するフレックスフィールド・セグメントで、値列からの値のかわりにID値を保存します。基礎表が翻訳をサポートしている場合、値セットの値列が基礎表の翻訳済属性に基づくようにすることで、翻訳済テキストの表示を有効にできます。さらに、言語依存ではない属性に基づくID列を定義して、値の不変ID(変更されないID)をトランザクション表に保存する必要があります。ランタイムでは、ランタイム・セッションのロケールの値列から対応する翻訳済テキストが表示されます。

表検証により、セグメントを同じコンテキスト構成内の複数の先行セグメントに依存させることができます。表検証の値セットのWHERE句内で、他のフレックスフィールド・セグメントを参照することはできません。つまり、WHERE句でSEGMENT.segment_codeやVALUESET.value_set_codeは参照できません。

表検証の値セットは、バインド変数に関係なく、表全体で一意の値を持ちます。値セットのWHERE句の断片は、バインド変数がない場合に考慮されます。バインド変数がある場合、値は値セット内で一意であると想定されます。キー・フレックスフィールドに表検証の値セットを使用する場合、キー・フレックスフィールドに対してサポートされている次のような統合機能はすべて使用できません。

  • データ・セキュリティ

  • Oracle Transactional Business Intelligence (OTBI)

  • ESSbase (Extended Spread Sheet Database)

  • ツリーまたは階層統合

キー・フレックスフィールドにこれらの統合機能を使用するには、独立値セットのみを使用する必要があります。

範囲

フォーマット、独立または従属の値セットの場合、範囲を指定して、有効な値を限定できます。値セット内で有効である値の範囲を指定できます。さらに、セグメントの範囲検証ペアを指定することもできます。その場合、1つのセグメントは範囲の下限を、もう1つのセグメントは範囲の上限を表します。

たとえば、フォーマット限定の値セットの範囲を、フォーマット・タイプを数値として、0から100までの値のみを入力できるように指定できます。

セキュリティ

独立値および従属値の場合、値セットを使用するセグメントの値にデータ・セキュリティを適用することを指定できます。ユーザーにプロビジョニングされたロールを基に、データ・セキュリティ・ポリシーにより、フレックスフィールド・セグメントのどの値をユーザーが表示または変更できるかが決定されます。

値セットに対してセキュリティを有効にするには、データベース・リソースを指定します。これは通常は値セットのコード値です。データベース・セキュリティ・ポリシーの管理タスクを使用して、フィルタやSQL述部などの条件、およびロールと条件を関連付けるポリシーを指定します。単純な条件にはフィルタを使用できます。より複雑な条件には、SQL述部を使用します。

値セットのデータ・セキュリティ・ポリシーと条件は、次の点でビジネス・オブジェクトのデータ・セキュリティ・ポリシーおよび条件とは異なります。

  • ユーザーに読取りアクセス権しか付与できません。他のアクションは指定できません。

  • SQL述部に基づく条件を定義するときは、従属、独立またはサブセットの値セットから値を参照するために、VALUE、VALUE_NUMBER、VALUE_DATE、VALUE_TIMESTAMPまたはVALUE_IDを使用します。表の値セットの場合、表を定義するために表の別名(&TABLE_ALIAS category=70など)を使用します。

表検証の値セットに対してセキュリティを有効にする場合、定義されるセキュリティ・ルールは絶対的なものであり、値セットのWHERE句で使用される可能性があるバインド変数(もしあれば)に基づく条件付きのルールではありません。たとえば、表検証の値セットに、値リストx、y、z、xx、yy、zzをフィルタして、x、y、zにするバインド変数があるとします。値セットに対して作成されるデータ・セキュリティ・ルールまたはフィルタでは、バインド変数について何も想定しないでください。値リスト全体が使用可能である必要があり、xを許可する、またはyとzを許可するなどのルールを記述する必要があります。データ・セキュリティのデフォルトでは、すべての値が拒否され、アクセス権が付与されている行のみが表示されます。

テストと保守

表検証値セットの値は、参照先の表または独立値セットの一部としてそれぞれ管理されるため、定義したり保守したりする必要はありません。

サンドボックスで値セットを管理することはできません。

既存の値セットを変更すると、影響を受けるすべてのフレックスフィールドのデプロイメント・ステータスが編集済に変わります。フレックスフィールドに変更を反映するには、その値セットを使用するすべてのフレックスフィールドを再デプロイする必要があります。値セットを管理するUIページで、値セットの使用状況には、値セットの変更によってどのフレックスフィールドが影響を受けるかが示されます。

アプリケーションに複数の言語がインストールされている場合、または今後アプリケーションに1つ以上の追加言語をインストールする可能性がある場合は、翻訳可能を選択します。これにより翻訳済の値をすぐに入力することが求められるわけではありませんが、後で言語を追加することにした場合でもこのオプションは変更できません。

値セットの計画: 考慮事項

作成および構成する値セットは、値セットを使用するビジネス・オブジェクト属性の有効な値に依存します。値セットの作成時には、値セットにまず名前を付けて説明を付与し、次にそのセットの有効な値を定義します。

値セットの計画には次の側面が重要です。

  • 値のリスト

  • 平文の入力

  • 値の範囲

  • 値のフォーマット仕様

  • セキュリティ

値のリスト

セグメントの有効な値を指定するには、次のいずれかのタイプのリストを使用できます。

  • 表列

  • カスタム・リスト。サブリストも含まれます。

  • 従属カスタム・リスト

有効な値が表列内に存在する場合は、表の値セットを使用して値のリストを指定します。有効な値を表内の値のサブセットに制限するには、SQL WHERE句を使用します。表値セットには、同じ構成にある別のセグメントに応じた検証の有効化など、いくつかの高度な機能も用意されています。

有効な値のカスタム・セットを指定するには、独立値セットを使用します。たとえば、月、火、水…と続く独立値セットを使用して、曜日を検証できます。また、セグメントの有効な値として、既存の独立値セットのサブセットも指定できます。たとえば、曜日の独立値セットがある場合、土曜日と日曜日のエントリで週末サブセットを構成できます。

リスト内の使用可能な値と、特定の値の意味が、すでに選択済のセグメント値に対して選択された独立値に依存する場合は、従属値セットを使用します。たとえば、有効な祝日は国によって異なります。従属値セットは値サブセットのコレクションであり、対応する独立値セットの各値に対して1つのサブセットがあります。

値のリスト・タイプの値セットでは、フォーマット、最小値、最大値を指定して、エンド・ユーザーが選択または入力できる有効な値をさらに制限できます。値のリスト・タイプの値セットでは、オプションで、値セットのデータ・セキュリティを実装できます。アプリケーションを様々なロケールで実行している場合には、値や説明用に別の翻訳を提供することが必要になる場合があります。

平文の入力

エンド・ユーザーがフォーマット・ルールに準拠しているかぎりどのような値でも入力できるように許可するには、フォーマット限定値セットを使用します。たとえば、最大長3、数値のみと指定した場合、エンド・ユーザーは456は入力できますが、4567や45Aは入力できません。最小値および最大値、右揃えにするか、ゼロ埋めを行うかを指定することもできます。フォーマット限定値セットでは、他のタイプの検証は適用されません。

値の範囲

値の範囲を指定するには、フォーマット限定、独立または従属のいずれかの値セットを使用できます。たとえば、フォーマット限定の値セットをフォーマット・タイプとして数値で作成し、エンド・ユーザーが0から100の範囲の値しか入力できないようにできます。または、フォーマット・タイプに日付を使用する、エンド・ユーザーがある特定の年の日付(たとえば1993年1月1日から1993年12月31日までの範囲など)しか入力できないフォーマット限定値セットを作成することもできます。最小値および最大値によりこのような制限が強制されるため、個々の数値や日付を含む値セットを定義する必要はありません。

値のフォーマット

フレックスフィールド・セグメントでは通常、検証タイプに関係なく、なんらかのフォーマット指定が必要です。値セットを作成する前に、要求するフォーマットの指定方法を検討します。

次の表は、検証タイプのオプションと値のデータ型を示しています。

オプション 説明

値のデータ型

文字、数値、日付、日時。

値のサブタイプ

テキスト、翻訳済テキスト、数字のみ、時刻(20:08)、時刻(20:08:08)。

従属、独立およびフォーマット検証タイプの文字データ型に対する追加のデータ型指定。

最大長

文字データ型の最大文字数または最大桁数。

精度

ユーザーが入力できる最大桁数。

スケール

小数点の後に続けることができる最大桁数。

大文字のみ

小文字は自動的に大文字に変更されます。

ゼロ埋込み

入力した数値を自動的に右揃えし、ゼロを埋め込みます(0-9の数字のみを含む値に影響)。

注意: テキスト値のデータ型は、値セットの作成後に、翻訳済テキスト値サブタイプに変更することはできません。表示される値を他の言語に翻訳する必要性が考えられる場合、翻訳済テキストを選択します。翻訳済テキスト・サブタイプを選択しても、翻訳済の値を入力する必要はありません。

コンテキスト・セグメントの値セット

コンテキスト値の検証には、表値セットおよび独立値セットのみを使用できます。データ型は文字でなければならず、格納される値の最大長は、コンテキストの列長よりも長くしないでください。表の値セットを使用する場合、その値セットは、値セットが割り当てられたフレックスフィールド・セグメントを除き、値セットのWHERE句にあるフレックスフィールド・セグメントは参照できません。

セキュリティ

値セットでセキュリティを有効にすると、データ・セキュリティ・リソースの名前は、既存の値セットの名前かまたはユーザーが作成した名前になります。通常、この名前は値セットのコード値に一致します。変更の保存後にデータ・セキュリティ・リソース名を編集することはできません。

関連トピック

表検証値セットとバインド変数: 考慮事項

値セットをフレックスフィールドに割り当てると、WHERE句内でバインド変数を使用できます。

次のバインド変数は、フレックスフィールドの要素を参照します。

  • :{SEGMENT.<segment_code>}

  • :{CONTEXT.<context_code>;SEGMENT.<segment_code>}

  • :{VALUESET.<value_set_code>}

  • :{FLEXFIELD.<internal_code>}

  • :{PARAMETER.<parameter_code>}

セグメント・コード

:{SEGMENT.<segment_code>}

このバインド変数により、セグメントのIDまたは値が参照され、<segment_code>がセグメントを識別しています。IDを参照している場合、値セットはID検証済です。値を参照している場合、値セットはID検証済ではありあません。バインド値のデータ型は、セグメントの列のデータ型と同じです。

付加フレックスフィールドおよび拡張可能フレックスフィールドのいずれの場合でも、このセグメントはソース・セグメントと同じコンテキスト内になければなりません。ソース・セグメントにはWHERE句が含まれます。付加フレックスフィールドの場合、このセグメントがグローバルであれば、ソース・セグメントもグローバルでなければなりません。

このセグメントは、このバインド変数のターゲット・セグメントの連番よりも小さい連番を持っていなければなりません。現在のフレックスフィールド・コンテキストに、一致するセグメントが存在していなければなりません。

このバインド変数は、有効な値のセットが、別のセグメントの値に依存している場合に便利です。たとえば、CITIES表から選択する値は、選択された国に依存している場合があります。SEGMENT1に国の値が含まれていれば、CITIES表のWHERE句は<country_code> = :{SEGMENT.SEGMENT1}となる可能性があります。

コンテキスト・コード

:{CONTEXT.<context_code>;SEGMENT.<segment_code>}

このバインド変数は、拡張可能フレックスフィールドに対してのみ有効で、ターゲット・セグメント(WHERE句があるセグメント)とは異なるコンテキストにあるセグメントのID(値セットがID検証済の場合)または値(ID検証済でない場合)を参照します。

  • コンテキストは<context_code>により識別されます。これは同じカテゴリ内または先祖のカテゴリ内になければなりません。これは複数行コンテキストにすることはできません。

  • セグメントは<segment_code>により識別されます。バインド値のデータ型は、セグメントの列のデータ型と同じです。

注意: ターゲット・セグメントは、ソース・セグメントに値があることを確認するために、ユーザー・インタフェース内ではソース・セグメントの後に表示される必要があります。ターゲット・セグメントのコンテキストが単一行コンテキストである場合、ソースとターゲットのセグメントは別々のページ上になければならず、ターゲット・ページはソース・ページの後に続く必要があります。

拡張可能フレックスフィールドのフレームワークでは、相互コンテキスト・バインド・パラメータで定義されたセグメントの不一致値に関連する追加の検証は実行されません。管理者は正しいペアのセグメント値を移入する必要があります。

このバインド変数は、有効な値のセットが、別のコンテキストのセグメントの値に依存している場合に便利です。たとえば、「コンプライアンスと証明書」コンテキストにあるセグメントに対してCERTIFICATION表から選択する値は、「製造」コンテキストの「国」セグメントの値に依存する場合があります。

値セット・コード

:{VALUESET.<value_set_code>}

このバインド変数は、value_set_codeで特定される値セットに割り当てられたセグメントのID(値セットがID検証済の場合)または値(ID検証済でまお場合)を参照します。バインド値のデータ型は、セグメントの列のデータ型と同じです。

このセグメントは、このバインド変数のセグメントの連番よりも小さい連番を持っていなければなりません。値セットに複数のセグメントが割り当てられている場合、以前に一致した最も近いセグメントが、バインド式の解決に使用されます。現在のフレックスフィールド・コンテキストに、一致するセグメントが存在していなければなりません。

一連の有効な値が、別のセグメントにある値に依存しており、そのセグメント・コードが一定ではない場合には、このバインド変数が便利です。これは値セットが複数のコンテキストやフレックスフィールドで使用される場合などが該当します。たとえば、CITIES表から選択する値は、選択された国に依存している場合があります。国の値を含むセグメントの値セットがCOUNTRIESである場合、CITIES表のWHERE句は<country_code> = :{VALUESET.COUNTRIES}などになります。

フレックスフィールドの内部コード

:{FLEXFIELD.<internal_code>}

このバインド変数は、値セットが使用されるフレックスフィールドの内部コード、または検証日付を参照します。internal_codeは、次のいずれかでなければなりません。

  • APPLICATION_ID: この値セットが使用されるフレックスフィールドのアプリケーションID。APPLICATION_IDのデータ型とその結果のバインド値はNUMBERです。

  • DESCRIPTIVE_FLEXFIELD_CODE: この値セットが使用されるフレックスフィールドの識別コード。DESCRIPTIVE_FLEXFIELD_CODEのデータ型とその結果のバインド値はVARCHAR2です。この文字列は、付加および拡張可能の両方のフレックスフィールドに使用することに注意してください。

  • CONTEXT_CODE: この値セットが使用されるフレックスフィールド・コンテキストのコンテキスト・コード。CONTEXT_CODEのデータ型とその結果のバインド値はVARCHAR2です。

  • SEGMENT_CODE: この値セットが使用されるフレックスフィールド・セグメントの識別コード。SEGMENT_CODEのデータ型とその結果のバインド値はVARCHAR2です。

  • VALIDATION_DATE: 現在のデータベース日付。VALIDATION_DATEのデータ型とその結果のバインド値はDATEです。

フレックスフィールドのパラメータ

:{PARAMETER.<parameter_code>}

このバインド変数は、フレックスフィールド・パラメータの値を参照し、parameter_codeによりパラメータが識別されます。結果のバインド値のデータ型は、パラメータのデータ型と同じになります。

注意: WHERE句がVALUESET.value_set_codeまたはSEGMENT.segment_codeバインド変数を使用する場合、表の値セットをコンテキスト・セグメントに割り当てることはできません。

表検証の値セット: 実例

アプリケーション・ユーザー・インタフェースで、顧客が満足度の入力に使用する値リストを表示するとします。値列の名前は1、2、3、4、5で、値列の説明は「非常に満足」、「満足」などとします。ユーザーは該当する値、または対応する名前が格納される説明を選択できます。これにより、名前の値を計算式で使用できます。

この場合、表検証の値セットの基準としてFND_LOOKUPS表を使用できます。参照の意味は「値」列名と対応し、参照の説明は「摘要」列名と対応します。次の表は、値セットのプロパティを示したものです。

プロパティ 値

FROM句

FND_LOOKUPS

WHERE句

lookup_type = 'CN_XX_CUST_SATISFACT_SCORE'

ID列

lookup_code

値列

meaning

説明列

description

有効化列

enabled_flag

開始日列

start_date_active

終了日列

end_date_active

ORDER BY

display_sequence

このタスクが完了すると、実装プロジェクトの「インセンティブ報酬」ページで使用される顧客満足度の値セットが作成されたことになります。

参照に基づいた値セットの作成

  1. 「設定および保守」作業領域から、「値セットの管理」タスクを見つけて、「タスクに進む」アイコン・ボタンをクリックします。

  2. 「値セットの管理」ページで、「作成」アイコン・ボタンをクリックします。

  3. 値セットの作成ページで、次の値を入力します。

    1. 「値セット・コード」フィールドで、CN_XX_CUSTOMER_SATISFACTION_SCORESと入力します

    2. 「摘要」フィールドで、顧客満足度を入力します。

    3. 「モジュール」フィールドで、「検索」を選択します

    4. 「検索と選択」の「モジュール」サブウィンドウで、ユーザー・モジュール名フィールドにIncentと入力します

    5. 「インセンティブ報酬」を選択します。

    6. 「OK」をクリックします。

  4. 値セットの作成ページで、次の値を入力します。

    1. 検証タイプフィールドで、「表」を選択します。

    2. 値のデータ型フィールドで、文字を選択します。

    3. 「定義」セクションのFROM句フィールドに、FND_LOOKUPSと入力します。

    4. 値列名フィールドに、DESCRIPTIONと入力します。

    5. 摘要列名フィールドに、MEANINGと入力します。

    6. ID列名フィールドに、LOOKUP_CODEと入力します。

    7. 有効化列名フィールドに、'Y'と入力します。

    8. 開始日列名フィールドに、START_DATE_ACTIVEと入力します。

    9. 終了日列名フィールドに、END_DATE_ACTIVEと入力します。

    10. WHERE句フィールドに、LOOKUP_TYPE = 'CN_XX_CUST_SATISFACT_SCORE'と入力します。

  5. 「保存してクローズ」をクリックします。

  6. 「値セットの管理」ページで、「完了」をクリックします。

「値セットの管理」ページへの属性の追加: 手順

属性は、独立、従属およびサブセットの値セットに追加できます。属性は「値セットの管理」ページに表示され、そこでそれぞれの有効な値に関する追加情報を格納できます。アプリケーション・ページに属性を表示するには、アプリケーションをプログラム的に変更する必要があります。

属性を追加してその後で「値セットの管理」ページに属性を表示するには、次の手順を実行します。

  1. 「付加フレックスフィールドの管理」タスクを使用して、FND_VS_VALUES_Bフレックスフィールドを見つけ、編集のために開きます。

  2. コンテキストの管理をクリックします。

  3. 新しいコンテキストを作成し、値セット・コードをコンテキスト・コードに使用します。

  4. 新しい属性をコンテキスト依存セグメントとして追加し、変更を保存します。

  5. FND_VS_VALUES_Bをランタイムにデプロイします。

  6. サインアウトしてサインインしなおします。

  7. 「値セットの管理」ページを開いて新しい属性を表示します。

値セットの値のインポート: 手順

編集する値、または特定の独立または従属値セットに追加する値が含まれるファイルをインポートできます。

たとえば、100個の値をアップロードするほうが、「値セットの管理」タスクを使用して個別に作成するよりも効率的である場合があります。しかし、数個の値であれば、関連タスクを実行するほうが速い可能性もあります。

値セットの値のインポート

値セットの値をインポートするには、次のようにします。

  1. 追加または更新する値セット内の値を含むフラット・ファイルを作成します。

    注意:

    • ファイルの作成時に、値を追加するかまたは既存の値を編集する、既存の値セット・コードを指定する必要があります。値セットが存在しない場合、「設定および保守」作業領域にある適切な「値セットの管理」設定タスクを使用して値セットを追加します。

    • 作成するファイルは、値セット値を含むフラット・ファイルを作成するためのフォーマットおよびコンテンツ要件を順守する必要があります。

  2. インポートおよびエクスポート用のファイルページを使用して、フラット・ファイルをコンテンツ・リポジトリにアップロードします。

  3. 「設定および保守」作業領域にある適切な「値セットの管理」設定タスクを使用してファイルをインポートします。ファイルをインポートするには、次のようにします。

    1. 「値セットの管理」ページで、「処理」→「インポート」の順にクリックします。

    2. 「ファイル名」フィールドで、インポートおよびエクスポート用のファイルページを使用してアップロードしたフラット・ファイルの名前を入力します。

    3. 「アカウント」フィールドで、フラット・ファイルが含まれるユーザー・アカウントを選択します。

    4. 「アップロード」をクリックします。

    注意: 別の方法として、次のいずれかの方式を使用してファイルをインポートすることもできます。

    • 値セットの値のアップロードスケジュール済プロセスを実行します。

    • アプリケーション・コア・メタデータのインポート Webサービスを使用します。アプリケーション・コア・メタデータのインポートWebサービスの詳細は、ご使用のクラウド・サービスの『SOAP Webサービス・ガイド』を参照してください。

関連トピック

値セットの値をアップロードするためのフラット・ファイルの要件: 説明

コンテンツ・リポジトリから大量の値セットの値データをインポートできます。値セットの値をコンテンツ・リポジトリにアップロードするには、追加または更新する値セットの値を含むフラット・ファイルを作成します。これらのフラット・ファイルをコンテンツ・リポジトリにアップロードするには、インポートおよびエクスポート用のファイルページを使用します。

一般要件

フラット・ファイルの最初の行には、値セットの値データのすべての必須列を含む列名が、「|」(パイプ)文字で区切られて、含まれている必要があります。後続の各行には、列名と同じ順序で指定されたデータの行が、「|」 文字で区切られて含まれている必要があります。

フラット・ファイルを作成するための要件は、次に示す値セットのタイプによって異なります。

  • 独立値セット

  • 従属値セット

独立値セット

独立値セットの値をアップロードするためのフラット・ファイルには、必須列が含まれている必要があります。次の表に、3つの必須列とそのデータ型を示します。

列名 データ型

ValueSetCode

VARCHAR2(60)

Value

VARCHAR2(150)

Enabled Flag

VARCHAR2(1)、YまたはN

注意: オプションの列も指定できます。

例:

  • 最小限の列しか持たないCOLORS独立値セットに値をアップロードするには、次のフラット・ファイルを使用できます。

    ValueSetCode | Value | EnabledFlag
COLORS | Red | Y
COLORS | Orange | Y
COLORS | Yellow | Y

  • 追加の(オプションの)列を持つSTATES独立値セットに値をアップロードするには、次のフラット・ファイルを使用できます。

    ValueSetCode | Value | Description | EnabledFlag
STATES | AK | Alaska | Y
STATES | CA | California | Y
STATES | WA | Washington | Y

従属値セット

従属値セットの値をアップロードするためのフラット・ファイルには、必須列が含まれている必要があります。次の表に、4つの必須列とそのデータ型を示します。

列名 データ型

Value Set Code

VARCHAR2(60)

Independent Value

VARCHAR2(150)

Value

VARCHAR2(150)

Enabled Flag

VARCHAR2(1)、YまたはN

注意: オプションの列も指定できます。

例:

CITIES従属値セット(STATES独立値セットに依存)に値をアップロードするには、次のフラット・ファイルを使用できます。

ValueSetCode | IndependentValue | Value | EnabledFlag
CITIES | AK | Juneau | Y
CITIES | AK | Anchorage | Y
CITIES | CA | San Francisco | Y
CITIES | CA | Sacramento | Y
CITIES | CA | Los Angeles | Y
CITIES | CA | Oakland | Y

追加のオプション列

必須列に加えて、オプション列を追加できます。次の表に、従属値セットと独立値セットの両方のオプション列を示します。

列名 型

Translated Value

VARCHAR2(150)、翻訳可能な値セットで使用

Description

VARCHAR2(240)

Start Date Active

DATE (形式はYYYY-MM-DD)

End Date Active

DATE (形式はYYYY-MM-DD)

Sort Order

NUMBER(18)

Summary Flag

VARCHAR2(30)

Flex Value Attribute1 ... Flex Value Attribute20

VARCHAR2(30)

Custom Value Attribute1 ... Custom Value Attribute10

VARCHAR2(30)

関連トピック

値セットの値のアップロード・プロセス

このプロセスにより、フレックスフィールドの値セットの値を含むフラット・ファイルがアップロードされます。スケジュール済プロセスを使用して、編集する値、または既存の独立あるいは従属の値セットに追加する値が含まれているファイルをアップロードできます。このプロセスは、自動化処理または反復処理により大量の値セットの値データを追加または更新する場合に役立ちます。たとえば、繰返しプロセスとしてスケジュールされている場合、繰返しベースで100個の値をアップロードできます。この方法は、「設定および保守」作業領域にある「値セットの管理」タスクのインポート処理を使用するよりも効果的である場合があります。ただし、100個の値をアップロードするタスクの場合、関連タスクのインポート処理を使用するほうが処理が速い可能性もあります。

このプロセスは、「スケジュール済プロセス」の「概要」ページから実行します。これは、コンテンツ・リポジトリ・アカウントのフラット・ファイルが更新されるたびに、繰返しベースで実行できます。

値データを含むフラット・ファイルを作成し、インポートおよびエクスポート用のファイルページを使用して、そのフラット・ファイルをコンテンツ・リポジトリにアップロードする必要があります。

パラメータ

フラット・ファイル名

インポートおよびエクスポート用のファイルページを使用してアップロードしたフラット・ファイルの名前を入力します。

アカウント

アップロードするコンテンツ・リポジトリにフラット・ファイルが含まれているユーザー・アカウントを選択します。

関連トピック

フレックスフィールドの翻訳および値セットの構成: 説明

フレックスフィールドまたはセグメントの最初の構成時に、入力する翻訳可能なテキスト(プロンプトや摘要など)は、インストールされているすべてのロケールに対してテキストとして保存されます。その後、特定のロケール用の翻訳を提供できます。特定のロケール用の翻訳を提供しない場合、最初に入力された値がそのロケールで使用されます。

特定のロケール用のテキストを翻訳するには、そのロケールでサイン・インするか、グローバル・ヘッダーで「設定およびアクション」→「パーソナライズ」→「プリファレンスの設定」の順に選択してロケールを指定します。次に、「付加フレックスフィールドの管理」タスク、「キー・フレックスフィールドの管理」タスクまたは「拡張可能フレックスフィールドの管理」タスクを使用して、フレックスフィールド内の翻訳可能なテキストを更新します。翻訳された値に変更内容が反映されるのは、現在のセッションのロケールに対してのみです。

翻訳が完了した後に、フレックスフィールドをデプロイします。

依存値セットまたは独立値セットのタイプが文字で、サブタイプが翻訳済テキストの場合は、その値セットに対して翻訳を定義できます。翻訳を定義するには、現在のセッションを、翻訳を定義するロケールに設定します。次に、「値セットの管理」タスクを使用して、そのロケールの翻訳済の値および説明を入力します。

複数の言語をサポートし、値セットの値列が基礎となる表の翻訳済属性に基づいている表の値セットには、翻訳済の値を定義できます。マルチ言語サポート機能の使用の詳細は、Oracle Fusion Applications開発者ガイドを参照してください。

「値セットの管理」のFAQ

値セットがセキュリティ対応の場合には、どのような動作になりますか。

値セット・セキュリティは、アプリケーション内でのユーザーのロールに基づいて、値セットの値へのアクセスを保護できる機能です。

例として、米国の州名の値セットがあるとします。この値セットがフレックスフィールド・セグメントの検証に使用され、ユーザーがそのセグメントの値を選択できる場合、値セット・セキュリティを使用して、ユーザーがアプリケーション内で割り当てられているロールに基づき、特定の州または州のサブセットしか選択できないように制限できます。

たとえば、西部地域の従業員には、California、Nevada、Oregonなどの州のみを有効な値として選択できるようにします。そして西部地域以外の州は選択できないようにします。東部地域の従業員には、New York、New Jersey、Virginiaなどの州のみを有効な値として選択できるようにして、東部地域以外の州は選択できないようにします。値セット・セキュリティは、Oracle Applications Cloudデータ・セキュリティを使用して実装されます。

フレックスフィールド・セグメントのデフォルト値はどのように設定できますか。

フレックスフィールド・セグメントを定義または編集するときに、割り当てられている値セットの値を選択し、デフォルトとして設定します。

付加フレックスフィールド・セグメントのデフォルト値は、パラメータとして設定できます。マップ先のエンティティ・オブジェクト属性が、セグメントの初期デフォルト値を提供します。

セグメントに割り当てられている値セットのデータ型に適切であれば、デフォルト値は定数として設定できます。

初期デフォルト値に加えて、パラメータ値が変更されるたびに属性の値を更新するための導出値を設定できます。選択するパラメータにより、エンティティ・オブジェクト・ソース属性が特定されます。ランタイム時のソース属性の値への変更はすべて、セグメントの値に反映されます。

セグメントの表示タイプがチェック・ボックスの場合は、セグメントのデフォルト値として選択か選択解除かを設定できます。

付加フレックスフィールドの管理

付加フレックスフィールド: 説明

カスタム属性をビジネス・オブジェクト・エンティティに追加したり、その検証を定義したりするには、付加フレックスフィールドを使用します。

アプリケーションで使用できるすべてのビジネス・オブジェクト・エンティティは、付加フレックスフィールドに対応しています。ただし、付加フレックスフィールドの構成はオプションのタスクです。

コンテキスト

付加フレックスフィールドには、コンテキスト依存性を提供するコンテキスト・セグメントを1つしか設定できません。同じ基礎データベース列を、異なるコンテキストの異なるセグメントで使用できます。

たとえば、次の属性を使用する「寸法」コンテキストを定義できます。

  • 高さのATTRIBUTE1列

  • 幅のATTRIBUTE2列

  • 奥行のATTRIBUTE3列

さらに、同じ列を次の他の属性に使用する「測定」コンテキストを定義することもできます。

  • 重量のATTRIBUTE1列

  • 容量のATTRIBUTE2列

  • 密度のATTRIBUTE3列

セグメントとコンテキスト

次の表に、様々なタイプの付加フレックスフィールド・セグメントを示します。

セグメント・タイプ ランタイムの表示

グローバル・セグメント

常に使用可能

コンテキスト・セグメント

どのコンテキスト依存セグメントを表示するかを決定する

コンテキスト依存セグメント

コンテキスト・セグメントの値に応じて表示される

次の図では、付加フレックスフィールドには「カテゴリ」という名前のコンテキスト・セグメントが1つあり、そこにレジスタ、バッテリ、キャパシタの3つの値があります。さらに、付加フレックスフィールドは、各コンテキストに表示される2つのグローバル・セグメントと、特定のコンテキストにのみ表示される3つのコンテキスト依存セグメントで構成されています。

図には、コンテキスト・セグメントがどのように属性のカテゴリ(レジスタ、バッテリまたはキャパシタ)として機能するかを示す例が含まれています。グローバル・セグメントはいつでも使用できます。ただし、コンテキスト依存セグメントは、コンテキストに応じて使用可能になります。

アプリケーション開発では、構成に使用できるセグメントの数が決定されます。実装時に、以下を決定しながらフレックスフィールドを構成します。

  • 使用可能なセグメントを使用して追加する属性

  • コンテキスト値

  • 各コンテキストの属性の組合せ

値セット

各グローバル・セグメントおよびコンテキスト依存セグメントについて、そのセグメントに許可する値を構成します。それに基づいて、エンド・ユーザーが入力する値が検証されます。これにはセグメント間の相互依存検証も含まれます。

保護された付加フレックスフィールド・データ

アプリケーション開発者は、付加フレックスフィールド内の一部のデータ構成に保護のマークを付け、それらが編集不可であることを示すことができます。

付加フレックスフィールドの計画: 考慮事項

構成するフレックスフィールドを特定したら、構成を事前に計画します。構成の影響を受ける、デプロイメント内のUIページや他のアーティファクトのリストをまとめます。フレックスフィールドの表示と構成に必要なロールがプロビジョニングされていることを確認します。フレックスフィールドが表示されているランタイム・ページが表示されているときに、「管理」メニューのフレックスフィールドの強調表示コマンドを使用してフレックスフィールドを表示します。テストおよび本番ユーザーに対してフレックスフィールドをデプロイする方法を計画します。フレックスフィールドの管理に使用できるツールやタスクを確認します。これにはフレックスフィールド・セグメントの追加および編集用の、「フレックスフィールドの定義」タスク・リスト、サンドボックスの管理およびフレックスフィールドの強調表示などが含まれます。

付加フレックスフィールドの計画には、次のタスクが含まれる場合があります。

  1. 既存のパラメータを特定します。

  2. 既存のコンテキスト値を特定し、そのコンテキスト値が導出されたものであるかどうかを特定します。

  3. カスタム属性を特定します。さらに付加フレックスフィールド・セグメント、セグメント・プロパティ、構成を計画します。

  4. 検証ルールを計画します。

  5. 初期値を計画します。

  6. Oracle Business Intelligenceオブジェクトへの属性マッピングを計画します。

既存の付加フレックスフィールド・パラメータの特定

一部の付加フレックスフィールドでは、付加フレックスフィールド・セグメントの初期値の指定に使用できるパラメータが提供されます。このパラメータは、列値やセッション変数などの外部参照データです。たとえば、フレックスフィールドにユーザーの電子メール・パラメータが入っている場合、顧客電子メール属性の初期値をこのパラメータから導出するように構成できます。

付加フレックスフィールドのセグメントの作成ページにある導出値フィールドで、使用可能なパラメータのリストを確認します。このパラメータの1つを使用して初期値を設定すると決定した場合は、付加フレックスフィールド・セグメントを追加するときに、そのパラメータを導出値ドロップダウン・リストから選択します。

コンテキスト値が導出されるかどうかの評価

付加フレックスフィールド・コンテキスト値は、外部参照から導出されるように事前構成されている場合があります。たとえば、コンテキストが「婚姻状態」であれば、その値は従業員ビジネス・オブジェクトの属性から導出される可能性があります。コンテキスト値が導出される場合、計画段階で導出値とそのソースを考慮に入れることが必要になる場合があります。

コンテキスト値が導出されるかどうかを判断するには、付加フレックスフィールドの編集タスクに移動して、そのフレックスフィールドに対する構成済コンテキスト値のリストを確認します。コンテキスト・セグメント領域の導出値フィールドに、使用可能なパラメータのリストが表示されます。コンテキスト値が事前構成されている場合、Oracle Applications Cloudのヘルプでそれらの値の使用に関する製品固有の情報を参照してください。

セグメント、セグメント・プロパティおよび構成の計画

付加フレックスフィールドのセグメントを決定するためにビジネス・オブジェクトで必要となるカスタム属性を特定します。プロンプト、表示タイプ、初期値などのセグメント・プロパティを決定します。

付加フレックスフィールドの構成は、グローバル、コンテキストおよびコンテキスト依存セグメントにより決定されます。ビジネス・オブジェクトの各インスタンスについて、属性を取得するグローバル・セグメントを計画します。ビジネス・オブジェクトの特定のインスタンスに適用する状況の条件に依存するセグメントのコンテキストを計画します。コンテキストに関係する属性を取得するためのコンテキスト依存セグメントを計画します。

付加フレックスフィールドで使用できるコンテキスト・セグメントは1つのみです。コンテキスト・セグメントを使用できるカスタム属性のグループが複数ある場合は、会社のニーズや優先順位に基づいて1つのグループを選び、それ以外のカスタム属性はグローバル・セグメントとして追加する必要があります。

検証ルールの計画

各セグメントの検証ルールを定義して、それらのルールの値セットが存在しているかを確認します。存在していない場合は、作成する必要があります。値セットを作成する必要がある場合は、フレックスフィールドの構成前、またはセグメントの作成時か編集時のいずれかで作成できます。

セグメントの検証ルールを決定するときは、次の質問を考慮します。

  • データ型は何か(文字、日付、日時または数字)。

  • セグメントにはデータ型および最大長以外の検証が必要か。

  • 文字タイプの値は数字に制限する必要があるか、または英字を許可するか。

  • 英字を自動的に大文字に変更する必要があるか。

  • 数値はゼロ埋込みをする必要があるか。

  • 数値の基数セパレータに続けることができる桁数はいくつか。基本的な十進数システムでは、基数セパレータは小数点です。

  • 値は範囲内に収まる必要があるか。

  • 値は有効な値のリストから選択する必要があるか。必要がある場合、次の質問を考慮します。

    • 有効な値のリストを取得するために既存のアプリケーション表を使用できますか。またはカスタム・リストを作成する必要がありますか。

    • 既存の表を使用している場合、WHERE句を使用して値のリストを制限する必要がありますか。

    • 有効な値のリストは、別のフレックスフィールド・セグメントの値に依存していますか。

    • 有効な値のリストは、別のフレックスフィールド・セグメントの値のリストのサブセットですか。

初期値の計画

すべてのセグメントに対して、カスタム属性の初期値に使用する定数値またはSQL文があればそれらをリストします。

Oracle Business Intelligenceオブジェクトへのセグメントのマップ方法の計画

付加フレックスフィールドは、アドホック・レポートの作成を目的として、Oracle Transactional Business Intelligence (OTBI)に拡張できます。レポート作成に使用できるようにする付加フレックスフィールド・セグメントを決定し、それに応じて「付加フレックスフィールドの管理」ページでBI対応チェック・ボックスを選択します。BI対応セグメントをOTBIに拡張するプロセスを実行する必要があります。BI対応セグメントのOTBIへの拡張の詳細は、Oracle Transactional Business Intelligence管理者ガイドの設定および構成に関する章を参照してください。

レポート作成のニーズに応じて、別のコンテキストからの類似のコンテキスト依存属性を、OTBI内の同じ属性にマップできます。たとえば、コンテキスト依存の付加フレックスフィールドの別のコンテキストに、「製品の色」属性を追跡するセグメントがあるとします。セグメント・ラベルを使用して、セグメント・ラベルを定義し、それに応じてBIラベル・リストを更新することで、それらのコンテキスト依存属性をまとめてマップできます。

付加フレックスフィールドの管理: 考慮事項

付加フレックスフィールドの構成には、Oracle Fusion Applicationsデータベースに登録された使用可能なフレックスフィールドの管理、そのフレックスフィールド・レベル・プロパティの構成、付加フレックスフィールド・コンテキストの定義と管理、およびグローバル・セグメントとコンテキスト依存セグメントの構成が含まれます。

すべての付加フレックスフィールドはコンテキスト・セグメントを組み込むように登録されます。コンテキスト・セグメントを使用するかどうかは選択できます。

一般的に、付加フレックスフィールドの構成には次の手順が含まれます。

  1. ビジネス・インテリジェンス対応のフレックスフィールド用にセグメント・ラベルを作成します。

  2. 識別情報、初期デフォルト値および表示プロパティを指定して、グローバル・セグメントを構成します。

  3. プロンプト、コンテキスト・セグメントを表示するかどうか、および値を必須にするかどうかを指定して、コンテキスト・セグメントを構成します。

  4. 各コンテキスト値のコンテキスト・コード、摘要および名前を指定し、識別情報、列割当て、初期デフォルト値および表示プロパティを含むように構成された各コンテキスト依存セグメントを追加して、コンテキストを構成します。

付加フレックスフィールドの管理を理解するために次の側面が重要です。

  • セグメント

  • 強調表示された付加フレックスフィールドへのセグメントの追加

  • 使用方法

  • パラメータ

  • デリミタ

  • 初期値

  • Business Intelligence

セグメント

連番の順序番号を、グローバル・セグメントと、各コンテキスト内のコンテキスト依存セグメントに割り当てることができます。セグメントは常に固定された順序で表示されます。セグメントに対して別のセグメントですでに使用されている番号を入力することはできません。

値セットは、コンテキスト・セグメントでは省略可能であり、次の具体的なガイドラインに従います。

  • コンテキスト・セグメントに指定する値セットは、コンテキスト・コードのセットで構成されます。

  • これらのコンテキスト・コードはそれぞれ、付加フレックスフィールドに適したコンテキストに対応します。

  • 値セットは、独立または表検証でなければなりません。

  • 表検証の場合、WHERE句では、VALUESET.value_set_codeおよびSEGMENT.segment_codeバインド変数を使用しないでください。

  • 値セットのデータ型は文字でなければならず、格納される値の最大長は、コンテキストの列長より長くすることはできません。

  • コンテキスト・セグメントに値セットを指定しない場合、そのコンテキスト・セグメントに有効な値は、コンテキスト・コードから導出されます。各コンテキスト・セグメントの定義により、エンド・ユーザーがそのコンテキスト・コードを選択したときに表示できる、コンテキスト依存セグメントのセットが指定されます。

  • データの整合性の理由から、既存のコンテキストは削除できません。かわりに、関連するコンテキスト値を、その値セット内で終了日を過去の日付に設定することで無効にできます。

  • 付加フレックスフィールドでは、グローバル・セグメントとコンテキスト依存セグメントを個別に構成できます。これらのセグメント・タイプはその使用方法によって区別されますが、ほとんど同じプロパティを使用するアプリケーション・ページ上に構成されます。

強調表示された付加フレックスフィールドへのセグメントの追加

ランタイム・ページでフレックスフィールドを強調表示し、セグメントの追加アイコン・ボタンを使用してセグメントを作成する場合、セグメント・コード、名前、摘要、表列および連番が自動的に設定されます。セグメントの追加アイコン・ボタンを使用して付加フレックスフィールド・セグメントを構成する場合には、既存の値セットは使用できません。値セットは、セグメントを追加すると自動的に作成されます。有効な値、その摘要およびデフォルト値を入力したり、最小値や最大値など、値セットに対するフォーマット設定制約を指定したりできます。

表示タイプに応じて、セグメントの追加アイコン・ボタンを使用して作成する値セットは、独立値セットまたはフォーマット限定値セットのいずれかになります。次の表は、選択するセグメント表示コンポーネントに応じて、どのタイプの値セットが作成されるかを示しています。

表示コンポーネント セグメントの追加を使用して作成される値セット

チェック・ボックス

独立

ドロップダウン・リスト

独立

値のリスト

独立

ラジオ・ボタン・グループ

独立

検索機能付きテキスト・フィールド

独立

テキスト・ボックス

フォーマット限定

テキスト領域

フォーマット限定

日時

フォーマット限定

ヒント: コンテキスト値を追加したら、新しい値を表示するためにページをリフレッシュします。

使用方法

付加フレックスフィールドの使用方法により、複数のエンティティ、またはUSER表やUSER_HISTORY表などの複数のアプリケーション表に同じ定義を適用できます。付加フレックスフィールドの構成後に、付加フレックスフィールド表に、フレックスフィールド・セグメントの値を格納するプレースホルダ・エンティティが定義されます。フレックスフィールドを構成すると、その構成がすべての使用方法に適用されます。

パラメータ

一部の付加フレックスフィールドには、同一または関連するエンティティ・オブジェクトの属性であるパラメータが用意されています。パラメータは、付加フレックスフィールドのpublic引数です。パラメータは、付加フレックスフィールドの検証に外部値を提供します。パラメータを使用して、属性の初期値または導出値を、ユーザー入力からではなく、列値やセッション変数などの外部参照データから設定します。パラメータは、デフォルト・セグメント値を導出する論理を使用するか、表検証値セットのWHERE句を使用して参照できます。

デリミタ

セグメントのデリミタまたはセパレータは、フレックスフィールドが連結セグメントの文字列として表示されるときに、セグメント値を視覚的に区切ります。

初期値

初期値を定義するSQL文は、1行のみかつ正しいタイプの値を返す有効な文でなければなりません。

次の2タイプのSQL文を使用できます。

  • バインディングなしのSQL文。たとえば、EMPLOYEESからMIN(SALARY)を選択します。

  • バインド変数があるSQL文。SQL文のWHERE句では、次のバインド変数を使用できます。

    • :{SEGMENT.<segment_code>}: 同じコンテキスト内のセグメントを特定します。

    • :{CONTEXT.<context_code>;SEGMENT.<segment_code>}: 異なるコンテキスト内のセグメントを特定します。コンテキストは同じカテゴリまたは先祖のカテゴリ内になければならず、複数行のコンテキストにすることはできません。

    • :{VALUESET.<value_set_code>}: 特定の値セットに割り当てられている、同じコンテキスト内で最も近い先行セグメントを特定します。

    • :{FLEXFIELD.<internal_code>}: フレックスフィールドを特定します。

バインド変数の使用の詳細は、値セットのヘルプを参照してください。

Business Intelligence

グローバル、コンテキストまたはコンテキスト依存セグメントのBI対応チェック・ボックスを選択すると、そのセグメントはOracle Business Intelligenceで使用できるようになります。

フレックスフィールドをOracle Business Intelligenceにインポートすると、BIラベルドロップダウン・リストで選択したラベルにより、そのセグメントと他のコンテキストのセグメントが均等化され、ラベルが表す論理オブジェクトにセグメントがマップされます。

Business Intelligenceに対する付加フレックスフィールド・セグメントの有効化: 考慮事項

データベースにOracle Business Intelligence (BI)対応と登録されている付加フレックスフィールドの各セグメントには、BI対応という設定があります。グローバル、コンテキストまたはコンテキスト依存セグメントがBI対応であれば、Oracle Business Intelligenceで使用できます。

BI対応フレックスフィールド・セグメントを理解するために次の側面が重要です。

  • Oracle BIでBI対応セグメントを使用するためのビジネス・コンポーネントの平坦化

  • 平坦化されたコンポーネントにおける重複および複雑さを回避するためのセグメントの均質化

  • 平坦化されたビジネス・コンポーネントの属性からOracle BIの論理オブジェクトへのマッピング

  • セグメントをOracle BIの論理オブジェクトにマップするラベルの管理

ビジネス・インテリジェンス対応のフレックスフィールドをデプロイした後、トランザクション・ビジネス・インテリジェンス用のOracle Fusionデータ拡張のインポートプロセスを使用して、フレックスフィールドの変更をOracle Business Intelligenceリポジトリにインポートします。ユーザーはビジネス・インテリジェンス・アプリケーションで新しく生成された属性を使用できます。たとえば、ユーザーは付加フレックスフィールドによって追加された属性が含まれるレポートを生成できます。論理オブジェクトとインポートに関する追加情報は、Oracle Transactional Business Intelligence管理者ガイドを参照してください。

平坦化

ビジネス・インテリジェンス対応の付加フレックスフィールドをデプロイすると、デプロイメント・プロセスにより、通常のADFビジネス・コンポーネントに加え、平坦化されたアプリケーション開発フレームワーク(ADF)ビジネス・コンポーネントの追加セットが生成されます。ADFはデプロイメント中に生成されたランタイム・アーティファクトを処理します。平坦化されたビジネス・コンポーネントには、ビジネス・インテリジェンス対応セグメントの属性のみが含まれます。平坦化とは、各コンテキストの各カスタム列が、属性としてOracle Business Intelligenceフォルダに表示されるという意味です。

平坦化されたコンポーネントには、BI対応コンテキスト・セグメントの属性が1つと、各ビジネス・インテリジェンス対応グローバル・セグメントの属性が1つ含まれています。BI対応コンテキスト依存セグメントについては、次の点を考慮してください。

  • ラベルをセグメントに割り当てた場合、平坦化されたコンポーネントには、そのラベルの付いたセグメントを表す属性がさらに1つ含まれます。

  • ラベルを割り当てなかった場合、平坦化されたコンポーネントには、各コンテキストのそれぞれのBI対応コンテキスト依存セグメントに対する個別の属性が含まれます。

Business Intelligenceの論理オブジェクトへのマッピング

Business Intelligenceでは類似の複数のセグメントを単一の論理オブジェクトとして表現することで、レポートを簡略化できます。

様々なコンテキストで同じ目的を果たすコンテキスト依存セグメントのセットにラベルを割り当てる場合、これらのセグメントを単一の属性に統合、つまり均等化できます。これにより、プロセスの平坦化による重複、余分のワークロードおよに複雑さが回避されます。たとえば、「アメリカ」コンテキストに「パスポート」セグメント、「カナダ」コンテキストに「ビザ」セグメントがあるとします。「パスポート」と「ビザ」の両セグメントに「NationalID」というセグメント・ラベルを割り当てた場合、平坦化されたビジネス・コンポーネントでは、これらは同じ「NationalID」属性に均等化されます。

ラベルが付けられていないコンテキスト依存セグメントは、コンテキスト値の間では均等化されないため、平坦化されたコンポーネントでは、各コンテキスト値のそれぞれのコンテキスト依存セグメントに個別の属性が含まれます。同じようにラベルが付けられたセグメントでも、データ型や値セットのタイプに互換性がなければ、均等化できない可能性があります。

平坦化されたコンポーネントの対応する属性をOracle Business Intelligenceの論理オブジェクトにマップするには、グローバル・セグメント、コンテキスト・セグメントまたはコンテキスト依存セグメントにラベルを割り当てます。ラベルを使用してセグメントをBI論理オブジェクトにマップすると、Oracle Business Intelligenceにフレックスフィールドをインポートする手順を最小限に抑えることができます。

注意: コンテキスト依存セグメントにラベルを割り当てると、コンテキスト間で属性が均等化され、均等化された属性はBIにマップされます。

ラベルの管理

事前定義済ラベルがあれば、それをセグメントに割り当てることができます。または必要に応じて、割当て用のラベルを新たに作成することもできます。各ラベルを識別するコード、名前、摘要を指定します。BIオブジェクト名フィールドには、インポート時にセグメント・ラベルをマップするOracle Business Intelligenceの論理オブジェクト名を入力します。BI論理オブジェクトを指定すると、フレックスフィールドをOracle Business Intelligenceにインポートするときの手順を最小限に抑え、コンテキスト間でコンテキスト依存セグメントを均等化しやすくなります。

BI対応セグメントにラベルが割り当てられていない場合、または割り当てられたラベルのBIオブジェクト名がBusiness Intelligenceに存在しない場合は、Oracle Business Intelligenceへのインポート時に、セグメントを目的の論理オブジェクトに手動でマップする必要があります。

さらに、ラベルが付けられていないコンテキスト依存セグメントは、コンテキスト値の間で均等化できません。平坦化されたコンポーネントには、各コンテキスト内のラベルが付けられていない各コンテキスト依存セグメントの個別属性が含まれます。

Oracle Business Intelligenceリポジトリへのインポート

ビジネス・インテリジェンス対応フレックスフィールドをデプロイしたら、フレックスフィールドの変更をOracle Business Intelligenceリポジトリにインポートして、新しく平坦化されたビジネス・コンポーネントをビジネス・インテリジェンスで使用できるようにし、それからフレックスフィールド・オブジェクトの変更を伝播します。メタデータをOracle Business Intelligenceリポジトリにインポートする場合は、FUSION_APPS_BI_APPIDユーザーとして実行する必要があります。

フレックスフィールドの変更を、Oracle Cloud実装のOracle Business Intelligenceリポジトリにインポートするには、トランザクション・ビジネス・インテリジェンス用のOracle Fusionデータ拡張のインポートプロセスを実行します。インポートに関する追加情報は、Oracle Transactional Business Intelligence管理者ガイドを参照してください。

注意: フレックスフィールドをOracle Business Intelligenceリポジトリにインポートするときに、各セグメントの<name>_および<name>_cの両方の属性が、他のいくつかのオプション属性とともに表示されます。<name> 属性には値が含まれています。<name>_c属性は、値の取得元である値セットのコードが含まれ、値ディメンションへのリンクに使用されます。両方の属性をインポートする必要があります。

拡張可能フレックスフィールドの管理

拡張可能フレックスフィールド: 説明

拡張可能フレックスフィールドは付加フレックスフィールドに似ていますが、いくつか機能が追加されています。

  • フレックスフィールドには、コンテキスト依存セグメントを必要なだけいくつでも追加できます。フレックスフィールドに対して事前定義されている登録済の列数により制限されることはありません。

  • エンティティとその拡張属性行の間には、1対多の関係を構成できます。

    • データの行には、複数のコンテキストを関連付けることができます。

    • データの行には、同じコンテキストが繰り返し出現してもかまいません。

  • 属性をグループに構成してコンテキストを形成し、ユーザー・インタフェースではコンテキストの属性が常にまとめて表示されるようにできます。

  • 既存の階層カテゴリを使用して、エンティティにその親に対して構成されたコンテキストを継承させることができます。コンテキストは、カテゴリ全体で再利用可能です。

  • アプリケーション開発では、表示や編集の権限をサポートするために、いくつかの拡張可能フレックスフィールドが登録されています。そのようなフレックスフィールドに対して、属性の表示や属性の値の変更ができるユーザーを管理するために、コンテキスト・レベルで表示や編集の権限を指定できます。

1エンティティ当たり複数行のコンテキストを構成する場合、セグメントは表として表示されます。

付加フレックスフィールドとは異なり、拡張可能フレックスフィールド・セグメントに対応する拡張列は、拡張表の一部であり、ベース・アプリケーション表とは別のものです。付加フレックスフィールド・コンテキストとは異なり、拡張可能フレックスフィールド・コンテキストの属性セットは一定であり、コンテキスト値ごとに異なるということはありません。

拡張可能フレックスフィールドは、アプリケーション・エンティティを表します。これにはランタイムにデータベースを拡張する機能があり、実装コンサルタントはこれを使用して、アプリケーションで表示されるデータ構成を定義できます。

拡張可能フレックスフィールドは、エンティティとその拡張属性行との間の1対多関係をサポートします。

事前定義された拡張可能フレックスフィールドのリストを取得するには、「設定および保守」作業領域を開き、「拡張可能フレックスフィールドの管理」タスクを使用します。

拡張可能フレックスフィールドを理解するためには次の側面が重要です。

  • 使用方法

  • カテゴリ

  • ページ

  • セキュリティ

  • 保護された拡張可能フレックスフィールド・データ

使用方法

付加フレックスフィールドと同様、拡張可能フレックスフィールドには複数の使用方法を定義できます。これにより、複数のアプリケーション表で同じフレックスフィールドを共有できます。

たとえば、出荷オプションのフレックスフィールドは、「サプライヤ」表と「バイヤー」表の両方で使用できます。さらに、1つのコンテキストを、フレックスフィールドの1つ、一部またはすべての使用方法と関連付けることができます。したがって、この出荷情報の例では、倉庫コンテキストを「サプライヤ」使用方法、納品場所コンテキストを「バイヤー」使用方法、出荷方法コンテキストをすべての使用方法と関連付けることができます。

使用方法には、ユーザー・アクセスに対してセキュリティを適用停止したり、表示および編集権限を強制したりするためのセキュリティ情報が含まれています。一部の製品固有の拡張可能フレックスフィールドには、セキュリティ用以外の特殊な使用方法フィールドがあります。

カテゴリ

複数の拡張可能フレックスフィールド・コンテキストを構成し、コンテンツをカテゴリにグループ化できます。すべての拡張可能フレックスフィールドには、少なくとも1つのカテゴリがあります。一部の拡張可能フレックスフィールドでは、カテゴリの階層を構成できます。階層の子カテゴリは、その親カテゴリからコンテキストを継承できます。

拡張可能フレックスフィールドのカテゴリを定義し、コンテキストの組合せと特定のカテゴリとを関連付けることができます。

たとえば、「電子機器とコンピュータ」カテゴリ階層に「家庭用娯楽機器」カテゴリを含め、さらにそのカテゴリに「オーディオ」カテゴリと「TV」カテゴリを含めることができます。「家庭用娯楽機器」製品には、電圧、寸法、入出力を指定するコンテキストが含まれる可能性があります。コンテキストは、特定の拡張可能フレックスフィールド内で再利用できます。たとえば、寸法コンテキストは、寸法情報を含める必要があるどのカテゴリにでも割り当てることができます。

ページ

拡張可能フレックスフィールドでは、コンテキストを結合してページと呼ばれるグループにできます。ページにより、コンテキストを結び付けて、それらをアプリケーション・ユーザー・インタフェースで常にまとめて表示できます。

各アプリケーション・ページは、1つの拡張可能フレックスフィールド・カテゴリに対応し、関連付けられた各コンテキストのページ内に個別の領域を持ちます。

セキュリティ

フレックスフィールドを構成時するときに、コンテキストの使用方法の表示権限と編集権限に対してアクションを選択することで、使用方法レベルでのコンテキストの権限を設定します。

エンド・ユーザーが検索を実行するときに、ユーザー・インタフェースにはユーザーが表示権限を持つコンテキストの属性値のみが表示されます。表示権限に関係なく、ユーザーはすべてのコンテキストに対してすべての属性を使用して検索を実行できます。

エンド・ユーザーがWebサービス経由でコンテキストにアクセスし、権限を持たないアクションを実行すると、例外がスローされます。

すべての拡張可能フレックスフィールドには、基本データ・セキュリティ・リソースがあります。拡張可能フレックスフィールドの一部のデータ・セキュリティ・リソースには、アクセス権限の指定に使用できるアクションが事前構成されています。アクションが事前構成されていない場合、セキュリティ管理者は、拡張可能フレックスフィールド属性に対するアクセス・コントロールをサポートするアクションとポリシーを作成できます。

一部の拡張可能フレックスフィールドには翻訳可能なオプションがあり、これらのフレックスフィールドには翻訳データ・セキュリティ・リソースもあります。

保護された拡張可能フレックスフィールド・データ

アプリケーション開発者は、拡張可能フレックスフィールド内の一部のデータ構成に保護のマークを付け、それらが編集不可であることを示すことができます。

拡張可能フレックスフィールドが部分的に保護されている場合、フレックスフィールドの構成の保護されている部分は編集できません。たとえば、次のようになります。

  • 拡張可能フレックスフィールド・ページが保護されている場合、次のものは編集できません。

    • コンテキスト詳細

    • コンテキスト・セグメント

    • コンテキスト使用方法

  • 拡張可能フレックスフィールド・ページが保護されている場合、次は実行できません。

    • ページの詳細の編集およびページの削除

    • ページに関連付けられているコンテキストの編集

注意:

  • 保護されたコンテキストへのページ参照には、制限はありません。作成するカスタム・ページには、保護されているかどうかを問わず、任意のコンテキストを含めることができます。

  • 保護されたコンテキストへのカテゴリ参照には、制限があります。コンテキストが保護されている場合、カテゴリへの追加およびカテゴリからの削除はできません。

拡張可能フレックスフィールドの計画: 考慮事項

フレックスフィールドを特定したら、その構成を事前に計画します。構成の影響を受ける、デプロイメント内のUIページや他のアーティファクトのリストをまとめます。フレックスフィールドの表示と構成に必要なロールがプロビジョニングされていることを確認します。フレックスフィールドが表示されているランタイム・ページが表示されているときに、「管理」メニューのフレックスフィールドの強調表示オプションを使用してフレックスフィールドを表示します。テストおよび本番ユーザーに対してフレックスフィールドをデプロイする方法を計画します。フレックスフィールドの管理に使用できるツールやタスクを確認します。これにはフレックスフィールド・セグメントの追加および編集用の、「フレックスフィールドの定義」タスク・リスト、サンドボックスの管理およびフレックスフィールドの強調表示などが含まれます。

拡張可能フレックスフィールドの計画には、次のタスクが関係します。

  1. 次の項目を識別します。

    • カテゴリの階層構成

    • 既存のコンテキスト値

    • カスタム属性、関連する拡張可能フレックスフィールド・セグメント、セグメント・プロパティおよび構成

  2. 次の項目を計画します。

    • 検証ルール

    • 初期値

    • セキュリティ

    • Oracle Business Intelligenceオブジェクトへの属性マッピング。

カテゴリ階層構成

既存のカテゴリ階層構成は、拡張可能フレックスフィールドにエンティティのカスタム属性として追加するセグメントを計画するためのフレームワークになります。一部のアプリケーションは、拡張可能フレックスフィールドのカテゴリ階層を作成および管理するためのユーザー・インタフェースを備えています。

コンテキストおよび既存のコンテキスト値

関連するカスタム属性をグループ化できる場合は、属性をセグメントのコンテキストとして追加することを計画し、その属性の表示順序を計画します。一部の拡張可能フレックスフィールドには、事前構成されたコンテキスト値があります。フレックスフィールド・セグメントを含むユーザー・インタフェース・ページまたはページに表示されるリージョン・ヘッダーによって、既存のコンテキストが識別されます。「拡張可能フレックスフィールドの管理」タスクを使用して、編集するフレックスフィールドを検索して開き、構成されたコンテキスト値のリストを表示します。

事前構成されたコンテキスト値の使用に関するガイダンスは、製品固有の情報を参照してください。

セグメントおよびセグメント・プロパティの計画

拡張可能フレックスフィールド・セグメントとして追加するすべてのカスタム属性をリストします。各セグメントについて、プロパティ(索引付きプロパティを含む)を定義します。

検証ルールの計画

各セグメントの検証ルールを定義して、それらのルールの値セットが存在しているかを確認します。存在していない場合は、作成する必要があります。値セットを作成する必要がある場合は、フレックスフィールドの構成前、またはセグメントの作成時か編集時のいずれかに値セットを作成できます。

セグメントの検証ルールを決定するときは、次の質問を考慮します。

  • データ型は何か(文字、日付、日時または数字)。

  • セグメントにはデータ型および最大長以外の検証が必要か。

  • 文字タイプの値は数字に制限する必要があるか、または英字を許可するか。

  • 英字を自動的に大文字に変更する必要があるか。

  • 数値はゼロ埋込みをする必要があるか。

  • 数値の基数セパレータに続けることができる桁数はいくつか。基本的な十進数システムでは、基数セパレータは小数点です。

  • 値は範囲内に収まる必要があるか。

  • 値は有効な値のリストから選択する必要があるか。必要がある場合、次の質問を考慮します。

    • 有効な値のリストを取得するために既存のアプリケーション表を使用できますか。またはカスタム・リストを作成する必要がありますか。

    • 既存の表を使用している場合、WHERE句を使用して値のリストを制限する必要がありますか。

    • 有効な値のリストは、別のフレックスフィールド・セグメントの値に依存していますか。

    • 有効な値のリストは、別のフレックスフィールド・セグメントの値のリストのサブセットですか。

初期値の計画

すべてのセグメントに対して、カスタム属性の初期値に使用する定数値またはSQL文があればそれらをリストします。

セキュリティの計画

コンテキスト属性への表示アクセス権と編集アクセス権についてどのような権限を設定するかを決定します(すべてのユーザーには表示アクセス権を付与するが、編集アクセス権はマネージャにのみ付与するなど)。

セキュリティ制限を複数のコンテキストに適用する場合は、汎用アクションを作成できます。最低でも、基本データ・セキュリティ・リソースに対する汎用アクションを作成します。フレックスフィールドに翻訳可能オプションがあり、翻訳可能コンテキストを使用することを予定している場合は、翻訳データ・セキュリティ・リソースに対する汎用アクションも作成します。たとえば、品目」フレックスフィールドは翻訳可能オプションをサポートしており、基本データ・セキュリティ・リソースITEM_EFF_Bに加えてデータ・セキュリティ・リソースITEM_EFF_VLがあります。両方のデータ・セキュリティ・リソースに対してアクションを作成します(ITEM_EFF_BにはEDIT_NONTRANS_ATTRS、ITEM_EFF_VLにはEDIT_TRANS_ATTRSなど)。

セキュリティ制限がより詳細な場合(たとえば、各コンテキストを異なる権限で保護する必要がある場合)は、より詳細なアクションを作成できます。

Oracle Business Intelligenceオブジェクトにマップするセグメントの計画

拡張可能フレックスフィールドがOracle Business Intelligenceに対して有効になっている場合、属性をOracle Business Intelligence Applicationsで使用可能にできます。

拡張可能フレックスフィールドの管理: 考慮事項

拡張可能フレックスフィールドの構成には、アプリケーション・データベースに登録された使用可能なフレックスフィールドの管理が含まれます。

次の手順では、拡張可能フレックスフィールドの構成方法について説明します。

  1. コンテキストを構成するには、各コンテキスト・セグメント、および各コンテキスト・セグメントに対するコンテキスト依存セグメントを作成し、各セグメントに次を指定します。

    1. 識別情報

    2. 列割当て

    3. 初期デフォルト値

    4. 表示プロパティ

  2. ユーザーがアクセス権を持つアクションを選択して、コンテキスト使用方法と使用方法セキュリティを構成します。

    • 表示

    • 編集

    • なし(特別な権限を適用する必要がない場合)。

  3. カテゴリとカテゴリ詳細を構成します。

  4. コンテキストをカテゴリに関連付けます。

  5. カテゴリの論理ページを作成します。

拡張可能フレックスフィールドの管理を理解するためには次の側面が重要です。

  • コンテキストとページ

  • カテゴリ

  • 初期値

  • 強調表示された拡張可能フレックスフィールドへのセグメントの追加

  • 索引付きセグメント

  • セキュリティ

  • デプロイメント

コンテキストとページ

各コンテキストは、コンテキスト依存セグメントを含むリージョンとしてエンド・ユーザーに表示されます。リージョンとその属性の使用方法をエンド・ユーザーに説明した手順を表示する、手順ヘルプ・テキストを指定できます。手順ヘルプ・テキストは、コンテキスト・リージョンの先頭に表示されます。コンテキストは、単一行または複数行として定義できます。単一行のコンテキストは、付加フレックスフィールド・コンテキストと同じです。単一行のコンテキストには、1セットのコンテキスト依存セグメントのみが含まれます。複数行のコンテキストを使用すると、複数の値セットを同じオブジェクト・インスタンスに関連付けることができます。

たとえば、BOOK表の場合、章のセグメントおよびページ数のセグメントを含む「章」という名前の、複数行のコンテキストを作成できます。次に、複数の章をBOOK表内の各ブックに関連付けることができます。

複数行を保存するコンテキストでは、各行で一意キーからの値を持つことにより、各行を一意に識別できます。

フレックスフィールドにカテゴリ階層がある場合は、その階層を利用して、類似するエンティティ(製品カタログ内の類似する品目など)にコンテキストを再利用できます。

コンテキストを翻訳可能に設定すると、エンド・ユーザーが入力する自由形式テキストがユーザーのロケールの言語で保存され、そのテキストの別の翻訳を他の言語で保存できます。翻訳済コンテキスト内のセグメントでは、自由形式のユーザー入力テキストを保存するためにフォーマット限定値セットを使用する必要があります。

コンテキスト・セキュリティを設定して、エンド・ユーザーにコンテキストへの表示アクセス権または編集アクセス権を付与します。表示アクセス権があるユーザーに対してのみ、コンテキストのタスク・フローとリージョンがユーザー・インタフェースに表示されます。編集アクセス権があれば、エンド・ユーザーはコンテキストの属性値を編集できます。使用方法に対してアクションが指定されていない場合、コンテキストの構成による特別な権限は適用されません。

ユーザー・インタフェースでコンテキストをグループ化するように論理ページを定義します。特定のカテゴリに対して、1つ以上の論理ページを作成できます。カテゴリの1つ以上の関連コンテキストを、カテゴリの各論理ページに追加できます。

次を指定できます。

  • 各ページ内のコンテキストの順序。

  • 論理ページが表示される順序。

  • ページの使用方法をエンド・ユーザーに説明する手順を表示するための、手順ヘルプ・テキスト。手順ヘルプ・テキストは、論理ページの先頭に、すべてのコンテキスト・リージョンよりも前に表示されます。

カテゴリ

カテゴリとは、同類とみなすことができる関連データ項目をグループ化したものです。コンテキストの任意の組合せを特定のカテゴリと関連付けることができます。30を超えるカテゴリがある拡張可能フレックスフィールドは、バックグラウンド・プロセスとしてデプロイする必要があります。

カテゴリ階層は、一連のカテゴリを論理的に編成します。たとえば、「電子機器とコンピュータ」カテゴリ階層には、「コンピュータ」カテゴリや「家庭用娯楽機器」カテゴリが含まれ、さらにこのカテゴリには「オーディオ」カテゴリと「TV」カテゴリなどが含まれる可能性があります。

カテゴリは、既存のカテゴリの子または兄弟にすることができます。階層は、ゼロ以上の兄弟カテゴリおよびゼロ以上の子カテゴリを任意に組み合せて、必要に応じて単純なものにすることも複雑なものにすることもできます。カテゴリが定義されていない場合、データ項目は事前定義された単一のデフォルト・カテゴリにグループ化されます。

各カテゴリは、そのカテゴリのデータ項目に関する関連情報を格納する関連コンテキストがあります。たとえば、「家庭用娯楽機器」製品には、「電圧」、「寸法」、「入出力」を指定するコンテキストが含まれます。コンテキストは、特定の拡張可能フレックスフィールド内で再利用できます。「寸法」コンテキストは、寸法の情報を含める必要があるすべてのカテゴリに割り当てることができます。

階層に子カテゴリが含まれる場合、各子カテゴリはその親カテゴリからコンテキストを継承します。たとえば、「家庭用娯楽機器」カテゴリは、「電子機器とコンピュータ」カテゴリから「電圧」と「寸法」を継承します。

各拡張可能フレックスフィールドは、特定のカテゴリ階層に関連付けられます。カテゴリ階層は、拡張可能フレックスフィールドとそのコンテキストを定義するフレームワークと見なすことができます。カテゴリ階層により、各カテゴリに有効なコンテキストが指定されます。

拡張可能フレックスフィールドには、特定のカテゴリをサポートするように定義した複数のコンテキストを含めることができます。これらのコンテキストは様々な目的に適合させることができますが、特定のカテゴリ内では、一部のコンテキストが相互に関連している、または相互に依存していると見なされる場合があります。これらのコンテキストは論理ページと呼ばれるグループに結合できます。さらに、このページが表示される順序を決定できます。これによって、コンテキストを、アプリケーション・ユーザー・インタフェースに特定の順序で常に一緒に表示されるように結び付けることができます。

たとえば、「家庭用娯楽機器」カテゴリには、「電圧」、「入出力」コンテキストを含む「電子機器とコンピュータ」ページと、「寸法」および「フォーム・ファクタ」コンテキストを含む「物理仕様」ページがあります。

初期値

初期値を定義するSQL文は、1行のみかつ正しいタイプの値を返す有効な文でなければなりません。

次の2タイプのSQL文を使用できます。

  • バインディングなしのSQL文。たとえば、EMPLOYEESからMIN(SALARY)を選択します。

  • バインド変数があるSQL文。SQL文のWHERE句では、次のバインド変数を使用できます。

    • :{SEGMENT.<segment_code>}: 同じコンテキスト内のセグメントを特定します。

    • :{CONTEXT.<context_code>;SEGMENT.<segment_code>}: 異なるコンテキスト内のセグメントを特定します。コンテキストは同じカテゴリまたは先祖のカテゴリ内になければならず、複数行のコンテキストにすることはできません。

    • :{VALUESET.<value_set_code>}: 特定の値セットに割り当てられている、同じコンテキスト内で最も近い先行セグメントを特定します。

    • :{FLEXFIELD.<internal_code>}: フレックスフィールドを特定します。

バインド変数の使用の詳細は、値セットのヘルプを参照してください。

強調表示された拡張可能フレックスフィールドへのセグメントの追加

ランタイム・ページでフレックスフィールドを強調表示し、セグメントの追加アイコン・ボタンを使用してセグメントを作成する場合、セグメント・コード、名前、摘要、表列および連番が自動的に設定されます。セグメントの追加アイコン・ボタンを使用して拡張可能フレックスフィールド・セグメントを構成する場合には、既存の値セットは使用できません。値セットは、セグメントを追加すると自動的に作成されます。有効な値、その摘要およびデフォルト値を入力したり、最小値や最大値など、値セットに対するフォーマット設定制約を指定したりできます。

表示タイプに応じて、セグメントの追加アイコン・ボタンを使用して作成する値セットは、独立値セットまたはフォーマット限定値セットのいずれかになります。次の表は、選択するセグメント表示コンポーネントに応じて、どのタイプの値セットが作成されるかを示しています。

表示コンポーネント セグメントの追加を使用して作成される値セット

チェック・ボックス

独立

ドロップダウン・リスト

独立

値のリスト

独立

ラジオ・ボタン・グループ

独立

検索機能付きテキスト・フィールド

独立

テキスト・ボックス

フォーマット限定

テキスト領域

フォーマット限定

リッチ・テキスト・エディタ

フォーマット限定

日時

フォーマット限定

ヒント: コンテキスト値を追加したら、新しい値を表示するためにページをリフレッシュします。

索引付きセグメント

拡張可能フレックスフィールド・セグメントを索引付きと指定して、エンド・ユーザーが属性の検索に使用できる選択的必須属性の1つにすることができます。「拡張可能フレックスフィールドの管理」UIページでセグメントに索引を付けるよう指定した場合は、セグメントを表す列がデータベース索引に追加される必要があります。通常、データベース管理者(DBA)がデータベース索引に列を追加します。

索引付きセグメントがある拡張可能フレックスフィールドがデプロイされると、他のフレックスフィールド・アーティファクトとともに検索タスク・フローが生成され、索引付き属性が選択的必須と指定されます。デプロイ済拡張可能フレックスフィールドの検索タスク・フローで、エンド・ユーザーは検索基準に少なくとも1つの索引付き属性を指定する必要があります。これにより、パフォーマンスの問題の原因となる可能性がある、非選択的検索を防止できます。

たとえば、メモリー属性とプロセッサ属性を索引付けし、データベース内の対応する列が索引付けされるようにすると、ユーザーは検索基準としてプロセッサまたはメモリー(あるいはその両方)を入力して、コンピュータのアイテム・カタログを検索できます。検索条件として索引付けされていない属性をエンド・ユーザーが入力しても、検索は実行されません。

セキュリティ

拡張可能フレックスフィールドのベース・データのセキュリティ・リソースは、通常は「_B」という接尾辞を持つ名前が付けられています。翻訳データのセキュリティ・リソースは、翻訳表のビューであり、通常は「_VL」という接尾辞を持つ名前が付けられています。

フレックスフィールドが翻訳可能なオプションをサポートしており、翻訳データのセキュリティ・リソースを持っている場合は、適切なデータ・セキュリティ・リソースのアクションを必ず作成します。

  • 翻訳不可能なコンテキストに対してコンテキスト固有のアクションを作成する場合は、ベース・データのセキュリティ・リソースに追加します。

  • 翻訳可能なコンテキストに対してコンテキスト固有のアクションを作成する場合は、翻訳データのセキュリティ・リソースに追加します。

デプロイメント

拡張可能フレックスフィールドは、「拡張可能フレックスフィールドの管理」タスクでのみデプロイできます。拡張可能フレックスフィールドは、オフラインでバックグラウンド・プロセスとしてデプロイでき、デプロイメントの完了を待機する必要なくセッションで作業を続行できます。複数の拡張可能フレックスフィールドをキューイングして、バックグラウンド・プロセスとしてデプロイできます。フレックスフィールドは、一度に1つずつ、キューにデプロイした順序でデプロイされます。30を超えるカテゴリを持つ拡張可能フレックスフィールドは、バックグラウンド・プロセスとしてデプロイする必要があります。

バックグラウンド・デプロイメントの取消しコマンドを使用してデプロイメント・キューから拡張可能フレックスフィールドを削除できます。拡張可能フレックスフィールドがバックグラウンド・プロセスでデプロイされると、そのオフライン・ステータスにより、フレックスフィールドがバックグラウンド・デプロイメント処理中であることが示されます。バックグラウンド・デプロイメント・プロセスが完了すると、フレックスフィールドのオフライン・ステータスはクリアされ、そのデプロイメント・ステータスは更新されます。

注意: 「拡張可能フレックスフィールドの管理」タスクで新規の検索を実行すると、オフライン・ステータス列がリフレッシュされます。

Business Intelligenceに対する拡張可能フレックスフィールド・セグメントの有効化: 考慮事項

データベースにOracle Business Intelligence (BI)対応と登録されている拡張可能フレックスフィールドの各セグメント・インスタンスには、BI対応という設定があります。セグメント・インスタンスがBI対応であれば、そのセグメント・インスタンスは、Oracle Business Intelligenceで使用できます。

BI対応である拡張可能フレックスフィールドの管理を理解するためには次の側面が重要です。

  • Oracle BIでBI対応セグメントを使用するためのビジネス・コンポーネントの平坦化

  • 平坦化されたビジネス・コンポーネントの属性からOracle BIの論理オブジェクトへのマッピング

ビジネス・インテリジェンス対応のフレックスフィールドをデプロイした後、トランザクション・ビジネス・インテリジェンス用のOracle Fusionデータ拡張のインポートプロセスを使用して、フレックスフィールドの変更をOracle Business Intelligenceリポジトリにインポートします。ユーザーはビジネス・インテリジェンス・アプリケーションで新しく生成された属性を使用できます。論理オブジェクトとインポートに関する追加情報は、Oracle Transactional Business Intelligence管理者ガイドを参照してください。

平坦化

ビジネス・インテリジェンス対応拡張可能フレックスフィールドをデプロイする場合、デプロイメント・プロセスにより、ビジネス・インテリジェンスで使用するための平坦化されたビジネス・コンポーネントの追加セットが生成されます。平坦化されたビジネス・コンポーネントには、ビジネス・インテリジェンス対応セグメント・インスタンスの属性のみが含まれます。

セグメントにラベルを割り当てた場合、平坦化されたコンポーネントには、そのラベルが付けられているすべてのセグメント・インスタンスを表す単一の属性が含まれます。ラベルを割り当てなかった場合、平坦化されたコンポーネントには、各構成内の各BI対応セグメント・インスタンスに対する個別の属性が含まれます。

Oracle Business Intelligenceリポジトリへのインポート

ビジネス・インテリジェンス対応フレックスフィールドをデプロイしたら、フレックスフィールドの変更をOracle Business Intelligenceリポジトリにインポートして、新しく平坦化されたビジネス・コンポーネントをビジネス・インテリジェンスで使用できるようにし、それからフレックスフィールド・オブジェクトの変更を伝播します。メタデータをOracle Business Intelligenceリポジトリにインポートする場合は、FUSION_APPS_BI_APPIDユーザーとして実行する必要があります。フレックスフィールドの変更を、Oracle Cloud実装のOracle Business Intelligenceリポジトリにインポートするには、トランザクション・ビジネス・インテリジェンス用のOracle Fusionデータ拡張のインポートプロセスを実行します。インポートに関する追加情報は、Oracle Transactional Business Intelligence管理者ガイドを参照してください。

ヒント: フレックスフィールドをOracle Business Intelligenceリポジトリにインポートするときに、各セグメントの<name>_および<name>_cの両方の属性が、他のいくつかのオプション属性とともに表示されます。<name>_ 属性には値が含まれています。<name>_c属性は、値の取得元である値セットのコードが含まれ、値ディメンションへのリンクに使用されます。両方の属性をインポートする必要があります。

拡張可能フレックスフィールドのカテゴリの管理: 考慮事項

カテゴリは、フレックスフィールドのコンテキスト依存セグメントの数を、フレックスフィールド・セグメント用に予約されている列数を超えて増やすための手段です。

たとえば、「品目」拡張可能フレックスフィールドには、品目ごとに1つのカテゴリがあり、各カテゴリは、1つ以上のコンテキストを持つことができます。品目「ラップトップ」は「コンピュータ」カテゴリに属します。拡張可能フレックスフィールドは、付加フレックスフィールドのように列のみでなく、別々の拡張表にマップされるため、拡張可能フレックスフィールド表にある30の予約済列を使用して、各コンテキストに対して、最大30個のコンテキスト依存セグメントを定義できます。

「コンピュータ」カテゴリに「寸法」コンテキストを追加すると、30個のセグメントを使用できます。ただし、30個を超える属性を追加する必要がある場合は、コンテキストをもう1つ作成して、同じカテゴリに関連付けます。同じ「コンピュータ」カテゴリに「電子機器属性」コンテキストを追加し、さらに30個のセグメントを作成できます。さらにコンテキストを作成して、「コンピュータ」カテゴリに追加することもできます。こうすることで、ラップトップ・コンピュータ品目を必要な数の属性を使用して拡張できます。これはラップトップ・コンピュータがカテゴリにマップされており、そのカテゴリにコンテキストを追加し続けることができるためです。

セグメント用に予約された30列を持つ品目表の付加フレックスフィールドが保持できるコンテキストは、1つのみです。その1個のコンテキストのために列を構成したら、それ以上セグメントは作成できません。

事前定義済カテゴリと事前構成済カテゴリ

フレックスフィールド構造をどのように構成するかは、カテゴリをどのようにフレックスフィールドで定義するかによって変わります。1つのカテゴリを使用して拡張可能フレックスフィールドを事前構成する場合は、すべてのコンテキストとページをそのカテゴリに関連付けます。製品固有の拡張可能フレックスフィールドが複数カテゴリにより事前構成されている場合は、コンテキストとページをそれらのカテゴリに関連付けます。拡張可能フレックスフィールドに、複数のカテゴリを構成するためのユーザー・インタフェースが用意されている場合は、継承を使用して、1つのコンテキストを複数のカテゴリに関連付けます。

拡張可能フレックスフィールド用にカテゴリを作成および保守するためのアクティビティまたはタスクを提供している製品もあります。フレックスフィールド用のカテゴリを作成できるかどうかを判別するには、製品固有の情報を参照してください。

フレックスフィールドのカテゴリ階層を表示するには、フレックスフィールドの強調表示機能または「拡張可能フレックスフィールドの管理」タスクを使用し、フレックスフィールドを見つけて編集用に開きます。

カテゴリの無効化

拡張可能フレックスフィールドの構成時に、カテゴリを無効にできます。拡張可能フレックスフィールドの編集ページの「カテゴリ」表にある「使用可能」列には、どのカテゴリが有効であるかが示されます。

注意: 無効化されたカテゴリを含む拡張可能フレックスフィールドをデプロイすると、そのカテゴリとその下位カテゴリはデプロイされません。コンテキストとそのセグメントは、少なくとも1つの有効なカテゴリに属している場合にデプロイされます。

コンテキスト

類似するカスタム属性をコンテキストにグループ化します。グループは、リージョン内にまとめて表示されます。リージョンのヘッダーがコンテキスト値です。

フレックスフィールドにカテゴリ階層が存在する場合、その階層を利用して、製品カタログの類似品目など、似たようなエンティティに対してコンテキストを再利用できます。

次の図は、コンテキストを再利用するためにカテゴリ階層機能を使用した「Item Extended Attributes」フレックスフィールドを示しています。このフレックスフィールドの「電子機器とコンピュータ」カテゴリには、「コンプライアンスと証明書」、「電圧」、「原材料」のコンテキストが含まれます。「TVとビデオ」サブカテゴリおよび「コンピュータ製品」サブカテゴリでは、独自のコンテキストに加えて、「電子機器とコンピュータ」のコンテキストを継承します。「原材料」コンテキストは、「電子機器とコンピュータ」製品カテゴリと「資材、自動車、産業」製品カテゴリの両方に属しています。

図は、コンテキストが複数のカテゴリでどのように再利用されるかを示しています

次の表は、拡張可能フレックスフィールドのカテゴリ階層の例を示しています。すべての電子機器とコンピュータ品目の電圧情報を格納するには、「電圧」コンテキストを「電子機器とコンピュータ」カテゴリに関連付けます。これにより、「TVとビデオ」サブカテゴリと「コンピュータ」サブカテゴリの両方が、親カテゴリ「電子機器とコンピュータ」から「電圧」コンテキストを継承します。

表示名 コード 説明

電子機器とコンピュータ

PROD_ELECTRONICS

電子機器とコンピュータ

  • TVとビデオ

PROD_TV_VIDEO

テレビとビデオ

  • コンピュータ

PROD_COMPUTERS

コンピュータ

オフィス製品と消耗品

PROD_OFFICE_PRODUCTS_SUPPLIES

オフィス製品と消耗品

工具、自動車、産業

PROD_TOOLS_AUTO_INDUSTRIAL

工具、自動車、産業

スポーツとアウトドア

PROD_SPORTS_OUTDOORS

スポーツとアウトドア

「Item Extended Attributes」フレックスフィールドの構成: 例

「Item Extended Attributes」フレックスフィールドは、「Item」ビジネス・オブジェクトの拡張に必要なセグメントを提供します。「拡張可能フレックスフィールドの管理」タスクで、「Electronics and Computers」カテゴリの品目のユーザー・インタフェースに「Technical Specifications」論理ページが含まれるように、製品のビジネス・オブジェクトを構成します。

この例では、このフレックスフィールドの構成により、カスタム属性は次のコンテキストにグループ化されます。

  • Materials and Substances

  • Compliance and Certification

  • Voltage

シナリオ

次のリストは、「Item Extended Attributes」フレックスフィールドのカスタム・コンピュータ属性のサンプル・プランを示しています。この例では、「Electronics Information」ページは、親カテゴリ「Electronics and Computers」から継承されます。

  • ページ: Electronics Information

    • コンテキスト: Compliance and Certification、単一行

      • ISO 14001(国際標準化機構による環境マネージメント・システムの規定)

      • ENERGY STAR(エネルギ効率化に向けたガイドライン)

      • ROHS(電子・電気機器における特定有害物質の使用制限)

    • コンテキスト: Voltage、単一行

      • Minimum voltage

      • Maximum voltage

      • Current type

    • コンテキスト: Materials and Substances、複数行

      • Material

      • Contain recyclate

      • Percent unit mass

  • ページ: Computer Information

    • コンテキスト: Processor Specifications、単一行

      • Manufacturer

      • CPU type

      • Processor interface

      • Processor class

      • Processor speed

      • Cores

次の表では、このシナリオの重要な決定事項をまとめています。

検討すべき決定項目 この例

どの拡張可能フレックスフィールドがカテゴリ階層の構成に使用できるか

「Item Extended Attributes」フレックスフィールド

技術仕様の収集

電子機器とコンピュータの製品在庫ページには、技術仕様ページが必要です。家具の製品在庫ページには、家具の仕様ページと組立て方法のページが必要です。電子機器とコンピュータ・カテゴリと家具カテゴリの両方にある品目は、原材料を指定するための属性を共有しています。

次の図は、「Electronics and Computers」カテゴリのユーザー・インタフェースにある「Technical Specifications」論理ページを示しています。「Recovery and Recycling」、「Compliance and Certification」、「Operating Conditions」および「Materials and Substances」のコンテキストでの属性が含まれます。「Materials and Substances」コンテキストは複数行で構成されています。ユーザーは1つの製品の製造に必要なすべての原材料を選択できます。

図では、「Electronics and Computers」カテゴリのユーザー・インタフェースにある「Technical Specifications」論理ページと、「Recovery and Recycling」、「Compliance and Certification」、「Operating Conditions」および「Materials and Substances」のコンテキストでの属性を示しています

分析

ユーザー・インタフェースでのコンテキストの表示方法を決定するには、論理ページを使用します。1つの製品を作成するために必要なすべての原材料を格納するために、コンテキストを使用します。エンティティごとに複数の行を格納するようにコンテキストを構成できます。「Materials and Substances」コンテキストのように、複数の行が1つの表に表示されます。

「Technical Specifications」論理ページには、4つのコンテキストの属性が含まれています。

  • Recovery and Recycling

  • Compliance and Certification

  • Operating Conditions

  • Materials and Substances

次の図は、「Furniture」カテゴリが、「Furniture Specifications」論理ページと「Assembly Instructions」論理ページを含むように構成されている例です。2つのカテゴリ(「Electronics and Computers」および「Furniture」)が、「Materials and Substances」コンテキストを共有しています。

図は、「Furniture Specifications」論理ページと「Assembly Instructions」論理ページを含むように構成された「Furniture」カテゴリがを示すチャートです。2つのカテゴリ(「Electronics and Computers」および「Furniture」)が、「Materials and Substances」コンテキストを共有しています。

「品目」フレックスフィールドのセキュリティの構成

次の表は、「品目」フレックスフィールドのデータ・セキュリティ・ポリシーの例を示しています。

データ・セキュリティ・リソース ポリシー ロール アクション 条件

ITEM_EFF_B

A

VOLTAGE_SPEC

edit_nontrans_voltage_ctx

すべての値

ITEM_EFF_VL

B

COMPLIANCE_SPEC

edit_trans_compliance_ctx

すべての値

ITEM_EFF_VL

C

COMPUTER_SPEC

edit_trans_attrs

ComputerCategoryFilter

ITEM_EFF_VL

D

TELEVISION_SPEC

edit_trans_attrs

TVCategoryFilter

次の表は、3つのフレックスフィールド・コンテキストに対する権限を示しています。

コンテキスト 編集権限 表示権限

Voltage

edit_nontrans_voltage_ctx

NONE

Compliance and Certification

edit_trans_compliance_ctx

NONE

Materials and Substances

edit_trans_attrs

NONE

この例では、誰でもコンテキストの属性を表示できますが、編集権限は次のように制限されています。

  • Voltage: 電圧の専門担当者のみがこの値を編集できます。

  • Compliance and Certification: コンプライアンスの専門担当者のみがこの値を編集できます。

  • Materials and Substances: コンピュータ・カテゴリの品目の属性については、コンピュータの専門担当者のみが編集できます。「TV」カテゴリの品目の属性については、テレビの専門担当者のみが編集できます。

要約すると、この例全体では、「Materials and Substances」コンテキストは、カテゴリ別のアクセス制限を適用する条件により汎用のアクションで保護されています。「Voltage」と「Compliance and Certification」は、各コンテキスト固有のアクションで保護されています。

拡張可能フレックスフィールドの管理に関するFAQ

拡張可能フレックスフィールド・コンテキストがランタイムに表示されないのはなぜですか。

デプロイ済の拡張可能フレックスフィールド・コンテキストがユーザー・インタフェースに表示されない場合、そのコンテキストが、拡張可能フレックスフィールドで定義されたカテゴリのページの1つに関連付けられていることを確認してください。

キー・フレックスフィールドの管理

キー・フレックスフィールド: 説明

キー・フレックスフィールドは、部品番号、ジョブ・コード、勘定科目コードなどのキーを取得する方法を提供します。キー・フレックスフィールドは1つ以上のセグメントで構成され、各セグメントに意味を持たせることができます。

たとえば、部品番号10-PEN-BLA-450は、部門番号10(事務用品)が販売する、サプライヤ番号450から仕入れた黒いペンに対応しています。アプリケーションはこの部品について、内部的に一意の番号として13452を使用していますが、ユーザーには常に部品番号10-PEN-BLA-450が表示されます。

キー・フレックスフィールドを理解するためには次の側面が重要です。

  • アーキテクチャ

  • セグメントとセグメント・ラベル

  • 構成

  • セグメントと構成インスタンス

  • 組合せ

  • 動的組合せ作成

  • セキュリティ

キー・フレックスフィールドはオプションではありません。アプリケーションを確実に正しく動作させるには、キー・フレックスフィールドを構成する必要があります。キー・フレックスフィールド定義の構成と保守には、「キー・フレックスフィールドの管理」タスクを使用します。事前定義されたキー・フレックスフィールドのリストを取得するには、「設定および保守」作業領域を開き、「キー・フレックスフィールドの管理」タスクを使用します。特定のキー・フレックスフィールドの詳細は、関連するビジネス・コンポーネントが実装されている製品のヘルプを参照してください。

アーキテクチャ

フレックスフィールド・メタデータは、フレックスフィールド・メタデータ表に格納されます。キー・フレックスフィールドを構成する場合は、次のような要素を対象としたキー・フレックスフィールドのメタデータを定義します。

  • 構成内のセグメント

  • フレックスフィールド内の構成

  • 各セグメントの値セット

フレックスフィールド・メタデータに基づいて、ランタイムに実際の部品番号がセグメント値の組合せとして取得され、組合せ表に格納されます。組合せ表には、フレックスフィールドのすべてのセグメント列と、一意のID列、および構成インスタンス番号列が含まれます。構成インスタンス番号列により、セグメント列の複数の配列が区別されます。たとえば、複数のセグメントで構成される部品番号をキー・フレックスフィールドで表すことができます。部品番号キー・フレックスフィールドには、対応する組合せ表があります。この表で、フレックスフィールドは、コードのセグメントごとに列が割り当てられた完全なコードのリストを、コードに対応する一意のIDと構成インスタンス番号とともに保管します。ユーザーが部品カタログで新しい部品番号を定義したり、既存の部品番号を保守したりするときには、この組合せ表にある行を直接保守します。

外部キー表に含まれるビジネス・エンティティは、組合せ表に含まれるそれとは異なります。たとえば、外部キー表のビジネス・エンティティは、注文用の部品に対する外部キー参照を含む注文書明細や請求書明細です。キー・フレックスフィールドで表される特定のエンティティを参照できる外部キー表の数に制限はありません。

セグメントとセグメント・ラベル

キー・フレックスフィールドにはセグメントが含まれており、セグメント・ラベルによりキー・フレックスフィールド内の特定のセグメントが識別されます。セグメント・ラベルは、製品開発時に定義されて使用できるようになります。セグメントには次の詳細が含まれます。

  • プロンプト

  • 短いプロンプト

  • 表示幅

  • キー・フレックスフィールド構成内でのセグメントの順位

  • 範囲のタイプ

  • セグメントにより格納される属性の列名

  • デフォルトの値セット

  • セグメントのラベル

アプリケーションは、セキュリティや計算など、一定の目的で特定のセグメントを識別します。セグメント名やセグメントの順序では、セグメントを確実に識別できません。キー・フレックスフィールド・セグメントは、すべてのプロンプトで任意の順序で表示されるように構成できるためです。セグメント・ラベルは、セグメントのタグとして機能します。

たとえば、会計フレックスフィールドのどのセグメントに残高情報が入っていて、どのセグメントに通常の勘定科目情報が入っているかを示す必要があります。セグメント・ラベルにより、勘定科目情報に使用されているセグメントを判別できます。会計フレックスフィールドを定義する場合、どのセグメント・ラベルがどのセグメントに適用されるかを指定する必要があります。一部のラベルは一意でなければならず、それぞれの構成内で複数のセグメントに適用することはできません。その他のラベルは必須であり、それぞれの構成で少なくとも1つのセグメントに適用される必要があります。

セグメント・ラベルは、ユーザーがセグメントを検索する際に役立ちます。たとえば「コスト・センター」ラベルでは、キー・フレックスフィールド全体でコスト・センターの値を保存しているすべてのセグメントを検索できます。

構成

キー・フレックスフィールド構成の定義には、セグメントの数と順序が含まれます。

一部のアプリケーションでは、同じフレックスフィールドであっても、ユーザーごとにセグメント構成の表示方法を変更する場合があります。複数の構成をサポートするように登録すると、1つのキー・フレックスフィールドが複数の構成を持つことができます。

フレックスフィールドは、ユーザーが入力した別のフィールドの値や、ユーザーのロールなど、アプリケーション・データのデータ条件に基づき、それぞれのユーザーに合わせて表示するフィールドを変更できます。たとえば、カスタマ・サービスへの問合せで使用される正しい形式の住所は、ロケールによって異なります。「住所」キー・フレックスフィールドは、ユーザーのロールや入力した値など、アプリケーション・データの場所条件に基づいて、それぞれのユーザーに合わせて表示するセグメントやプロンプトを変更できます。

各構成は1つ以上のセグメントを持つことができます。したがって、セグメントは構成の子と言えます。コスト・センターなど、特定のセグメントを2つの異なる構成に格納する必要がある場合は、それぞれの構成で個別にセグメントを定義する必要があります。各構成は、1つ以上の構成インスタンスを持つことができます。構成の各インスタンスでは、同じ数と順序のセグメントが共有されますが、セグメントの検証に使用される値または値セットは異なります。

構成インスタンスとセグメント・インスタンス

1つのキー・フレックスフィールド構成の複数の構成を定義できます。これらの構成インスタンスのセグメント構成と順序は同じです。大きな違いは各セグメントの検証方法です。構成インスタンスは、キー・フレックスフィールドごと、およびキー・フレックスフィールド構成インスタンスごとに定義します。

キー・フレックスフィールドの構成インスタンスのセグメントは、セグメント・インスタンスです。セグメント・インスタンスは、特定の値セットが割り当てられているセグメントです。キー・フレックスフィールドがツリー構成を使用して登録されている場合、セグメント・インスタンスに対してツリー・コードを指定できます。

組合せ

組合せは、完全なコード、またはコードを構成するセグメント値の組合せであり、オブジェクトを一意に識別します。

たとえば、PAD-YEL-11x14や01-COM-876-7BG-LTNのような各部品番号は、1つの組合せです。これらの組合せでは、ハイフンがセグメント・セパレータです。10個の部品がある場合は、10個の組合せが定義されます。有効な組合せとは、現在アクティブであるため使用可能な既存の組合せまたは新しい組合せであり、相互検証およびセキュリティのルールに違反していないものです。組合せはのセグメントは、その組合せで使用されるフレックスフィールド構成に応じて異なります。どの組合せも、特定のフレックスフィールド構成1つのみに関連付けられます。

多くのアプリケーションは、エンティティの名前またはキー・フレックスフィールド自体を使用して、キー・フレックスフィールドの組合せを参照します。たとえば、「資産」は「資産」キー・フレックスフィールドを使用し、その組合せの1つを「資産」キーまたは「資産」キー・フレックスフィールドとして参照します。別の例として、Oracle Fusion General Ledgerは、「会計」フレックスフィールドの組合せを、「勘定科目」または「GL勘定科目」として参照します。

各キー・フレックスフィールドには、組合せ表と呼ばれる1つの対応表があります。この表に、フレックスフィールドは、コードのセグメントごとに列が割り当てられた完全なコードのリストを、そのコードの対応する一意のID番号(勘定科目組合せID)とともに格納します。アプリケーションのその他の表には、そのコードの一意のIDのみを格納する列があります。たとえば、PAD-YEL-11x14のような部品番号コードがあるとします。「部品」組合せ表には、このコードがID「57494」とともに格納されています。アプリケーションで部品の注文を受ける場合、部品の注文を格納する「注文」表がある可能性があります。この「注文」表には、完全なコードPAD-YEL-11x14に対する複数の列ではなく、部品ID「57494」を格納する1つの列を含めます。通常、キー・フレックスフィールドは1つの組合せページで保守されます。このページでは、キー・フレックスフィールドが、アプリケーション内のエンティティを表しています。部品番号などの個々の組合せは、組合せページで保守します。

動的組合せ作成

動的組合せ作成では、組合せページ以外のページから、新しい有効な組合せが組合せ表に挿入されます。次の表に、動的組合せ作成を有効にできるレベルをリストします。

動的組合せ作成のレベル 制御担当者:

フレックスフィールド

アプリケーション開発者

キー・フレックスフィールドの使用方法ごとまたは参照ごと

アプリケーション開発者

構成インスタンス

管理者および実装コンサルタント

その他

管理者および実装コンサルタント

キー・フレックスフィールド、またはキー・フレックスフィールドの特定の使用方法や参照で動的組合せ作成が許可されていない場合、構成インスタンスごとに動的組合せ作成を有効にするかどうかを制御できます。有効にした場合、ユーザーは外部キー・ページからフレックスフィールド・ウィンドウを使用して、セグメント値の新しい組合せを入力できます。たとえば、トランザクションを入力するときに、GLユーザーは、まだ存在していない勘定科目に対して新しい費用勘定科目の組合せを入力できます。アプリケーションは、内部的に組合せ表に新しい組合せを挿入して、新しい勘定科目を作成します。新しい組合せが既存の相互検証ルールを満たすとすれば、フレックスフィールドは組合せ表が外部キー・ページの基礎表でないとしても、その新しい組合せを組合せ表に挿入します。

キー・フレックスフィールドの計画: 考慮事項

キー・フレックスフィールドを計画する際の最初のステップは、アプリケーションで必要とされるキー・フレックスフィールドを判別することです。計画には次の点を含める必要があります。

  • キー・フレックスフィールドの目的

  • 使用可能なセグメント列の数と長さ

  • キー・フレックスフィールドで複数の構成を許可するかどうか

  • 複数の構成を定義する必要があるかどうか

  • 各構成におけるセグメントの数、順序および長さ

始める前に

フレックスフィールドを特定したら、その構成を事前に計画します。構成の影響を受ける、デプロイメント内のUIページや他のアーティファクトのリストをまとめます。フレックスフィールドの表示と構成に必要なロールがプロビジョニングされていることを確認します。「管理」メニューのフレックスフィールドの強調表示コマンドを使用して、フレックスフィールドが表示されるランタイム・ページを表示します。テストおよび本番ユーザーに対してフレックスフィールドをデプロイする方法を計画します。「フレックスフィールドの定義」タスク・リストやサンドボックスの管理など、フレックスフィールドの管理に使用できるツールやタスクを確認します。

値セットの使用を計画している場合は、値セットを作成してから、キー・フレックスフィールドを構成します。キー・フレックスフィールド・セグメントを追加および構成するときに、キー・フレックスフィールドの値セットを作成することはできません。

フレックスフィールド関連タスクへのアクセス

フレックスフィールドと値セットを構成するには、「フレックスフィールドの定義」タスク・リスト、または製品固有フレックスフィールドの管理タスクへのアクセス権が必要です。詳細は、セキュリティ管理者に問い合せてください。「固定資産キー・フレックスフィールドの管理」などの製品固有のフレックスフィールド・タスクについては、製品固有の資料を参照してください。

制限

値セットの使用を計画している場合は、値セットを作成してから、フレックスフィールドを構成します。キー・フレックスフィールドの構成は、企業のニーズに合わせて拡張できるように計画します。たとえば、古いコスト・センターを使用不可にして、新しいコスト・センターの使用頻度を増やす予定であれば、使用可能な値を増やすことができるように、コスト・センター値セットの最大サイズを大きめに計画します。1000個の使用可能な値がある3文字の値セットでは、100個の使用可能な値がある2文字の値セットに比べて、変更のための余地が大きくなります。

構成する予定のフレックスフィールドのコード名を書き留めて、「フレックスフィールドの定義」タスク・リストまたは製品固有のキー・フレックスフィールドの管理タスクですぐに検索できるようにしておきます。場合によっては、ページ上でのフレックスフィールドの表示方法をカスタマイズできます。製品固有のキー・フレックスフィールドの使用に関する制限事項を確認するには、製品固有のドキュメントを参照してください。

レポート作成

口座番号やプロジェクトや地域など、特定の基準やサブエンティティに基づくデータについてレポートを作成するには、そのサブエンティティを別のサブエンティティと組み合せるのではなく、それを単独のセグメントにすることを検討します。より小さな情報単位で、分類およびレポート作成ができます。

キー・フレックスフィールドの管理: 考慮事項

キー・フレックスフィールドを構成するときは、キー・フレックスフィールド、セキュリティ、生成結果のランタイム・ページについての計画を検討します。

計画

構成は慎重に計画し、将来のニーズに対応できるようにします。フレックスフィールド・データを取得したら、セグメントの番号、順序番、最大長は変更しないでください。

構成デリミタ

デリミタは、ユーザーに表示されるセグメントを区切ります。構成のデリミタ値には、キー・フレックスフィールドが連結されたセグメントの文字列としてUIに表示されるときに、セグメント値を視覚的に区切るために使用する文字を指定します。

キー・フレックスフィールドのデリミタ値は、フレックスフィールドのデータと競合しないように、慎重に識別してください。たとえば、貨幣値や数値などのピリオドが含まれることが多いデータを扱う場合は、セグメント・セパレータとしてピリオドを使用しないでください。セグメント値や説明に頻繁に出現することが予期される文字は、デリミタの適正な選択肢にはなりません。デリミタなどのキー・フレックスフィールドの構成を変更すると、その構成を使用する以前に格納されたキー・フレックスフィールドも変更の影響を受けます。

セキュリティ

Oracle Fusionデータ・セキュリティにより、値セットのセキュリティが実施されます。

キー・フレックスフィールド内で、値セットのセキュリティは、セグメントの値リストでの個々のセグメント値の選択に適用されます。組合せ表からキー・フレックスフィールドのセグメント値を選択する場合、データ・セキュリティにより、ユーザーがアクセス権を持つセグメント値がある組合せのみ表示することが許可されます。値セットのセキュリティ・ルールを外部キー表にまで伝播するかどうかは、アプリケーション開発者が制御します。デフォルトでは、伝播されます。

ランタイム・ページ

フレックスフィールドのレンダリングに使用するユーザー・インタフェース(UI)ページは、アプリケーション開発で決定されます。キー・フレックスフィールドUIページには、次のタイプがあります。

  • 組合せページ。ここでは、基礎となるエンティティ・オブジェクトが、組合せ表自体を使用します

  • 外部キー・ページ。ここでは、基礎となるエンティティ・オブジェクトに、組合せ表への外部キー参照が含まれます

  • 部分的な使用方法ページ。ここでは、キー・フレックスフィールドのセグメント列の一部またはすべてが、製品表内にあります

同じキー・フレックスフィールドを、別々のページ上で異なる方法で使用できます。

外部キー参照を持つページには、実際のフレックスフィールドのセグメント列を持つ組合せ表への外部キー参照を含む、元表またはベース・ビューがあります。これにより、勘定科目組合せID (勘定科目の組合せ)を含む行を操作できます。

キー・フレックスフィールドの部分的な使用方法を含むページには、組合せ表での定義に加えて、製品のトランザクション表で定義されたセグメントが表示されます。部分的な使用方法ページの場合、構成の一部のみを表示できる可能性があります。これにより、キー・フレックスフィールドを、付加フレックスフィールドのように動作させることができます。

勘定科目の組合せ保守ページまたは組合せページには、組合せ表が表示されます。これにより、勘定科目の組合せを直接作成したり、保守したりできます。この組合せ表には、キー・フレックスフィールドのすべてのセグメント列と、一意のID列が含まれます。

一般的なアプリケーションには、組合せページが1つしかありません。管理者による保守をサポートしていないアプリケーションには、組合せページがない場合もあります。

検索リージョンを含むページでは、フレックスフィールド・メタデータの検索基準として使用する、キー・フレックスフィールドのビュー・オブジェクトの属性をユーザーが選択できます。

たとえば、会計キー・フレックスフィールドに7個のセグメントを構成できます。外部キー参照ページには、キー・フレックスフィールド・ピッカーと7個すべてのセグメントが表示され、ユーザーは組合せを検索できます。同じキー・フレックスフィールドを使用する部分的な使用方法ページでは、ユーザーは「コスト・センター」というラベルが付いたセグメントなど、単一のセグメントしか表示できないという可能性があります。また、複数のセグメントが表示されるが、組合せを選択するためのオプションではなく、個々のセグメントとして表示される可能性があります。

キー・フレックスフィールド・ページに関する詳細は、Oracle Fusion Applications開発者ガイドを参照してください。

キー・フレックスフィールド構成: 説明

キー・フレックスフィールド構成は、キーのセグメントを編成し、単一のキー・フレックスフィールドを、同じセグメント複数の組合せまたはそれらのセグメントのサブセットで再利用できるようにします。1つの構成の複数インスタンスにより、その構成のセグメントに割り当てられた値セットの差異に対応できます。

この構成により、キー・フレックスフィールドの次の面が決定されます。

  • 含めるセグメント

  • セグメントの順序

  • 含まれるセグメントのセグメント・ラベル

  • 構成インスタンス内のセグメント・インスタンスに適用される各セグメントのプロパティ

キー・フレックスフィールド構成の管理

キー・フレックスフィールドに定義されているセグメントはすべて、キー・フレックスフィールド構成に含めることができます。

キー・フレックスフィールドの組合せ表で定義されているセグメント列の数だけ、セグメントを定義できます。セグメントは必ず、キーで必要となる順序で追加してください。デプロイ後は、この順序は変更できません。

セグメントを使用可能にして、それらが使用中であることを示します。フレックスフィールドでは、ランタイムに使用不可のセグメントは表示されません。データの整合性を保護するため、すでにデータの入力に使用したセグメントは無効にします。

キー・フレックスフィールドの構成インスタンスとセグメントのインスタンス: 説明

キー・フレックスフィールド構成には、1つ以上の代替構成インスタンスを設定できます。キー・フレックスフィールド構成のインスタンスは、構成の次の面を共有します。

  • 同じセグメント・セット

  • 同じセグメントの配列

  • セグメント・レベルおよび構成レベルでの同じプロパティ

構成インスタンスの違いには、動的組合せ作成が許可されるかどうかが含まれます。同様に、構成インスタンス・レベルでは、セグメント・インスタンスの違いは次のものに基づいています。

  • 値セット

  • デフォルト・タイプとデフォルト値

  • ツリー・コード

  • セグメントが次のいずれかであるかどうか

    • 必須

    • 表示対象

    • ビジネス・インテリジェンスに対して有効

    • 問合せ条件としてオプションまたは必須

たとえば、値セットのグループ1つをアメリカ用、もう1つをフランス用に使うことができます。

次の図は、部品番号構成の2つの構成インスタンスを示しています。

図は、使用できる複数の構成がある部品番号キー・フレックスフィールドを示しています。特定の構成に、複数のインスタンスが存在する可能性があります。また、特定の構成インスタンスには、他の構成インスタンスと区別するためのセグメント・インスタンスがあります。

各構成は、セグメントの数と、使用されるセグメント・セパレータが異なります。構成インスタンスは、その構成に対して定義されているすべてのプロパティを共有します。ただし、構成インスタンスは、プロパティが構成インスタンス・レベルまたはセグメント・インスタンスのレベルで定義されている場合は異なる場合があります。たとえば、セグメント・インスタンスに割り当てられる値セットなどです。

問合せ必須セグメント・インスタンス

キー・フレックスフィールド・セグメント・インスタンスを問合せとして指定し、選択的必須属性にできます。ユーザーはこれをキー・フレックスフィールド組合せ検索として使用できます。「キー・フレックスフィールドの管理」UIページでセグメント・インスタンスに索引付けが必要であると指定した場合は、セグメントを表す列をデータベースの索引に追加します。通常、データベース管理者(DBA)がデータベース索引に列を追加します。

デプロイに続いて、キー・フレックスフィールドの組合せピッカーは、問合せ必須属性を選択的に必須として表示します。ユーザーは、検索基準で少なくとも1つの問合せ必須属性を指定する必要があります。これにより、パフォーマンス問題の原因となる可能性がある不要な検索を防止できます。

たとえば、コスト・センター属性と勘定科目属性に問合せ必須のマークを付け、データベース内の対応する列が必ず索引付けされるようにします。ユーザーはコスト・センター、勘定科目またはその両方を検索基準として入力して、組合せを検索できます。エンド・ユーザーが検索基準として問合せ必須属性を1つも入力しない場合、検索は実行されません。

ヒント: 組合せ表の構成インスタンス番号列に索引を付けると、ランタイムのパフォーマンスが向上します。

動的組合せ

キー・フレックスフィールドが動的組合せ作成をサポートしている場合、動的組合せ作成の許可を選択して、この機能を有効にできます。これにより、ユーザーはランタイムでそのフレックスフィールドの新しい勘定科目の組合せを生成する値を入力します。動的組合せ作成の許可が有効でない場合、新しい有効な組合せを入力するには、フレックスフィールドの組合せ表を使用するしかありません。

ツリー

セグメント・インスタンスに割り当てられている値セットのツリー・コードを定義できます。ツリー・コードをセグメント・インスタンスに割り当てると、セグメント値に対するツリー階層の検索操作が使用可能になります。

セグメント・インスタンスをツリー・ベースにするには、次の条件を満たす必要があります。

  • アプリケーション開発者がキー・フレックスフィールドをツリー構成を使用して登録している。ツリー構成はフレックスフィールドのすべてのセグメントで固定にすることも、セグメント間で可変にすることもできます。

  • そのツリー構成のツリー・コードが存在する。

  • ツリー・コードに、セグメント・インスタンスに割り当てられた値セットの値を含むツリー・バージョンが含まれている。

  • 必要なツリー・コードをセグメント・インスタンスに直接割り当てている。

これらの条件が満たされている場合、同じ値セットを使用する異なるセグメント・インスタンスに、同じツリー・コードまたは異なるツリー・コードを割り当てることができます。

相互検証ルール: 説明

相互検証ルールを定義して、新しいキー・フレックスフィールド・コードの組合せの作成を制御できます。相互検証ルールにより、セグメント間での検証が定義され、特定のセグメントの値を別のセグメントの特定の値と組み合せて、新しい組合せを作成できるかどうかが決定されます。

次の表では、セグメント検証とセグメントの相互検証を比較しています。

検証のタイプ 制御のタイプ

セグメント検証

特定のセグメントに入力できる値を制御します

セグメントの相互検証

管理者とエンド・ユーザーがキー・フレックスフィールドに対して作成できる値の組合せを制御します

注意: 相互検証ルールは、相互検証が有効なすべてのキー・フレックスフィールドで使用できます。キー・フレックスフィールドが相互検証をサポートしているかどうかを確認するには、そのキー・フレックスフィールドの資料を参照してください。

相互検証ルールにより、同じ組合せに共存できない値の組合せが作成されることを防止できます。たとえば、企業で、すべての収益計上科目には具体的な部門が必要であると規定されているとします。そのため、収益計上科目の値(たとえば、4000-5999の範囲内のすべての値)を持つ勘定科目の組合せには、対応する部門の値が存在する必要があります(部門が指定されていないことを表す000を除く)。この場合に、4100-000や5000-000など、互換性のないセグメントとの組合せの作成を許可しない相互検証ルールを定義できます。

別の例として、会計キー・フレックスフィールドに「組織」セグメントがあり、01と02という値を指定できるとします。また、多くの値を指定可能な「勘定科目」セグメントもありますが、会社のポリシーで、組織01は勘定科目値001-499、組織02は勘定科目値500-999を使用すると定められています。この場合、02-342や01-750のような値の組合せでGL勘定科目をユーザーが作成できないようにする相互検証ルールを作成できます。

相互検証ルールを理解するためには次の側面が重要です。

  • ルール定義

  • 強制

  • タイミング

ルール定義

次の表に、相互検証ルールで使用される定義を示します。

ルール定義 目的

名前

デプロイメント内の相互検証ルールを一意に識別します。

説明

管理者がルールの目的を識別する助けになります。

エラー・メッセージ

試行した組合せがルールに違反する理由を説明します。

開始日、終了日

ルールが有効である期間を示します。

有効

ルールが強制されるかどうかを判別します。

条件フィルタ

有効な相互検証ルールが評価される条件を決定します。

検証フィルタ

条件を満たしたときにルールにより強制される検証を決定します。

条件フィルタに指定されたイベントが該当する場合、組合せを作成するには、検証フィルタ条件を満たす必要があります。条件フィルタに指定されたイベントに該当しない場合、組合せはルールに合格したと見なされ、ルールは有効であっても評価されません。

注意: 条件フィルタに文を指定しない場合、条件は必ず真になり、ルールは必ず評価されます。

強制

相互検証により、保守ページを使用する管理者、または外部キー・ページの動的挿入を使用するエンド・ユーザーが、無効な組合せを作成しないようにできます。

セグメント値の新しい組合せを作成しようとすると、有効なルールが強制されます。無効なルールは無視されます。ルールを削除しても同じ効果がありますが、無効にされたルールは再度有効にできます。

タイミング

ユーザーが新しい組合せを作成しようとすると、キー・フレックスフィールドは、有効で効力を持つ相互検証ルールをすべて評価します。

注意: 相互検証ルールは、すでに存在する組合せには影響を与えません。フレックスフィールドは、ルールよりも前に作成された既存の無効な組合せをすべて有効として扱います。

相互検証ルールによってすでに有効ではなくなった既存の組合せをユーザーが使用できないようにするには、そのキー・フレックスフィールドの組合せページを使用して、そのような組合せを手作業で無効にします。

相互検証ルールを定義するときには、開始日と終了日を指定して、ルールの有効期間を限定します。ルールは、「日付: 自」および「日付: 至」のそれぞれの日付とその間の期間内は有効です。

相互検証ルール: 考慮事項

セグメント値のキー・フレックスフィールドの組合せをセグメント間で検証するには、相互検証ルールを最適化して、管理者やユーザーのエクスペリエンスを向上させます。

相互検証ルールを定義するときには、次の点を考慮してください。

  • フィルタ

  • ルールの複雑さ

  • 保守

フィルタ

相互検証ルールには、条件フィルタと検証フィルタが含まれます。ルールは、「条件フィルタが満たされている場合、次は検証フィルタを適用する」という論理順序を使用して評価されます。

条件フィルタは、ルールが評価されるイベントを記述します。条件フィルタに指定されたイベントが該当しない場合、ルールは有効であっても評価されません。条件フィルタに指定されたイベントが該当する場合、組合せを作成するには、検証フィルタ条件を満たす必要があります。

たとえば組織で、「Operations」という特定の会社値が「Marketing」という特定のコスト・センターを使用できないと判断したとします。相互検証ルールを定義して、組合せを検証できます。

  1. このルールは、会社の条件フィルタを評価します。

  2. 会社が「Operations」と等しい場合、このルールはコスト・センターの検証フィルタを評価します。

  3. コスト・センターが「Marketing」と等しい場合、このルールにより組合せは作成できなくなります。

  4. ルールに定義されたエラー・メッセージは、試行された組合せがルールに違反していることをユーザーに通知します。

このようなルールは、「Marketing」コスト・センターと「Operations」以外の会社値の組合せの作成には影響しません。

ルールの複雑さ

パフォーマンスを最適化し、理解しやすくするには、1つの複雑なルールを使用するのではなく、複数の単純な検証ルールを定義します。単純な検証ルールを使用すると、より具体的なエラー・メッセージを提供でき、その後の保守が簡単になります。

可能であれば、3つ以上のセグメントにまたがる検証を制御するルールは避けてください。複数のセグメントにわたる相互検証ルールを定義することは可能ですが、相互検証エラー・メッセージの解釈や、無効なキー・フレックスフィールドの組合せの修正が難しくなります。

保守

一貫性のある検証を維持するために、相互検証ルールを更新するときには、既存のキー・フレックスフィールドを見直してください。現行の検証ルールに関係なく、使用可能になっている場合は既存のキー・フレックスフィールドの組合せを使用できます。したがって、正確な検証を確実に行うには、既存の組合せを見直し、新しいルールの基準と一致しない組合せをすべて無効にする必要があります。

ヒント: このタイプのキー・フレックスフィールドの保守を必要最小限に抑えるには、キー・フレックスフィールド構成を最初に設定するときに、相互検証ルールを決定しておきます。相互検証ルールは、組合せを作成する前、および組合せをトランザクションで使用する前に定義します。

相互検証ルールに従って有効ではなくなってしまった既存の組合せをユーザーが使用できないようにするには、組合せページを使用して無効にします。

相互検証ルールの編集: 例

相互検証ルールによって勘定科目組合せで特定のセグメント値の組合せが行われないようにします。「相互検証ルールの管理」タスクを使用して、既存のルールを編集または1回限りのルールを作成できます。

シナリオ

組織に「会社131および151」という相互検証ルールがあり、このルールでそれらの会社の勘定科目組合せを部門40と製品211に制限しています。両方の会社の勘定科目組合せに、部門30を含めることが必要になりました。相互検証ルールを編集するには、次の手順を実行します。

  1. 「設定および保守」作業領域にナビゲートします。相互検証ルールの管理タスクを探して選択します。

  2. 組織の勘定体系を選択し、「会社131および151」相互検証ルールを選択します。次の図に、そのルールの条件および検証フィルタを示します。

    会社131および151の相互検証ルールの条件および検証フィルタ。

  3. 「検証フィルタ」アイコンをクリックします。

  4. 「フィールドの追加」をクリックし、「部門」セグメントを選択します。

  5. デフォルトの演算子(EQUALS)を受け入れて、部門「30」を選択します。次の図に、更新された検証フィルタを示します。

    部門30と40、および製品211を指定した検証フィルタ。

  6. 「OK」をクリックします。

  7. 「保存」をクリックします。次の図に、保存された検証フィルタを示します。

    部門40と30、および製品211を指定した更新済検証フィルタ。

  8. エラー・メッセージを更新するには、「一般会計」タスクに対して「メッセージの管理」を検索し、選択します。相互検証ルールのエラー・メッセージ名を問い合せ、メッセージを編集して部門30を含めます。

Business Intelligenceに対するキー・フレックスフィールド・セグメントの有効化: 考慮事項

データベースにOracle Business Intelligence (BI)対応と登録されているキー・フレックスフィールドの各セグメント・インスタンスには、BI対応という設定があります。セグメント・インスタンスがBI対応であれば、そのセグメント・インスタンスは、Oracle Business Intelligenceで使用できます。

BI対応であるキー・フレックスフィールドの管理を理解するためには以下の側面が重要です。

  • Oracle BIでBI対応セグメントを使用するためのビジネス・コンポーネントの平坦化

  • 平坦化されたコンポーネントにおける重複および複雑さを回避するためのセグメントの均質化

  • 平坦化されたビジネス・コンポーネントの属性からOracle BIの論理オブジェクトへのマッピング

  • セグメントをOracle BIの論理オブジェクトにマップするラベルの管理

ビジネス・インテリジェンス対応のフレックスフィールドをデプロイした後、トランザクション・ビジネス・インテリジェンス用のOracle Fusionデータ拡張のインポートプロセスを使用して、フレックスフィールドの変更をOracle Business Intelligenceリポジトリにインポートします。ユーザーはビジネス・インテリジェンス・アプリケーションで新しく生成された属性を使用できます。論理オブジェクトとインポートに関する追加情報は、Oracle Transactional Business Intelligence管理者ガイドを参照してください。

平坦化

ビジネス・インテリジェンス対応キー・フレックスフィールドをデプロイする場合、デプロイメント・プロセスにより、ビジネス・インテリジェンスで使用するための平坦化されたビジネス・コンポーネントの追加セットが生成されます。平坦化されたビジネス・コンポーネントには、ビジネス・インテリジェンス対応セグメント・インスタンスの属性のみが含まれます。

セグメントにラベルを割り当てた場合、平坦化されたコンポーネントには、そのラベルが付けられているすべてのセグメント・インスタンスを表す単一の属性が含まれます。ラベルを割り当てなかった場合、平坦化されたコンポーネントには、各構成内の各BI対応セグメント・インスタンスに対する個別の属性が含まれます。

Business Intelligenceの論理オブジェクトへのマッピング

Business Intelligenceでは類似の複数のセグメントを単一の論理オブジェクトとして表現することで、レポートを簡略化できます。異なる構成で同じ目的を果たすセグメントにラベルを割り当てる場合、これらのセグメントを単一の属性に統合できます。これにより、プロセスの平坦化による重複、余分のワークロードおよに複雑さが回避されます。たとえば、会計レポートの様々な要件を満たすために、組織で会計キー・フレックスフィールドに複数の定義を持たせることができます。アメリカの会計フレックスフィールド構成に、プロジェクトの支出をトラッキングするためのセグメント「補助科目」があるとします。イギリスの会計フレックスフィールド構成では、同じタイプの情報がセグメント「プロジェクト」でトラッキングされています。レポート用に1つの値リストを作成するために、これらの2つのセグメントを均等化します。

ラベルのついていないセグメントは、コンテキスト値間で均等化されないため、平坦化されたコンポーネントには、各構成のセグメントごとに別々の属性が含まれます。同じようにラベルが付けられたセグメントでも、データ型や値セットのタイプに互換性がなければ、均等化できない可能性があります。

平坦化されたコンポーネントの対応する属性をOracle Business Intelligenceの論理オブジェクトにマップするには、セグメントにラベルを割り当てます。ラベルを使用してセグメントをBI論理オブジェクトにマップすると、Oracle Business Intelligenceにフレックスフィールドをインポートする手順を最小限に抑えることができます。ラベルをセグメントに割り当てると、構成間で属性が均等化されるだけでなく、均等化された属性がビジネス・インテリジェンスにマップされます。

ラベルの管理

事前定義済ラベルがあれば、それをセグメントに割り当てることができます。または必要に応じて、割当て用のラベルを作成することもできます。各ラベルを識別するコード、名前、摘要を指定します。BIオブジェクト名フィールドには、インポート時にセグメント・ラベルをマップするOracle Business Intelligenceの論理オブジェクト名を入力します。BI論理オブジェクトを指定すると、フレックスフィールドをOracle Business Intelligenceにインポートするときの手順を最小限に抑え、構成間でコンテキスト依存セグメントを均等化しやすくなります。

BI対応セグメントにラベルが割り当てられていない場合、または割り当てられたラベルのBIオブジェクト名がBusiness Intelligenceに存在しない場合は、Oracle Business Intelligenceへのインポート時に、セグメントを必要な論理オブジェクトに手動でマップする必要があります。さらに、ラベルのないセグメントは、構成間で均等化できません。平坦化されたコンポーネントには、各構成内のラベルが付けられていない各セグメントに対する個別の属性が含まれます。

Oracle Business Intelligenceリポジトリへのインポート

ビジネス・インテリジェンス対応フレックスフィールドをデプロイしたら、フレックスフィールドの変更をOracle Business Intelligenceリポジトリにインポートして、新しく平坦化されたビジネス・コンポーネントをビジネス・インテリジェンスで使用できるようにします。その後、フレックスフィールド・オブジェクトの変更を伝播します。メタデータをOracle Business Intelligenceリポジトリにインポートする場合は、FUSION_APPS_BI_APPIDユーザーとして実行する必要があります。

フレックスフィールドの変更を、Oracle Cloud実装のOracle Business Intelligenceリポジトリにインポートするには、トランザクション・ビジネス・インテリジェンス用のOracle Fusionデータ拡張のインポートプロセスを実行します。インポートに関する追加情報は、Oracle Transactional Business Intelligence管理者ガイドを参照してください。

注意: フレックスフィールドをOracle Business Intelligenceリポジトリにインポートするときに、各セグメントの<name>_および<name>_cの両方の属性が、他のいくつかのオプション属性とともに表示されます。<name>_ 属性には値が含まれています。<name>_c属性は、値の取得元である値セットのコードが含まれ、値ディメンションへのリンクに使用されます。両方の属性をインポートする必要があります。

キー・フレックスフィールド: 例

キー・フレックスフィールドは、費用勘定情報を取得できます。

シナリオ

各支出の詳細を入力する場合、ユーザーは支出の請求先勘定科目を指定します。

費用勘定の入力

経費を入力するためのユーザー・インタフェースを使用すると、ユーザーは、その経費の処理に必要なコスト・センターなどの詳細を識別する費用勘定を選択できます。

分析

費用勘定フィールドは、勘定科目の組合せの外部キー参照です(EXPENSE_LINES.EXPENSE_ACCOUNT = ACCOUNT.COMBINATION)。

勘定科目と従業員を入力するための勘定科目組合せ表

この勘定科目組合せ表は、費用勘定などの勘定科目情報の入力をサポートします。

次の図は、ユーザーにより指定された勘定科目の勘定科目組合せ表の参照元を表しています。勘定科目組合せIDレコードには、キー・フレックスフィールドの構成に基づいて費用勘定のまとめに使用される、キー・フレックスフィールド・セグメントの情報が格納されます。

図は、費用表と勘定科目組合せ表を示しています。勘定科目組合せでは、費用表からの勘定科目組合せIDを取得します。 その後、セグメント情報がプロジェクト番号の形式で組合せ詳細表に渡されます。組合せデータは費用勘定として見積もられ、すべての詳細が費用詳細ユーザー・インタフェースに提供されて、ユーザーは費用勘定に対して経費金額を入力できます。

キー・フレックスフィールドの保守ページである組合せページは、組合せ表の行を管理するためのものです。この例では、組合せの管理とは、キー・フレックスフィールド・メタデータ・ルールに従って口座番号を追加または編集することです。

次の図は、フレックスフィールドの構成と勘定科目組合せ表に反映された費用勘定例で使用される勘定科目組合せの詳細を示しています。

この図は、勘定科目組合せ表が保守される組合せ詳細ユーザー・インタフェースと、勘定科目組合せ表の結果である組合せ詳細を示しています。

動的組合せ作成が使用可能ではない場合、ユーザーは支出明細を入力ときに、ACCOUNTS(組合せ)表にすでに存在する勘定科目のみ選択できます。存在しない勘定科目が必要な場合には、組合せ表に勘定科目を追加できる、適切なアプリケーション管理者に問い合せる必要があります。

動的組合せ作成が有効な場合、ユーザーは支出明細を入力するときに、既存の勘定科目を選択するか、またはACCOUNTS(組合せ)表にその場で動的に作成される新しい勘定科目を入力できます。新しい組合せが作成されると、同じユーザーはその組合せを支出明細で参照できるようになります。

従業員情報を管理する場合、ユーザーは、その従業員が属するコスト・センターを指定します。このコスト・センター・フィールドは、会計キー・フレックスフィールドにある1つのラベル付きセグメントに対応し、そのセグメントに対して許可される値セットなどのメタデータが定義されています。

次の図では、勘定科目へのコスト・センターID参照を指定するかわりに、コスト・センター・セグメントのみが使用され、値は従業員表に直接格納されています。

この図は、組合せ詳細と、それが「従業員詳細」ユーザー・インタフェースにどのように表示されるかを示しています。

関連トピック