Fraska Portal

Exploring the WebSphere Commerce world

Featured

WebSphere Commerce, the curious life of a front-end catalog request

Posted by on in Core
  • Font size: Larger Smaller
  • Hits: 18834
  • 36 Comments
  • Subscribe to this entry
  • Print
WebSphere Commerce, the curious life of a front-end catalog request

The life begins in a random internet browser when an unaware user- browsing the Aurora shop- makes a simple request asking for details about the child laptop product. This request can be translated in a Uniform Resource Locator exactly as the following:

http://www.mywcsaurora.com/shop/en/aurora/eletronics/laptops/child-laptop

After just few milliseconds, or maybe few hours mostly depending from the performance of the Aurora shop, the URL assumes the shape of a page, the death of the request:

b2ap3_thumbnail_WCS_liferequest.png 

 

Between the request's birth and its death some many things have happened; I'll try to summarize the "typical life of a catalog request" in a WCS v7 FEP7 "world" marking just the communication "links" between the several components look after the request.

Target:

WebSphere Commerce professionals

Environment:

  • WebSphere Commerce Developer v 7.0.0.8 FEP7
  • WebSphere Application Server 7.0.0.29
  • DB2 9.7
  • SOLR 4.3.0 (local)

IBM HTTP Server and WAS Plugin

From the client browser the request hits directly the IBM HTTP Web Server (IHS). Now, two main factors contribute the proper handling of the catalog request: the WAS plugin module and the a rewriting rule.

Loading of the WAS plugin, http.conf
LoadModule was_ap22_module "C:\IBM\WebSphere\Plugins\bin\mod_was_ap22.dll"
WebSpherePluginConfig "C:\IBM\WebSphere\Plugins\config\webserver1\plugin-cfg.xml"
Context root rewrite rule
RewriteRule ^shop/(.*) /webapp/wcs/stores/servlet/$1

 

For the effect of the rewrite rule the URL becomes:

http://www.mywcsaurora.com/webapp/wcs/stores/servlet/en/aurora/eletronics/laptops/child-laptop

 

Hence, IHS sends the request to the WAS plugin; it chooses the WebSphere cluster node which consider to be able to handle the request. Once it takes a decision the request is sent to the HttpTransport instance of the chosen node.

Part of the plugin-conf.xml ServerCluster configuration
<ServerCluster Name="server1_Cluster" ... >
<Server Name="server1" ... >
<Transport Hostname="..." Port="10080" Protocol="http"/>
</Server>
...
</ServerCluster>

According to the above configuration the WAS plugin will send the request to the server1 HttpTransport using the port 10080 and the protocol http.

 

WebSphere Commerce server, HttpTransport and WebContainer

The server1 has an HttpTransport instance- WCInboudDefault- waiting on port 10080; WCInboudDefault will take any request and pass them to the Web Container; for this reason the HttpTransport is also called Web Container transport chain.

The transport chains of server1

WCS_liferequest_2.png

 WCInboudDefault takes the incoming request and sends it to the Web Container. At this point, the next step is determined by the following factors:

  • server1 has the WebSphere Commerce enterprise application- WC.ear- deployed and running
  • WC.ear has a web module- Stores.war- which maps the context root /webapp/wcs/stores with its Servlet
server1 WC.ear web modules

WCS_liferequest_3.png

 

