Introduction to WCS Cache Invalidation - Part 1

"There are only two hard problems in Computer Science: cache invalidation and naming things."
-- Phil Karlton

As the quote above suggests cache invalidation can be a complex topic.

In this post will discuss the basics of cache invalidation; along with some guidelines for the different invalidation strategies that can be used with WebSphere Commerce.
This guide assumes some familiarity with configuring caching in WebSphere.

What is cache invalidation ?

Essentially it is the mechanism of removing the stale items from cache.

WebSphere Commerce has a caching system called DynaCache.

Why is invalidation important?

To protect the accuracy of the data available in cache. 

Most business applications have a consistency requirement for certain types of data.

For example, If my inventory reaches zero, I don't want the customer to purchase items which have no inventory and which can not be back-ordered.

How can I invalidate cache?
Here is a list of the different ways you can invalidate cache:

1. Manual Invalidation
2. Time to Live (TTL)
3. Dependency IDs
1. Using command invalidation
2. Using CACHEIVL (only in WebSphere Commerce)
3. Using custom code

Manual Invalidation
This type of invalidation is done by using the WebSphere Commerce Cache Monitor.
The cache monitor is a web application which uses the DynaCache API to remove specific entries.

The EAR file comes with WebSphere Application Server but it is not installed by default.
Make sure servlet caching is enabled in your WCS environment before installing the Cache Monitor.

The advantage of this method is that you can invalidate all entries at the same time by pushing a button.
You can also invalidate only a given group of entries. This is a more complex topic which will be explained in a later post.

The disadvantage is that if you have a large number of entries it will be difficult to find a specific entry.
There is no search capability and the navigation is not very user friendly.

Invalidation using a TTL
The TTL value is configured in cachespec.xml.
A <timeout> child element is added to a <cache-entry> element. The timeout is specified in seconds.
This type of invalidation is best used when you don't have a hard consistency/freshness requirement.

Let's use the caching of the product display page as an example
For this example we will assume the following:

1. The product table is updated once a day
2. The update is done by a scheduled job
3. The scheduled job runs once a day at 10pm

In this case it would make sense to set the TTL for ProductDisplay to 86400 (seconds in a day):



The timeout starts from the time each cache entry is created. Each product has a separate cache entry which is created when a page for a specific product id or part number is accessed. Since each cache entry could be created at a different time, they could also expire at a different time.

The advantage of this method is that it is easier to configure compared to dependency ID invalidation.

The main disadvantage of using TTL invalidation is that there is no guarantee that the cache will expire before the product table is updated.

Here is a scenario where the cache would not be properly invalidated:

1. Most cache entries expire around midnight.
2. The scheduled job is delayed due to some problem.
3. A user access the product page for part number ABC at 12:30am creating a new cache entry
4. The scheduled job updates the data for ABC and finishes running at 1am
5. The product page for ABC is not updated because the timeout value was reset at 12:30am

Ideally the product update job should always run before the cache expires, but in this case it didn't.
The easiest solution in this case is to do a manual cache invalidation at 1am after the scheduled job has finished running.

Another disadvantage is that all the entries will expire around the same time. This will cause a large number of requests to hit WebSphere Commerce at the same time without the benefit of a cached response. This will degrade the performance perceived by the user.

In conclusion this method is best used when:

1. You have a low consistency business requirement: The cache can be updated sometime after the database is updated.
2. You have the operational resources: Someone is watching the scheduled job to see if it is delayed and if something goes wrong he knows to manually invalidate the cache.

NOTE: The <timeout> value is separate and different from the <inactivity> value. It is possible to have both settings. The <inactivity> value will expire the cache after it has not been accessed for a given number of seconds.

Stay tuned for the next post which will cover dependency ID based cache invalidation ...

A Classic case of redirect and passing objects !!

Redirect does not support passing objects back to view. I am sure, we have all tried to pass an object or ArrayList of objects to make a pretty URL in the browser or convert a POST request to a GET and so instead of doing a forward, we try to do redirect  from a command\controller to a view.

