Commerce Server Blog

Commerce server site term is a set of valid values (in the form of key value pair) which can be used in conjunction with Profile system. For example, there is no point to ask user the month name – rather it would be good to provide month information in dropdown and the user can select one from it. By this, we are making the application to store uniform values. So, the common and unchanged items can be created as site terms.

By default commerce server creates many site terms, includes user title, user status, user role, months,weeks, year, etc. We have flexibility in creating our own profile objects by creating new tables in the database but the same flexibility is not applicable for site terms. All site terms are stored in a single table under profile database and the table name is “MemAttrib”. This table not only stores site terms but also stores product definition information. Few of the important fields to remember are

CatalogName:  This field is used to differentiate whether the data belongs to site term or product definition. If catalogName field value contains “Site Terms”, that means the row belongs to site term and if it contains “Profile Definitions” means the row contains profile definition information.

MembershipName: This field is used to store site term or profile definition name.

AttributeName: This holds site term key name.

DisplayName: This holds site term value.

The below query can be used to fetch all data of site  term “Country”

Note: Since we are storing all information in a single table (unlike catalog tables), we don’t have the flexibility of using same site term for multiple languages.

For past few weeks, I am seeing few architecture questions in MSDN communities on how to mold catalog system to address client requirements. Catalog system is heart of the ecommerce solution and any architecture flaw can lead the application into failure. While doing some of the SME reviews to ecommerce projects, I also feel that developers might of done over architecture without knowing the strengths and weakness of catalog system. 

Catalog system contains following items.

• Base Catalogs: Catalogs created in commerce server are base catalog.
• Virtual Catalogs: Catalogs that are aggregated from one or more base or virtual catalogs.\
• Catalog Sets: Grouping of one or more catalogs to target to the user is called catalog sets.
• Categories: A category is a logical group of products or sub-categories.
• Product/Product families: A product is a individual item in the catalog and if that product has multiple variants then it is called product family.

Microsoft has shared some of the architecture suggestions to be considered while developing CS2009 catalog system. Here are the few items which I collated from msdn site or documents published from Microsoft.

• Supports up to 10,000 catalogs: 10,000 base catalogs, 10,000 virtual catalogs, or a combination of both base and virtual catalogs.
• A catalog supports at least five million products. (CS has not been tested with 10,000 catalogs each containing five million products.)
• A catalog can support up to 1,000 property definitions.
• A virtual catalog can include content from up to 80 base catalogs.
• A virtual catalog can include up to one million products.
• A virtual catalog can support up to 10,000 price rules.
• A category can support up to 10,000 products & can be nested up to five layers deep is recommended.
• Multiple product catalogs can share a single SQL Server full-text catalog.
• Add your own user-defined attributes at the catalog level and/or Category /Product level, as needed. Catalog attributes, such as currency, unit of weight measure, locale, and catalog name are available by default. You might want to add your own catalog attributes, for example, to store information about the vendor that supplies the products in a catalog.
• Create separate catalogs (base or virtual) if search is to be restricted across a collection of products.
• After you create a product, you cannot assign a different product definition to it. If you create a product based on product definition “mobile”, at a later date you cannot change the product to be based on product definition “Electronics”. You can, however, change product definition “mobile”, for example, by adding/removing a property.
• You cannot change a data type of a property after the property is created.
• You cannot assign a new product definition, or change a data type, after it is in use because other products or properties might be affected by the change.
• If you need to search on a custom property, you should add an SQL index to that property.
• Fewer catalogs are better, depending on hardware and your specific scenarios. This guideline is valid up to around 500,000 products per catalog.
• A materialized catalog is a snapshot of a virtual catalog.
• If the virtual catalog contains a number of base catalogs and/or the base catalogs contain a lot of products and categories then materializing the virtual catalog can result in better runtime performance.
• If the content of the base catalogs changes frequently then materializing the virtual catalogs will mean frequent rebuilds which might offset the performance gain.
• If the desired performance without materializing a virtual catalog meets your needs then you should not materialize the virtual catalog.
• As a general rule of thumb : start without materializing a virtual catalog and determine based on whether  the desired performance is acceptable or not.
• Do not add a product variant property to any properties that are being used as a Product Identifier property in a catalog. For example, if you use ModelNumber as the identifier for products in your catalog, do not create a product based on a product definition in which ModelNumber appears as a product variant property. If you do, you will not be able to identify variant information based on the product definition in that catalog.
• Do not use the same value for product unique identifiers and variant unique identifiers. For example, you cannot assign stockkeeping unit (SKU) as the product unique identifier and the product variant unique identifier.
• Before you import an XML catalog file, select the Validate XML file option on the Import Catalog dialog box to ensure that all data in your XML file is valid.
• Start the full-text indexing service before you import a catalog. When a catalog is imported into catalog database, the full-text index is created at the same time.
• If you experience poor performance when importing 100,000 to 1 million products into a base catalog, or publishing a virtual catalog of a similar size,
  run DBCC FREEPROCCACHE and sp_updatestats to improve the performance of APIs such as GetProduct and GetProductProperties:
