Review these best practices for creating price rules so
you can learn ways to simplify price rule maintenance and reduce performance
impacts.
1. Reuse components in your price rules
With
careful planning, you can find ways to reuse components in price rules.
For example, you can:
- Reuse the same price equation in multiple price rules.
- Reuse the same price constant to calculate a new price in more
than one price equation.
- Reuse the same price list in multiple price rules.
- Nest price rules that contain a common set of pricing instructions
within other price rules.
This way, it is easier to maintain a set of price rules that
are based on reusable components. You can make a change to the reusable
component, and all price rules that use the component are updated
automatically.
2. Give price rule components meaningful
names
One real advantage of price rules is that they display
in a graphical format in the Price Rule Builder. To optimize the readability
of your price rules, make sure you assign meaningful names to:
- Price rules and price lists
- Paths in branches
- Price equations and constants
The following best practices relate to minimizing performance
impacts of price rules. If your site is experiencing performance issues,
you can review your price rules based on these best practices and
make any necessary adjustments.
3. Place conditions that are
most likely to be met on the first path in the price rule
One
way you can minimize the performance impact of price rules is by ordering
the conditions in the price rule like this:
- Place the condition that is most likely to be met on the top path.
- Place the condition that is the second most likely to be met on
the second path, and so on.
This reduces the number of conditions that must be checked each
time a customer views a catalog entry on the storefront. Consider
a price rule that uses the Customer Condition to differentiate prices
for three member groups; however, one member group has significantly
more customers than the other two. To minimize performance impacts,
specify the member group with the most customers in the condition
on the top path.
4. In a price rule with conditions,
the path with no conditions must be the bottom path
Typically,
you should not add a condition element to the bottom path in a price
rule. The bottom path should set pricing for any catalog entries or
customers that do not meet the conditions on the other paths. Using
a bottom path with no conditions ensures that your price rule can
generate a price for all catalog entries and all customers that the
price rule must handle. This prevents the situation in which catalog
entries on the storefront show "No Price Available" because the price
rule cannot output a price. Customers cannot purchase catalog entries
that do not have a price. Make sure it is the bottom path, and not
some other path, that has no condition. This is because when the price
rule reaches a path with no conditions, no additional paths below
that path are used for pricing.
5. Limit the nesting depth for
nested price rules
You can nest a price rule within another
price rule, and then nest that price rule within another price
rule, and so on. The more nesting you do, the greater the impact
to performance.
6. Limit the number of Condition
Branches in a single price rule
To handle complex pricing logic,
you can have more than one Condition Branch in
a price rule. The more Condition Branch elements
you include, the greater the impact to performance.
7. Use the Coordinator Branch wisely
and only when necessary
Consider this: if you use a Coordinator
Branch that contains 20 paths, then WebSphere Commerce
must run 20 price rules to come up with the prices to compare. This
amount of processing can affect performance. For this reason, try
to limit the use of the Coordinator Branch in
your pricing strategy. If you do use it, try to keep the number of
paths in the Coordinator Branch to a minimum.