機械翻訳について

キー・フレックスフィールドの概要

キー・フレックスフィールドは、部品番号、ジョブ・コード、勘定科目コードなどのキーを取得する方法を提供します。 キー・フレックスフィールドは1つ以上のセグメントで構成され、各セグメントに意味を持たせることができます。

たとえば、部品番号10-PEN-BLA-450は、部門番号10(事務用品)が販売する、サプライヤ番号450から仕入れた黒いペンに対応しています。 アプリケーションはこの部品について、内部的に一意の番号として13452を使用していますが、ユーザーには常に部品番号10-PEN-BLA-450が表示されます。

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

  • アーキテクチャ

  • セグメントとセグメント・ラベル

  • セグメントの識別方法

  • Override、VisibleおよびRenderedプロパティの動作

  • 構成インスタンスとセグメント・インスタンス

  • 組合せ

  • 動的組合せの作成

  • セキュリティ

キー・フレックスフィールドはオプションではありません。 アプリケーションを確実に正しく動作させるには、キー・フレックスフィールドを構成する必要があります。 キー・フレックスフィールド定義の構成と保守には、「キー・フレックスフィールドの管理」タスクを使用します。 事前定義されたキー・フレックスフィールドのリストを取得するには、「設定および保守」作業領域の「キー・フレックスフィールドの管理」タスクを使用します。 特定のキー・フレックスフィールドの詳細は、関連するビジネス・コンポーネントが実装されている製品のヘルプを参照してください。

アーキテクチャ

フレックスフィールド・メタデータは、フレックスフィールド・メタデータ表に格納されます。 キー・フレックスフィールドを構成する場合は、次のような要素を対象としたキー・フレックスフィールドのメタデータを定義します。

  • 構成内のセグメント

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

  • 各セグメントの値セット

フレックスフィールド・メタデータに基づいて、実際の部品番号がセグメント値の組合せとして取得され、組合せ表に格納されます。 組合せ表には、フレックスフィールドのすべてのセグメント列と、一意のID列、および構成インスタンス番号列が含まれます。 構成インスタンス番号列により、セグメント列の複数の配列が区別されます。 たとえば、複数のセグメントで構成される部品番号をキー・フレックスフィールドで表すことができます。 部品番号キー・フレックスフィールドには、対応する組合せ表があります。 この表で、フレックスフィールドは、コードのセグメントごとに列が割り当てられた完全なコードのリストを、コードに対応する一意のIDと構成インスタンス番号とともに保管します。 ユーザーが部品カタログで新しい部品番号を定義したり、既存の部品番号を保守したりするときには、この組合せ表にある行を直接保守します。

外部キー表に含まれるビジネス・エンティティは、組合せ表に含まれるそれとは異なります。 たとえば、外部キー表のビジネス・エンティティは、注文用の部品に対する外部キー参照を含む注文書明細や請求書明細です。 キー・フレックスフィールドで表される特定のエンティティを参照できる外部キー表の数に制限はありません。

セグメントとセグメント・ラベル

キー・フレックスフィールドにはセグメントが含まれています。 各セグメントには次の詳細が含まれます。

  • プロンプト

  • 短いプロンプト

  • 表示幅

  • キー・フレックスフィールド構成内でのセグメントの順位

  • 範囲のタイプ

  • セグメントにより格納される属性の列名

  • デフォルトの値セット

  • セグメントのラベル

セグメントの識別方法

セグメント・ラベルを使用して、キー・フレックスフィールド内のセグメントを識別および制御できます。 セグメント・ラベルはセグメントのタグとして機能し、これらのラベルはアプリケーション開発者によって定義されます。 たとえば会計フレックスフィールドで、どのセグメントに残高情報が入っていて、どのセグメントに通常の勘定科目情報が入っているかを確認する必要があるとします。 セグメント・ラベルから通常の勘定科目情報が含まれているセグメントを識別できます。 会計フレックスフィールドを定義するときに、各セグメントに対しセグメント・ラベルを指定する必要があります。 一部のセグメントは一意でなければならず、それぞれの構成内で複数のセグメントに適用することはできません。 その他のラベルは必須であり、それぞれの構成で少なくとも1つのセグメントに適用される必要があります。

また、セグメント・ラベルを使用してセグメントを検索できます。たとえば「コスト・センター」ラベルでは、キー・フレックスフィールド全体でコスト・センターの値を保存しているすべてのセグメントを検索できます。 キー・フレックスフィールド内のセグメントを識別および制御するため、フレックスフィールドXML内でいくつかのセグメント・プロパティをリテラル値またはEL式を使用して設定できます。 次のプロパティは、フレックスフィールドの<flexfieldLabeledSegmentHint>要素の属性です。 これらのプロパティ設定は、指定したセグメント・ラベルが割り当てられているすべてのセグメントに適用されます。

