Oracle Fusion Pricing

Data Caching
July 2016
Table of Contents
Introduction – Caching Data ................................................................................................................. 2
What is Cached in Pricing? ................................................................................................................... 2
When is the Data Cached? .................................................................................................................... 2
How Caching Works for Pricing Rules Data ..................................................................................... 3
Does Cached Data Clear or Expire?................................................................................................ 3
How to Disable Caching ..................................................................................................................... 4
Use Cases for Pricing Rules Data Caching ................................................................................... 7
How Caching Works for Pricing Algorithms ................................................................................... 10
How Caching Works for Service Mappings .................................................................................... 11
Introduction – Caching Data
This document provides an overview of the caching feature and its impacts within Fusion Pricing. Caching
is one of the most common approaches for improving the performance of accessing commonly used data.
Caching minimizes expensive object initializations and database round-trips, which ultimately result in
improved application performance. This document will highlight key details that will allow you to
understand the impacts to your pricing if caching is enabled.

 What is Cached in Pricing?

 When is the Data Cached?
 How Caching Works for Pricing Rules Data
 How to Disable Caching
 Use Cases for Pricing Rules Data Caching
 How Caching Works for Pricing Algorithms
 How Caching Works for Service Mappings

What is Cached in Pricing?

In Fusion Pricing, data for the following are cached:

1. Pricing Rules (Price Lists, Cost Lists, Shipping Charge Lists, Discount Lists, Pricing Strategies,
Pricing Segments, Customer Pricing Profiles, Return Price Lists, Pricing Strategy Assignments,
Currency Conversion Lists, Matrix Rules) and Reference Entities (Functional Setup Manager
(FSM) Pricing Setup Data, Matrix Classes, Item Attributes, Customer Attributes)

These are the various rules that a user needs to define as part of pricing administration, e.g. a
price list containing items and their charges. During price execution these rules are queried to
calculate the price of an item including shipping charges, various discounts, margin and
applicable taxes. Caching of the pricing rule data avoids roundtrips to the database and improves
price execution performance.

2. Pricing Algorithms

A component of pricing execution infrastructure that enables you to define procedural logic that
transforms a set of input rows into an output set. This is the core of the price execution engine
that contains the logic to price a transaction. Algorithm metadata is cached to avoid reading and
parsing it repeatedly from the database.

3. Service Mappings

Represents a high-level grouping of entities that can be retrieved and updated by a consumer
service, such as the Price Sales Transaction service. Service mapping schema definitions are
cached to optimize performance.

When is the Data Cached?

1. Pricing Rules and Reference Entities

Pricing rules (e.g. Price Lists) are cached using the ADF-BC shared application module caching
infrastructure. Data is loaded into the cache the first-time pricing rules are looked up while pricing
a transaction. The next time a price request is made, pricing rules will be read from the cache.
Any subsequent changes made to the pricing rule(s) are not reflected immediately in the cache.
Please refer to the section “How Caching Works for Pricing Rules data” for more details.

2. Pricing Algorithms
 Pricing algorithms leverage Fusion Application's user session cache. They are parsed and loaded
into the cache during the very first invocation of price execution after a server restart (e.g.,, when
an item is priced from Order Management for the very first order). Subsequent calls make use of
the cached algorithms.

3. Service Mappings

Service mappings definitions are used by the pricing algorithms and are loaded in MDS cache
when an item is priced from Fusion Order Management (FOM).

How Caching Works for Pricing Rules Data

This section will explain how caching works for pricing rules data. Let’s take an example of creating an
order in Fusion Order Management (FOM).

The user selects a customer and a pricing call is made to get the applicable pricing rules data.
Let’s assume this is the first time the user has created an order, and therefore the cache will not
have this data and needs to be loaded. The pricing rules data then will be loaded in to a shared
Application Module (AM) cache. Subsequent calls will use this cached data until the cached data
gets cleared/expires or the server gets bounced.

Does Cached Data Clear or Expire?

The cached data does get cleared. There are AM configuration parameters that control how long the
cached data will live. The parameters of interest are “Time To Live” and “Idle Instance Timeout”. The
standard Fusion Application values for these parameters are 60 minutes, and 10 minutes respectively.

“Time To Live” is the time after which data is reloaded into the cache, bringing in any changes made to
the pricing rules. When pricing rules are changed, users can expect the changes to be reflected in FOM
after 60 minutes.

“Idle Instance Timeout” is the time after which an inactive AM instance in the pool is a candidate for
removal during the next resource cleanup. This means if a specific pricing rule data is not accessed in the
cache for 10 minutes, it will get cleared from the cache.

The screenshot below shows the parameter values in Enterprise Manager (EM).
How to Disable Caching
We recommend caching to be enabled at all times in production environments to get the best
performance. However while testing some price changes in a test environment, if customers want to see
the price changes immediately, they can disable caching using the following steps.

