WebSphere Commerce extended sites capability enables businesses to create multiple, unique sites to serve different brands, regions or targeted groups of customers. Each of these sites can have a unique look and feel, and can implement business rules and policies unique to the customer relationship (special pricing and product entitlement, for example). Yet the unique sites coexist on the same infrastructure, sharing as much data and business logic as possible to ease operation and management.

This article talks about how to remodel a current e-commerce store into the standard extended sites model such that it would help simplify future creation of hosted stores easily without requiring significant development. This re-model will  help leverage WebSphere Commerce features that are available within the standard extended sites model, such as shared marketing and promotional assets and usage of the available line of business tools for configuration of the hosted sites.

What is the extended sites store model?

Architectural model that provides a selling enterprise with the ability to rapidly build customized sites while also maximizing site management and scalability A complex selling enterprise has multiple go-to-market strategies, each of which targets different kind of customer. Extended Sites provides the infrastructure to facilitate this process. Key is to share as many assets as possible between these sites, to minimize management and maintenance.

E-sites provide an infrastructure to share assets, whether it be catalog data, presentation assets or business objects (i.e. Promotions/campaign data). Extended-site store can be a B2B direct or a B2C direct store.

Some typical extended sites scenarios are

• Multi-Brand
• Brand-specific user interface, product assortment, marketing promotions, and merchandising associations
• Multi-Geography
• Localized products, language, currency, marketing, and business rules
• Customer Segments
• Industry vertical segmentation or customer value/tier segmentation
• Corporate Customers
• Contract pricing, unique approval and registration processes, and customized product assortment
• Business Partners
• Special promotions, specialized product assortment.

Extended sites store model concepts

Asset Store

Is a type of store that is not accessed by customers, but instead holds business data.  Business data may be catalog, campaign, promotions, contracts, presentation, etc. Typical asset stores are Catalog Asset Store, Presentation Asset Store, etc.

Extended Site

Lightweight WebSphere Commerce customer facing store that has very minimal data. Gets the major data from sharing with asset stores. The stores can be customized in order to achieve their uniqueness. For example: product exclusion/inclusion, pricing, tax, etc.

Example

Having explained the concepts of extended sites store model we will now walk through the example scenario of an organization where the current store model was remodeled to extended sites model to implement multiple e-sites each with their own diverse look and feel and data. Some of the requirements that were considered here are:

• Three different B2C e-commerce sites to be implemented each catering to a different brand and hence has its own look and feel and also individual product catalog.
• In addition to the above sites, each brand has its own partner sites where the brands join hands with their corporate partners such as airline sites, credit card companies to assimilate and redeem reward points for purchases on a selected set of catalog.
• User account, orders and shoppers data to be unique across all sites.
• Single corporate ownership for all the above e-commerce sites, hence overlap in business processes, rules etc.
• Need to share infrastructure and be scalable.
  

Organization structure

One of the key concepts in any extended sites implementation is the WebSphere Commerce organization structure that creates and organizes ownership for all the assets. The WebSphere Commerce organization structure provides a framework for the actors, or entities, in the business scenario. This framework is organized in a hierarchical structure, which mimics typical organizational hierarchies with entries for organizations and organizational units and users. The organizations and organizational units in the framework act as owners for the parts of your business. All parts of your business, including customers, administrators, stores, catalogs and distributors, must be owned by an organization or organizational unit. The organization structure and the access control model are closely related, in that the access control model applies access control policies to organizations rather than to individual entities (stores, customers, administrators and so on).

There is a basic organization structure that gets published with the bootstrap data when the commerce instance is created and then there are the addendum organizations that get created when the store model is published. It is always recommended that we begin with the basic store model that gets created when the store model is published and then build upon that.

Figure 1. (click image to enlarge)

The figure 1 above depicts the overall organization structure for our example.

In this figure the following is the legend for the various organizations.

