WebSphere Commerce Search and the B2B direct business model

WebSphere Commerce Search includes support for the B2B direct business model for the Aurora B2B starter store.

Prices in WebSphere Commerce Search

Prices that are returned by WebSphere Commerce Search are either indexed or calculated:
  • Offer prices, or default contract prices, are indexed directly from the default contract of the owning store.
  • List prices are indexed directly from the LISTPRICE or OFFER database tables, depending on the price source.
  • Contract prices are calculated based on the selected contract. They are then indexed in WebSphere Commerce Search in either the Catalog Entry index or the Price extension index, depending on the number of contracts your site contains, or the source of the price data.

Indexed prices are populated quickly, but not evaluated dynamically. To ensure that the storefront displays accurate prices, you can change the price mode to suit your business needs. For more information, see Changing price modes.

When working with prices and currencies in WebSphere Commerce Search, a separate index column is used by default to handle multiple currencies.

Typical B2B flows

A typical business-to-business storefront navigation shopping flow involves scenarios such as unique pricing, catalog filtering, ordering on a customer's behalf, and multiple contract selections. Sellers, Sales Managers, and Account Representatives can use either the Management Center or Accelerator to implement pricing strategies that meet the site's business needs over time, and to filter their catalog for product and price entitlement.

WebSphere Commerce Search can be used to enhance the storefront keyword search and browsing experience to satisfy most of the business-to-business requirements using catalog filters. You can use the Catalog Filter and Pricing tool to filter your catalog to a specific set of catalog entries by specifying which categories, catalog entries, attribute dictionary attributes, and catalog entry properties to include or exclude from the catalog filter. Use catalog filters for your product entitlement, that is, to entitle customers to a subset of your catalog.

For more information, see Using catalog filters.

Contract price indexing and facets

WebSphere Commerce Search builds calculated prices into the search index, so that the Aurora B2B starter store can use the indexed price mode to support contract-based pricing based on calculated prices.

The results displayed in the storefront facet values are based on the selected contract. Asset stores can either share prices, or use different prices for Extended Sites based on the selected pricing model.

Configurable price fields

The following configurable fields are available to support pricing:
  • The wc-component.xml file on the Search EAR contains the following configurable Pricing fields:
    Defines the operation between multiple contracts.
    If the operation is AND, the expression among multiple contracts is wrapped with +.
    Otherwise, multiple expressions are wrapped with a space.
    The default value is an OR operation.
    For more information, see Search properties in the component configuration file (wc-component.xml) (Search EAR).
  • The STORECONF table contains the following configurable Pricing fields to the wc.search.priceMode.compatiblePriceIndex property:
    The price column is indexed from the contract price using the following naming convention: price_#currency_#contractId.
    The price column is indexed from the standard offer price using the following naming convention: price_#currency.
    For more information, see Search configuration properties in the STORECONF table.
  • If you are using price mode as 1:

    When the indexed price mode is set (wc.search.priceMode=1 in the STORECONF table), all the catalog search and browsing pages, including the product display page use the indexed price. If the contract price is indexed, these pages use the indexed contract price. However, all the checkout pages, including the shopping cart pages, use the price commands to calculate real time pricing.

Changing price modes

To change price modes in WebSphere Commerce Search:
  1. Set the SearchProfilesPrice Search profiles global defaults property in the wc-component.xml file. For more information, see Search properties in the component configuration file (wc-component.xml) (WebSphere Commerce EAR).
  2. Set the wc.search.priceMode property in the STORECONF table. For more information, see Search configuration properties in the STORECONF table.

Prioritized price mode settings in starter stores

Different starter stores can use different price modes in WebSphere Commerce Search, instead of relying on the values in the preceding configuration files.

Starter stores that use the Business Object Document (BOD) command framework prioritize prices in the following order:
  1. By passing in the search profile in the store URL. This flag receives the highest priority.
  2. By specifying the search profile in the search request. That is, any search request can contain a price mode and entitlement check, for business or performance considerations.
  3. By using the storepath. For example, B2B stores by default use the calculated price mode, while B2C stores use the indexed price mode. Extended sites inherit the asset store configuration.
  4. By using the site-level setting as a fallback. Indexed mode is used by default.