• If you create a .pup package that contains a materialized virtual catalog, after you unpack the virtual catalog, you must materialize the virtual catalog again.
• Delete temporary tables from the MSCS_CatalogScratch database regularly. To improve run-time performance, the Product Catalog System uses the MSCS_CatalogScratch database to store temporary catalog tables.
• Rebuild a virtual catalog in the following scenarios:
• If a virtual catalog is materialized, when any data changes in the associated base catalogs.
• If the virtual catalog is not materialized, whenever the data in the associated base catalogs changes (for example, pricing changes, and hierarchy and relationship changes).
• You must rebuild a virtual catalog whenever you change include/exclude rules or pricing rules.
• Do not rebuild a virtual catalog on a production server. Users will not be able to access the catalog. Only rebuild on staging server. After the catalogs are materialized, you can replicate them to you production servers.
• Limit the number of rules in the virtual catalog. As a general rule you should rely on catalog and category level rules.

The list may be small and remaining good practices, you will learn in real time .

Recently I came across a post in MSDN communities where the query request says ‘how I can give access to the Merchants so that they can add/browse his products using catalog manager”.

The requirement is genuine and we will get such requests from customer regularly. Some of the commerce server developers think that it is not possible as the user of a role (say catalog Administrator or Editor) can able to see all catalogs in a particular site. In few some cases developers has created a separate site for their tenant/merchant to achieve this functionality. In this blog, I am explaining a simple tip which will allow access to provide multiple tenants to their catalog only.

Simple tip: You can achieve this using Authorization manager setting (Azman) and there are no changes to commerce server configuration settings.

• As you might of aware the Azman works with windows authentication. So, whenever you get a new tenant, you should create his user Id and password in Active Directory (AD).
• As a administrator, create a catalog for the tenant. Now if you reload catalogAuthorizationStore.xml in Azman, you can able to see new scope for the catalog.
• Now you expand the scope and assign proper privileges to tenant AD user id.
  
• Now if the tenant opens the catalog manager, he can able to see only his catalogs.

Note: All operations and tasks are copied from parent to scope level and I recommend to create proper roles and task at scope level too.

In this example, I have assigned my ID to catalog editor role in – Adventure works catalog but not in “Adventure 2 works” catalog. When I open the catalog manager, I can only see adventure works catalog but not the other one (as shown in the image below).

For more information on Azman, refer to msdn – http://msdn.microsoft.com/en-us/library/ms914867(CS.70).aspx

This blog is continuation to my blog entry “Creating custom display types in commerce server”. In my previous blog entry, I have explained how can we display adobe flash advertisements and in this blog post, I will explain how can we display silver light advertisements in commerce server. The steps are pretty simple –> Each advertisement will store template ID and the properties. Based on the template Id, commerce server loads the template structure are replace tokens with properties and file output is rendered to HTML.

The steps for creating silverlight display type is pretty simple.

1. Create the HTML required to render for silver light: If you are not aware of the HTML structure – open any silverlight website (silverlight.net) in your web browser, go to code behind and copy the silverlight loading object tag – as shown below

2. Identify the properties that needs to get updated from Marketing manager: In this step, we will identify the tokens when are required to get input from the customer. For example, here I have identified following tokens

• Source Param
• Background
• Height
• Width

so, my template structure will become like this

3. Create a display template into marketing system: You can find the code block on this blog to create or modify the DisplayTemplate and the URL is http://microsoftblog.co.in/commerceserver/creating-custom-display-types-in-commerce-server/

That’s all… Now you can able to see silverlight template in your marketing system. In coming days, I will try to write a blog entry on how to show Google advertisements in commerce server.

Knowing the condition of a SKU is compulsory during checkout process. The sku condition can be “In stock”, “out of stock”, “Pre-ordered”, “Back Ordered”, etc. The status calculation is based on commerce server global settings as well as settings on sku. In this post, we will learn how commerce server calculates inventory.

Commerce server inventory behavior is driven by site resources. To see inventory site resources – follow below steps.

• Open commerce server manager.
• Expand commerce server manager –> commerce sites –> [Your site] –> Site resources –> click on Inventory.

Two site resources setting will play key role in determining the sku condition

1. Ignore missing SKUs: This resource is used to specify whether a missing sku can be treated as in-stock or out-of-stock. If the value is set to –1(true) then the missing sku is treated as in-stock and if the value is set to 0 (false) then the missing sku is treated as “out-of-stock”.
2. Stock Handling: This resource is used to specify whether pre-order and back-order can be associated to a sku. If the value is set to –1(true) then the stock handling exist for SKUs(i.e., a sku can be pre-ordered or back-ordered) and if the value is set to 0 (false) then stock handling doesn’t exist for SKUs.

The below flow chart shows how commerce server calculates the inventory.

In the first condition, we will check whether a product catalog is mapped to an inventory catalog. If it is not then we will determine inventory status on site resource –“Ignore missing Skus”. If the product catalog is associated then we will check the inventory condition based on sku status. If the status is set to disabled then the inventory condition is “out of stock” and if the status is ignored then the inventory condition is “In stock”. If the sku status is “enabled” then commerce server calculates inventory based on site resource “stock handling”.