機械翻訳について

価格設定アルゴリズム・ステップのデータ・セット

データセットを使用して、ステップで処理するレコードのセットをフィルタします。 すべてのステップでデータ・セットが使用され、すべてのデータ・セットに同じ属性があります。 一部のステップには、複数のデータ・セットが含まれます。

Order Managementのユーザーが手動で価格を調整する例を見てみましょう。 Order Managementは、調整に従って品目の価格を再設定するリクエストをOracle Pricingに送信し、検証して価格設定の範囲内であることを確認します。 たとえば、価格表で許可される調整を超えないようにします。

Order Managementのユーザーが手動で価格を調整する例。

ノート

  • 販売オーダーには1つの販売オーダー明細が含まれます。

  • 価格設定は、PriceRequestサービス・データ・オブジェクトの販売オーダーを表します。

  • PriceSalesTransaction価格設定プロセスは、HeaderIdなどの属性でデータを送信します。

  • データはフラットです。 階層的ではありません。 ヘッダーと明細は同じレベルです。 つまり、参照に階層を含めることなく、明細を参照できます。

PriceRequestサービス・データ・オブジェクトは料金を追加します。

PriceRequestサービス・データ・オブジェクトは料金を追加します。

ノート

  • 販売オーダーには1つのラインのみが含まれ、ラインには1つの課金のみが含まれます。

  • PriceRequestサービス・データ・オブジェクトの各料金には、1つの料金コンポーネントが含まれます。

  • 価格設定アルゴリズムの一部のステップでは、ExtendedAmountに対して300など、手数料および手数料コンポーネントの値がすでに実行および生成されているとします。

データ・セットの構造

次に、事前定義済の商品およびサービスに対する手動調整の適用価格設定アルゴリズムの手動調整の検証ステップからのデータ・セットの一部を示します。

事前定義済の商品およびサービスに対する手動調整の適用価格設定アルゴリズムの手動調整の検証ステップの一部のデータ・セット。

ノート

  1. プライマリ・データ・セットには、ステップの目標を満たすデータが格納されます。 たとえば、ステップの目標が手数料を計算する場合、ChargeComponentをプライマリとして設定します。

    通常、プライマリ・データ・セットは、データ・セット領域の最初のデータ・セットです。

  2. 変数パスを使用して、サービス・データ・オブジェクトを指し示します。 たとえば、PriceRequest.Headerは、PriceRequestサービス・データ・オブジェクトのヘッダー・エンティティを参照します。

  3. カーディナリティを使用して、プライマリ・データ・セットに追加する非プライマリ・データ・セットのレコード数を指定します。 たとえば、ヘッダー・データ・セットのZero or oneは、ChargeComponentごとに1つ以上のヘッダーが存在しないことを意味します。

  4. データ・セット結合を使用して、データ・セット領域の別のデータ・セットに追加するデータ・セットを結合します。 次の書式を使用します

    [implicit reference: {target.targetAttribute}]

    説明

    • implicit referenceは、現在編集しているデータ・セットのエンティティの属性の名前です。

    • targetは、結合するデータ・セットの名前です。

    • target attributeは、ターゲット・データ・セットが参照するエンティティの属性の名前です。

    たとえば、ヘッダー・データ・セットを明細データ・セットに結合します。

    [HeaderId: {Line.HeaderId}]

    説明

    • HeaderId: は、ヘッダー・エンティティの属性の名前です。 オーダー・ヘッダーを識別します。 コロンの前に含める属性は、現在編集しているデータ・セットの変数パスで指定するエンティティへの暗黙的な参照です。

    • Lineは、結合するデータ・セットの名前です。

    • .HeaderIdは、Lineエンティティの属性です。 明細データ・セットは明細エンティティを参照します。 ドット( .)の後に含める属性は、ターゲット・データ・セットのエンティティ内の属性への明示的な参照です。

      各注文ラインは販売オーダーの一部です。 LineエンティティにはHeaderId属性が含まれているため、データ・モデルはその行が属する場所を認識します。

データ・セットをサービス・データ・オブジェクトにマップする方法を次に示します。

データ・セットをサービス・データ・オブジェクトにマップする方法。