Displaying prices is managed differently if you are using the REST framework.
Starter stores inherit price modes in the following order:
  1. Store-level
  2. Asset store
  3. Site
  4. Profile
Note: The wc.search.entitlement property in the STORECONF table inherits price modes in the same order, except for Profile, which is ignored.

Indexing prices

You can index price data into the following locations, based on the number of contracts your site contains, or the source of the price data:
  • In the Catalog Entry index, when your site contains less than 1000 contracts and price data is contained within WebSphere Commerce. Prices are calculated and indexed using the di-calculateprice utility and ContractPriceCalculate job command.

    The di-calculateprice utility updates the information in the price index on demand based on the pricing model your store uses. For more information, see Adding contract prices to the Catalog Entry index.

    The ContractPriceCalculate job command is used for calculating prices on a schedule for all catalog entries that belong to a specific master catalog. The catalog entry price is calculated against all contracts that belong to the store. For more information, see Creating and scheduling the ContractPriceCalculate job.

  • In the Price extension index, when your site contains more than 1000 contracts, or if you use an external source to populate prices. Prices are indexed using Index Load, as it can populate a large amount of data into a separate extension index faster than the Catalog Entry index can index price data. For more information, see Index Load.

Calculating prices

Prices can be calculated either fully, or for a specified catalog entry, contract, or currency. When full price recalculations are used, all prior price data is removed from the index before the B2B contract prices are recalculated.

To help decide when and where to calculate prices, consider the following options:
Dedicated server or environment
Allocate a dedicated server or instance to calculate prices.
You can either use the di-calculateprice utility or ContractPriceCalculate job after the price feed is available on the WebSphere Commerce database. Preprocess the master index after the calculation is complete.
In this configuration, calculating prices has no performance impact on the WebSphere Commerce node.
Non-staging environment
Calculate prices on a managed WebSphere Commerce node.
Preprocess the price index after calculation is complete, which saves the price index into a master index server. Then, prices and other data within the catalog entry and catalog group index are replicated to the search slaves.
In this configuration, calculating prices impacts the performance of the managed WebSphere Commerce node, as traffic is served from this environment. However, no additional topology changes are required, thus remaining compatible with earlier feature pack versions.
Staging environment
Calculate prices on a WebSphere Commerce node on staging.
Preprocess the price index to the search node on staging, then run the indexprop utility to replicate the index to the repeater.
In this configuration, no additional topology changes are required, thus remaining compatible with earlier feature pack versions.

Full price recalculations logic

  • Recalculating prices uses current and future store contracts that share the master catalog.
  • Only the supported currencies for all active stores that are identified in the master catalog are respected, while others are ignored and not indexed. This is because the prices are recalculated on behalf of the site administrator, and therefore cannot calculate any customer segment-level pricing.
  • By default price calculations are either based on some unit of measure (kilos, crates, lots) that has a base numeric quantity of 1, or on a unit of C62. C62 is used to signify items that are not counted according to a separate unit of measure. For instance, shirts are not typically measured in kilos, but in shirts, therefore their unit of measure could be set as C62. One limitation of this approach is that any step-level pricing, that is, quantity-based pricing, is skipped.
    Tip: You can work around this limitation by explicitly defined C62 as having a value of 1, then defining a unit based upon C62 that can be multiplied. For instance, the following SQL query creates a new unit, CS, based on C62, that can be multiplied to enable to step-level or quantity-based pricing.

Recalculations logic

  • Contract IDs are not validated when passed in as a separate parameter, so that future contracts show the correct prices when you preview a future date in store preview.
  • All expired and suspended contracts are safe to remove from the TI_CNTRPRICE temporary table for the specified catalog entry or contract that is specified in the utility's parameters. That is, the purge list is only limited to the specified catalog entry or contract. For example, if you specify an expired contract, all catalog entries that are covered by that contract are purged. However, if you specify a catalog entry, all expired contracts are purged only for the specified catalog entry.
  • If a contract is suspended and inactive, the contract price is removed. If a business user resumes the contract and it becomes active again, the price is not shown in the storefront until the price is calculated again for the resumed contract.
  • When an invalid product, contract or currency is passed in, the logic ignores, and therefore does not index invalid values.
  • If a contract passed in is expired or suspended, it is deleted and purged from the calculation result. Otherwise, if a contract that will be active at a future date is passed in, it is indexed. That is, even though it is not currently active at the time of the price recalculation.
  • The storeId and currency parameters cannot be specified with any other parameters.