プロパティ

摘要

SegmentLabel

構成中のセグメントのセグメント・ラベルを示します。

レンダリング済

セグメントがページ上で使用可能かどうかを示します。 値をTrueFalseまたはEL式に設定できます

必須

ユーザーが保存する前に、コンポーネントのデータを入力する必要があるかどうかを示します。 値をTrueFalseまたはEL式に設定できます。

読取り専用

ユーザーがセグメントを変更できるかどうかを示します。 値をTrueFalseまたはEL式に設定できます。

Visible

セグメントがページに表示されるかどうかを示します。 値をTrueFalseまたはEL式に設定できます。

ラベル

セグメントの表示テキストを示します。

ShortDesc

ユーザーがコンポーネント上にカーソルを置いたときに表示されるテキストを示します。

テキスト・コントロールの幅を表示される文字数で示します。 列の数はブラウザのデフォルトのフォント・サイズに基づいて計算されます。 このプロパティは、リテラル値またはEL式で設定できます。

Override

親コンポーネント内の特定の子コンポーネントが表示するかどうかを示します。 値をTrueFalseまたはEL式に設定できます。 このプロパティをvisibleプロパティとともに使用すると、親コンポーネントのvisibleプロパティがオーバーライドされます。

Override、VisibleおよびRenderedプロパティの動作

次に、いくつかのシナリオを示します。

  • overrideプロパティのないコード・スニペットを次に示します。

    <fnd:keyFlexfieldPartial value="#{bindings.Kff1PaInstanceIterator}" id="kfp1" visible="false">
    		<fnd:flexfieldLabeledSegmentHint
    			segmentLabel="SEGMENT_LABEL_R1" visible="true"/>
    </fnd:keyFlexfieldPartial>

    この場合、子コンポーネントのvisibleプロパティはtrueに設定されており、親コンポーネントのvisibleプロパティはfalseに設定されています。 子コンポーネントのvisibleプロパティが親コンポーネントのvisibleプロパティと組み合せて使用されているため、SEGMENT_LABEL_R1を持つセグメントは表示されません。

  • overrideプロパティを使用したコード・スニペットを次に示します。

    <fnd:keyFlexfieldPartial value="#{bindings.Kff1PaInstanceIterator}" id="kfp1" visible="false">
    		<fnd:flexfieldLabeledSegmentHint 
             		segmentLabel="SEGMENT_LABEL_R1" visible="true" override="true"/>
    </fnd:keyFlexfieldPartial>

    この場合も、子コンポーネントのvisibleプロパティがtrueに設定されており、親コンポーネントのvisibleプロパティはfalseに設定されています。 ただし、子コンポーネントのoverrideプロパティをtrueに設定しています。 子コンポーネントのvisibleプロパティが親コンポーネントのvisibleプロパティをオーバーライドするため、SEGMENT_LABEL_R1を持つセグメントが表示されます。

renderedプロパティをoverrideプロパティとともに使用しないでください。フレックスフィールド・レベルでrenderedプロパティをfalseに設定したときに、Oracle ADFモジュールでセグメント・レベルのrenderedプロパティが無視されるためです。 たとえば、次のコード・スニペットについて考えます。

<fnd:keyFlexfieldPartial value="#{bindings.Kff1PaInstanceIterator}" id="kfp1" rendered="false">
		<fnd:flexfieldLabeledSegmentHint 
        			segmentLabel="SEGMENT_LABEL_R1" rendered="true" override="true"/>
</fnd:keyFlexfieldPartial>

セグメント・レベルでrenderedプロパティをtrueに設定しても、このプロパティは無視されます。 これは、フレックスフィールド・レベルでrenderedプロパティがfalseに設定されているためです。 そのため、renderedプロパティではなく、visibleプロパティをoverrideプロパティとともに使用するようにください。

構成インスタンスとセグメント・インスタンス

キー・フレックスフィールド構成の定義には、セグメントの数と順序が含まれます。

一部のアプリケーションでは、同じフレックスフィールドであっても、ユーザーごとにセグメント構成の表示方法を変更する場合があります。 複数の構成をサポートするように登録すると、1つのキー・フレックスフィールドが複数の構成を持つことができます。

フレックスフィールドは、ユーザーが入力した別のフィールドの値や、ユーザーのロールなど、アプリケーション・データのデータ条件に基づき、それぞれのユーザーに合わせて表示するフィールドを変更できます。 たとえば、カスタマ・サービスへの問合せで使用される正しい形式の住所は、ロケールによって異なります。 「住所」キー・フレックスフィールドは、ユーザーのロールや入力した値など、アプリケーション・データの場所条件に基づいて、それぞれのユーザーに合わせて表示するセグメントやプロンプトを変更できます。