All the other Organizations are created manually through the Organization administration console. We create individual seller organizations for the various Brands Brand1 Seller Organization, Brand 2 Seller Organization and Brand 3 Seller Organization so as to separate the customer assets for the 2 sites tied to these brands. The next level of Organizations – Brand 1 B2C Seller Organization, Brand 2 B2C Seller Organization and Brand 3 B2C Seller organization is created so as to allow scalability in the future should there be a requirement to support  a B2B e-commerce site per brand.

The following are the steps to follow to create custom Organizations:

1. Launch the Organization Administration console and select the Access Management – Create new Organization menu item
2. This will launch the new Organization screen. Figure 2 below shows the details of Organization creation screen. Fill in the following parameters and click ok. Parameters:
   • Organization Name and Description
   • Select the parent Organization as Extended Sites Seller Organization
   • Address



Figure 2. (click image to enlarge)



3. After the Organization is created we now assign roles to it. Launch the Access management → Find Organization page. Type in the name of the newly created Organization and hit “Find”. This brings back the Organization.
4. Select the new Organization from the Organization listing and click the “Roles” button. This will launch the roles assignment page. Assign the roles as shown below. Click “OK” button when done. The figure 3 below shows the role assignment via Organization administration console.
   • Channel Manager
   • Seller Administrator
   • Seller
   • Registered Customer
   • Sales Manager
   • Category Manager
   • Returns Administrator
   • Customer Service Supervisor
   • Operations Manager
   • Pick Packer
   • Receiver
   • Product Manager
   • Marketing Manager
   • Store Administrator
   • Customer Service Representative



Figure 3. (click image to enlarge)



5. To satisfy the requirement of separating shopper data by brand e-sites, ensure that when creating the e-sites via accelerator the checkbox marked “Allow the users of other stores to access this store” configuration is unchecked. This will ensure that when customers create their profiles online they are created with the registered customer role in the appropriate Brand specific seller organization. Figure 4 shows the details of this configuration in the store creation wizard in accelerator.



Figure 4. (click to enlarge)

Presentation asset store relationships explained

The Presentation Asset Store consists of Web assets such as HTML pages, JSP files, style sheets, images, graphics and other multimedia file types. You can also define shipping methods, shipping charges, marketing promotions, and contracts assets and other business rules that are related to the flow and presentation of the website in the presentation asset store. In our example we have to consider the following when deciding what goes into the presentation asset store:

• Each of the 3 brands have completely different look and feel, but they follow the same page layouts and general site flow.
• Each site has different promotional and marketing requirements
• The business rules are common across all the brands
• We have to consider the partner sites for each Brand which have the same the site structure and flow (page layout, check out flow etc) as the brand sites but may have different marketing and promotional requirements.

The figure 5 below shows the model for presentation asset store hierarchy that we designed. Some of the highlights of this model are mentioned below.

• Three presentation asset stores were created:
  • B2C Presentation asset store – This asset store contains all the basic artifacts such as JSPs, HTML, business rules such as taxation, marketing rules, customer segmentation, property files etc that are common to all the B2C sites.
  • Partner Sites Presentation asset store – This asset store contains any presentation artifacts that are unique to the partner sites.
  • Brand Shipping Asset store – This asset store was purely created to manage shipping rules. The reason for creating a separate asset store for this purpose was that the Organization had e-commerce shipping rules that were specific to a brand and hence common to both the B2C site as well as the partner sites for that brand. Hence a brand specific asset store to hold all the shipping rules is created.
• The relationships between the e-sites and the asset stores are managed by creating the appropriate STOREPATHS paths in the STOREREL for the specific STORELTYP. The figure 5 below shows the details of STOREPATHS that are set up between the various e-sites and their corresponding presentation asset stores.



Figure 5. (click image to enlarge)

Catalog Asset Store relationships explained

A catalog Asset store is a collection of catalog artifacts that creates a virtual catalog. The asset store contains one Master catalog and can include one or more sales catalog depending upon the desired configuration. In our example, we consider the following:

