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.

After deploying couple of pages/web parts/user controls, the site stopped working. I am getting wired error “An unexpected error” on the screen and the event log is clear – no events.

Its very strange to found that SharePoint will hide debugging information and all commerce server developers know that debugging is not easy in commerce server 2009. First my concentration went on WSP package – thinking that there might be some problem with WSP package which is leading some UI problem and SharePoint is not logging any events. But, I have managed to get rid of that error screen completely. The solution is to change a couple of entries in website web.config file. Modify the line <SafeMode MaxControls=“200“ CallStack=“false“… /> to <SafeMode MaxControls=“200“ CallStack=“true“… />

and also we have to set custom errors to ‘Off’ .
<customErrors mode=“Off“/>

That’s it, I stopped getting fancy ASP.NET custom page and able to see full stack trace and also errors in the eventlog. Now my development has got little bit easier!!

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 .

After setting up the website using SharePointCommerceServicesConfiguration tool, sometimes you may get following error when you try to open the website.

This error is because the commerce server site name is different than what is mentioned in the application configuration file. To fix this issue, we have to correct the site name value in web.config and channelconfiguration.config file.

In most of the B2C web sites, the user account creation process is pretty simple, i.e., the user can able to login to the application once he register in the website. The same process will not be applied for B2B websites as the user has to go undergo some organization process (may be contract sign, security deposit, etc). So, how can we implement workflow in registration process.

For this, we can leverage user object’s account status field. It will take three values – “Inactive”, “Active” and “Requires Approval” and by default commerce server sets this field value to “Active” on user object creation. We will make the user’s account status to “Requires approval” in commerce server on account creation – that means he can’t log in to the application. The business user completes their formalities and can change the user account status to active from business tools. Once enabled, the user can able to log into the application.

I foresee couple of options for you

1. Create a class which extend OperationSequence. This class performs account status update operation through API. Inject this class in channel configuration at “CommerceUpdateOperation_UserProfile”.

2. The second option is creating insert trigger on UserObject as shown below.