ノート

  1. 最初にプライマリ・データ・セットを追加します。 たとえば、PriceRequest.ChargeComponentは、PriceRequestサービス・データ・オブジェクトのChargeComponentエンティティを参照します。

  2. エンティティごとに個別のデータ・セットを追加します。 たとえば、ヘッダー・エンティティを参照するには、データ・セットを追加し、ヘッダーに名前を付け、変数パスをPriceRequest.Headerに設定します。

  3. データ・セットを結合する属性を追加します。

別のデータ・セットを追加します。 たとえば、手数料データ・セットを追加する方法を次に示します。

手数料データ・セットの追加方法

ノート

  • データ・セットの追加は、アルゴリズムがステップを完了するために必要なサービス・データ・オブジェクトのすべてのエンティティおよび属性を移入する必要があるデータ・セットの追加が終了するまで続けます。

    たとえば、ステップで使用する条件とアクションの属性を必ず移入します。

  • データ・セット領域の上に移動および下に移動を使用して、依存関係に従ってデータ・セットを順序付けします。 このアルゴリズムは、データ・セット領域に表示される順序でデータ・セットを処理します。

    たとえば、アルゴリズムは、オーダー明細に適用する前に手数料を計算する必要があります。 そのため、手数料データ・セットが明細データ・セットより上になるようにデータ・セットを整理します。

ヒント: アプリケーションを使用して、Microsoft VisioやPowerpointなどのサービス・データ・オブジェクトのダイアグラムを作成します。 データ・セットを追加する場合は、図を参照してください。

その他の結合の例

要件

データ・セット結合

カーディナリティ

1つのオーダー明細を1つのオーダー・ヘッダーに結合します。

1つの属性を照合します。

[HeaderId: {Line. HeaderId}]

オーダー明細は1つの販売オーダーにのみ存在でき、販売オーダーには1つのヘッダーのみが含まれるため、使用してください。

  • 1つ

  • 0または1つ

手数料に手動価格調整を結合します。

複数の属性を照合しています。

1つのオーダーに複数の料金を含めることができます。 使用する正しい手数料を結合で識別できるように、手数料のすべての属性を指定する必要があります。

[ParentEntityId: {Charge.ParentEntityId}, ParentEntityCode: {Charge.ParentEntityCode}, RollupFlag: {Charge.RollupFlag}, ChargeAppliesTo: 'PRICE']

1つの手数料に対して複数の手動調整が存在できるため、カーディナリティを多に設定します。

手動価格調整を手数料と照合する別の方法。

Groovy式を使用して、ChargeDefinitionIdまたはChargeDefinitionCodeに一致します。

ERROR'!=Mpa.MessageTypeCode &&

(Charge.ChargeDefinitionCode==Mpa.ChargeDefinitionCode || Charge.ChargeDefinitionId==Mpa.ChargeDefinitionId) && Charge.PricePeriodicityCode==Mpa.PricePeriodicityCode && Charge.MessageTypeCode!='ERROR' &&

Charge.ParentEntityId==Mpa.ChargeParentEntityId && Charge.RollupFlag==Mpa.ChargeRollupFlag

複数

新規手数料コンポーネントを作成します。

1つの属性を照合します。

[ChargeId: {Charge.ChargeId}]

ほとんどのサービス・データ・オブジェクトには、すでに手数料および手数料コンポーネントが含まれています。 新しいエンティティまたは手数料コンポーネントを作成する場合は、カーディナリティを多に設定して、結合で正しいものを識別できるようにします。

別のデータ・セットの例

次に、一般的なデータ・セットがいくつか含まれるステップを示します。

一般的なデータ・セットを含むステップ