各構成は1つ以上のセグメントを持つことができます。 したがって、セグメントは構成の子と言えます。 コスト・センターなど、特定のセグメントを2つの異なる構成に格納する必要がある場合は、それぞれの構成で個別にセグメントを定義する必要があります。 各構成は、1つ以上の構成インスタンスを持つことができます。 構成の各インスタンスでは、同じ数と順序のセグメントが共有されますが、セグメントの検証に使用される値または値セットは異なります。

1つのキー・フレックスフィールド構成の複数の構成を定義できます。 これらの構成インスタンスのセグメント構成と順序は同じです。 大きな違いは各セグメントの検証方法です。 構成インスタンスは、キー・フレックスフィールドごと、およびキー・フレックスフィールド構成インスタンスごとに定義します。

キー・フレックスフィールドの構成インスタンスのセグメントは、セグメント・インスタンスです。 セグメント・インスタンスは、特定の値セットが割り当てられているセグメントです。 キー・フレックスフィールドがツリー構成を使用して登録されている場合、セグメント・インスタンスに対してツリー・コードを指定できます。

組合せ

組合せは、完全なコード、またはコードを構成するセグメント値の組合せであり、オブジェクトを一意に識別します。

たとえば、PAD-YEL-11x14や01-COM-876-7BG-LTNのような各部品番号は、1つの組合せです。 これらの組合せでは、ハイフンがセグメント・セパレータです。 10個の部品がある場合は、10個の組合せが定義されます。 有効な組合せとは、現在アクティブであるため使用可能な既存の組合せまたは新しい組合せであり、相互検証およびセキュリティのルールに違反していないものです。 組合せはのセグメントは、その組合せで使用されるフレックスフィールド構成に応じて異なります。 どの組合せも、特定のフレックスフィールド構成1つのみに関連付けられます。

多くのアプリケーションは、エンティティの名前またはキー・フレックスフィールド自体を使用して、キー・フレックスフィールドの組合せを参照します。 たとえば、「資産」は「資産」キー・フレックスフィールドを使用し、その組合せの1つを「資産」キーまたは「資産」キー・フレックスフィールドとして参照します。 別の例として、Oracle General Ledgerは、「会計」フレックスフィールドの組合せを、「勘定科目」または「GL勘定科目」として参照します。

各キー・フレックスフィールドには、組合せ表と呼ばれる1つの対応表があります。この表に、フレックスフィールドは、コードのセグメントごとに列が割り当てられた完全なコードのリストを、そのコードの対応する一意のID番号(勘定科目組合せID)とともに格納します。 アプリケーションのその他の表には、そのコードの一意のIDのみを格納する列があります。 たとえば、PAD-YEL-11x14のような部品番号コードがあるとします。 「部品」組合せ表には、このコードがID「57494」とともに格納されています。 アプリケーションで部品の注文を受ける場合、部品の注文を格納する「注文」表がある可能性があります。 この「注文」表には、完全なコードPAD-YEL-11x14に対する複数の列ではなく、部品ID「57494」を格納する1つの列を含めます。 通常、キー・フレックスフィールドは1つの組合せページで保守されます。このページでは、キー・フレックスフィールドが、アプリケーション内のエンティティを表しています。 部品番号などの個々の組合せは、組合せページで保守します。

動的組合せの作成

動的組合せ作成では、組合せページ以外のページから、新しい有効な組合せが組合せ表に挿入されます。 次の表に、動的組合せ作成を有効にできるレベルをリストします。

動的組合せ作成のレベル

制御担当者

フレックスフィールド

アプリケーション開発者

キー・フレックスフィールドの使用方法ごとまたは参照ごと

アプリケーション開発者

構成インスタンス

管理者および実装コンサルタント

その他

管理者および実装コンサルタント

キー・フレックスフィールド、またはキー・フレックスフィールドの特定の使用方法や参照で動的組合せ作成が許可されていない場合、構成インスタンスごとに動的組合せ作成を有効にするかどうかを制御できます。 有効にした場合、ユーザーは外部キー・ページからフレックスフィールド・ウィンドウを使用して、セグメント値の新しい組合せを入力できます。 たとえば、トランザクションを入力するときに、GLユーザーは、まだ存在していない勘定科目に対して新しい費用勘定科目の組合せを入力できます。 アプリケーションは、内部的に組合せ表に新しい組合せを挿入して、新しい勘定科目を作成します。 新しい組合せが既存の相互検証ルールを満たすとすれば、フレックスフィールドは組合せ表が外部キー・ページの基礎表でないとしても、その新しい組合せを組合せ表に挿入します。