Fraska Portal

Exploring the WebSphere Commerce world

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.

WebSphere Commerce, Review of the Search Navigation Flow

This time I prefer report this fundamental topic just with a schema I draw looking at the following IC pages:

It's the combination of the above documents; the following schema remarks the different interaction WCS runs in order to get Catalog information from SOLR.

I hope you can enjoy!

 

FIRST PART: from Request to Search Expression

SearchRequest_flow_1_20140708-081219_1.png

 

 

SECOND PART: from Expression to Search Response

SearchRequest_flow_2.png

THIRD PART: from Search Response to BOD noun

SearchRequest_flow_3.png

 

 

 

WebSphere Commerce by default includes more than 200 policies to meet the most common access control needs of the different kind of business models. To simplify the handling of these policies, Commerce arranges them in groups, calles Policy Groups where the Organizations can subscribe to.

 WebSphere Commerce Policy Groups

The InfoCenter reports the list of the policy groups.

The default policies are organized into two levels:

  1. Role Based also called Command Level (complete list);
  2. Resource Level (complete list).  

Hence, the Policy Manager checks:

  1. if the user is allowed to execute the Command (command level)
  2. if the user is allowed to access the Resource (resource level)

The resource level check is done only if the command level check is satisfied.

 

The authorizations are basically rules allow a group of users to run set of actions on specific resources according to defined relationships.

Users, Actions and Resources in WebSphere Commerce

WebSphere Commerce defines those rules with XML assertions called policies. Each policy is defined in the following way:

<Policy Name="value"
        OwnerId="value"
        UserGroup="value"
        UserGroupOwner="value"
        ActionGroupName="value"
        ResourceGroupName="value"
        PolicyType="value"
        RelationName="value"
        RelationGroupName="value"
        RelationGroupOwner="value">
</Policy>

The persistent side- stored in the DB- has the following data model mapped with the previous definition:

WebSphere Commerce Data Access Control Model

Most Popular Post

WebSphere Commerce, the SOLR extension index
Administration
Rate this blog entry:
4
WebSphere Commerce, Data Load and SOLR Delta Index
Data Load
Rate this blog entry:
0
WebSphere Commerce, FEP 7, SOLR index pre-process error
Administration
Rate this blog entry:
0

Latest Blogs

WebSphere Commerce, CommandLevelAuthorizationCache
Cache
Rate this blog entry:
0
WebSphere Commerce v8, toolkit exception, ClassNotFound db2
Administration
Rate this blog entry:
1
WebSphere Commerce, ATP migration
Store
Rate this blog entry:
0
WebSphere Commerce, the curious life of a front-end catalog request
Core
Rate this blog entry:
5
WebSphere Commerce, Performance analysis of few European stores
Performance
Rate this blog entry:
0