22フレックスフィールドの保守
この章の内容は次のとおりです。
付加フレックスフィールドの管理
付加フレックスフィールドの概要
属性をビジネス・オブジェクト・エンティティに追加したり、その検証を定義したりするには、付加フレックスフィールドを使用します。
アプリケーションで使用できるすべてのビジネス・オブジェクト・エンティティは、付加フレックスフィールドに対応しています。ただし、付加フレックスフィールドの構成はオプションのタスクです。
コンテキスト
付加フレックスフィールドには、コンテキスト依存性を提供するコンテキスト・セグメントを1つしか設定できません。同じ基礎データベース列を、異なるコンテキストの異なるセグメントで使用できます。
たとえば、次の属性を使用する「寸法」コンテキストを定義できます。
-
高さのATTRIBUTE1列
-
幅のATTRIBUTE2列
-
奥行のATTRIBUTE3列
さらに、同じ列を次の他の属性に使用する「測定」コンテキストを定義することもできます。
-
重量のATTRIBUTE1列
-
容量のATTRIBUTE2列
-
密度のATTRIBUTE3列
セグメントおよびコンテキスト
次の表に、様々なタイプの付加フレックスフィールド・セグメントを示します。
| セグメント・タイプ | ランタイム時の表示 |
|---|---|
|
グローバル・セグメント |
常に表示される |
|
どのコンテキスト依存セグメントを表示するかを決定する |
|
|
コンテキスト・セグメントの値に応じて表示される |
次の図では、付加フレックスフィールドには「カテゴリ」という名前のコンテキスト・セグメントが1つあり、そこにレジスタ、バッテリ、キャパシタの3つの値があります。さらに、付加フレックスフィールドは、各コンテキストに表示される2つのグローバル・セグメントと、特定のコンテキストにのみ表示される3つのコンテキスト依存セグメントで構成されています。
アプリケーション開発では、構成に使用できるセグメントの数が決定されます。実装時に、以下を決定しながらフレックスフィールドを構成します。
-
使用可能なセグメントを使用して追加する属性
-
コンテキスト値
-
各コンテキストの属性の組合せ
値セット
各グローバル・セグメントおよびコンテキスト依存セグメントについて、そのセグメントに許可する値を構成します。それに基づいて、エンド・ユーザーが入力する値が検証されます。これにはセグメント間の相互依存検証も含まれます。
保護された付加フレックスフィールド・データ
アプリケーション開発者は、付加フレックスフィールド内の一部のデータ構成に保護のマークを付け、それらが編集不可であることを示すことができます。
付加フレックスフィールドの計画の考慮事項
構成するフレックスフィールドを特定したら、構成を事前に計画します。構成の影響を受ける、デプロイメント内のUIページや他のアーティファクトのリストをまとめます。フレックスフィールドの表示と構成に必要なロールがプロビジョニングされていることを確認します。フレックスフィールドが表示されているランタイム・ページが表示されているときに、「管理」メニューのフレックスフィールドの強調表示コマンドを使用してフレックスフィールドを表示します。テストおよび本番ユーザーに対してフレックスフィールドをデプロイする方法を計画します。フレックスフィールド・セグメントを追加および編集するために、フレックスフィールドの管理に使用できるツールとタスクをレビューします。
付加フレックスフィールドの計画には、次のタスクが含まれる場合があります。
-
既存のパラメータを特定します。
-
既存のコンテキスト値を特定し、そのコンテキスト値が導出されたものであるかどうかを特定します。
-
ユーザー定義属性を特定し、付加フレックスフィールド・セグメント、セグメント・プロパティ、構成を計画します。
-
検証ルールを計画します。
-
初期値を計画します。
-
Oracle Business Intelligenceオブジェクトへの属性マッピングを計画します。
既存の付加フレックスフィールド・パラメータの特定
一部の付加フレックスフィールドでは、付加フレックスフィールド・セグメントの初期値の指定に使用できるパラメータが提供されます。このパラメータは、列値やセッション変数などの外部参照データです。たとえば、フレックスフィールドにユーザーの電子メール・パラメータが入っている場合、顧客電子メール属性の初期値をこのパラメータから導出するように構成できます。
付加フレックスフィールドの「セグメントの作成」ページにある「導出値」フィールドで、使用可能なパラメータのリストを確認します。いずれかのパラメータを使用して初期値を設定する場合は、付加フレックスフィールド・セグメントを追加するときに、「導出値」ドロップダウン・リストからそのパラメータを選択します。
コンテキスト値が導出されるかどうかの評価
付加フレックスフィールド・コンテキスト値は、外部参照から導出されるように事前構成されている場合があります。たとえば、コンテキストが「婚姻状態」であれば、その値は従業員ビジネス・オブジェクトの属性から導出される可能性があります。コンテキスト値が導出される場合、計画段階で導出値とそのソースを考慮に入れることが必要になる場合があります。
コンテキスト値が導出されるかどうかを判断するには、付加フレックスフィールドの編集タスクに移動して、そのフレックスフィールドに対する構成済コンテキスト値のリストを確認します。コンテキスト・セグメント領域の導出値フィールドに、使用可能なパラメータのリストが表示されます。コンテキスト値が事前構成されている場合、Oracle Applications Cloudのヘルプでそれらの値の使用に関する製品固有の情報を参照してください。
セグメント、セグメント・プロパティおよび構成の計画
付加フレックスフィールドのセグメントを決定するためにビジネス・オブジェクトで必要となる、ユーザー定義属性を特定します。プロンプト、表示タイプ、初期値などのセグメント・プロパティを決定します。
付加フレックスフィールドの構成は、グローバル、コンテキストおよびコンテキスト依存セグメントにより決定されます。ビジネス・オブジェクトの各インスタンスについて、属性を取得するグローバル・セグメントを計画します。ビジネス・オブジェクトの特定のインスタンスに適用する状況の条件に依存するセグメントのコンテキストを計画します。コンテキストに関係する属性を取得するためのコンテキスト依存セグメントを計画します。
付加フレックスフィールドで使用できるコンテキスト・セグメントは1つのみです。コンテキスト・セグメントを使用できるユーザー定義属性のグループが複数ある場合は、会社のニーズや優先順位に基づいて1つのグループを選び、それ以外のユーザー定義属性はグローバル・セグメントとして追加する必要があります。
検証ルールの計画
各セグメントの検証ルールを定義して、それらのルールの値セットが存在しているかを確認します。存在していない場合は、作成する必要があります。値セットを作成する必要がある場合は、フレックスフィールドの構成前、またはセグメントの作成時か編集時のいずれかで作成できます。
セグメントの検証ルールを決定するときは、次の質問を考慮します。
-
データ型は何か(文字、日付、日時または数字)。
-
セグメントにはデータ型および最大長以外の検証が必要か。
-
文字タイプの値は数字に制限する必要があるか、または英字を許可するか。
-
英字を自動的に大文字に変更する必要があるか。
-
数値はゼロ埋込みをする必要があるか。
-
数値の基数セパレータに続けることができる桁数はいくつか。基本的な十進数システムでは、基数セパレータは小数点です。
-
値は範囲内に収まる必要があるか。
-
値は有効な値のリストから選択する必要があるか。必要がある場合、次の質問を考慮します。
-
有効な値のリストを取得するために既存のアプリケーション表を使用できますか。またはリストを作成する必要がありますか。
-
既存の表を使用している場合、WHERE句を使用して値のリストを制限する必要がありますか。
-
有効な値のリストは、別のフレックスフィールド・セグメントの値に依存していますか。
-
有効な値のリストは、別のフレックスフィールド・セグメントの値のリストのサブセットですか。
-
初期値の計画
すべてのセグメントに対して、ユーザー定義属性の初期値に使用する定数値またはSQL文がある場合は、それらをリストします。
Oracle Business Intelligenceオブジェクトへのセグメントのマップ方法の計画
付加フレックスフィールドは、アドホック・レポートの作成を目的として、Oracle Transactional Business Intelligence (OTBI)に拡張できます。レポート作成に使用できるようにする付加フレックスフィールド・セグメントを決定し、それに応じて「付加フレックスフィールドの管理」ページで「BI有効」チェック・ボックスを選択します。BI対応セグメントをOTBIに拡張するプロセスを実行する必要があります。BI対応セグメントのOTBIへの拡張の詳細は、『Oracle Applications Cloud分析とレポートの作成および管理』ガイドの「フレックスフィールド」の章を参照してください。
レポート作成のニーズに応じて、別のコンテキストからの類似のコンテキスト依存属性を、OTBI内の同じ属性にマップできます。たとえば、コンテキスト依存の付加フレックスフィールドの別のコンテキストに、「製品の色」属性を追跡するセグメントがあるとします。セグメント・ラベルを使用して、セグメント・ラベルを定義し、それに応じてBIラベル・リストを更新することで、それらのコンテキスト依存属性をまとめてマップできます。
付加フレックスフィールドの管理に関する考慮事項
付加フレックスフィールドの構成には、Oracle Applications Cloudデータベースに登録された使用可能なフレックスフィールドの管理、そのフレックスフィールド・レベル・プロパティの構成、付加フレックスフィールド・コンテキストの定義と管理、およびグローバル・セグメントとコンテキスト依存セグメントの構成が含まれます。
すべての付加フレックスフィールドはコンテキスト・セグメントを組み込むように登録されます。コンテキスト・セグメントを使用するかどうかは選択できます。
一般的に、付加フレックスフィールドの構成には次の手順が含まれます。
-
ビジネス・インテリジェンス対応のフレックスフィールド用にセグメント・ラベルを作成します。
-
識別情報、初期デフォルト値および表示プロパティを指定して、グローバル・セグメントを構成します。
-
プロンプト、コンテキスト・セグメントを表示するかどうか、および値を必須にするかどうかを指定して、コンテキスト・セグメントを構成します。
-
各コンテキスト値のコンテキスト・コード、摘要および名前を指定し、識別情報、列割当て、初期デフォルト値および表示プロパティを含むように構成された各コンテキスト依存セグメントを追加して、コンテキストを構成します。
付加フレックスフィールドの管理を理解するために次の側面が重要です。
-
セグメント
-
強調表示された付加フレックスフィールドへのセグメントの追加
-
使用方法
-
パラメータ
-
デリミタ
-
初期値
-
ビジネス・インテリジェンス
セグメント
連番の順序番号を、グローバル・セグメントと、各コンテキスト内のコンテキスト依存セグメントに割り当てることができます。セグメントは常に固定された順序で表示されます。ある番号が別のセグメントですでに使用されている場合、その番号をセグメントに対して入力することはできません。
値セットは、コンテキスト・セグメントでは省略可能であり、次の具体的なガイドラインに従います。
-
コンテキスト・セグメントに指定する値セットは、コンテキスト・コードのセットで構成されます。
-
これらのコンテキスト・コードはそれぞれ、付加フレックスフィールドに適したコンテキストに対応します。
-
値セットは、独立または表検証でなければなりません。
-
表検証の場合、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>}: 同じコンテキスト内のセグメントを特定します。 -
:{PARAMETER.<parameter_code>}: パラメータを特定します。 -
:{CONTEXT.<context_code>;SEGMENT.<segment_code>}: 異なるコンテキスト内のセグメントを特定します。コンテキストは同じカテゴリまたは先祖のカテゴリ内になければならず、複数行のコンテキストにすることはできません。 -
:{VALUESET.<value_set_code>}: 指定された値セットに割り当てられた、同じコンテキスト内の直前のセグメントを特定します。 -
:{FLEXFIELD.<internal_code>}: フレックスフィールドを特定します。
-
ビジネス・インテリジェンス
グローバル、コンテキストまたはコンテキスト依存セグメントのBI対応チェック・ボックスを選択すると、そのセグメントはOracle Business Intelligenceで使用できるようになります。
フレックスフィールドをOracle Business Intelligenceにインポートすると、BIラベル・ドロップダウン・リストで選択したラベルにより、そのセグメントと他のコンテキストのセグメントが均等化され、ラベルが表す論理オブジェクトにセグメントがマップされます。
ビジネス・インテリジェンスに対する付加フレックスフィールド・セグメントの有効化の考慮事項
データベースに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オブジェクト名フィールドには、インポート時にセグメント・ラベルをマップする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管理者ガイドを参照してください。
<name>_と<name>_cの両方の属性が、他のいくつかのオプション属性とともに表示されます。<name>属性には値が含まれます。<name>_c属性には、値の取得元の値セットのコードが含まれ、値ディメンションにリンクするために使用されます。両方の属性をインポートする必要があります。
拡張可能フレックスフィールドの管理
拡張可能フレックスフィールドの概要
拡張可能フレックスフィールドは付加フレックスフィールドに似ていますが、いくつか機能が追加されています。
-
フレックスフィールドには、コンテキスト依存セグメントを必要なだけいくつでも追加できます。フレックスフィールドに対して事前定義されている登録済の列数により制限されることはありません。
-
エンティティとその拡張属性行の間には、1対多の関係を構成できます。
-
データの行には、複数のコンテキストを関連付けることができます。
-
データの行には、同じコンテキストが繰り返し出現してもかまいません。
-
-
属性をグループに構成してコンテキストを形成し、ユーザー・インタフェースではコンテキストの属性が常にまとめて表示されるようにできます。
-
既存の階層カテゴリを使用して、エンティティにその親に対して構成されたコンテキストを継承させることができます。コンテキストは、カテゴリ全体で再利用可能です。
-
アプリケーション開発では、表示や編集の権限をサポートするために、いくつかの拡張可能フレックスフィールドが登録されています。そのようなフレックスフィールドに対して、属性の表示や属性の値の変更ができるユーザーを管理するために、コンテキスト・レベルで表示や編集の権限を指定できます。
1エンティティ当たり複数行のコンテキストを構成する場合、セグメントは表として表示されます。
付加フレックスフィールドとは異なり、拡張可能フレックスフィールド・セグメントに対応する拡張列は、拡張表の一部であり、ベース・アプリケーション表とは別のものです。付加フレックスフィールド・コンテキストとは異なり、拡張可能フレックスフィールド・コンテキストの属性セットは一定であり、コンテキスト値ごとに異なるということはありません。拡張可能フレックスフィールドは、アプリケーション・エンティティを表します。これにはランタイムにデータベースを拡張する機能があり、実装コンサルタントはこれを使用して、アプリケーションで表示されるデータ構成を定義できます。拡張可能フレックスフィールドは、エンティティとその拡張属性行との間の1対多関係をサポートします。事前定義された拡張可能フレックスフィールドのリストを取得するには、「設定および保守」作業領域の「拡張可能フレックスフィールドの管理」タスクを使用します。
拡張可能フレックスフィールドを理解するためには次の側面が重要です。
-
使用方法
-
カテゴリ
-
ページ
-
セキュリティ
-
保護された拡張可能フレックスフィールド・データ
使用方法
付加フレックスフィールドと同様に、拡張可能フレックスフィールドに複数の使用方法を定義できます。これにより、複数のアプリケーション表で同じフレックスフィールドを共有できます。
たとえば、出荷オプションのフレックスフィールドは、「サプライヤ」表と「バイヤー」表の両方で使用できます。さらに、1つのコンテキストを、フレックスフィールドの1つ、一部またはすべての使用方法と関連付けることができます。したがって、この出荷情報の例では、倉庫コンテキストを「サプライヤ」使用方法、納品場所コンテキストを「バイヤー」使用方法、出荷方法コンテキストをすべての使用方法と関連付けることができます。
使用方法には、ユーザー・アクセスに対してセキュリティを適用停止したり、表示および編集権限を強制したりするためのセキュリティ情報が含まれています。一部の製品固有の拡張可能フレックスフィールドには、セキュリティ用以外の特殊な使用方法フィールドがあります。
カテゴリ
複数の拡張可能フレックスフィールド・コンテキストを構成し、コンテンツをカテゴリにグループ化できます。すべての拡張可能フレックスフィールドには、少なくとも1つのカテゴリがあります。一部の拡張可能フレックスフィールドでは、カテゴリの階層を構成できます。階層の子カテゴリは、その親カテゴリからコンテキストを継承できます。
拡張可能フレックスフィールドのカテゴリを定義し、コンテキストの組合せと特定のカテゴリとを関連付けることができます。
たとえば、「電子機器とコンピュータ」カテゴリ階層に「家庭用娯楽機器」カテゴリを含め、さらにそのカテゴリに「オーディオ」カテゴリと「TV」カテゴリを含めることができます。「家庭用娯楽機器」製品には、電圧、寸法、入出力を指定するコンテキストが含まれる可能性があります。コンテキストは、特定の拡張可能フレックスフィールド内で再利用できます。たとえば、寸法コンテキストは、寸法情報を含める必要があるどのカテゴリにでも割り当てることができます。
ページ
拡張可能フレックスフィールドでは、コンテキストを結合してページと呼ばれるグループにできます。ページにより、コンテキストを結び付けて、それらをアプリケーション・ユーザー・インタフェースで常にまとめて表示できます。
各アプリケーション・ページは、1つの拡張可能フレックスフィールド・カテゴリに対応し、関連付けられた各コンテキストのページ内に個別の領域を持ちます。
セキュリティ
フレックスフィールドを構成時するときに、コンテキストの使用方法の表示権限と編集権限に対してアクションを選択することで、使用方法レベルでのコンテキストの権限を設定します。
エンド・ユーザーが検索を実行するときに、ユーザー・インタフェースにはユーザーが表示権限を持つコンテキストの属性値のみが表示されます。表示権限に関係なく、ユーザーはすべてのコンテキストに対してすべての属性を使用して検索を実行できます。
エンド・ユーザーがWebサービス経由でコンテキストにアクセスし、権限を持たないアクションを実行すると、例外がスローされます。
すべての拡張可能フレックスフィールドには、基本データ・セキュリティ・リソースがあります。拡張可能フレックスフィールドの一部のデータ・セキュリティ・リソースには、アクセス権限の指定に使用できるアクションが事前構成されています。アクションが事前構成されていない場合、セキュリティ管理者は、拡張可能フレックスフィールド属性に対するアクセス・コントロールをサポートするアクションとポリシーを作成できます。
一部の拡張可能フレックスフィールドには翻訳可能なオプションがあり、これらのフレックスフィールドには翻訳データ・セキュリティ・リソースもあります。
保護された拡張可能フレックスフィールド・データ
アプリケーション開発者は、拡張可能フレックスフィールド内の一部のデータ構成に保護のマークを付け、それらが編集不可であることを示すことができます。
拡張可能フレックスフィールドが部分的に保護されている場合、フレックスフィールドの構成の保護されている部分は編集できません。次に例を示します。
-
拡張可能フレックスフィールド・ページが保護されている場合、次のものは編集できません。
-
コンテキスト詳細
-
コンテキスト・セグメント
-
コンテキスト使用方法
-
-
拡張可能フレックスフィールド・ページが保護されている場合、次は実行できません。
-
ページの詳細の編集およびページの削除
-
ページに関連付けられているコンテキストの編集
-
-
保護されたコンテキストへのページ参照には、制限はありません。作成するページには、保護されているかどうかを問わず、任意のコンテキストを含めることができます。
-
保護されたコンテキストへのカテゴリ参照には、制限があります。コンテキストが保護されている場合、カテゴリへの追加およびカテゴリからの削除はできません。
拡張可能フレックスフィールドの計画の考慮事項
フレックスフィールドを特定したら、その構成を事前に計画します。構成の影響を受ける、デプロイメント内のUIページや他のアーティファクトのリストをまとめます。フレックスフィールドの表示と構成に必要なロールがプロビジョニングされていることを確認します。フレックスフィールドが表示されているランタイム・ページが表示されているときに、「管理」メニューのフレックスフィールドの強調表示オプションを使用してフレックスフィールドを表示します。テストおよび本番ユーザーに対してフレックスフィールドをデプロイする方法を計画します。フレックスフィールド・セグメントを追加および編集するために、フレックスフィールドの管理に使用できるツールとタスクをレビューします。
拡張可能フレックスフィールドの計画には、次のタスクが関係します。
-
次のものを識別します。
-
カテゴリの階層構成
-
既存のコンテキスト値
-
ユーザー定義属性、関連する拡張可能フレックスフィールド・セグメント、セグメント・プロパティ、および構成
-
-
次のものを計画します。
-
検証ルール
-
初期値
-
セキュリティ
-
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セットのコンテキスト依存セグメントのみが含まれます。複数行のコンテキストを使用すると、複数の値セットを同じオブジェクト・インスタンスに関連付けることができます。
たとえば、BOOK表の場合、章のセグメントおよびページ数のセグメントを含む「章」という名前の、複数行のコンテキストを作成できます。次に、複数の章をBOOK表内の各ブックに関連付けることができます。
複数行を保存するコンテキストでは、各行で一意キーからの値を持つことにより、各行を一意に識別できます。
フレックスフィールドにカテゴリ階層がある場合は、その階層を利用して、類似するエンティティ(製品カタログ内の類似する品目など)にコンテキストを再利用できます。
コンテキストを翻訳可能に設定すると、エンド・ユーザーが入力する自由形式テキストがユーザーのロケールの言語で保存され、そのテキストの別の翻訳を他の言語で保存できます。翻訳済コンテキスト内のセグメントでは、自由形式のユーザー入力テキストを保存するためにフォーマット限定値セットを使用する必要があります。
コンテキスト・セキュリティを設定して、エンド・ユーザーにコンテキストへの表示アクセス権または編集アクセス権を付与します。表示アクセス権があるユーザーに対してのみ、コンテキストのタスク・フローとリージョンがユーザー・インタフェースに表示されます。編集アクセス権があれば、エンド・ユーザーはコンテキストの属性値を編集できます。使用方法に対してアクションが指定されていない場合、コンテキストの構成による特別な権限は適用されません。
ユーザー・インタフェースでコンテキストをグループ化するように論理ページを定義します。特定のカテゴリに対して、1つ以上の論理ページを作成できます。カテゴリの1つ以上の関連コンテキストを、カテゴリの各論理ページに追加できます。
次のものを指定できます。
-
各ページ内のコンテキストの順序。
-
論理ページが表示される順序。
-
ページの使用方法をエンド・ユーザーに説明する手順を表示するための、手順ヘルプ・テキスト。手順ヘルプ・テキストは、論理ページの先頭に、すべてのコンテキスト・リージョンよりも前に表示されます。
カテゴリ
カテゴリとは、同類とみなすことができる関連データ項目をグループ化したものです。コンテキストの任意の組合せを特定のカテゴリと関連付けることができます。30を超えるカテゴリがある拡張可能フレックスフィールドは、バックグラウンド・プロセスとしてデプロイする必要があります。
カテゴリ階層は、一連のカテゴリを論理的に編成します。たとえば、「電子機器とコンピュータ」カテゴリ階層には、「コンピュータ」カテゴリや「家庭用娯楽機器」カテゴリが含まれ、さらにこのカテゴリには「オーディオ」カテゴリと「TV」カテゴリなどが含まれる可能性があります。
カテゴリは、既存のカテゴリの子または兄弟にすることができます。階層は、ゼロ以上の兄弟カテゴリおよびゼロ以上の子カテゴリを任意に組み合せて、必要に応じて単純なものにすることも複雑なものにすることもできます。カテゴリが定義されていない場合、データ項目は事前定義された単一のデフォルト・カテゴリにグループ化されます。
各カテゴリは、そのカテゴリのデータ項目に関する関連情報を格納する関連コンテキストがあります。たとえば、「家庭用娯楽機器」製品には、「電圧」、「寸法」、「入出力」を指定するコンテキストが含まれます。コンテキストは、特定の拡張可能フレックスフィールド内で再利用できます。「寸法」コンテキストは、寸法の情報を含める必要があるすべてのカテゴリに割り当てることができます。
階層に子カテゴリが含まれる場合、各子カテゴリはその親カテゴリからコンテキストを継承します。たとえば、「家庭用娯楽機器」カテゴリは、「電子機器とコンピュータ」カテゴリから「電圧」と「寸法」を継承します。
各拡張可能フレックスフィールドは、特定のカテゴリ階層に関連付けられます。カテゴリ階層は、拡張可能フレックスフィールドとそのコンテキストを定義するフレームワークと見なすことができます。カテゴリ階層により、各カテゴリに有効なコンテキストが指定されます。
拡張可能フレックスフィールドには、特定のカテゴリをサポートするように定義した複数のコンテキストを含めることができます。これらのコンテキストは様々な目的に適合させることができますが、特定のカテゴリ内では、一部のコンテキストが相互に関連している、または相互に依存していると見なされる場合があります。これらのコンテキストは論理ページと呼ばれるグループに結合できます。さらに、このページが表示される順序を決定できます。これによって、コンテキストを、アプリケーション・ユーザー・インタフェースに特定の順序で常に一緒に表示されるように結び付けることができます。
たとえば、「家庭用娯楽機器」カテゴリには、「電圧」、「入出力」コンテキストを含む「電子機器とコンピュータ」ページと、「寸法」および「フォーム・ファクタ」コンテキストを含む「物理仕様」ページがあります。
初期値
初期値を定義するSQL文は、1行のみかつ正しいタイプの値を返す有効な文でなければなりません。
次の2タイプのSQL文を使用できます。
-
バインディングなしのSQL文。たとえば、EMPLOYEESからMIN(SALARY)を選択します。
-
バインド変数があるSQL文。SQL文のWHERE句では、次のバインド変数を使用できます。
-
:{SEGMENT.<segment_code>}: 同じコンテキスト内のセグメントを特定します。 -
:{PARAMETER.<parameter_code>}: パラメータを特定します。 -
:{CONTEXT.<context_code>;SEGMENT.<segment_code>}: 異なるコンテキスト内のセグメントを特定します。コンテキストは同じカテゴリまたは先祖のカテゴリ内になければならず、複数行のコンテキストにすることはできません。 -
:{VALUESET.<value_set_code>}: 指定された値セットに割り当てられた、同じコンテキスト内の直前のセグメントを特定します。 -
:{FLEXFIELD.<internal_code>}: フレックスフィールドを特定します。
-
強調表示された拡張可能フレックスフィールドへのセグメントの追加
ランタイム・ページでフレックスフィールドを強調表示し、「セグメントの追加」アイコン・ボタンを使用してセグメントを作成すると、セグメント・コード、名前、摘要、表列および順序番号が自動的に設定されます。「セグメントの追加」アイコン・ボタンを使用して拡張可能フレックスフィールド・セグメントを構成する場合には、既存の値セットは使用できません。値セットは、セグメントを追加すると自動的に作成されます。有効な値、その摘要およびデフォルト値を入力したり、最小値や最大値など、値セットに対するフォーマット設定制約を指定したりできます。
表示タイプに応じて、セグメントの追加アイコン・ボタンを使用して作成する値セットは、独立値セットまたはフォーマット限定値セットのいずれかになります。次の表は、選択するセグメント表示コンポーネントに応じて、どのタイプの値セットが作成されるかを示しています。
| 表示コンポーネント | セグメントの追加を使用して作成される値セット |
|---|---|
|
チェック・ボックス |
独立 |
|
ドロップダウン・リスト |
独立 |
|
値リスト |
独立 |
|
ラジオ・ボタン・グループ |
独立 |
|
検索機能付きテキスト・フィールド |
独立 |
|
テキスト・ボックス |
フォーマット限定 |
|
テキスト領域 |
フォーマット限定 |
|
リッチ・テキスト・エディタ |
フォーマット限定 |
|
日付/時間 |
フォーマット限定 |
索引付きセグメント
拡張可能フレックスフィールド・セグメントを索引付きと指定して、エンド・ユーザーが属性の検索に使用できる選択的必須属性の1つにすることができます。「拡張可能フレックスフィールドの管理」UIページでセグメントに索引を付けるよう指定した場合は、セグメントを表す列がデータベース索引に追加される必要があります。通常、データベース管理者(DBA)がデータベース索引に列を追加します。
索引付きセグメントがある拡張可能フレックスフィールドがデプロイされると、他のフレックスフィールド・アーティファクトとともに検索タスク・フローが生成され、索引付き属性が選択的必須と指定されます。デプロイ済拡張可能フレックスフィールドの検索タスク・フローで、エンド・ユーザーは検索基準に少なくとも1つの索引付き属性を指定する必要があります。これにより、パフォーマンスの問題の原因となる可能性がある、非選択的検索を防止できます。
たとえば、メモリー属性とプロセッサ属性を索引付けし、データベース内の対応する列が索引付けされるようにすると、ユーザーは検索基準としてプロセッサまたはメモリー(あるいはその両方)を入力して、コンピュータのアイテム・カタログを検索できます。検索条件として索引付けされていない属性をエンド・ユーザーが入力しても、検索は実行されません。
セキュリティ
拡張可能フレックスフィールドのベース・データのセキュリティ・リソースは、通常は「_B」という接尾辞を持つ名前が付けられています。翻訳データのセキュリティ・リソースは、翻訳表のビューであり、通常は「_VL」という接尾辞を持つ名前が付けられています。
フレックスフィールドが翻訳可能なオプションをサポートしており、翻訳データのセキュリティ・リソースを持っている場合は、適切なデータ・セキュリティ・リソースのアクションを必ず作成します。
-
翻訳不可能なコンテキストに対してコンテキスト固有のアクションを作成する場合は、ベース・データのセキュリティ・リソースに追加します。
-
翻訳可能なコンテキストに対してコンテキスト固有のアクションを作成する場合は、翻訳データのセキュリティ・リソースに追加します。
デプロイメント
拡張可能フレックスフィールドは、「拡張可能フレックスフィールドの管理」タスクでのみデプロイできます。拡張可能フレックスフィールドはバックグラウンド・プロセスとしてオフラインで配置でき、配置の完了を待機しなくてもセッションでの作業を続行できます。複数の拡張可能フレックスフィールドをキューに格納して、バックグラウンド・プロセスとして配置できます。フレックスフィールドは、キューに配置された順に1つずつ配置されます。拡張可能フレックスフィールドに30を超えるカテゴリがある場合は、バックグラウンド・プロセスとして配置する必要があります。
バックグラウンド配置の取消コマンドを使用して、拡張可能フレックスフィールドを配置キューから削除できます。拡張可能フレックスフィールドがバックグラウンド・プロセスで配置される場合、そのオフライン・ステータスは、フレックスフィールドがバックグラウンド配置プロセス中であることを示します。バックグラウンド・デプロイメント・プロセスが完了すると、フレックスフィールドのオフライン・ステータスはクリアされ、そのデプロイメント・ステータスは更新されます。
ビジネス・インテリジェンスの拡張可能フレックスフィールド・セグメントの有効化の考慮事項
データベースに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管理者ガイドを参照してください。
<name>_と<name>_cの両方の属性が、他のいくつかのオプション属性とともに表示されます。<name>_属性には値が含まれます。<name>_c属性には、値の取得元の値セットのコードが含まれ、値ディメンションにリンクするために使用されます。両方の属性をインポートする必要があります。
拡張可能フレックスフィールド・カテゴリの管理の考慮事項
カテゴリは、フレックスフィールドのコンテキスト依存セグメントの数を、フレックスフィールド・セグメント用に予約されている列数を超えて増やすための手段です。
たとえば、「品目」拡張可能フレックスフィールドには、品目ごとに1つのカテゴリがあり、各カテゴリは、1つ以上のコンテキストを持つことができます。品目「ラップトップ」は「コンピュータ」カテゴリに属します。拡張可能フレックスフィールドは、付加フレックスフィールドのように列のみでなく、別々の拡張表にマップされるため、拡張可能フレックスフィールド表にある30の予約済列を使用して、各コンテキストに対して、最大30個のコンテキスト依存セグメントを定義できます。
「コンピュータ」カテゴリに「寸法」コンテキストを追加すると、30個のセグメントを使用できます。ただし、30個を超える属性を追加する必要がある場合は、コンテキストをもう1つ作成して、同じカテゴリに関連付けます。同じ「コンピュータ」カテゴリに「電子機器属性」コンテキストを追加し、さらに30個のセグメントを作成できます。さらにコンテキストを作成して、「コンピュータ」カテゴリに追加することもできます。こうすることで、ラップトップ・コンピュータ品目を必要な数の属性を使用して拡張できます。これはラップトップ・コンピュータがカテゴリにマップされており、そのカテゴリにコンテキストを追加し続けることができるためです。
セグメント用に予約された30列を持つ品目表の付加フレックスフィールドが保持できるコンテキストは、1つのみです。その1個のコンテキストのために列を構成したら、それ以上セグメントは作成できません。
事前定義済カテゴリと事前構成済カテゴリ
フレックスフィールド構造をどのように構成するかは、カテゴリをどのようにフレックスフィールドで定義するかによって変わります。1つのカテゴリを使用して拡張可能フレックスフィールドを事前構成する場合は、すべてのコンテキストとページをそのカテゴリに関連付けます。製品固有の拡張可能フレックスフィールドが複数カテゴリにより事前構成されている場合は、コンテキストとページをそれらのカテゴリに関連付けます。拡張可能フレックスフィールドに、複数のカテゴリを構成するためのユーザー・インタフェースが用意されている場合は、継承を使用して、1つのコンテキストを複数のカテゴリに関連付けます。
拡張可能フレックスフィールド用にカテゴリを作成および保守するためのアクティビティまたはタスクを提供している製品もあります。フレックスフィールド用のカテゴリを作成できるかどうかを判別するには、製品固有の情報を参照してください。
フレックスフィールドのカテゴリ階層を表示するには、フレックスフィールドの強調表示機能または「拡張可能フレックスフィールドの管理」タスクを使用し、フレックスフィールドを見つけて編集用に開きます。
カテゴリの無効化
拡張可能フレックスフィールドの構成時に、カテゴリを無効にできます。拡張可能フレックスフィールドの編集ページの「カテゴリ」表にある「使用可能」列には、どのカテゴリが有効であるかが示されます。
コンテキスト
類似する属性をコンテキストにグループ化します。グループは、リージョン内にまとめて表示されます。リージョンのヘッダーがコンテキスト値です。
フレックスフィールドにカテゴリ階層が存在する場合、その階層を利用して、製品カタログの類似品目など、似たようなエンティティに対してコンテキストを再利用できます。
次の図は、コンテキストを再利用するためにカテゴリ階層機能を使用した「Item Extended Attributes」フレックスフィールドを示しています。このフレックスフィールドの「電子機器とコンピュータ」カテゴリには、「コンプライアンスと証明書」、「電圧」、「原材料」のコンテキストが含まれます。「TVとビデオ」サブカテゴリおよび「コンピュータ製品」サブカテゴリでは、独自のコンテキストに加えて、「電子機器とコンピュータ」のコンテキストを継承します。「原材料」コンテキストは、「電子機器とコンピュータ」製品カテゴリと「資材、自動車、産業」製品カテゴリの両方に属しています。
次の表は、拡張可能フレックスフィールドのカテゴリ階層の例を示しています。すべての電子機器とコンピュータ品目の電圧情報を格納するには、「電圧」コンテキストを「電子機器とコンピュータ」カテゴリに関連付けます。これにより、「TVとビデオ」サブカテゴリと「コンピュータ」サブカテゴリの両方が、親カテゴリ「電子機器とコンピュータ」から「電圧」コンテキストを継承します。
| 表示名 | コード | 説明 |
|---|---|---|
|
電子機器とコンピュータ |
PROD_ELECTRONICS |
電子機器とコンピュータ |
|
PROD_TV_VIDEO |
テレビとビデオ |
|
PROD_COMPUTERS |
コンピュータ |
|
オフィス製品と消耗品 |
PROD_OFFICE_PRODUCTS_SUPPLIES |
オフィス製品と消耗品 |
|
工具、自動車、産業 |
PROD_TOOLS_AUTO_INDUSTRIAL |
工具、自動車、産業 |
|
スポーツとアウトドア |
PROD_SPORTS_OUTDOORS |
スポーツとアウトドア |
品目拡張属性フレックスフィールドの構成例
「Item Extended Attributes」フレックスフィールドは、「Item」ビジネス・オブジェクトの拡張に必要なセグメントを提供します。「拡張可能フレックスフィールドの管理」タスクで、「Electronics and Computers」カテゴリの品目のユーザー・インタフェースに「Technical Specifications」論理ページが含まれるように、製品のビジネス・オブジェクトを構成します。
この例では、このフレックスフィールドの構成により、属性が次のコンテキストにグループ化されます。
-
Materials and Substances
-
Compliance and Certification
-
Voltage
シナリオ
次のリストは、品目拡張属性フレックスフィールドのコンピュータ属性のサンプル・プランを示しています。この例では、「電子情報」ページは、親カテゴリ「電子機器及びコンピュータ」から継承されます。
-
ページ: 電子情報
-
コンテキスト: Compliance and Certification、単一行
-
ISO 14001(国際標準化機構による環境マネージメント・システムの規定)
-
ENERGY STAR(エネルギ効率化に向けたガイドライン)
-
ROHS(電子・電気機器における特定有害物質の使用制限)
-
-
コンテキスト: Voltage、単一行
-
最低電圧
-
最高電圧
-
電流タイプ
-
-
コンテキスト: Materials and Substances、複数行
-
資材
-
リサイクル品の含有
-
単位質量当たりのパーセント
-
-
-
ページ: Computer Information
-
コンテキスト: Processor Specifications、単一行
-
製造業者
-
CPUタイプ
-
プロセッサ・インタフェース
-
プロセッサ・クラス
-
プロセッサ速度
-
コア
-
-
次の表に、このシナリオにおける主な検討事項の概要を示します。
| 検討事項 | この例の場合 |
|---|---|
|
どの拡張可能フレックスフィールドがカテゴリ階層の構成に使用できるか |
「品目拡張属性」フレックスフィールド |
技術仕様の収集
電子機器とコンピュータの製品在庫ページには、技術仕様ページが必要です。家具の製品在庫ページには、家具の仕様ページと組立て方法のページが必要です。電子機器とコンピュータ・カテゴリと家具カテゴリの両方にある品目は、原材料を指定するための属性を共有しています。
次の図は、「Electronics and Computers」カテゴリのユーザー・インタフェースにある「Technical Specifications」論理ページを示しています。「Recovery and Recycling」、「Compliance and Certification」、「Operating Conditions」および「Materials and Substances」のコンテキストでの属性が含まれます。「Materials and Substances」コンテキストは複数行で構成されています。ユーザーは1つの製品の製造に必要なすべての原材料を選択できます。
分析
ユーザー・インタフェースでのコンテキストの表示方法を決定するには、論理ページを使用します。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」コンテキストを共有しています。
「品目」フレックスフィールドのセキュリティの構成
次の表は、「品目」フレックスフィールドのデータ・セキュリティ・ポリシーの例を示しています。
| データ・セキュリティ・リソース | ポリシー | ロール | 処理 | 条件 |
|---|---|---|---|---|
|
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 |
なし |
|
Compliance and Certification |
edit_trans_compliance_ctx |
なし |
|
Materials and Substances |
edit_trans_attrs |
なし |
この例では、誰でもコンテキストの属性を表示できますが、編集権限は次のように制限されています。
-
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という特定のコスト・センターを使用できないと組織が決定しました。組合せを検証するための相互検証ルールを定義できます。
-
このルールにより、会社の条件フィルタが評価されます。
-
会社がOperationsと等しい場合、このルールにより、コスト・センターの検証フィルタが評価されます。
-
コスト・センターがMarketingと等しい場合、このルールにより、組合せが作成されなくなります。
-
ルールに対して定義したエラー・メッセージは、試行された組合せがルールに違反していることをユーザーに通知するために表示されます。
このようなルールは、Marketingコスト・センターとOperations以外の会社の値の組合せの作成には影響しません。
ルールの複雑さ
パフォーマンスを最適化し、理解しやすくするには、1つの複雑なルールを使用するかわりに複数の単純な検証ルールを定義します。単純な検証ルールを使用すると、より具体的なエラー・メッセージを提供でき、その後の保守が簡単になります。
可能であれば、3つ以上のセグメントにまたがる検証を制御するルールは避けてください。複数のセグメントにわたる相互検証ルールを定義することは可能ですが、相互検証エラー・メッセージの解釈と、無効なキー・フレックスフィールドの組合せの訂正が難しくなります。
保守
一貫性のある検証を維持するために、相互検証ルールを更新するときに、既存のキー・フレックスフィールドをレビューしてください。現行の検証ルールに関係なく、既存のキー・フレックスフィールドの組合せが使用可能な場合はそれを使用できます。したがって、正確な検証を確実に実行するには、既存の組合せをレビューして、新しいルールの基準と一致しない組合せをすべて使用不可にする必要があります。
相互検証ルールによって有効ではなくなった既存の組合せをユーザーが使用できないようにするには、組合せページを使用して、それらを使用不可にします。
相互検証ルールの編集
相互検証ルールにより、勘定科目組合せの特定のセグメント値の組合せが禁止されます。「相互検証ルールの管理」タスクを使用して、既存のルールを編集することも、1回かぎりのルールを作成することもできます。
シナリオ
組織にCompanies 131 and 151という、これらの会社の勘定科目組合せを部門40と製品211に制限する相互検証ルールがあります。現在では、両方の会社の勘定科目組合せには、部門30が含まれる必要があります。相互検証ルールを編集するには、次のステップを実行します。
-
「設定および保守」作業領域で、次の項目に移動します。
-
オファリング: 財務
-
機能領域: 財務レポート体系
-
タスク: 相互検証ルールの管理
-
-
組織の勘定体系を選択して、Companies 131 and 151相互検証ルールを選択します。
次の図は、会社131および151の条件フィルタ詳細と検証フィルタ詳細が指定された相互検証ルールの編集ページのセクションを示しています。131または151に等しい会社値について条件が定義されて、検証で、部門値が40に等しく、製品値が211に等しいことが指定されます。
-
「検証フィルタ」アイコンをクリックします。
-
「フィールドの追加」をクリックし、「部門」セグメントを選択します。
-
デフォルトの演算子「等しい」を受け入れて、部門30を選択します。
次の図は、部門が40に等しい、部門が30に等しい、および製品が211に等しいという、3つの検証が指定された「検証フィルタ」ウィンドウを示しています。
-
「OK」をクリックします。
-
「保存」をクリックします。
次の図は、相互検証ルールの編集ページの更新された検証の詳細を示しています。検証で、30または40に等しい部門、および211に等しい製品が指定されます。
-
エラー・メッセージを更新するには、「一般会計のメッセージの管理」タスクを検索して使用します。相互検証ルールのエラー・メッセージ名を問い合せて、部門30が含まれるようにメッセージを編集します。
ビジネス・インテリジェンスに対するキー・フレックスフィールド・セグメントの有効化の考慮事項
データベースに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管理者ガイドを参照してください。
<name>_と<name>_cの両方の属性が、他のいくつかのオプション属性とともに表示されます。<name>_属性には値が含まれます。<name>_c属性には、値の取得元の値セットのコードが含まれ、値ディメンションにリンクするために使用されます。両方の属性をインポートする必要があります。
キー・フレックスフィールドの例
キー・フレックスフィールドは、費用勘定情報を取得できます。
シナリオ
各支出の詳細を入力する場合、ユーザーは支出の請求先勘定科目を指定します。
費用勘定の入力
経費を入力するためのユーザー・インタフェースを使用すると、ユーザーは、その経費の処理に必要なコスト・センターなどの詳細を識別する費用勘定を選択できます。
分析
費用勘定フィールドは、勘定科目の組合せの外部キー参照です(EXPENSE_LINES.EXPENSE_ACCOUNT = ACCOUNT.COMBINATION)。
勘定科目と従業員を入力するための勘定科目組合せ表
この勘定科目組合せ表は、費用勘定などの勘定科目情報の入力をサポートします。
次の図は、ユーザーにより指定された勘定科目の勘定科目組合せ表の参照元を表しています。勘定科目組合せIDレコードには、キー・フレックスフィールドの構成に基づいて費用勘定のまとめに使用される、キー・フレックスフィールド・セグメントの情報が格納されます。
キー・フレックスフィールドの保守ページである組合せページは、組合せ表の行を管理するためのものです。この例では、組合せの管理とは、キー・フレックスフィールド・メタデータ・ルールに従って口座番号を追加または編集することです。
次の図は、フレックスフィールドの構成と勘定科目組合せ表に反映された費用勘定例で使用される勘定科目組合せの詳細を示しています。
動的組合せ作成が使用可能ではない場合、ユーザーは支出明細を入力ときに、ACCOUNTS(組合せ)表にすでに存在する勘定科目のみ選択できます。存在しない勘定科目が必要な場合には、組合せ表に勘定科目を追加できる、適切なアプリケーション管理者に問い合せる必要があります。
動的組合せ作成が有効な場合、ユーザーは支出明細を入力するときに、既存の勘定科目を選択するか、またはACCOUNTS(組合せ)表にその場で動的に作成される新しい勘定科目を入力できます。新しい組合せが作成されると、同じユーザーはその組合せを支出明細で参照できるようになります。
従業員情報を管理する場合、ユーザーは、その従業員が属するコスト・センターを指定します。このコスト・センター・フィールドは、会計キー・フレックスフィールドにある1つのラベル付きセグメントに対応し、そのセグメントに対して許可される値セットなどのメタデータが定義されています。
次の図では、勘定科目へのコスト・センターID参照を指定するかわりに、コスト・センター・セグメントのみが使用され、値は従業員表に直接格納されています。
