Launched in 1994, www.microsoft.com has grown from its original role as a Microsoft® technical support Web site to become one of the largest and most complex business Web sites in the world. The site has matured into one of the enterprise’s most important marketing vehicles, delivering support and product information on behalf of more than 300 different marketing groups at Microsoft.
Prior to 1999, this product information reached over one million people who visited www.microsoft.com daily. Customers who wanted to acquire a product were referred to a retailer’s toll-free number or online retail Web site.
Many of Microsoft’s products, which include hardware and books as well as software, are retail products well suited to Internet online shopping. To take advantage of the rapidly increasing popularity of the online sales channel, the company decided to build a storefront to www.microsoft.com. In February 1999, Microsoft implemented Shop.microsoft.com, a powerful new electronic commerce site that makes it easy for customers to order products directly over the Web, from the online retailer of their choice.
Shop.microsoft.com aims to give one of the best shopping experiences of any electronic commerce site. It is available twenty-four hours a day, seven days a week and interfaces with a wide spectrum of reseller sites. Shop.microsoft.com expects up to 200,000 online shoppers per day.
Before Shop.microsoft.com, visitors to www.microsoft.com could browse product information and special offers, but could only place orders by contacting a Microsoft reseller. Now, with Shop.microsoft.com, shoppers can move easily from browsing product information to buying the product. Shoppers can browse the extended catalog and add items to their shopping basket. At checkout time, they can choose an online reseller by clicking one of the reseller icons that appear in the Shop.microsoft.com checkout section.
Shop.microsoft.com transfers the customer and her shopping basket seamlessly to the reseller site for pricing, payment, and delivery. At the reseller site, she can compare prices, possibly see whether a product is in stock, and learn about additional services or product tie-ins that the online retailer may be offering in conjunction with the products in the shopping basket.
Information about the sale is later returned to Microsoft by the reseller, and is analyzed as a key part of the product marketing process.
Microsoft created Shop.microsoft.com with two main goals:
To make the site accessible and easy, the shopper interface had to support a wide range of Web browsers. In addition, the shopper interface had to provide users with a simple way to access the wide selection of Microsoft products. This was possible by providing search, navigation, and selection into the different software, hardware, and book products.
The site is a single Internet storefront for Microsoft products, books, and publications. Therefore, systems integration had to ensure high volumes of pricing and product changes with that of corresponding changes at Microsoft-internal and reseller sites.
The reseller interface had to meet the needs of a wide variety of reseller online systems. It had to be designed to be easy for new resellers to come aboard, no matter how their own sites had been implemented. The interface is based on open Internet protocols allowing simple integration with other proprietary systems.
The reseller receives shopper and basket information via a form post, and later returns order status data to Microsoft using the content deployment features of Microsoft Site Server. The first page at the reseller provides the transition from Shop.microsoft.com’s interface to the reseller’s own graphic interface. After this first interface page, the reseller is free to process the shopper’s order information using their own branded graphics standards.
Making the online store robust requires good site security and well-designed batch systems integration procedures. Site security of Shop.microsoft.com is maintained, despite the integration of multiple third-party sites, by using encryption and staging for data exchange. The Microsoft electronic commerce technologies deployed for Shop.microsoft.com include Microsoft Site Server version 3.0, Commerce Edition, the Microsoft Windows NT® version 4.0 operating system, and Microsoft SQL Server™ version 6.5.
Shoppers can access the store via Order Now buttons on the www.microsoft.com Web site, or browse product information directly at Shop.microsoft.com. This single virtual store makes it easy for shoppers to find detailed information about most any Microsoft product. When a shopper decides to place an order, she can add the item to a virtual shopping basket and either go to the secure “checkout” area or continue browsing.
To complete the transaction, the shopper can select a retailer or can license directly from Microsoft. By clicking the reseller’s icon in the checkout area, a shopper can compare prices, see whether the product is in stock, and learn about additional services or product tie-ins that a reseller may offer in conjunction with the products in the shopping basket.
The technologies behind Shop.microsoft.com make it easy for online resellers to integrate with their own electronic commerce systems. When a shopper selects a reseller, the shopper’s name, shipping information, and contents of the shopping basket are sent over the Internet to the staging server at the reseller’s site via an HTTPS form post. The data is secured using Secure Sockets Layer to help protect the privacy of the shopper's information. Figure 1 illustrates this process:
Figure 1: Integration of the reseller in the shopping process
On the staging server, a set of scripts sends queries to the reseller’s order processing systems to inquire about the availability and pricing for the items in the shopping basket. If the shopper likes the prices that are returned, she can click the Proceed to Checkout button. The staging server passes the shopper and basket information on to the reseller’s fulfillment systems for order processing and shipping.
The staging server acts as a generic Application Programming Interface (API) at this point, with published rules for data and variable names. All the reseller has to do is link that API to its existing processing and fulfillment systems. Once the reseller has processed the shopper ’s order, the staging server sends information to Shop.microsoft.com, which clears the shopping basket and updates the shopper profile database with the purchase information.
The technology behind Shop.microsoft.com allows for high transaction volumes, while making it easy to tailor the presentation of the store to meet the needs of each individual shopper. Shop.microsoft.com runs on the Microsoft Windows NT Server operating system with its built-in Web server, Microsoft Internet Information Server (IIS) version 4.0, and Active Server Pages (ASP) technology. It relies on Microsoft SQL Server 6.5 to support the Online Store product database, and Microsoft Site Server 3.0 Commerce Edition to manage the storefront and shopping baskets.
Most of the development effort focused on the four central features of Shop.microsoft.com. Key online development focus was on the Storefront that provides item browsing and selection, Checkout/Referral that gathers shipping information and offers a choice of resellers, and the Reseller Interface that posts shopper and shipping information to the reseller. The development of the Batch System Integration feature keeps the store’s online files available and in step with Microsoft’s many internal product and pricing databases and provides reporting back to Microsoft.
Two essential functionalities provided by Shop.Microsoft.com are Catalog Management and SKU Synchronization.
Shop.microsoft.com is a leading-edge, graphically elegant site, and provides shoppers with a user-friendly shopping experience. The goal is to provide shoppers with information they want as conveniently as possible, and allows them to purchase products they have selected, from either Microsoft Direct or a participating reseller, moving them seamlessly from product browsing to purchasing via the store’s referral engine.
The home page allows shoppers to:
Figure 2: Structure of Shop.microsoft.com’s Storefront
One of the focal points of Shop.microsoft.com is the wealth of frequently changing product information available to customers. The site is organized to provide both quick jumps to featured products, as well as easy drill-down functionality through categories and subcategories of products.
For example, customers can easily visit the homepage, click on the software catalog link, and be presented with categories of software. Customers can continue to drill down into any particular area of software such as Development Tools or Internet Products. The category and menu selections make it easy to find the product that will meet their needs.
When customers narrow their interest down to a particular product, they are presented with an overview of the product with easy navigation to the different areas of information such as System Requirements, Frequently Asked Questions, Features, Benefits, and even online Windows® Media Player streaming media demos.
Figure 3: The Overview Page
The Shop.microsoft.com overview page provides customers with complete command over product information, and allows them to compare related products using the small slider boxes underneath the menu bar. This feature allows horizontal comparison—while viewing an online demo for Encarta® Deluxe, the customer can switch to viewing the online demo for Encarta Africana, or any other product in the same category.
The store also allows customers to quickly view their Order Information with Microsoft Direct and associated resellers. Additionally, customers have the option of visiting the reseller’s customer service page by clicking on any order of interest. One-click order status and history are available for customers who order directly from Microsoft.
A product search engine is available to search the entire Microsoft product catalog. The search page allows for detailed criteria refinement including price scale, operating system, SKU number, and keywords.
The Checkout/Referral process allows shoppers to make changes to their shopping basket, and choose a reseller. The shopper is handed off to the reseller after processing registration information.
Adding a product to the basket takes the shopper to the product cross-sell page, where the option of checking out is provided. If the Check Out button is clicked, the shopper is taken to the shopper information page to supply shipping information and if needed, modify existing shopper information from a previous purchase.
The shopper information and basket contents are stored in the store database for transaction tracking and reporting. The Store Choice page is dynamically generated and shows active links to only those reseller Web sites that are currently known to be open. Clicking a reseller icon initiates a secure post of the shopper information and basket contents to the chosen reseller. The transaction data is logged in the store database for reporting.
Figure 4: The Shop.microsoft.com Store Choice Page
When the shopper arrives at the reseller’s online store, the initial page layout is consistent with Shop.microsoft.com. After the initial page, the incoming information is stored in a staging database, and the rest of the sales transaction is part of the reseller’s existing production process. Resellers are free to present their own branded user interface after the shopper arrives at the first page on the reseller site, ResellerStaging.asp, has executed. Graphical guidelines are provided to make the transition from Shop.microsoft.com pages to the reseller consistent and intuitive.
The reseller is responsible for payment, tax, and shipping calculations, and for any order status details or notifications.
The reseller staging page receives the secure form from Shop.microsoft.com containing shopper and product information. Before the page is displayed, product availability and pricing is returned by the reseller’s production system via custom stored procedures. The reseller’s pricing and availability is then presented to the shopper.
A scheduled batch report runs every night against the reseller staging database to return the transaction history for reconciliation with the store database. This data is generated by a series of SQL Server tasks. A regular batch process exports the data into a reporting database, thus allowing data mining by store analysts.
Externally, Shop.microsoft.com’s batch process includes migrating data from Microsoft entities such as software licensing organizations in North America and Europe, importing product and product marketing information, and importing product images for the catalog. Internally, Shop.microsoft.com also migrates data from Store-Staging to Store-Production, and from Store-Production to the Reporting database (see Batch System Integration in the Implementation section, for details).
Shop.microsoft.com’s emphasis on a robust online site is reflected in the design of batch system interfaces. Design goals included data integrity, recoverability, configurability with minimal systems impact, and tools for monitoring and handling exceptional conditions online. The fastest possible execution speeds were sought, compliant with these design goals.
Shop.microsoft.com allows remote customization and tailoring of the product catalog via an administration tool developed to facilitate the selection of featured products and manage the relationships of cross-selling items.
Resellers get updates of current SKUs through a secure Web site. Resellers must check this Web site regularly or implement an automated process that executes a daily information download of the product name, street date and Microsoft’s price per SKU. The street date provides a latency period for resellers. By the time the SKU begins to appear in the referred shoppers’ baskets, resellers should have the SKU stocked and ready to sell.
The Shop.microsoft.com site runs on eight servers:
Figure 5: Physical Architecture
Table 1: Typical Hardware Configurations
| Server | Memory | Disk |
| Web server | 512 MB | 9 GB |
| Store Production Database server | 1 GB | 16 GB |
| Store Staging Database server | 256 MB | 16 GB |
The steps through the purchase process are clearly posted at the top of the Shop.microsoft.com Web pages, making it easy for shoppers to purchase products they placed in their virtual shopping baskets. To ensure transaction security, the shopper is prompted to type a Microsoft Online ID and password, which starts a secure checkout process. The SQL Server 6.5 authorization database validates the information using an Internet Server Application Programming Interface (ISAPI) filter. If the shopper has previously transacted with the online store, the shopper and shipping information fields are automatically filled in with information from the authorization database. This timesaving feature allows the shopper to shop regularly without having to reenter information on each visit.
The Shop.microsoft.com application features three major components: the online store system which uses a product database, the basket and shopper information pages which are integrated with a standard internal Microsoft authentication process, and the reseller staging area which is Microsoft’s connection point to resellers and their proprietary data systems.
Figure 6: System Overview
The Shop.microsoft.com Web application is based on the open HTML3.2 standard. This allows it to be used by many different Web browsers, including Netscape Navigator 3.0 and above and Microsoft Internet Explorer 3.0 and above on multiple platforms including Intel x86 and Macintosh. Core functionality is provided through Active Server Pages. SQL Server stored procedures are used for performance gain and to simplify and centralize some of the business logic.
The Start page’s gray menu bar links to the different parts of the online store.
Figure 7: The Storefront
Most links, such as those to content areas, are static URLs. Links to product selectors contain URL encoded data. For example:
<a href=”/shop/products/prod_selector.asp?intGrp=X&intCat=X”>
configures the product selector with the appropriate product as clicked from the Start page.
When a shopper enters the Shop.microsoft.com site, she is given a shopper ID (a GUID) via a persistent client-side cookie. This cookie indicates only that the shopper has been to the site before. It is used in basket tracking, but not for security or for transaction purposes during the checkout process.
The shopper ID cookie is generated from code in a site-wide include file. Cookie requirements are as follows:
Each independent Microsoft site and product group can place an Order Now button on their Web page. Order Now buttons link to the Shop.microsoft.com site. This interface is defined as:
<form action=”http://shop.microsoft.com/referral/selector.asp” method=POST>
<input type=hidden name=Site_ID value=123>
<input type=hidden name=Originating_URL value=http://www.microsoft.com>
<input type=submit value=” Order Now! “>
</form>
This form post brings up the Shop.microsoft.com SKU selector with the appropriate pricing and licensing for the product.
The product selector is a series of pages that allow the shopper to navigate through the hierarchy of product groups, categories, and subcategories. It is accessed from the homepage by selecting one of the product groups—Software or Books. Selecting one of these links will lead to the Category Selector Page.
Figure 8: Category Selector Page
Area 1 of Figure 8 lists all of the categories that exist for the select group in alphabetical order. Clicking on a category from this list will navigate to the Subcategory Selector page (see next section). Area 2 displays three featured items from the selected group.
Table 2: Application-level Objects as Data Sources
| Name | Purpose |
| Group/Category List | Dictionary containing a list of all categories for a given group. |
| Featured List | Array used to obtain data on featured items. |
The category list is obtained from a group category dictionary by using the group ID as a partial key to the dictionary. The following code shows how to obtain an array from a given GroupId.
aryIds = Split(Application("dictGroupCatList").Value("id1"), "|")
aryNames = Split(Application("dictGroupCatList").Value("name1"), "|")
Figure 9: Subcategory Selector Page
Area 1 of Figure 9 lists alphabetically all of the subcategories in the Group and Category combination selected by the shopper. In this example, the Software group was selected and the Business Software category was selected. Selecting a link in this list refreshes the subcategory page with a list of products from the selected subcategory. Area 2 lists all of the products that fall in the current subcategory. This area is populated by calling a stored procedure.
The Subcategory Selector page is built from application level dictionaries.
Table 3: Application-level Dictionaries
| Name | Purpose |
| Software SubCategory List | Dictionary holding delimited lists of Groups & GroupIDs, SubCats & SubCatIds keyed by Category ID. |
| Hardware SubCategory List | Dictionary holding delimited lists of Groups & GroupIDs keyed by Category ID. (The hardware group does not have Subcategories) |
| Press SubCategory List | Dictionary holding delimited lists of Groups & GroupIDs, SubCats & SubCatId keyed by Category ID. |
The dictionaries are used to create arrays of subcategories for that category. These arrays are used to populate the left-hand column of subcategories, which are hyper-links to the Product Selector page. They pass the group, category and subcategory IDs on the URL as follows:
<a href=”/product_selector/software_selector.asp?intGrp=1&intCat=2&intSubCat=3”>
Each selector page is built dynamically via ASP and Active Directory™ Objects (ADO), and displays a list box representing all products within the selected group. This list box is contained in the application level strings strSoftProductSelect, strHardProductSelect, and strPressProductSelect.
The Pricing and Versions page lists the different pricing schemes and versioning information for any given site ID. This page follows the rules of the similar Product Overview pages.
When the page loads, ADO functions in the ASP call a stored procedure to populate the HTML. The navigation bar on the left posts the user to other product pages for this particular SiteID (which is passed in the URL).
In addition to pricing and version information, this page features Add To Basket buttons that let the user add the product to their basket. These hyper-links post the user to the basket handling ASP page with the particular SKU in the URL, with an eventual redirect to basket.asp.
The Basket Handler page (baskethandler.asp) and the basket stored procedure includes file handles and all non-UI interactions with the database. The pages checkout_1.asp and basket.asp post their information to the basket handler each time they need to remove, add, or update an item in a shopper’s basket.
When baskethandler.asp has been posted to, from either the checkout basket page or the main store basket page, baskethandler.asp first uses the query string parameters to see what operations must be performed. It uses an operation mode to determine whether to remove, add or update a basket element. Baskethandler.asp uses the finishing URL to determine which page to redirect the browser to at process completion. Finally, the calling URL parameter is used to determine where to redirect the browser in the case of an error.
strOpMode = UCase(CStr(Request("operationMode")))
strDestPage = Request("finishingURL")
If Len(strDestPage & "") = 0 Then
strDestPage = Request("destpage")
End If
strErrPage = Request("callingURL")
If Len(strErrPage & "") = 0 Then
strErrPage = Request("errpage")
End If
If Len(strErrPage & "") = 0 Then
HandleError FORM_MISSING,"No error page passed to the basket handler.",""
Response.Write("Error")
Response.End
End If
In the case of adding an item to the basket, the page invokes an ASP function that uses a stored procedure to insert an item into the database. The page uses functions that delete and change the quantity for removing and updating items.
The Cross-Sell page is an Active Server Page that runs one stored procedure and returns a list of cross-selling items to the customer in HTML. This page also serves as a confirmation when a particular SKU is added to the customer’s basket.
When this page is loaded, the particular site ID is passed in via a URL. At this point the ASP runs a function which always returns at least three cross sell products; products may of course have more than three cross-sell products specified. If no cross-sells are defined for the product, three default products are returned. These default products are specified using a custom Administration tool. The cross-sell function then randomizes the cross-sell products returned and if there are more than three cross-sell products it picks three random products to be displayed to the user. When there are more than three cross-sell products, subsequent page refreshes will display different cross-sell products.
' ************* Business Logic
If (intRecordCount > 2) Then
' Pick three random entities for Result Set (may be 25, may be 4)
Randomize()
intLow = 0
intHigh = intRecordCount
intRandOne = Int((intHigh - intLow + 1) * Rnd())
intRandTwo = Int((intHigh - intLow + 1) * Rnd())
intRandThree = Int((intHigh - intLow + 1) * Rnd())
' arySiteCrossSell(3,1)
Do Until aryTempRSHolder(3, intRandTwo) <> _
aryTempRSHolder(3, intRandOne)
intRandTwo = Int((intHigh - intLow + 1) * Rnd())
Loop
Do Until aryTempRSHolder(3, intRandThree) <> _
aryTempRSHolder(3, intRandTwo) And _
aryTempRSHolder(3, intRandThree) <> aryTempRSHolder(3, intRandOne)
intRandThree = Int((intHigh - intLow + 1) * Rnd() + intLow)
Loop
aryRandomNumbers(0) = intRandOne
aryRandomNumbers(1) = intRandTwo
aryRandomNumbers(2) = intRandThree
' Copy random records in offical array
For intLoop = 0 to 2
For intSubLoop = 0 to 5
arySiteCrossSell(intSubLoop, intLoop) =_
aryTempRSHolder(intSubLoop, aryRandomNumbers(intLoop))
Next
Next
Else
' assign official array
arySiteCrossSell = aryTempRSHolder
End If
The Cross-Sell page also features additional icons to continue shopping (which returns the shopper to the RETURN_URL from where they clicked Add To Basket, proceed to the check out, to view their basket via basket.asp.
The continue shopping information will be retrieved via the URL as the location of where the AddToBasket is posted to the SKU selector, and carried through to the cross-sell page. This variable is referenced when the user is sent back to continue shopping.
When the Check Out button is clicked, the user is taken to the shopper information (ShopperInfo.asp) page to supply shipping information and if needed, modify existing shopper information from a previous purchase. The ShopperInfo.asp page presents a Choose Online Store button that targets the Store Choice page.
All shopper information and basket contents are stored in the store database for transaction tracking and reporting. The store choice page shows icons representing resellers of Microsoft products. Clicking a reseller icon initiates a secure post of shopper information and basket contents to the chosen reseller.
Shop.microsoft.com’s interface with an individual reseller is implemented by installing Site Server 3.0 Commerce Edition at the reseller’s site. The implementation is in three parts:
At the point where the shopper arrives with their information at the reseller’s online store, the design and coding of that initial page is consistent with Shop.microsoft.com. After that initial page, the rest of the sales transaction is entirely done through the reseller’s own process.
This is achieved by coordinating the design of Shop.microsoft.com’s final page (StoreChoice.asp) with the first page (ResellerStaging.asp) on the reseller side. These two pages are designed to provide a uniform data transfer, regardless of the details of the reseller’s proprietary e-commerce system.
ResellerStaging.asp is modified by the reseller. Design of the page, branding, cross-sell, color choices, and extra buttons are at the discretion of the reseller, so long as basket specifications are met. Shop.microsoft.com provides graphic guidelines, icons, and tables to help the reseller adapt the page, including:
When the shopper clicks a reseller icon, a form of name-value pairs and a collection representing the basket is posted to the reseller. The transaction is logged in the store database for reporting. Table 4 shows the data sent in the form:
Table 4: Data Set Posted to ResellerStaging.asp
| Post Field Name | Data Type |
| TransactionKey | Variant (String) |
| ShopperKey | Variant (String) |
| ReferrerName | Variant (String) |
| EmailAddress | Variant (String) |
| SKUArray | Variant (Form Field Array) |
| QuantityArray | Variant (Form Field Array) |
| ProductNameArray | Variant (Form Field Array) |
| ERPArray (ListPrice) | Variant (Form Field Array) |
| ShipFName | Variant (String) |
| ShipLName | Variant (String) |
| ShipStreet1 | Variant (String) |
| ShipStreet2 | Variant (String) |
| ShipCity | Variant (String) |
| ShipState | Variant (String) |
| ShipPostalCode | Variant (String) |
| ShipCountry | Variant (String) |
| ShipPhone | Variant (String) |
| ShipExtension | Variant (String) |
| FName | Variant (String) |
| LName | Variant (String) |
| Street1 | Variant (String) |
| Street2 | Variant (String) |
| ShopperCity | Variant (String) |
| ShopperState | Variant (String) |
| ShopperPostalCode | Variant (String) |
| ShopperCountry | Variant (String) |
| ShopperPhone | Variant (String) |
| ShopperExtension | Variant (String) |
| ShareOptout | Variant (Boolean) |
| ContactOptOut | Variant (Boolean) |
After posting the data, Shop.microsoft.com invokes ResellerStaging.asp iterates through the basket arrays and stores them in the Basket Table. Once the ShopperKey is stored in the ShopperMapping table, Shop.microsoft.com invokes reseller-specific code to map ShopperKey to the reseller’s key. Control is then passed to reseller-specific code to continue reseller order fulfillment.
The reseller runs a batch report at nightly intervals against the staging database, to return the transaction history for reconciliation with the store data. A regular batch process exports the master data into HTML tables, allowing offline analysis.
Transaction Reporting returns data from the Reseller back to the Shop.microsoft.com referral server. This happens daily and includes:
These actions are performed by a series of SQL Server scheduled tasks that run on the reseller database server, as follows:
Table 5: Scheduled Tasks
| Job Name | Frequency | Function |
| ReturnTransaction | Daily | This job executes a stored procedure that populates the ReturnTransaction table with purchase transaction data posted during the past 48 hours.
The stored procedure accepts a single parameter that is equal to the number of hours. Thus, the 48 hour time range (from past to present) can be changed to support troubleshooting efforts. By increasing the number of hours, potentially more records will be inserted into the ReturnTransaction table. Other than increasing the amount of data, no harm will be done to downstream processes, which were designed to accommodate this situation. |
| ReturnTransactionBCP | Daily | This job executes a bulk copy using the standard BCP console application that comes with SQL Server 6.5. This produces the file that contains the data from the ReturnTransaction table. |
| ReturnTransactionEncrypt | Daily | This job executes an encryption utility that encrypts the file and places it in a folder on an IIS FTP virtual directory. This encrypted file is available for retrieval by the store referral server. |
The integration of batch systems is achieved by a series of batch processes that migrate external and internal data to the Store-Staging environment, followed by a bulk copy of data from Store-Staging to Store-Production, using a batch process.
Figure 10 shows the relationship between the Store-Staging and Store-Production environments, which are described in more detail below.
Figure 10: Store-Staging and Store-Production Environments
The Store-Staging Environment consists of a server with SQL Server 6.5, with the following databases:
The Store-Production Environment also uses SQL Server 6.5 and includes the following databases.
Data from StoreProduct DB in the Store-Staging Environment is populated through a series of stored procedures.
FeedStore: Contains data about the different SKUs (part numbers) and their different attributes. It stores prices for software and hardware products, but not for books.
Apart from providing SKU level and pricing information, Feedstore provides data on ISOCountry, ISOLanguage and ISOCurrency and on Denial tables like Denial Order Address, Denial Order Alias, Forbidden Country, and so forth.
Each night, the batch import process bulk copies a number of tables from FeedStore (MSProd) to the Store-Staging Environment StoreFeedStoreStg DB.
PMDB: The Product Marketing Database (PMDB) is maintained by the same group who maintains www.microsoft.com. PMDB has all marketing related information and pricing information for Books that Shop.microsoft.com requires. It also defines the hierarchy of products like Group, Category, Subcategory and Sites, which in turn are mapped to SKUs (as defined in FeedStore).
PMDB also provides Shop.microsoft.com with all boxshots, screenshots, .gifs and .jpegs, and Sample Chapters and Table of Contents for Books.
Authentication requires an online ID and the password the shopper supplied when registering with Shop.microsoft.com. This information is stored in a database using a standard internal Microsoft authentication process implemented via an ISAPI filter. Since it is not stored as a cookie, it must be supplied by the shopper when they want to view their private information.
A Shop.microsoft.com shopper gains authenticated status after successfully completing the logon page. Status is maintained for as long as the shopper’s browser stays open, after which, the shopper must reauthenticate.
Stored procedures that permit database updates will limit the number of basket items to 250 unique SKUs. This is a backup measure to prevent database abuse by limiting shoppers to the number of records they can add to the database.
Shop.microsoft.com was developed using the following tools and technologies:
The global.asa file is responsible for initializing application-level variables and data structures. Application-level variables are loaded from a binary file and by querying the Shop.microsoft.com database back end. Data structures are populated on application start through ASP code in the CreateDictionaries.asp script include file.
For added site security, most application-level variables are stored in binary file format and later transferred to a dictionary object. From the dictionary object the items are placed into the appropriate application-level variables.
Table 6: Application-level Variables Loaded from Dictionary Objects
| Variable | Description |
| Store Root | the Vroot of the application |
| Store Name | The name of the store |
| Log Path | Used in debugging to determine where logs are written to |
| SQL Client DSN | Main DSN used by server code for data access |
| Browser DSN | DSN Not currently in use |
| ADC_SERVER | Connection information for RDS, not currently in use |
| Netshow™ URL | URL to locate server for NetShow™demonstrations |
| DSN Name | DSN name of store used to build URLs |
| ASX Path | Path to locate ASX file necessary for Netshow demos |
| MS Data Server | Regwiz server |
| MS Data Path | Path to the script that is used to retrieve data from regwiz |
| MS Data Set Path | Path to the script that is used to set data in regwiz |
Table 7: Other Application Variables Initialized in the global.asa
| Variable | Description |
| Database name | Name of the product database on the SQL Server backend |
| SQL Server Name | Name of the SQL Server backend |
| ISO Country | ISO Country ID value used to call all sprocs |
| ISO Language | ISO Language ID used in calling sprocs |
| Program ID | Program ID necessary for backend |
| Software Select | String holding HTML to display the software product drop-down search list box. |
| Hardware Select | String holding HTML to display the hardware product drop-down search list box. |
| Press Select | String holding HTML to display the MS Press product drop-down search list box. |
These values are obtained by calling stored procedures that query the default database specified in the DSN string.
Example of code used to populate a dictionary:
Function CreateDictionaries()
Set dictSoftSubCatList = Server.CreateObject(“Commerce.Dictionary”)
Set oCn = Server.CreateObject(“ADODB.Connection”)
Set oCmd = Server.CreateObject("ADODB.Command")
oCn.Open “DSN=xxx;UID=xxx;PWD=xxx”
Set oCmd.ActiveConnection = oCn
oCmd.CommandText = "<stored procedure name>"
oCmd.CommandType = adCmdStoredProc
oCmd.Parameters.Append _
oCmd.CreateParameter("@GroupId", adInteger, adParamInput, , GroupId)
oCmd.Parameters.Append _
oCmd.CreateParameter("@CategoryId", adInteger, adParamInput, , CategoryId)
oCmd.Parameters.Append _
oCmd.CreateParameter("@VersionFlag", adInteger, adParamInput, , 0)
Set oRs = oCmd.Execute
Do While Not oRs.EOF
NameList = “”
SiteList = “”
Set oCn1 = Server.CreateObject(“ADODB.Connection”)
Set oCmd1 = Server.CreateObject("ADODB.Command")
oCn1.Open “DSN=xxx;UID=xxx;PWD=xxx”
Set oCmd1.ActiveConnection = oCn1
oCmd1.CommandText = "<stored procedure name>"
oCmd1.CommandType = adCmdStoredProc
oCmd1.Parameters.Append _
oCmd1.CreateParameter("@GroupId", adInteger, adParamInput, , GroupId)
oCmd1.Parameters.Append _
oCmd1.CreateParameter("@CategoryId", adInteger, adParamInput, , CategoryId)
oCmd1.Parameters.Append _
oCmd1.CreateParameter("@VersionFlag", adInteger, adParamInput, , 0)
Set oRs1 = oCmd1.Execute
Do While Not oRs1.EOF
If SiteList <> “” Then SiteList = SiteList & “|”
If NameList <> “” Then NameList = NameList & “|”
SiteList = SiteList & oRs1(“SiteId”)
NameList = NameList & oRs1(“SiteName”)
Loop
Set dictSoftSubCatList.Value(oRs(“CategoryId”)) = _
Server.CreateObject(“Commerce.Dictionary”)
dictSoftSubCatList.Value(oRs(“CategoryId”))(“SiteList”) = SiteList
dictSoftSubCatList.Value(oRs(“CategoryId”))(“SiteNameList”) = NameList
Loop
oRs.Close
Set oRs = Nothing
oCn.Close
Set oCmd = Nothing
End Function
Maximum use is made of application-level arrays, used where lists need to be generated. Table 8 shows major arrays used on the site.
Table 8: Major Application-level Arrays
| Array Name | Description |
| General Feature List | Array of feature sites in the general grouping. Used for feature lists not associated with one of the major groupings. Used in panorama and home page. |
| Software Feature List | Array of featured software sites for software product selector and software panorama. |
| Hardware Feature List | Array of featured hardware sites for hardware product selector and hardware panorama. |
| Press Feature List | Array of featured Microsoft Press® sites for Microsoft Press product selector and Microsoft Press panorama. |
| Minimum Memory | Array of memory configurations for search pages |
| Minimum CPU | Array of CPU configurations for search pages |
| Operating System | Array of Operating Systems for search pages |
| Price Range | Array of Price Ranges for search pages |
Table 9: Array Structure
| y-Index | Value held |
| 0 | Category ID |
| 1 | Site ID |
| 2 | Site Name |
| 3 | Nugget |
| 4 | URL ID |
| 5 | Short Description |
| 6 | Box Shot Path |
Arrays are populated by calling a stored proc and using the GetRows() method of ADO.
Application-level arrays and dictionary objects are used extensively. Arrays are used in situations where lists need to be generated, and dictionary objects are used where lookups are needed. This takes advantage of each data structure’s strengths and allows the application to scale better since the database is not being hit for each page request
The global.asa file is used by Internet Information Server (IIS) to specify event scripts and declare objects that have application-level and session-level scope. It is not a content file displayed to the shoppers; instead it stores event information and objects used globally by the application. The file will only be used by IIS if it resides in the root directory of the shop application. The global.asa file can contain only the following information:
All script inside of the global.asa must be enclosed within <SCRIPT RUNAT = Server> tags. Also, objects created inside of the global.asa must be defined as having session or application scope. The server ignores tagged scripts that the application or session events do not use, as well as any HTML in the file.
The code contained in the global.asa file is written using the Visual Basic for Scripting language although any language that conforms to Active scripting requirements could have been used. The decision to use VBScript over Jscript® was due to its mature error handling capabilities.
When making changes to the global.asa one should remember that the server does not recompile the global.asa until after it is finished processing all of the current application requests. While the application is being restarted, the server refuses additional requests and returns an error message stating that the request cannot be processed while the application is being restarted. Note also that saving changes to a file that is included by the global.asa file does not cause the server to recompile global.asa. In order for the server to recognize changes in the included file the global.asa file must be saved again.
After all of the current shopper requests have been processed, the server deletes all active sessions, calling the Session_OnEnd event for each session it deletes, closes the application, and calls the Application_OnEnd event. The global.asa file must be reloaded by stopping and restarting the Microsoft IIS service. Subsequent shopper requests will start the application and create new sessions, and trigger the Application_OnStart and Session_OnStart events.
Procedures declared in the global.asa file can only be called from one or more of the scripts associated with the Application_OnStart, Application_OnEnd, Session_OnStart, and Session_OnEnd events. Procedures in the global.asa file are not accessible to other ASP pages using server side include files (SSI).
<OBJECT RUNAT=Server SCOPE=Application
ID=NTEventLog PROGID="WebResponse.NTEventLog.1">
</OBJECT>
<!--METADATA TYPE="TypeLib" UUID="C0F3260C-49EE-11D2-BD71-00AA0044F9AB" -->
<!-- METADATA TYPE="TypeLib"
FILE="c:\program files\common files\system\ado\msado15.dll"
UUID="00000507-0000-0010-8000-00AA006D2EA4"
-->
<!-- #INCLUDE File="./assets/server_scripts/createdictionaries.asp" -->
<!-- #INCLUDE File="./assets/server_scripts/sprocs/GetProdDBName.asp" -->
<!-- #INCLUDE File="./assets/server_scripts/sprocs/GetProgramId.asp" -->
<!-- #INCLUDE File="./assets/server_scripts/sprocs/GetIsoLanguageId.asp" -->
<!-- #INCLUDE File="./assets/server_scripts/sprocs/GetIsoCountryId.asp" -->
<!-- #INCLUDE File="./assets/server_scripts/GlobalUpdate.asp" -->
<!-- #INCLUDE File="./assets/server_scripts/build_search_listboxes.asp" -->
<SCRIPT LANGUAGE=VBScript RUNAT=Server>
The shopper identity cookie is used to indicate that the shopper has previously visited the site. The cookie is used to track the shopper’s basket but is not used for transacting at the checkout process. A sample ASP code to handle cookies is shown below:
strShopperID = Request.Cookies("shop")("ShopperID")
If IsNull(strShopperID) or IsEmpty(strShopperID) Then
'
' Determine where we are
'
Dim strTargetSN
Dim strActualSN
strTargetSN = LCase(Application("strStoreRoot") & "/products/pricing_versions.asp")
strActualSN = LCase(Request.ServerVariables("SCRIPT_NAME"))
If ( strTargetSN = strActualSN ) Then
' They are attempting to access pricing_versions.asp
' and they don't have a cookie..... we will do a test
' to see if they accept them.
strShopperID = GetNewShopperID()
drop_cookie strShopperID
Dim callingURL, encodedURL
callingURL = (Request.ServerVariables("SCRIPT_NAME") & "?" & _
Request.ServerVariables("QUERY_STRING"))
encodedURL = Server.URLEncode(callingURL)
Response.Redirect(Application("strStoreRoot") & "cookiecheck.asp" & _
"?callingURL=" & encodedURL)
Response.End()
Else
strShopperID = GetNewShopperID()
REM Set the cookie
drop_cookie strShopperID
End If
End If
The process for building all of Product Selector pages for software, hardware, and books is nearly identical. Each page builds process calls a stored procedure, which returns multiple recordsets, which provide all data necessary to build the page. Table 10 shows how stored procedures relate to pages.
Table 10: Stored Procedures
| Stored Procedure Function | Page |
| Product Overview | Product Overview |
| Press Product Overview | Microsoft Press Overview |
| Netshow | NetShow Page |
| Product Features | Features Page |
| Product System Reqs | System Requirements |
| Product FAQ | Common Questions |
| Press Product Authors | Microsoft Press Author Bios |
After calling the appropriate stored procedure, the page build process works through the recordsets sequentially to build the page. Table 11 describes the purpose of each recordset.
Table 11: Recordset Purpose
| Area # | Recordset | Purpose |
| 1 | Subcategory Sites | Build breadcrumbs list |
| 2 | Additional Items | Build Product Information navbar option list |
| 3 | More Information URL | Add link to other sites |
| 4 | Related Products | Build list of related products in navbar |
| 5 | Product Information | These recordsets vary with each page as per the following table |
Table 12: Product Information Data References
| Page | Product Information Data |
| Product Overview | Single recordset containing an overview, copy text, and boxshot URLs |
| Microsoft Press Overview | Single recordset containing authors, description, and other related info |
| NetShow Page | Three recordsets:
|
| Features Page | Single recordset containing list of features |
| System Requirements | Single recordset containing list of system requirements |
| Common Questions | Single recordset containing list of common questions and answers |
Each Product Selector page indicates its current location on the left-hand product navbar by highlighting the current page. This is done by checking the file name of the page and changing the background color of the item in the navbar that relates to the file name.
RadView WebLoad 3.0 is used to evaluate the performance and scalability of Shop.microsoft.com. WebLoad 3.0 verifies the scalability of Web applications by generating a load composed of virtual clients that simulate real-world traffic. Users create JavaScript-based test scripts that define the behavior of the virtual clients. WebLoad executes these test scripts and measures the performance application in real time through graphical and statistical reports.
The following table shows examples of WebLoad 3.0 used for performance monitoring.
Table 13: Page Performance
| Page Name | Page HTML (bytes) | Images (bytes) | ASP Pages per Sec | ASP Bytes per Sec | ASP+GIF Bytes perSec | Bandwidth usage |
| Homepage | 25,721 | 67,947 | 31.04 | 798,379.84 | 2,907,454 | 29.07% |
| Software Selector lvl1 | 40,082 | 67,152 | 22.78 | 913,067.96 | 2,442,790 | 24.43% |
| Software Selector lvl2 | 32,537 | 73,728 | 24.52 | 797,807.24 | 2,605,617 | 26.06% |
| Hardware Selector lvl1 | 32,953 | 73,445 | 25.42 | 837,665.26 | 2,704,637 | 27.05% |
| Overview | 25,420 | 81,726 | 17.90 | 455,018.00 | 1,917,913 | 19.18% |
It is best to begin Performance Monitoring work as soon as possible in the development cycle. The implementation choices made at the beginning were based on what seemed to be “reasonable” predictions about performance, but some of the code turned out to run slower than was predicted. Shop.microsoft.com is a high-volume site, so performance is a primary issue.
RadView WebLoad 3.0, SQL Server 6.5 and a test ASP were used to monitor performance. Some of the lessons learned based on this monitoring were:
The front-end was developed strictly using HTML 3.2 to provide the greatest platform accessibility. During development the site was successfully tested with Microsoft Internet Explorer version 3.0 and above and Netscape Navigator 3.0 and above. Future plans call for use of DHTML data-binding and Remote Data Services to take advantage of client-side processing power.
Active Server Pages and stored procedures were used to implement much of the business logic. Going forward, much of this logic will be ported to COM objects and will take advantage of Microsoft Transaction Server which will allowing further decoupling of business and data layers and an increase in performance.
Significant performance gains were made by caching static but frequently accessed data, such as product categories. This allowed for useful reductions to be made in the number of pages that hit the database. This caching was achieved using application-level dictionaries and arrays.
A modular design played an important role in integrating the various internal and external systems with Shop.microsoft.com. Due to the inherently modular and complex design of commerce solutions, COM and Microsoft Transaction Server will be used on a greater scale in future versions.
The original objectives of the Microsoft Electronic Commerce project, Shop.microsoft.com, were:
These objectives have been met. Shop.microsoft.com provides a single Internet storefront for most Microsoft products, software licenses, books, and publications. It successfully enables consumers to browse Microsoft software, hardware, and publication products online, then acquire them from Microsoft directly, or from a Microsoft reseller site that plays an integral role of the online store.
This integration with resellers removes previous obstacles to Internet consumer sales. A shopper now browses an extended catalog and adds items to their shopping basket, but at checkout time is transferred seamlessly to a chosen reseller’s online site for pricing, payment, and delivery.
Capitalizing on consumer sales uses information about the sale returned by the reseller, which is analyzed as a key part of the personalization process. This retail data is used to drive sales through special offers and cross-selling based on this reseller feedback and shopper profiles.
Shop.microsoft.com clearly showcases Microsoft’s electronic commerce technology. It shows how Microsoft development technologies are readily deployable to meet enterprise needs–in this case a high-performance, complex site with high levels of integration with third-party solutions. And it demonstrates how an implementation based on Microsoft Site Server 3.0 Commerce Edition, Microsoft Windows NT, and Microsoft SQL Server 6.5, is designed to scale to meet the needs of over 200,000 online shoppers per day.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This document is for informational purposes only.
MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
© 1999-2000 Microsoft Corporation. All rights reserved.
Microsoft, ActiveX, EasyBall, Encarta, FrontPage, JScript, Microsoft Press, Netshow, the Office Logo, Visual Basic, Visual C++, Visual InterDev, Visual SourceSafe, Windows NT, Windows, and the Windows Logo are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries/regions.
Other product or company names herein may be the trademarks of their respective owners.
The example companies organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person or event is intended or should be inferred.