Please note: Caching can be disabled for all pricing rules data except matrix rules. Matrix rules are
defined in pricing segments, pricing strategy assignments, and adjustment rules in price lists. This
behavior is set for all implementations of the matrix including custom matrix classes created by the user.
These rules are always cached and will only be cleared after user has waited for the duration defined by
the parameter, “Time To Live” (as explained in “Does Cached Data Clear or Expire?”).
For the rest of the pricing rules data, caching can be turned off by the following method.

1. Login to Pricing Administration > Manage Algorithms, search for algorithms starting with 'Price Sales'.
2. Select algorithm with name 'Price Sales Transactions'. Ideally you should see only Version 1. But if you
see more than one, select the latest published version. Click Actions > Create Version
3. You will see a new version created with status 'In progress'. Edit that version.
4. In the algorithm step 'Set Initial Values', review the Input Variables. Set the Variable EnableCache to
false.

Note: The value true means caching is enabled, false means caching is disabled.

5. Save and Close the page. Navigate back to the Manage Algorithms page, and publish the latest
version of the Price Sales Transactions algorithm.
6. Logout and Log back into FOM. Create an order, you should start seeing the changes to the pricing
rules (except Matrix rules) immediately.
Use Cases for Pricing Rules Data Caching
The examples below illustrate how price calculations are impacted by caching.

Use Case - 1 (Price for Charge, CH1 for item, T1 changed from $300 -> $399) Caching Unit Price
OM User 1 creates an order for item, T1 that has only 1 charge, CH1=$300 Enabled CH1 = $300
OM User 2 creates an order for item, T1 that has only 1 charge, CH1=$300 Enabled CH1 = $300
Pricing Admin User updates the price for charge, CH1 for item T1 to $399 Enabled N/A
OM User 1 signs out of the application, signs back in and creates a new order for item,
Enabled CH1 = $300
T1
OM User 2 signs out of the application, signs back in and creates a new order for item,
Enabled CH1 = $300
T1

OM User 1 creates an order for item, T1 that has only 1 charge, CH1=$300 Disabled CH1 = $300
OM User 2 creates an order for item, T1 that has only 1 charge, CH1=$300 Disabled CH1 = $300
Pricing Admin User updates the price for charge, CH1 for item T1 to $399 Disabled N/A
OM User 1 signs out of the application, signs back in and creates a new order for item,
Disabled CH1 = $399
T1
OM User 2 signs out of the application, signs back in and creates a new order for item,
Disabled CH1 = $399
T1
Use Case – 1a (Price for Charge, CH1 for item, T1 changed from $300 -> $399) Caching Unit Price
OM User 1 creates an order for item, T1 that has only 1 charge, CH1=$300 Enabled CH1 = $300
OM User 2 creates an order for item, T1 that has only 1 charge, CH1=$300 Enabled CH1 = $300
Pricing Admin User updates the price for charge, CH1 for item T1 to $399 Enabled N/A
OM User 1 & User 2 wait for 60 minutes Enabled N/A
OM User 1 signs out of the application, signs back in and creates a new order for item,
Enabled CH1 = $399
T1
OM User 2 signs out of the application, signs back in and creates a new order for item,
Enabled CH1 = $399
T1
Use Case - 2 (Add a second charge, CH2 for an existing item T1) Caching Unit Price
OM User 1 creates an order for item, T1 that has only 1 charge, CH1=$300 Enabled CH1 = $300
OM User 2 creates an order for item, T1 that has only 1 charge, CH1=$300 Enabled CH1 = $300
Pricing Admin User updates the item T1 and adds a second charge, CH2=$200 Enabled N/A
OM User 1 signs out of the application, signs back in and creates a new order for item, T1 Enabled CH1 = $300
OM User 2 signs out of the application, signs back in and creates a new order for item, T1 Enabled CH1 = $300

OM User 1 creates an order for item, T1 that has only 1 charge, CH1=$300 Disabled CH1 = $300
OM User 2 creates an order for item, T1 that has only 1 charge, CH1=$300 Disabled CH1 = $300
Pricing Admin User updates the item T1 and adds a second charge, CH2=$200 Disabled N/A
CH1 = $300,
OM User 1 signs out of the application, signs back in and creates a new order for item, T1 Disabled
CH2 = $200
CH1 = $300,
OM User 2 signs out of the application, signs back in and creates a new order for item, T1 Disabled
CH2 = $200
Use Case - 2a (Add a second charge, CH2 for an existing item T1) Caching Unit Price
OM User 1 creates an order for item, T1 that has only 1 charge, CH1=$300 Enabled CH1 = $300
OM User 2 creates an order for item, T1 that has only 1 charge, CH1=$300 Enabled CH1 = $300
Pricing Admin User updates the item T1 and adds a second charge, CH2=$200 Enabled N/A
OM User 1 & User 2 wait for 60 minutes Enabled N/A
CH1 = $300,
OM User 1 signs out of the application, signs back in and creates a new order for item, T1 Enabled
CH2 = $200
CH1 = $300,
OM User 2 signs out of the application, signs back in and creates a new order for item, T1 Enabled
CH2 = $200
Use Case - 3 (add a price adjustment matrix for an existing charge, CH1 for an item, T1) Caching Unit Price
OM User 1 creates an order for item, T1 that has only 1 charge, CH1=$300 Enabled CH1 = $300
OM User 2 creates an order for item, T1 that has only 1 charge, CH1=$300 Enabled CH1 = $300
Pricing Admin User updates the existing charge for item T1 and adds an adjustment
Enabled N/A
matrix, markup = $20
OM User 1 signs out of the application, signs back in and creates a new order for item, T1 Enabled CH1 = $300
OM User 2 signs out of the application, signs back in and creates a new order for item, T1 Enabled CH1 = $300