Controller command:
In JSP:

Error:
Unable to find a value for "methodName" in object of class "java.lang.String" using operator "."

HTTP redirection allows servers to redirect a client request to a different location. A POST request can be a converted to a GET request using redirection with a status code 302.A server specifies redirection by sending 3XX status code.
Redirect is done via  URL and hence can only support name/value pair. Forward works with Objects but redirects can not pass objects back to the view. When trying to access the object retrieved from WCParam, it throws the above exception.

Alternate Solutions: If you do need to pass an object on redirect.
1. Putting object in HTTPSession (Not recommended as it could use a ton of memory in application server depending on how many users hit the URL)
2. Serialize objects in a XML/JSON String, like what Accelerator does.
3. Commerce context services, customize a commerce service for storing session information and store in database.

Demonstrating an Industry Standard Search Solution

Demonstrating an Industry Standard Search Solution

IBM WebSphere Commerce is now a fully operational search engine.
The product now includes Lucene Solr (http://lucene.apache.org/solr/) as the internal search engine, thus not only leveraging open standards, also incorporates industry best practices.

With that, you will probably benefit to enable the IBM WebSphere Commerce search capability in a starter store, so that you can get a good idea what is available out-of-the-box with the product.

Here is a link to the IBM WebSphere Commerce information center documentation regarding WebSphere Commerce search:
http://publib.boulder.ibm.com/infocenter/wchelp/v7r0m0/topic/com.ibm.commerce.developer.doc/concepts/csdsearch.htm

At a high level, WebSphere Commerce search provides the following key business benefits:

• It is built on the top of open architecture.
• It contains a rich set of search functionality for shoppers in starter stores.
• It provides integrated search management tooling for business users in the Management Center.
• It lowers the total cost of deployment and ownership, since its functionality is included as a feature of WebSphere Commerce.

In regards to starter stores, here is a link to the IBM WebSphere Commerce information center to summarize what is available-to-market in the product:
http://publib.boulder.ibm.com/infocenter/wchelp/v7r0m0/topic/com.ibm.commerce.starterstores.doc/concepts/csmsearch.htm

This blog entry covers the steps required to enable search for a starter store.

This is where you should start to understand how to setup search for a starer store:
http://publib.boulder.ibm.com/infocenter/wchelp/v7r0m0/topic/com.ibm.commerce.starterstores.doc/refs/rsdfepfeatroadmap.htm

As a side note to this link, I was only able to install Feature Pack 2, due to limited resource access, but I still brought IBM WebSphere Commerce up to Fix Pack level 5 (WCS v7.0.0.5).

The following list of steps is the procedure that I took in order to enable a fully integrated search solution into a demonstrable starter store:

1. Install "WebSphere Commerce Developer Enterprise" version 7
2. Update "WebSphere Commerce Developer Enterprise" to version 7.0.0.5
3. Install "Feature Pack 2" (preferably feature pack 3 or higher)
4. Enable the Store Enhancement Features
1. cd 'WCDE_installdir'\bin
2. enableFeature.bat -DfeatureName=store-enhancements
5. Publish the Madisons Feature Pack Store Archive:
1. Publish Madisons-FEP.sar
6. Enable the Solr foundation
1. cd 'WCDE_installdir'\bin
2. enableFeature.bat -DfeatureName=foundation [DsolrHome=C:\IBM\WCDE_ENT70\search\solr\home]
7. Setup the Search Index:
1. cd 'WCDE_installdir'\components\foundation\subcomponents\search\bin
2. setupSearchIndex.bat -masterCatalogId 10001 -instance WCDE_ENT70 -dbuser db2admin -dbuserpwd db2admin [-solrhome C:\IBM\WCDE_ENT70\search\solr\home]
8. Preprocess the Search index:
1. cd WCDE_installdir\bin
2. di-preprocess.bat C:\IBM\WCDE_ENT70\search\pre-processConfig\MC_10001\DB2\ [-fullbuild true] [-localename en_US]
9. Test the current Solr index to ensure that a request can be recognized:
1. http://host_name/solr/Default/select?q=*%3A*
10. Build out the index (first make sure to start the test server in toolkit):
1. cd 'WCDE_installdir'\bin
2. di-buildindex.bat -masterCatalogId 10001 
11. Test the indexed Solr index to ensure results are returning:
1. http://localhost/solr/MC_10001_CatalogEntry_en_US/select?q=catentry_id:10251
12. Enable the store to display the search breadcrumb and faceting filters:
1. Open Management Center
2. Click "Management Center Tools" menu and select "Store Management"
3. Select the "Madisons" store and click the "Catalog" tab
4. check "Search-based navigation"
5. click Save
13. Test live on the starter store:
1. http://localhost/webapp/wcs/stores/servlet/Madisons/index.jsp
2. http://localhost/webapp/wcs/stores/servlet/Elite/index.jsp

Using Contracts for eCommerce in Websphere Commerce

As per the request from one of the comments on the blog, this is a high level view on contracts using Websphere commerce and by no means a complete coverage of contracts as it's such a vast topic.

Contracts: This is one of the most interesting concepts when dealing with both B2B and B2C eCommerce systems. Every store published out of the box is associated with a default contract. Lot of clients use contracts on B2C site, if the requirements for a B2C site include using contracts or employment purchase programs using contracts. It is a best practice to use EliteStoreFront or if you are still using V 6.0 (Advance B2B).

Why are contracts required? These are good reasons.
1. If you want to use the same offer price lists as your regular customers but provide a percentage or fixed amount off of the same prices to a subset of customers such as Employees or Students.
2. If you want include or exclude a set of categories or products to a different set of customers.
3. In the case of B2B systems, contracts allow creating separate pricing tiers for different set of customers.
4. Contracts can extend existing contracts or new contracts to provide multi-tiered pricing.
5. You can also have separate shipping prices per contract.
6. Payment methods can also be setup per contract.

How do you create contracts? Essentials for creating a contract.
Organization->Account->Contract

1. Create organization--using orgadmin console.
2. Create Account --(Accelerator, sales-> accounts)
3. Create Contract --(Accelerator, sales->accounts->new contract)

Important concepts related to contracts:
Catalog Filter : Tooling to provide pricing and catalog filters.
Pricing: (Pricing percentage off/fixed amount off) can be used to increment or decrement the default offer price for a subset of customers.
This is provided in Accelerator and Management center. The one is management center is not restricted to a store and can be shared across stores and contracts.
Include/Exclude Catalog: Allows to include exclude catalog specific set of catalog entries by specifying which categories,catalog entries, attribute dictionary attributes.

Solution Faceted Search

Search is an integral part of every company with online presence and corpus data both structured and unstructured. The goal is always to navigate customer find the product/content in a fast efficient way to purchase or view.

What is a facet: As per the Google definition, it's a particular feature or an aspect of something. For those of us from SQL background think of facets as groupBy functionality. As we all understand to perform a groupBy is a complex performance operation from code. In world of searchandize, each facet is modeled as a Dimensions and Dimension Values using a Search engine(It could be any engine Endeca or SOLR or something else)

E.g. Dimensions: Color, Size, Price, Men's, Shirts
Dimensions Values: Red,Blue,Black, White
Ranges: In case where you have e.g. Authors on books or Price where we have a lot of values, it is a good idea to go with a range.

Faceted Search process:
Most of the Search engines have an ETL process to merge\Join data from various sources and massage\clean data, if you are data is not good (e.g. If a company sells USB drive, GB would be a facet but if the value is not clean as an G B or GB. or G.B for GB, it would translate to wrong facets in the front end). hence it is important to have good data.
Once you have get past cleaning data, the process is to build Attribute dictionary and map it to the data and build indices off it.
From the front end, the Navigation is driven by state N=0 that would provide all data from Search and as you drill to specific data, you change the Navigation state. Most of the times, the navigation state is encrypted for front end customers to make the URL smaller. There are other parameters such as Navigation filters.

Endeca | Programmer primer | Objects Query\Results\Connection

A lot of customers use Endeca or SOLR as their search engine in WCS world and this primer series on Endeca is to provide some basics:

Information Transformation Layer: Transforms the source data into indices for MDEX Engine. The transformation process does not change the original data but only it's representation within your Endeca Impl.

Query (Object ENEQuery or sub class UrlENEQuery): Endeca follows one query one page approach. The MDEX is designed to return all of the information required to build an entire page.The MDEX engine is specifically designed this way to reduce the number of queries. There are four kinds of queries:

• Navigation (N) --setNavDescriptors(),
• Endeca Record (R)- setERecSpec(), 
• Dimension Search(D) --setDimSearchTerms(),
• Aggregate Endeca Record (A, An, Au)--setAggrERecSpec.

e.g. ENEQuery nequery = new UrlENEQuery(request.getQueryString(), “UTF-8”);
     ENEQuery nequery = new ENEQuery();
    DimValIdList descriptors = new DimValIdList("123");
   nequery.setNavDescriptors(descriptors);


Query Search results as EnQueryResults object: For any given type of query such as navigation, record search, dimension search, .etc. The top level object returned is EnQueryResults and that could encapsulate other objects.

Endeca Record Object as ERec Object: It contains all the information regarding the Endeca record including Endeca Properties (name\value pairs) and Information about record's location within the dimension hierarchy.

Connectivity object HttpENEConnection: enables connections with MDEX engine.
     e.g. ENEConnection nec = new HttpENEConnection(eneHost, enePort);


Query Exceptions : There are multiple exceptions ENException, ENEConnectionException objects.


Sample code for retrieval of query results:

//Create an ENEConnection
ENEConnection nec = new HttpENEConnection(eneHost, enePort);
//Create a query from the browser request query string
ENEQuery nequery = new UrlENEQuery(request.getQueryString(),
“UTF-8”);
//Execute the MDEX Engine query
ENEQueryResults results = nec.query(nequery);

Endeca overview ---High level Architecture

Endeca is a very widely used search engine for Web and E-commerce applications and it is very popular with lot of WCS clients. High level architecture components of include:

MDEX Engine:  The MDEX engine is the indexing and querying engine that provides the core functionality for all Endeca. MDEX Engine is stateless and hence requires the query to have all the parameters to be provided each time.

Endeca Workbench: The Endeca workbench is a web based tools that allows business users to configure and administer an Endeca application for Merchandising, content spotlighting, search configuration and usage reporting. The main functions are as follows
Rule Manager: Add\Edit\Activate\Deactivate rules and preview using the preview application.
KeyWord Redirects: Create and manage keyword redirects.
There are multiple functions such as Resources Lock Page, Instance Configuration Page, Dimension Order, Stop Words Page, Phrases Page, Thesaurus, Daily Reports,User Management  and EAC settings, EAC Admin Console.

Endeca Platform Services:  This consists of mainly Endeca Information Transformation Layer and Endeca application controller (EAC).
EAC consists of EAC central server and agents. EAC centeral server manages all agents.
Data Foundry: consists of forget program and related components.
Presentation and logging API's: API's to MDEX Engine and Log Server.
Logging and Reporting system.
Reference Implementation: Sample developer studio project source data for multiple platforms.
emgr_update: Utility to update instance configuration to Endeca workbench.
Endeca Control System: The Job control Daemon (JCD) and the control Interpreter.
     Forging \ETL Server: Process of gather data from various sources and building the indices is Forging.
     Pipelines: Data handling components that transforms Raw data to Indices and Deploy them


Endeca Presentation API: provides interfaces to log server and MDEX Server. The API is available in 2 flavors for Unix and Windows.