Skill Level: Intermediate

Developers or Architects with WebSphere Commerce exposure on B2C Store model and contract based pricing

E-commerce hybrid store solution for existing B2C store model and how B2B business features can be plugged into the Business to Customer (B2C) model with minimal changes on WebSphere Commerce product


  1. Introduction

    Here is a view on E-commerce hybrid store solution for existing B2C store model and how B2B business model or features can be plugged into the Business to Customer (B2C) model with minimal customization on the WebSphere Commerce product. This hybrid model enables customers to leverage the B2B store and commerce features on an existing Business to Customer model. The approach explains how this can be achieved without converting the existing Store model into a complete B2B model. Commerce product team are aligned to this unique model and they have acknowledged the benefits of this model and its uniqueness in achieving the high-performance SLA, especially with a large data set.

    In this paper, a sample feature is considered for explaining such business need and how the feature is plugged in without adversely affecting the product performance in the Price Calculation area. There are some customizations carried out to meet the high-performance Price Calculations with this hybrid commerce business model. The same concept can be extended to accommodate more number of such features or programs into the B2C Store model capability list without altering the store model itself. The approach would benefit for B2C customers as the normal trend is their B2C version would be feature rich as compared to a thinner B2B version or even non-existing B2B site.

  2. Warehouse or Region based Catalog and Pricing

    This section runs through a feature request where the products or items are configured and setup under different warehouses and the price and inventory for such products vary across different warehouses. For instance, a business feature where special set of products are configured and marked for the instant delivery involving a premium fee. Such product sets would be existing in multiple warehouses and its price could be varying from one warehouse to another warehouse. Even the product set could be varying between each warehouse.

    • Instant Delivery (ID) items are configured and setup under different warehouses and such products’ price may vary across warehouses
    • Instant Delivery items will be a subset of the master catalog
    • Initial data load might contain many warehouses and associated products (For instance, Six hundred warehouses and Ten thousand products within each warehouse)
  3. Design Criteria and basis for selection

    1. Existing store model is based out of Elite B2C Store model
    2. Store is of Extended Site model and one store for US and another one for non-US
    3. Existing Store model does not contain separate store fronts or extended site stores per each Warehouse or Fulfillment centers
    4. Distinct default contracts are defined at the Extended site store level – one for US site and a different one for non-US site
    5. B2B contract based catalog and pricing model best suites with the custom business requirement with minimal WCS product customization
  4. Challenges faced, and Solutions applied

    There were some challenges faced during the implementation of Contract based catalog and pricing solution. In this section, the key challenges faced, and various solutions applied to effectively solve the problems are explained. Since these are reusable solutions, thought of listing these potential solutions for common business problems in the e-commerce implementations where B2C and B2B hybrid features are implemented on an existing B2C model. Following are some challenges worth noting –

    • Long execution time for the Solr di-calculateprice Job when the number of contracts are very high with each contract having associated catalog with substantial product set
    • Longer di-calculateprice execution time contribute to longer Solr end-to-end processing time, which in turn adversely affect the business team’s changes to the commerce catalog reflecting onto the site after Solr indexing
    • Out Of the Box Context management CTXDATA.SERVALUE column length become insufficient when the number of contracts are very high causing breaks in the Add to cart functionality
  5. Customizations or Solutions

    Below are some well designed solutions or designs to the common problems listed above.

    • Execute the di-calculateprice job in a slightly different mode than the OOB technique
      1. Instead of using trading ID based execution, use the catentry ID list to drive the price calculate job execution
      2. Calculate the subset of catentry ID list those are directly linked with the custom contract or trading ID against which the price calculate job is executed
      3. Skip the price calculate job execution against the default contract, for which the default catalog set is linked and might not need a price calculation as it’s not necessary
    • Code customization to calculate the subset of catentry ID list those are directly linked with the custom contract instead of sending the full set of catentry ID list for the price calculation
    • Shard or parallel process the data set per catentry ID list (partitioned over the whole set of catentry ID list) instead of the trivial partition per contract ID list to avoid potential data collision
    • Partition per contract ID could lead to potential data collision as the TI_CNTRPRICE_0, PRICE clob value will get processed at the same time by different threads or shards with this execution pattern
  6. Warehouse level Catalog and Pricing – Design components

    Following section cover different commerce components used in this point of view and how each component tie back to the feature request. It also contains an overview of the current B2C context and how the custom contract would inherit from the B2C default store contract.

    Catalog Filter usage: Product entitlement

    By assigning a catalog filter to a contract, customers shopping under the contract can browse, search, and purchase the catalog entries that are defined in the catalog filter. The customers shopping under the specific warehouse contract can see and purchase only the catalog entries that are entitled to. 


    Contract based design model

    Considering the current reference B2C business model, that was derived out of an Elite B2B direct with its extended site model (US & non-USA), a B2B direct model is adopted to accommodate the warehouse level catalog and pricing feature request as part of the Instant Delivery (ID) program implementation. A default contract is defined at the US extended site store level for US Site and another one for non-USA Site.

    Additional custom contracts will be setup and assigned with Catalog filter and Price rules based on the warehouse specific catalog and pricing need. A high-level depiction of the default and additional custom contracts and its association to different price rules are outlined below. Catalog filter can be setup either as a category or product inclusion model or exclusion model. The decision on usage of either the Catalog filter inclusion or exclusion model will be based on the Instant Delivery product setup within the Sourcing system(s), such as Product Information Master or on the OMS Warehouse and Item association. It would also depend on how the sale catalogs are setup within the existing Commerce catalog subsystem.

    Below diagram depicts the Elite B2C site model and associating the contract based cataloging and pricing in a warehouse or region based model.




    Following diagram depicts the contract inheritance model in an extended site scenario and assignment and entitlement of buyer participants into a custom contract. In this model, the custom contract(s) are still differentiated by extending from the respective base and default contracts. In this example, custom contract(s) under US catalog and non-USA catalog will be maintained separately. The custom contracts under US catalog would be extended from the US default or base contract and non-USA custom contracts would be extended out of the non-USA default or base contract to keep its inheritance model clean and separate. The model depicted here is one of the common business scenario and based on specific business needs, the custom contracts and its inheritance model can be tailored quite easily. With latest Aurora store model on WebSphere Commerce Version 9 aka Watson Customer Engagement V9, the flexibility of defining these kinds of inheritance model(s) based on business context are more trivial.


    PRICE RULES: EXTENDED SITE – B2C DIRECT Extended_site_Elite_B2B_edit


    Custom Contract(s), Price rule and Price list

    Following diagram depicts the data model and data relationship between the store, contract, price rule and associated price lists. For each custom contract, there will be a set of data persisted into the child tables and it assists in calculating the contract specific prices and other terms and conditions. STORECNTR table hold the link between the store and the set of contracts linked to the store. STORETPC holds the link between the store and the trade position and which in turn links with different terms and conditions like price rule, shipping TC and so on.




    1. STORECNTR – Defines the relationship between a store and contract. A store can be associated with multiple contracts. CONTRACT table determines the type of contracts that are associated to a store. A store can have default contract, base for default contract, storefront asset store base for default contract, or a customer contract
      1. Default contract – applies to all shoppers who browse the store and do not have any other customer contract associated
      2. Base for default contract – base contract that can be shared by other contracts
      3. Storefront asset store base for default contract – Default base contract that is inherited by all associated extended sites stores
      4. Customer or custom contract – applies to a specific shopper account
    2. TRADING – Each contract can have ‘reference contracts’. By default, the default contract for an extended site store refers to that ‘Base for default contracts’ which refers to the ‘StorefrontAssetStore Base for default Contract’.
    3. TERMCOND – Each contract has multiple terms and conditions that are associated with it, which govern a seller’s relationship with a buyer. For example, term and conditions can dictate the products and prices that a buyer is able to see on the storefront.
      1. From TERMCOND table, termcond_id’s that have tcsubtype_id=PriceRuleTC, corresponding STRINGFIELD1 column contains the default price rule that is associated to the contract.
    4. STORETPC – Each store is associated with several offer price and list price lists and STORETPC table holds the relationship. This table links the Storeent_id and the Tradeposcn_id (which is the price list)
      1. The name and description for the price list can be seen on TRADEPOSCN table (column names – Name and Description)
    5. PRELEMENT, PRELEMENTATTR – A price rule has many elements that are either condition or action. The price elements are described in the PRELEMENTATTR table with the specific tradeposcn_id (that is the price list)


    Catalog Filter and Product set

    Following diagram depicts the data model or relationship between the Catalog filter and product set. It also shows a snapshot of the product inclusion expression while defining the catalog filter and associated product set.








Join The Discussion