Piece of Stores.war Deployment Descriptor configuration
<servlet>
...
        <servlet-name>Stores Request Servlet</servlet-name>
        <servlet-class>com.ibm.commerce.struts.ECActionServlet</servlet-class>
        <init-param>
            <param-name>config</param-name>
            <param-value>/WEB-INF/struts-config.xml,...</param-value>
       </init-param>
        ...
    </servlet>
    <servlet-mapping>
       <servlet-name>Stores Request Servlet</servlet-name>
       <url-pattern>/servlet/*</url-pattern>
    </servlet-mapping>

 

WebSphere Commerce server, Stores Servlet

The Stores Servlet gets finally the request; it will start a communication flow with different components: URLMapping, Struts mapping, controller command, forward action and JSP view. Let's review the flow gradually.

Since the URL is SEO-Friendly, the Servlet needs to understand exactly which Controller command should execute; to accomplish this task the Servlert invokes the URLMapper component:; it resolves each token of the URL part just after the context root: /en/aurora/eletronics/laptops/child-laptop. Using the data stored in the tables SEOURLKEYWORD and SEOURL, and matching the pattern indicated in SEOURLPatterns-Products.xml, the URLMapper sends the following information to the Servlet:

  • "en" is the language identification
  • "aurora" is the store name
  • "eletronics" is the parent category
  • "laptops" is the current category
  • "child-laptop" is the product name
  • ProductDisplay is the view name
Part of SEOURLPatterns-Products.xml
<seourl:seoUrlPattern viewName="ProductDisplay">/LanguageToken/StoreToken:CatalogToken/CategoryToken/CategoryToken/CatEntryIDToken</seourl>
<seourl:urlToParamMapping>
    <seourl:mapping name="langId" value="?LanguageToken?"/>
    <seourl:mapping name="storeId" value="?StoreToken?"/>
    <seourl:mapping name="catalogId" value="?CatalogToken?"/>
   <seourl:mapping name="productId" value="?CatEntryToken?"/>
    <seourl:mapping name="errorViewName" value="ProductDisplayErrorView"/>
    <seourl:mapping name="top_category" value="?CategoryToken?"/>
    <seourl:mapping name="parent_category_rn" value="?CategoryToken?"/>
   <seourl:mapping name="categoryId" value="?CategoryToken.1?"/>
   <seourl:mapping name="pageName" value="CatalogEntryPage"/>
 <seourl:mapping name="pageGroup" value="CatalogEntry"/>
</seourl:urlToParamMapping>
<seourl:paramToUrlMapping>
   <seourl:mapping name="LanguageToken" value="?langId?"/>
    <seourl:mapping name="StoreToken" value="?storeId?"/>
    <seourl:mapping name="CatalogToken" value="?catalogId?"/>
  <seourl:mapping name="CategoryToken" value="?parent_category_rn?"/>
   <seourl:mapping name="CategoryToken.1" value="?categoryId?"/>
    <seourl:mapping name="ProductToken" value="?productId?"/>
</seourl:paramToUrlMapping>

 

The control comes back to the Servlet; now, with the help of struts-config.xml, the system resolves the viewname addressing a specific controller command: ProductDisplayCmd; using CDMREG table the Servlet gets the implementation class name: ProductDisplayCmdImpl

Once executed, the controller command ProductDisplayCmdImpl returns the display view name: ProductDisplayView.

Again the Servlet uses the display view name and the struts-config.xml to get the forward action: ProductDisplayView/storeId. Than, using the DISPENTREL table, it catches the view resource path:

ShoppingArea/CatalogSection/CatalogEntrySubsection/ProductDisplay.jsp

So, the JSP ProductDisplay is executed: the first and main thing it does is to call a REST service

http://<solrsearchserver>/search/resources/store/<storeId>/productview/byId/<productId>

REST service called from ProductDisplay.jsp
<wcf:rest var="catalogNavigationView" url="${searchHostNamePath}${searchContextPath}/store/${WCParam.storeId}/productview/byId/${productId}" >    
        <wcf:param name="langId" value="${langId}"/>
        <wcf:param name="currency" value="${env_currencyCode}"/>
      <wcf:param name="responseFormat" value="json"/>        
       <wcf:param name="catalogId" value="${WCParam.catalogId}"/>
 </wcf:rest>

 

Search Server modules

The WAS search server has the enterprise search application- Search.ear- deployed and running. There are 3 modules: Search-Preview, Search-Rest and Search-Solr.

Search server and its modules

WCS_liferequest_6.png

The request, "evolved" in a RESTful service call, hits the search server and in particular the Rest servlet of the module Search-Rest mapped with the context root /search/resources. One of the task of the Rest Servlet is to know which search profiles it has to use in order to create a proper search expression.

To do so, the servlet uses the information stored in the wc-rest-resourceconfig.xml.

Part of the wc-rest-resourceconfig.xml content
<GetUri uri="store/{storeId}/productview/byId/{productId}" description="Get product by unique ID"
searchProfile="IBM_findProductByIds_Details,IBM_findProductByIdsWithAttributesAndAttachments,IBM_findProductByIds_Summary,IBM_findProductByIds_Summary_WithNoEntitlementCheck,IBM_Admin_findProductByIds"/>
 

At this point the Search-Rest module starts a communication flow with the Search-Solr module.  In fact, the Rest Servlet sends the request- plus the list of search profiles- to Search-Solr Expression Provider. According to the rest resource configuration the search profiles configured are:

  • IBM_findProductByIds_Details
  • IBM_findProductByIdsWithAttributesAndAttachments
  • IBM_findProductByIds_Summary
  • IBM_findProductByIds_Summary_WithNoEntitlementCheck
  • IBM_findProductByIds

 

The Expression provider consolidates the request and creates a search expression the SOLR server can perfectly understand. Now the request has evolved again in a SOLR search query.

It's time for the SOLR server, mapped using the web Search-Solr module, to elaborate the request and provide finally an answer.

After few milliseconds- or maybe seconds ... again it depends from so many factors- the answer is ready and the SOLR server sends the results- under the format of a JSON page- to the caller: the Search Expression Provider. It could eventually changes the answer according to the logic of the post process elaboration.

The request is now a JSON page ready to go back to the WC enterprise application.

 

Back to WC ear

The client of the REST service- the ProductDisplay.jsp- gets an answer: the JSON page. In order to use this data, the results have to be integrated in the business layer of WCS. In other words, they have to be converted in nouns.

The Java code under the wcf:rest tag takes the JSON and creates the catalog nouns. It's able to do it using the Catalog Business Object Mediator. In fact, this component, using the configuration stored in wc-business-object-mediator.xml, generates the BOD Nouns the JSP code can perfectly manage.

Easy life for the JSP now, because it can render the results in the way it prefers and the request finally "dies". RIP.

 

Final consideration

The front-end catalog request has been a short life but very intense thought. It got different evolutions: URL SEO-Friendly, URL not so SEO-Friendly, Servlet request, Search profiles, SOLR query, JSON code, BOD Nouns. Wow, so many changes in a really short gap of time! Don't you think so? 

 

Useful links

Rate this blog entry:
5
Tagged in: REST SOLR WAS Plugin WebSphere Application Server WebSphere Commerce

Comments

Leave your comment

Guest
Guest Sunday, 31 May 2020

Most Popular Post

WebSphere Commerce, the curious life of a front-end catalog request
Core
Rate this blog entry:
5
36 comment(s) 18834 hits Read More
on 08 October 2014
WebSphere Commerce, the SOLR extension index
Administration
Rate this blog entry:
4
52 comment(s) 16962 hits Read More
on 09 July 2014
WebSphere Commerce, Data Load and SOLR Delta Index
Data Load
Rate this blog entry:
0
128 comment(s) 16246 hits Read More
on 04 June 2013

Tag Cloud

Performances Management Center Thank You Troubleshooting Delta WCUserDistributedMapCache Content Precision Marketing Quality Assurance Team WebSphere Commerce Developer RAD CommandLevelAuthorizationCacheCmdImpl Promotions SOLR FEP7 Subcore SoapUI Store Quality Landing page InitializationServlet Search Expression Provider DataLoad WebSphere Application Server Search Navigation Flow Data Model Coupons WAS Plugin Cores REST Web Activity ATP WebSphere Commerce Tables delta Inventory Search Expression Processor Javacore Admin UI ClassNotFoundException Migration Dynacache preprocess Deploy non-ATP JR47273 Core Validation Marketing European stores Toolkit Data cache Index Congratulations Deadlock

Categories

Latest Blogs

WebSphere Commerce, CommandLevelAuthorizationCache
Cache
Rate this blog entry:
0
Comments (47) Hits (4280)
Posted by Francesco Schettini on 08 December 2016
WebSphere Commerce v8, toolkit exception, ClassNotFound db2
Administration
Rate this blog entry:
1
Comments (36) Hits (5340)
Posted by Francesco Schettini on 18 April 2016
WebSphere Commerce, ATP migration
Store
Rate this blog entry:
0
Comments (37) Hits (6883)
Posted by Francesco Schettini on 28 March 2016
WebSphere Commerce, the curious life of a front-end catalog request
Core
Rate this blog entry:
5
Comments (36) Hits (18834)
Posted by Francesco Schettini on 08 October 2014
WebSphere Commerce, Performance analysis of few European stores
Performance
Rate this blog entry:
0
Comments (27) Hits (4950)
Posted by Francesco Schettini on 22 July 2014