ノート

  1. 名前

    説明

    配送費用を作成

    データ・セットを説明するテキスト。

    名前がアルゴリズム内で一意であることを確認してください。

    キャメル・ケースを使用し、最初の文字を大文字にします。 たとえば、MyDataSetです。

  2. 変数パス。 データ・セットのソースを指定する式。

    変数を参照する式の作成に使用する形式を次に示します。

    • AlgorithmVariableName.Attribute

    説明

    • AlgorithmVariableNameは、アルゴリズム変数の名前を識別します。

    • Attributeは、サービス・データ・オブジェクトの属性を識別します。

    この例でヘッダー・データ・セットが使用する式を次に示します。

    • PriceRequest.Header

      この式は、このアルゴリズムのPriceRequest変数およびサービス・データ・オブジェクトのHeader属性を使用することを指定します。

    関数を参照する式の作成に使用する形式を次に示します。

    • algorithmFunctionName(argument1.argument2.argument3 . . .)

    たとえば:

    • checkAllowedCurrency(strategyId.currencyCode)

    この式は、checkAllowedCurrency関数のstrategyId引数およびcurrencyCode引数を使用することを指定します。

  3. プライマリ

    • チェック・マークが含まれます。 この行をプライマリ・データ・セットとして使用します。 各アルゴリズム・ステップでは、プライマリ・データ・セットに含まれるレコードのセットが処理されます。 各ステップに設定できるプライマリ・データ・セットは1つのみです。

    • チェック・マークは含まれません。 この行を非プライマリ・データ・セットとして使用します。 非プライマリ・データ・セットによって、プライマリ・データ・セットが処理するレコードがフィルタ処理されます。

  4. Cardinality. プライマリ・データ・セットと非プライマリ・データ・セット間のカーディナリティを指定します。

    カーディナリティ

    説明

    1つ

    1つのプライマリ・データ・セットから1つの非プライマリ・データ・セット。 内部結合を確立します。

    ゼロまたは1

    1つのプライマリ・データ・セットを1つの非プライマリ・データ・セットにゼロまたは1つにします。 外部結合を確立します。

    複数

    1つの非プライマリ・データ・セットにゼロまたは多数のプライマリ・データ・セットがあります。

  5. データ・セット結合。 ステップで非プライマリ・データ・セットのフィルタに使用する結合を設定します。

    たとえば、明細データ・セットをフィルタするデータ・セット結合を次に示します。

    • [LineId:{Candidate.ParentEntityId}]

    ノート

    • ブール値に評価されるGroovy式を使用します。

    • 非プライマリ・データ・セットの属性をクオリファイアなしで使用します。

    • データ・セット結合を使用する場合、最適化された索引検索は作成できないため、パフォーマンスが低下する可能性があります。

    • 変数パスで関数を参照する場合、データ・セット結合は使用できません。

    式がリテラル文字列の場合は、データ・セット結合を作成します。 たとえば:

    • [ActiveFlag: 'Y', HeaderId:{Line.HeaderId}]

  6. ソート・キー 1つ以上の列に従って、データ・セットのレコードを昇順または降順にソートします。 使用するフォーマットは次のとおりです。

    • AttributeName modifier, AttributeName2 modifierなど

    説明

    • カンマによってソートの各レベルが区切られます。

    • 修飾子は(DESC|ASC) (NULLS FIRST|NULLS LAST)です

    このコードを考えます。

    3つのレベルのソートを行います。

    1. データ・セット・レコードをNetPriceに従って降順にソートします。 NetPriceのnull値を含むレコードが最後に配置されます。

    2. NetPrice内のレコードを、販売オーダー・ヘッダーの割引属性の値に従って昇順にソートします。 割引にnull値を含むレコードが最初に配置されます。

    3. NetPrice属性の値に従って、割引内のレコードを昇順にソートします。 NetPriceのnull値を含むレコードを最初に配置します。

    モディファイアを定義しない場合、価格設定では昇順が使用されます。

  7. 候補者データ・セット。 このアルゴリズム・ステップで処理する候補となるレコードを識別します。 価格設定には、ほとんどのデータ・セットで候補者をプライマリとして使用するように事前定義されています。

    たとえば、Order Managementユーザーが出荷手数料をオーダー明細xに追加した場合、このステップでは、価格設定戦略や価格設定セグメントなど、アルゴリズムで考慮される他のファクタに応じて、出荷手数料をオーダー明細xに適用するかどうかが考慮されます。

    使用できる候補者データ・セットの属性を次に示します。

    属性

    説明

    変数パス

    候補者はCandidateInt.ShippingChargeCandidate変数パスを使用します。

    • CandidateInt. この価格設定アルゴリズムの変数。 品目が配送料の候補かどうかを決定する値が格納されます。

    • ShippingChargeCandidate. サービス・データ・オブジェクトの属性。 品目が配送料の候補かどうかを指定します。

    プライマリ

    通常、候補者は、このステップが処理するフィルタされていないレコードのセットを識別するため、プライマリにはチェック・マークが含まれます。

  8. ServiceParamデータセット。 価格設定には、ServiceParamを使用してサービス・データ・オブジェクトを識別し、このステップで使用するサービス・データ・オブジェクトの属性を識別するために事前定義されています。

    この例では、ServiceParamが使用する値を次に示します。

    属性

    説明

    変数パス

    ServiceParamは通常、PriceRequest.PricingServiceParameter変数パスを使用します。

    • PriceRequest. この価格設定アルゴリズムの変数。 この変数は、Sales webサービスを参照します。

    • PricingServiceParameter. 販売webサービスの属性。

    プライマリ

    候補は通常プライマリであり、プライマリ・データ・セットをフィルタするためにServiceParamなどの非プライマリ・データ・セットを参照します。 したがって、プライマリには非プライマリ・データ・セットのチェック・マークは含まれません。

    カーディナリティ

    ゼロまたは1は、各候補者に0または1つのServiceParamがあることを指定します。

  9. 明細データ・セット。 価格設定には、プライマリ・データ・セットのレコードをフィルタするときにこのステップで検証するオーダー明細の属性を識別するために、明細を使用する事前定義されています。

    この例では、Lineデータ・セットが使用する属性を示します。

    属性

    説明

    変数パス

    行は通常、PriceRequest.Line変数パスを使用します。

    • PriceRequest. この価格設定アルゴリズムの変数。 この変数は、Salesサービスを参照します。

    • Line. サービス・データ・オブジェクトの属性。 オーダー明細を識別します。

    カーディナリティ

    ゼロまたは1は、各候補者にゼロまたは1つの明細があることを指定します。

    この例では、各候補者は単一のオーダー明細のみを参照できるため、カーディナリティは1対1です。

    このカーディナリティは、オーダー明細が参照できるヘッダーは1つのみであるため、ヘッダーにも適用されます。

    データ・セット結合

    通常、行は[LineId:{Candidate.ParentEntityId}]結合を使用します。

    • LineId. オーダー明細を識別します。 たとえば、 101

    • 候補者 このステップの候補者データ・セットを参照します。

    • ParentEntityId.

  10. ヘッダー・データ・セット。 価格設定には、ヘッダーを使用して、プライマリ・レコード・セットのレコードをフィルタするときにこのステップで検証するオーダー・ヘッダーの属性を識別するための事前定義されています。

    この例のヘッダー・データ・セットで使用される属性は次のとおりです。

    属性

    説明

    変数パス

    通常、ヘッダーはPriceRequest.Header変数パスを使用します。

    • PriceRequest. この価格設定アルゴリズムの変数。 この変数は、Salesサービスを参照します。

    • ヘッダー サービス・データ・オブジェクトの属性。 オーダー・ヘッダーを識別します。

    データ・セット結合

    通常、ヘッダーは[HeaderId: {Line.HeaderId}]結合を使用します。

    • HeaderId. ヘッダーを識別する属性。 たとえば、 101

    • Line. このステップの明細データ・セットを参照します。

    • HeaderId.

  11. 手数料データ・セット。 価格設定には、オーダー明細が参照する手数料を識別するための手数料の使用が事前定義されています。

    この例では、手数料データ・セットが使用する属性を示します。

    属性

    説明

    変数パス

    通常、料金はPriceRequest.Charge変数パスを使用します。

    • PriceRequest. この価格設定アルゴリズムの変数。 この変数は、Salesサービスを参照します。

    • 手数料 サービス・データ・オブジェクトの属性。 1つ以上の配送料を識別します。

    カーディナリティ

    手数料は、1つの手数料に対して多数の候補者が存在することを指定します。

  12. ローカル変数。 条件でのみ使用する変数を定義します。

  13. デフォルトのアクション。 (図には示されていません。 「アルゴリズムの編集」ページのローカル変数の下にあります。) Groovyを使用して、フローが設定した他の条件を満たしていない場合に実行する条件を作成します。