ルールまたはサービス・マッピングの変更時のランタイム動作の考慮
アプリケーションのパフォーマンスを向上させます。 価格設定データをリフレッシュして、オブジェクトの初期化に必要な回数を減らし、データベースへのラウンドトリップを最小限に抑えます。
リフレッシュできるデータは次のとおりです。
データ |
説明 |
---|---|
価格設定ルール |
価格設定問合せのルールとエンティティを使用して、出荷手数料、割引、マージン、税金など、品目の価格を計算します。 価格設定ルールでリフレッシュできるオブジェクトは、次のとおりです。
リフレッシュできるその他のデータを次に示します。
更新19C以降、価格設定ルールをリフレッシュするための価格設定が事前定義されていません。 Oracle Applicationには、価格設定ルールに加えた変更がすぐに含まれます。 アプリケーションの例として、Order Management、Supply Chain Financial Orchestration、Subscription Managementなどがあります。 |
価格設定アルゴリズム |
アルゴリズム・メタデータをリフレッシュして、データベースからの読取りおよび解析を複数回行わないようにします。 |
サービス・マッピング |
サービス・マッピングをリフレッシュしてパフォーマンスを最適化します。 |
価格設定ルールの変更時の処理
例について考えてみます。
-
ユーザー1とユーザー2は、それぞれOrder Management作業領域を使用するオーダー入力スペシャリストです。
-
管理者は価格設定管理者で、価格設定管理作業領域を使用します。
リフレッシュなしの動作
価格設定管理者が標準デスクトップを単価$300で設定するとします。
ステップ |
説明 |
リフレッシュ使用可能の単価 |
リフレッシュ使用不可の単価 |
---|---|---|---|
1 |
ユーザー1は、Standard Desktopをオーダー明細に追加します。 |
$300 |
$300 |
2 |
ユーザー2は、標準デスクトップをオーダー明細に追加します。 |
$300 |
$300 |
3 |
管理者は、Standard Desktopの価格を$399に更新します。 |
該当なし |
該当なし |
4 |
ユーザー1はサイン・アウトし、サイン・インし、新しい販売オーダーを作成し、次にStandard Desktopをオーダー明細に追加します。 |
$300 |
$399 |
5 |
ユーザー2はサインアウトし、サイン・インし、新しい販売オーダーを作成し、次にStandard Desktopをオーダー明細に追加します。 |
$300 |
$399 |
リフレッシュ時の動作
Standard Desktopを単価$300で設定し、データを60分ごとにリフレッシュし、Order Managementユーザーがサインインするまでに60分待つとします。
ステップ |
説明 |
リフレッシュ使用可能の単価 |
リフレッシュ使用不可の単価 |
---|---|---|---|
1 |
ユーザー1は、Standard Desktopをオーダー明細に追加します。 |
$300 |
$300 |
2 |
ユーザー2は、標準デスクトップをオーダー明細に追加します。 |
$300 |
$300 |
3 |
管理者は、Standard Desktopの価格を$399に更新します。 |
該当なし |
該当なし |
4 |
ユーザー1はサインアウトし、「待機60分」はサイン・インし、新しい販売オーダーを作成し、Standard Desktopをオーダー明細に追加します。 |
$399 |
$399 |
5 |
ユーザー2はサイン・アウトし、「待機60分」はサイン・インし、新しい販売オーダーを作成し、Standard Desktopをオーダー明細に追加します。 |
$399 |
$399 |
リフレッシュなしの2つの手数料での動作
Standard Desktopを$300の手数料1と$200の手数料2で設定するとします。
ステップ |
説明 |
リフレッシュ使用可能の単価 |
リフレッシュ使用不可の単価 |
---|---|---|---|
1 |
ユーザー1は、Standard Desktopをオーダー明細に追加します。 |
手数料1は$300と等しい |
手数料1は$300と等しい |
2 |
ユーザー2は、標準デスクトップをオーダー明細に追加します。 |
手数料1は$300と等しい |
手数料1は$300と等しい |
3 |
管理者は、200ドル分の課金をStandard Desktopに追加します。 |
該当なし |
該当なし |
4 |
ユーザー1はサインアウトし、サイン・インし、新規販売オーダーを作成し、販売オーダー明細にStandard Desktopを追加します。 |
手数料1は$300と等しい |
手数料1は$300と等しい 手数料2は$200です |
5 |
ユーザー2はサインアウトし、サイン・インし、新しい販売オーダーを作成し、オーダー明細にStandard Desktopを追加します。 |
手数料1は$300と等しい |
手数料1は$300と等しい 手数料2は$200です |
リフレッシュ時の2つの手数料の動作
Standard Desktopを$300の手数料1と$200の手数料2で設定するとします。 データが60分ごとにリフレッシュされ、Order Managementユーザーは60分待機してから再度サインインするとします。
ステップ |
説明 |
リフレッシュ使用可能の単価 |
リフレッシュ使用不可の単価 |
---|---|---|---|
1 |
ユーザー1は、Standard Desktopをオーダー明細に追加します。 |
手数料1は$300と等しい |
手数料1は$300と等しい |
2 |
ユーザー2は、標準デスクトップをオーダー明細に追加します。 |
手数料1は$300と等しい |
手数料1は$300と等しい |
3 |
管理者は、200ドルに等しい料金2を標準デスクトップに追加 |
該当なし |
該当なし |
4 |
ユーザー1はサインアウトし、「待機60分」はサイン・インし、新しい販売オーダーを作成し、Standard Desktopをオーダー明細に追加します。 |
手数料1は$300と等しい 手数料2は$200です |
手数料1は$300と等しい 手数料2は$200です |
5 |
ユーザー2はサイン・アウトし、「待機60分」はサイン・インし、新しい販売オーダーを作成し、Standard Desktopをオーダー明細に追加します。 |
手数料1は$300と等しい 手数料2は$200です |
手数料1は$300と等しい 手数料2は$200です |
価格調整時の動作(リフレッシュなし)
単価が$300でマークアップが$20のStandard Desktopを設定するとします。
ステップ |
説明 |
リフレッシュ付き単価 |
リフレッシュなし単価 |
---|---|---|---|
1 |
ユーザー1は、Standard Desktopをオーダー明細に追加します。 |
$300 |
$300 |
2 |
ユーザー2は、標準デスクトップをオーダー明細に追加します。 |
$300 |
$300 |
3 |
管理者は、Standard Desktopに$20マークアップを追加する調整マトリックスを作成します。 |
該当なし |
該当なし |
4 |
ユーザー1はサインアウトし、サイン・インし、新規販売オーダーを作成し、販売オーダー明細にStandard Desktopを追加します。 |
$300 |
$320 |
5 |
ユーザー2はサインアウトし、サイン・インし、新しい販売オーダーを作成し、オーダー明細にStandard Desktopを追加します。 |
$300 |
$320 |
価格設定アルゴリズムが実行時に変更された場合の処理
価格設定では、ランタイム・セッションを使用して各価格設定アルゴリズムをリフレッシュします。
-
価格設定では、トランザクションの価格設定時にアルゴリズムが初めて取得されたときに価格設定アルゴリズムがロードされ、後続の各価格リクエスト時にセッションからアルゴリズムが読み込まれます。
-
セッションからサインアウトするまで、価格設定ではセッション・データが引き続き使用されます。
-
アプリケーションにサインインしなおすまで、価格はデータをリフレッシュしません。
例について考えてみます。
-
ユーザー1とユーザー2、ユーザー3は、それぞれOrder Management作業領域を使用するオーダー入力スペシャリストです。
-
管理者は、価格設定管理作業領域を使用する価格設定管理者です。
-
管理者は自分の出荷手数料の計算という価格設定アルゴリズムを作成し、アルゴリズムのバージョン1を作成して公開します。
-
ユーザー1はOrder Managementにサイン・インし、販売オーダーを作成してから、標準デスクトップをオーダー明細に追加します。
-
Order Managementは、オーダー明細の価格を設定するためのリクエストをPricingに送信します。
-
価格設定では、セッション・データで自分の出荷手数料の計算が検索されますが、これはこのセッションの最初のリクエストであるため見つかりません。
-
Pricingでは、データベースから送料計算を行い、セッション・データにロードします。
-
ユーザー2はOrder Managementにサイン・インし、販売オーダーを作成してから、標準デスクトップをオーダー明細に追加します。
-
Order Managementは、オーダー明細の価格を設定するためのリクエストをPricingに送信します。
-
価格設定では、セッション・データで自分の出荷手数料の計算が検索され、検索されてオーダー明細の価格設定に使用されます。
管理者が自分の出荷手数料の計算価格設定アルゴリズムを変更し、そのバージョン2を作成して公開するとします。
-
Order Managementからサインアウトしていないユーザー1は、新しい販売オーダーを作成し、標準デスクトップをオーダー明細に追加します。
-
Order Managementは、ユーザー1のオーダー明細を価格設定するリクエストを送信します。
-
Pricingでは、セッション・データでCalculate My Shipping Chargesが検索され、バージョン1が検索され、ユーザー1のオーダー明細の価格設定に使用されます。
-
ユーザー2は、Order Managementからサインアウトしてサイン・インし、販売オーダーを作成し、Standard Desktopを販売オーダー明細に追加します。
-
Order Managementは、ユーザー2のオーダー明細の価格を設定するためのリクエストをPricingに送信します。
-
管理者がバージョン2を公開したため、Pricingでは、セッション・データで自分の出荷手数料の計算のバージョン2が検索されますが、見つかりません。 そのため、Pricingはバージョン2をセッション・データにロードし、バージョン2を使用してユーザー2のオーダー明細の価格を設定します。
-
ユーザー3はOrder Managementにサイン・インし、販売オーダーを作成し、標準デスクトップをオーダー明細に追加します。
-
Order Managementは、ユーザー3のオーダー明細の価格を設定するためのリクエストをPricingに送信します。
-
価格設定では、セッション・データで自分の出荷手数料の計算のバージョン2が検索され、検索されて、ユーザー3のオーダー明細の価格設定に使用されます。
サービス・マッピングを変更した場合の処理
価格設定では、各サービス・マッピングをOracle Metadata Serviceのセッション・データに公開します。 サービス・マッピングを変更しない場合、Pricingは、品目の価格設定時にOracle Metadata Serviceのデータからサービス・マッピングを読み取ります。
サービス・マッピングを変更した場合のPricingの動作を次に示します。
-
変更したサービス・マッピングを取得します。
-
変更したマッピングのスキーマを作成します。
-
スキーマをOracle Metadata Serviceのデータに公開します。
-
Oracle Metadata Serviceのデータからマッピングを読み取って、品目の価格を設定します。
詳細は、「Oracle Middleware Oracle Application Development Frameworkの理解」にアクセスし、「Oracle Metadataサービス」の章を参照してください。