(Enterprise)

Best practices for price rules

Review these best practices for creating price rules so we can learn ways to simplify price rule maintenance and reduce performance impacts.


1. Reuse components in your price rules

With careful planning, we can find ways to reuse components in price rules. For example, we can:

This way, it is easier to maintain a set of price rules that are based on reusable components. We 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:

The following best practices relate to minimizing performance impacts of price rules. If the site is experiencing performance issues, we 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 we can minimize the performance impact of price rules is by ordering the conditions in the price rule like this:

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. 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

We 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, we 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 we 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.