In this post, I wanted to describe the major subsystems of Commerce Server…

The Catalog System
The product Catalog system provides a managed taxonomy for storing and querying the hierarchical data that is utilized to represent goods or services for sale made available for offer to customers utilizing the system. The system is comprised of:

•    Schema – This is defined in a managed capacity to identify the item and category entities and resultant attributes that go into the catalog. Data can be multi-lingual and stored in any language supported by Windows without duplicating records for other languages. Only a single currency supported per defined attribute though – this can be translated utilizing an exchange rate table or multiple currency attributes stored per entity.
•    Base Catalog – This is an instance of a given schema
•    Virtual Catalog – This is an abstraction of one or more Base Catalogs. One can – by defining inclusion and exclusion rules – merge catalogs together, partition them apart, or override data (e.g. – keep all attribute data points the same from the base catalog item except perhaps just a price change). The main benefit – behind obvious filtering for presentation – is the ability to have data stored once but prepared for many different consumptions with only the data that needs to be changed for any given consumption scenario being changed – and all other underlying data remaining the same. Some typical real-world scenarios are:

o    Merging catalogs from various suppliers into a single catalog for presentation on a site
o    Overriding individual data attributes but leaving the rest the same for things like special customer discounts (typical in Business-to-Business (B2B) scenarios) and seasonal data changes (e.g. – marketing a coat differently in winter versus summer).
o    Or any combination thereof!

•    Catalog Sets – This feature allows Catalogs to be targeted to a specific user at the time they browse the site. For example, User A will see Catalog 1 whereas User B will see Virtual Catalog 2.
Catalog data is stored in its own set of SQL Server tables. These can either live in the same database as other Commerce Server entities, or reside separately. The programming model is all based in .NET and most COM-related infrastructure from prior versions is gone in Commerce Server 2007.

 

The Catalog system features its own caching capabilities to help expedite querying of data when browsing a site.

The Catalog system follows the typical Commerce Server system pattern and implements a site development API, a Web Service API, an Agent API, and a BizTalk adapter.

The Catalog system does not depend on any other Commerce Server systems, with the exception of Catalog Sets – which relies upon the Profile system for targeting against customer records.

 

The Inventory System
The Inventory system is a close sibling of the Catalog system. It is meant to store quantity on hand and define stock-out business rules for items stored in the Catalog system. It provides its own .NET programming model and its data is also stored in SQL Server. It can live either in a standalone database or be shared in a database with other Commerce Server entities.

The site development API, Web Service API, Agent API, and BizTalk adapter support is shared with that of the Catalog system, given the close affinity between the two components.

The Inventory system depends upon the Catalog system.

 

The Order System
As its name descriptively implies, the Order system is all about shopping baskets and purchase orders generated at checkout. Developers can define basket and order schema as a mix of strongly and weakly typed properties. From a Basket perspective, data will be persisted in binary format. This makes searching and doing direct updates to baskets a pretty onerous task; fortunately it is not one that is typically performed every day. With respect to Orders, data storage is a mix of binary storage or what is called XML Mapped Storage – which will map data fields to underlying columns in SQL Server that can be queried directly after an order has been persisted to database.

The Order system also provides what is known as the Pipeline, which is responsible for providing a serial, linear, definable workflow for calculating basket and order totals. Pipelines are COM-based. They date back all of the way to Merchant Server 1.0 (circa 1995-1996), Site Server 2.0 (circa 1997), and Site Server 3.0 Commerce Edition (circa 1998).

What Commerce Server 2007 adds in terms of Pipeline support is x64 component support (as all previous versions of Commerce Server were 32-bit) plus the ability to write components in .NET managed code. Given the seemingly dated technology, begs the question – why on earth are Pipelines still around? The answer is simple – a lot of people use them and there are a lot of 3rd party ISV components out there. That being said, the future will likely not be bright for pipelines, with a managed multi-dimensional workflow solution being desired (such as Windows Workflow Foundation) – though some sort of backward compatibility story is still likely.

 

The Profile System
The Profile system is meant to store data about customers and organizations and enforcing relationships between all of the associated metadata that typically goes with such record types. It does so in a somewhat interesting manner. Rather than providing a managed schema or a black box that cannot be touched by the end developer, it is a case of bring-your-own-schema (though one is provided as a default starting point). The core assumption behind this is that profile data will live elsewhere in pre-existing database – be it SQL Server, Active Directory, or a generic OLE/DB- or ODBC-compliant data source such as Oracle or DB/2.

Conceptually, it works like this:

1.    The core attributes of customers and organizations are defined
2.    These are then mapped to underlying data sources – regardless of their technical origin
3.    A uniform view and programming model (supporting CRUD) then provides a single view of the customer or organization, regardless of where the underlying data is stored

For example, one could have user with:

•    Login information stored in Active Directory
•    Generic profile information (such as name, address, etc.) stored in SQL Server
•    Private personal statistics (such as height, weight, age, eye color, etc.) stored in Oracle

Using the Profile system this could be a single record and rowset as far as the Commerce Server developer is concerned – and it will automatically handle the data update operations to all of the various disparate data sources.

The Profile system does its work through its own custom OLE/DB provider entitled CSOLEDB. All of this is abstracted through the Profile system’s programming model. And speaking of that – the whole enchilada is delivered: site API, Agent, Web Service, and BizTalk adapter.

The Profile system has no dependences on other Commerce Server components.

 

The Marketing System
The Marketing system provides a personalized shopping experience for users of sites constructed with Commerce Server. It is comprised of three principal components:

•    Advertisements – The name is misleading; it really should be content blob. Here, text, image, or multimedia elements can be defined, placed on a page, and then targeted towards specific users. The system features click and impression tracking (to ensure that enough people see the content that they are supposed to see, etc.).
•    Discounts – Like its name implies, personalized targeted discounts can be created at the item level (e.g. – buy item X, get Y off  item X), order level (e.g. – buy $100, get 10% off), or free/discounted shipping.
•    Direct Mail – Create personalized e-mails that can be targeted towards a specific audience (e.g. – Dear John, we know you like X and it is on sale).
Internally the marketing system utilizes a series of pre-built Pipeline components called the Content Selection Framework (for associating content with targeted users) and additional discount components to operate. In some cases, these components can be augmented with user generated code to extend and alter behavior.

Data storage is in SQL Server. The system features a Web Service and Agent API – in addition to the site API, but does not have a BizTalk Adapter. The reasoning behind no BizTalk Adapter is that these elements are represented too differently from one business to another to provide an effectively uniform means of importing and exporting data.

The Marketing system has hard dependencies on the Catalog system (for item discounts) and the Profile system and the Order system (for all discounts).

 

Analytics
The Analytics system collects IIS Web Log data and Commerce Server data from all of the aforementioned systems and aggregates it into a single data mart (with pre-built Extract/Transform/Load (ETL) tasks capable of working in both initial construction and ongoing incremental data population modes). Exposed on top of this report is 35 canned reports, with the provisions made to customize these reports or create new ones.

The ETL processes leverage the same OLE/DB provider utilized by profiles coupled with SQL Server 2000 Data Transformation Services (DTS) tasks to populate the data mart, which itself is based on SQL Server Analysis Services. DTS is used for compatibility with both SQL Sever 2000 and SQL Server 2005 and so as not to require two separate ETL codebases. SQL Server Reporting Services is utilized for the reporting interface on top of the data mart – which provides secure, scheduled or on-demand report generation in a variety of formats such as HTML, Plain Text, Excel, Adobe Acrobat, and e-mail. Standard SQL Server Reporting Services extensibility mechanisms can be used for customizations or new report creation.