• Each Brand to be implemented has its own individual product catalog.
• There is no overlap of products between the Brands sites.
• The partner sites for the specific brand and the brand e-site itself do have an overlap of products.

The figure 6 below shows the model for the catalog asset store hierarchy that we designed. Some of the highlights of this model are mentioned below.

• Three catalog asset stores were created each catering to its specific Brand.
• Brand 1 Catalog Asset Store
• Brand 2 Catalog Asset Store
• Brand 3 Catalog Asset Store
• The Catalog Asset store contains the individual Master catalog since the product sets are common between the specific brand’s B2C site and partner sites.
• The sales catalog is created at the e-site level as the sales catalog primarily direct site navigation and are unique to the specific e-site.



Figure 6. (click image to enlarge)

How to create a Custom Asset Store

Lastly in this section we talk about how to create our own asset store.

1. To create our own asset store we always begin with the existing out of the box store.  Use a base asset store SAR file to start with. Fetch the WC_InstallDir/starterstores/ExtendedSites/ConsumerDirectStorefrontAssetStore.sar file and extract it to a temp directory.
2. Rename the root directory from temp_directory\ConsumerDirectStorefrontAssetStore.sar to any name you want to assign to your custom asset store. In our example we will use CommonB2CStoreFrontAssetStore.
3. Rename any subdirectories inside of the temp_directory having name ConsumerDirectStorefrontAssetStore to CommonB2CStoreFrontAssetStore.
4. Copy all the custom jsps to the temp_directory/ CommonB2CStoreFrontAssetStore directory in their respective directories.
5. If there is a need to include custom struts config entries as a part of the asset store edit the temp_directory /WEB-INF/stores/CommonB2CStoreFrontAssetStore /data/struts-config-update.tpl.xml file.
6. Update the accesscontrol.xml file in temp_directory/WEB-INF\stores\ CommonB2CStoreFrontAssetStore\data if required.
7. Several files need to be customized that contain data that identifies the store archive file and provides publishing parameters.
1. Open the following file in a text editor:< temp directory >\WEB-INF\stores\StoreAssetsDir\data\ForeignKeys.DTD
2. Search for lines that look like these
   • < !--ENTITY STORE_IDENTIFIER_BMP  "ConsumerDirectStorefrontAssetStore"-- >
   • < !--ENTITY STORE_DIR  "ConsumerDirectStorefrontAssetStore"-- >
3. Change the values to match your new asset store name (for example):
   • < !--ENTITY STORE_IDENTIFIER_BMP  "CommonB2CStoreFrontAssetStore"-- >
   • < !--ENTITY STORE_DIR  "CommonB2CStoreFrontAssetStore"-- >
4. Save and close the file.
5. Open the following file in a text editor:
   • < temp_directory >\SAR-INF\store-refs.xml
6. Change the value of ConsumerDirectStorefrontAssetStore to match the value of your presentation asset store name. e.g. CommonB2CStoreFrontAssetStore
7. Save and close the file.
8. Open the following file in a text editor:
   • < temp_directory >\SAR-INF\unpack.xml
9. Change the value of ConsumerDirectStorefrontAssetStore to match the value of your presentation asset store name. e.g. CommonB2CStoreFrontAssetStore
10. Save and close the above file
11. Re-package the sar file.
12. Copy your updated sar file to the following directory:<WC_installdir>\starterstores\ExtendedSites

Conclusion

E-sites provide several advantages including data shared, presentation sharing, ease of management, scalability, rapid store launch. There are many e-site models to consider: brands, geography, partners, segments, and business models.

The key is to plan for and design the store model accurately while considering asset stores, presentation catalog and business logic.

• Which assets will be shared in the asset stores?
• What future capabilities are expected out of the store model?
• Organizational structure plays key role in granting access to catalogs, business logic
• Catalog configuration depends on requirements for sharing data across sites and managing administration access for merchandisers