OM User 1 creates an order for item, T1 that has only 1 charge, CH1=$300 Disabled CH1 = $300
OM User 2 creates an order for item, T1 that has only 1 charge, CH1=$300 Disabled CH1 = $300
Pricing Admin User updates the existing charge for item T1 and adds an adjustment
Disabled N/A
matrix, markup = $20
OM User 1 signs out of the application, signs back in and creates a new order for item, T1 Disabled CH1 = $300
OM User 2 signs out of the application, signs back in and creates a new order for item, T1 Disabled CH1 = $300

Use Case - 3a (add a price adjustment matrix for an existing charge, CH1 for an item, T1) Caching Unit Price
OM User 1 creates an order for item, T1 that has only 1 charge, CH1=$300 Enabled CH1 = $300
OM User 2 creates an order for item, T1 that has only 1 charge, CH1=$300 Enabled CH1 = $300
Pricing Admin User updates the existing charge for item T1 and adds an adjustment
Enabled N/A
matrix, markup = $20
OM User 1 & User 2 wait for 60 minutes Enabled N/A
OM User 1 signs out of the application, signs back in and creates a new order for item, T1 Enabled CH1 = $320
OM User 2 signs out of the application, signs back in and creates a new order for item, T1 Enabled CH1 = $320
How Caching Works for Pricing Algorithms
Pricing algorithms are a set of instructions written in groovy and stored in the database. Algorithms are
parsed and loaded into cache during the very first invocation and subsequent calls make use of the
cached algorithms.

Algorithms are cached in order to get good system performance. Disabling the cache is not supported
and should not be attempted. However there are ways for a user to access the updated algorithm version
that has been published.

The following illustrates how caching works for pricing algorithms.

Use Case 1: When there is only version 1 of pricing algorithm, ALGM (ALGM-Ver1), in published state.

 OM User 1 logs into FOM, creates an order for an item. User action invokes price
execution that in turn looks for an algorithm (ALGM-Ver1) in the pricing algorithm session
cache. Since this is the first call to Fusion Pricing, the pricing algorithm session cache is
empty. The algorithm (ALGM-Ver1) then is loaded from the database and stored in the
session cache.
 OM User 2 logs in and creates an order for an item. The price execution follows the same
process as above, but when looking for ALGM, finds ALGM-Ver1 in cache and hence
avoids the database query.
 OM User 3 logs in and creates an order for an item. Again, the price execution follows the
same process as above, finds ALGM-Ver1 in cache and hence avoids the database
query.

Use Case 2: Pricing Admin User has modified ALGM, created a version 2 and published it.

Assumptions:

There are 2 published versions for ALGM, ALGM-Ver1 and ALGM-Ver2

OM User 1 didn’t log out but OM User 2 and OM User 3 logged out

Note: The database query to get the latest published version (just the version number), only
happens when a user logs in and will not be done again until the user logs out and logs back in.

 OM User 1 continues to work and creates a new order for an item. Price execution finds
algorithm (ALGM-Ver1) in the pricing algorithm session cache (explained in Use Case 1).
 OM User 2 logs back in and creates an order for an item. Price execution looks for
algorithm (ALGM-Ver2) in the pricing algorithm session cache. Since it does not find it in
the cache, it parses and loads ALGM-Ver2 from the database and stores in the session
cache.
 OM User 3 logs in and creates an order for an item. Price execution follows the same
process as above but, when looking for ALGM-Ver2, finds it in the cache and hence
avoids the database query.
How Caching Works for Service Mappings

The following diagram explains how caching works for service mappings. If there are any
changes in the service mapping definitions it will re-query the data from the Meta Data Store
(MDS). Otherwise it will always read it from the MDS cache.
 Oracle Corporation, World Headquarters Worldwide Inquiries
500 Oracle Parkway Phone: +1.650.506.7000
Redwood Shores, CA 94065, USA Fax: +1.650.506.7200

CONNECT W ITH US

blogs.oracle.com/oracle
Copyright © 2016, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and the
contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other
facebook.com/oracle warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or
fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are
formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means,
twitter.com/oracle electronic or mechanical, for any purpose, without our prior written permission.

oracle.com Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and
are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are
trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 0116

Data Caching
July 2016
Author: Rakesh Arora
Contributor: Priya Gopal, Srinivas Pagadala