How WCS selects the correct price from OFFER table?

Offers for catalog entries are stored in the OFFER table. When setting pricing for catalog entries, WC uses specific criteria to find valid offers from the OFFER table and then select the correct price.

To set the price for a catalog entry, WC must first determine all the valid offers for each applicable price list. To be valid, the offer must meet the following criteria according to data in the OFFER table: 

1. The offer must be published, that is, the PUBLISHED value must be 1.
2. The quantity of the catalog entry being purchased must be within the MINIMUMQUANTITY and MAXIMUMQUANTITY values for the offer.
3. The purchase date must be within the defined STARDATE and ENDDATE values for the offer.

If you load pricing data into WC using the data loader utility or SQL statements, it is possible to have more than one valid offer for a catalog entry. If there is more than one valid offer, WC sets the price using the offer with the highest value in the PRECEDENCE column of the OFFER table. If multiple offers exist with that same highest precedence value, the offer with the lowest price is used.

Price rules and offer price selection

If your store uses price rules for storefront pricing, the price rule also retrieves offers from the OFFER table, but then the price rule might perform additional calculations on the offer price.

In this price rule, the Get Price from Price List action retrieves the offer from the OFFER table and then performs the mark down and rounding on the offer price. To evaluate and select the correct offer to retrieve from the OFFER table, WC uses the same criteria described earlier in this topic.

Solr concept and Architecture

Conceptually, the Solr can be divided into four blocks:

    Mode (schema.xml)
    Configuration (the solrconfig.xml)
    Index
    Search

A Document contains one or more Field, A Field by name, content, and content approach of metadata. Analysis of the content to be searched. Analysis is completed by a Tokenizer and zero or more TokenFilter link to the Tokenizer to the input stream split into words (tags) TokenFilter can change (for example, stem) or remove the tag . Solr schema can easily configure the code analysis process. It also provides a more powerful type of feature that allows you to Field specific designated as String, int, float, or other type of original or custom.

Solr schema for the index is defined in schema.xml. it contains field type definitions within  the <types> element and the index's fields within <fields> elements. you may also notice <copyField> element, which copy an input field as provided to another field.

1. Schema design decisions in which you map your source data to document limited structure.
2. The structure of the schema.XML file where the schema definition is defined. Within this file are both the definition of field types and the fields of those types that store your data.
3. Text analysis—the configuration of how text is processed (tokenized and so on) for indexing. This configuration affects whether or not a particular search is going to match a particular document.

In the configuration, the solrconfig.xml file specified not only Solr how to deal with the index, highlight, classify, search, and other requests, and also specifies the properties used to specify the cache approach, and used to specify the method of the Lucene index properties . Configuration depends on the model, but the pattern does not depend on the configuration.

Solr's solrconfig.xml file contains lots of parameters that can be tweaked. At the moment, we're just going to take a peak at the request handlers, which are defined with <requestHandler> elements. They make up about half of the file. In our first query, we didn't specify any request handler.

<requestHandler name="search" class="solr.SearchHandler default="true">
<!-- default values for query parameters can be specified, these will be overridden by parameters in the request -->
   <lst name="defaults">
   <str name="echoParams">explicit</str>
   <int name="rows">10</int>
   </lst>
</requestHandler>

Each HTTP request to Solr, including posting documents and searches, goes through a particular request handler. Handlers can be registered against certain URL paths by naming them with a leading "/".

<requestHandler name="/update" class="solr.XmlUpdateRequestHandler" />

Resetting the Cloudscape database to contain only bootstrap data

The initial installation of WebSphere Commerce Developer contains pre-published starter stores using IBM Cloudscape (derby) as the development database.

1. Navigate to the WCDE_installdir\bin directory.

2. Run the resetdb.bat script. This script will reset your Cloudscape database to its bootstrap configuration. When prompted you must confirm that you want the database to be reset by typing YES.

3. Run the resetstores.bat script. This script will reset the Stores Web module in your workspace to its bootstrap configuration so there will be no starter store resources in the Stores Web module.

4. If you run the resetdb.bat command after you have applied a WebSphere Commerce fix pack, you must run the updatedb.bat command to bring that database back to the appropriate level.

5. Use the Administration Console to publish only those starter stores that are of interest to you.