Customization logic

Active and future contract prices are built into the catalog entry index using field definitions that start with price_, followed by a combination of contract and currency. For example, price_USD_10001 or price_CNY_10002. In contrast, for releases without indexed contract prices, the catalog entry index uses field definitions that start with price_, followed only by its currency.

The di-calculateprice utility and ContractPriceCalculate job command resolve all deployed contracts for stores that share the specified master catalog. Then, they initialize the price API command to calculate prices for all the catalog entries that belong to the specified master catalog. The calculated price result is saved into the TI_CNTRPRICE_#INDEX_SCOPE temporary table. All the calculated results for a catalog entry are composed into a single column:


Name Type Description
CATENTRY_ID BIGINT NOT NULL The ID of the catalog entry. This column contains all catalog entry for the specified master catalog.
PRICE CLOB Multiple value pairs for different contracts and currency values that are separated with white space.
The NameValuePairTransformer is the default transformer that transforms the wide multiple value column into the dynamic price field. You can generate different dynamic price column names in Solr by customizing or creating a new transformer. If you customize the transformer, you must override the applyFieldNamingPattern method in the following classes to get the updated price column names:
  • SolrRESTSearchCatalogEntryViewPriceQueryPostprocessor
  • SolrRESTSearchByPriceExpressionProvider
  • SolrSearchResultFieldQueryPreprocessor
  • SolrSearchFacetQueryPreprocessor

In extended sites, the catalog asset store defines the price in the master catalog so that extended sites share the catalog asset store's prices. Or, the extended site can override the prices so that it contains the extended site-specific prices. Different extended sites can create specific items with specific price. When prices are calculated, the store-specific items are calculated first, then the shard items are calculated. Shared items are each calculated per store by their specific contract and currency. The price API gets the correct price, based on the specified contract, price rule, price model, or contract terms and conditions. Different extended sites can define different prices by using different contract. When a shopper logs on to a different extended site store, different contracts are resolved. Then, the shopper sees the relevant prices in the store, even for the same product in the master catalog.

Multiple price columns are set up in the catalog entry index. When a buyer logs on to the storefront, the eligible buyer contract is retrieved. If there are multiple eligible contracts, the buyer can select a contract to set for the session. Then, the corresponding price column that is related to the contract in session is displayed in the storefront. To customize this behavior, the ContractPriceCalculate URL uses ContractPriceCalculateCmd as the overall entry command. The logic can be overridden by a registering a new command implementation in the command registry table. If you want to introduce different calculation logic, override the calculateStoreSpecificItemPrice and calculateSharedItemPrice methods in the ContractPriceCalculateCmd command.

The IBM_Admin_CalculatePriceIndex access profile is used to bootstrap the common entry of the com.ibm.commerce.price.commands.CompositeGetContractUnitPriceCmdImpl price API:

<cmdreg storeent_id="0" interfacename="com.ibm.commerce.price.commands.GetContractUnitPriceCmd+IBM_Admin_CalculatePriceIndex" 
classname="com.ibm.commerce.price.commands.CompositeGetContractUnitPriceCmdImpl" target="Local"/>
If your store uses the price rule price model, you can use the following command implementation for performance reasons:

<cmdreg storeent_id="0" interfacename="com.ibm.commerce.price.commands.GetContractUnitPriceCmd+IBM_Admin_CalculatePriceIndex" 
classname="com.ibm.commerce.price.commands.PriceRuleGetContractUnitPriceCmdImpl" target="Local"/>

If your store uses the external price model, you can register your own price command to get your intended price result.

Workspace preview

When working with workspace preview:
  • B2B prices that are shown in store preview are only from approved content.
  • Future prices can be previewed provided that the appropriate future contract is indexed. The future date is respected in the preview context and shows the correct contract for viewing.
  • Prices cannot be associated with new non-approved content, such as previewing a non-approved new product that does not belong to any contract.
  • To ensure that workspace previews are accurate, set up the ContractPriceCalculate job to run regularly. Then, set up an event-consumer trigger to perform a delta product index update for the affected products to pick up the new price changes.