Site Server - Direct Technical Deployment

Article
08/28/2007

August 1999

By Sean Emam, Steven C. Robertson, Kumar Parambir, Sunitha Devaguptapu, Mark Huck, Ted Hardy, Rajesh Patil, Stacie Croft, Wenbo Shao, Nalinabai Chelladurai, Ian Witucki, Mary Anne Blake, Mike Hartzog, and Bobby Kishore

Other contributions from: Roy Hirst, Mukesh Agarwal

Special Thanks to: Chris Cale, Beverly Jones

Release Version: 1.5

Microsoft Direct

This white paper documents the implementation of the first phase of Microsoft Direct, a Web site that provides online order management and customer assistance services to shoppers acquiring Microsoft products.

Microsoft offers a wide range of products, including software, hardware, courseware, and publications, that are suited to high-volume retail distribution over the Web. There are many independent online resellers who have Web storefronts that offer Microsoft products, along with other information technology products from other Vendors. Microsoft Direct's mission is to serve those shoppers who wish to acquire their Microsoft products directly from Microsoft.

Microsoft Direct achieves this through the concept of Tenants. A Microsoft Direct Tenant is an online storefront, linked to Microsoft Direct, that hands shoppers over to Microsoft Direct as soon as they have selected all the Microsoft products they want to order. A shopper wishing to buy directly from Microsoft selects Microsoft Direct from a list of online resellers displayed by the Tenant. Microsoft Direct processes the order, calling on a variety of online Vendors for services such as credit card payment and shipment, and provides extensive Web-based customer assistance services.

These Web-based customer assistance services are the core business justification for the implementation of the Microsoft Direct site. Before Microsoft Direct went live, all customer assistance services were handled over the phone by Microsoft customer service representatives. These services included locating orders and shipments, handling order changes, and processing product returns, and cost approximately $5.00 per transaction because of the high administrative efforts involved. While customer assistance is still available over the phone, Microsoft Direct enables most shoppers to help themselves using their Web browser. The savings are considerable—Microsoft Direct processes about 60,000 order transactions per day—and makes a major contribution to the profit margins of both Microsoft Direct and its Tenants, who would otherwise have to offer such services themselves.

Microsoft Direct's charter is to support multiple Tenants and Vendors in one system infrastructure. Its first Tenant was Microsoft's own online retail store, shop.microsoft.com, which refers Web-initiated orders for hardware, software, and publications that are shipped to consumers in the USA or Canada, paid for by credit card. Microsoft Direct is designed to accommodate future implementations of other Tenant types, payment methods, geographic locations, and fulfillment Vendors.

Having one scalable infrastructure capable of serving multiple Tenants is a key objective of Microsoft Direct. A multi-Tenant capability reduces the joining cost and time-to-market for new Tenants, for example, organizations selling courseware or software licenses to small and medium-sized businesses. It also allows easy integration with other major electronic commerce initiatives at Microsoft, such as Online ID that provides user authorization services across the company.

Microsoft Direct's own electronic commerce technology includes Microsoft Site Server 3.0 Commerce Edition, Microsoft Windows NT^®, and Microsoft SQL Server^™ 6.5. The current configuration, which is designed to process up to 60,000 shopper transactions per day with a single database server, can easily be scaled by adding additional database or Web servers as required. The Tenant and Vendor interfaces have to meet the needs of a growing variety of storefront and fulfillment systems, and have been built to make it easy for new Tenant and Vendor channels to come aboard.

Key ingredients in Microsoft Direct's success have been managing the integration with other projects that were also in development, and the performance evaluation work that helped optimize response times and ensured future scalability. After more than a year of planning and development, Microsoft Direct went live for U.S. shoppers in February, 1999, simultaneously with its first Tenant, shop.microsoft.com.

Solution Overview

There are four main components to the Microsoft Direct solution: Tenant, Order Management, Customer Service, and Reports. The Order Management and Customer Service components are the subject of this white paper.

The Tenant component initiates the order process with the online shopper and hands-off this order to Microsoft Direct for purchase and shipment. An example of a Tenant implementation can be found in the case study on shop.microsoft.com (available in the Site Server 3.0 Commerce Edition Resource Kit).
The Order Management component is Microsoft Direct's capability of tracking the order from the Tenant's hand-off to purchase to shipment, and is documented in this white paper.
The Customer Service component is Microsoft Direct's capability of responding to Customer inquiries regarding orders via the Web, and is documented here.
The Reports component includes tax, cash, and other financial statements, and order and delivery status summaries. Implementation of this component is not included in this white paper.

Order Management

Microsoft Direct's Order Management application is an online process that accepts Web-initiated orders for physical goods, calculates prices, taxes and shipping charges, and accepts credit card payment for the order.

Web orders arrive online via a Tenant, an online store that has already allowed the shopper to select products, and has verified shopper name and address and shipping information before passing the shopper to Microsoft Direct. An example of a Tenant is shop.microsoft.com, which invites the shopper to select products from a catalog, and choose a reseller from a list (which includes Microsoft Direct) to have their order fulfilled.

The order basket, shipping, and payment information are displayed for the shopper in a single page on entering Microsoft Direct (see Figure 1 below).

A deliberate design choice was made to display the information all in one page, based on shopper behavior and performance considerations. The alternative, to display basket, shipping, and payment information on separate pages, would have caused a large number of unnecessary pages to be sent, because so few shoppers elected to change the shipping and payment information that they had previously provided to the Tenant.

Figure 1 The Microsoft Direct Order Handoff Page

The Microsoft Direct process accepts the shopper from the Tenant, checks inventory, extends the order pricing, calculates shipping charges and sales taxes, and validates the credit card number. The shopper has the opportunity to modify the shipping and billing details that they supplied to the Tenant, and the committed order is then passed to a service Vendor for physical delivery.

The design of the Order Management application allows for a considerable scaling of order volumes, and the future implementation of other Tenant and Vendor types and payment methods. The major features of the Order Management component are:

Web-based Order Entry: Microsoft Direct supports a wide range of browser technologies on both Windows® and non-Windows platforms (see the section "Browser Support").
Multi-Tenant/Multi-Vendor Compatibility: Clearly defined interfaces and batch processes are designed to accommodate different types of Tenants and Vendors in the future (see the section "Interface and Batch Processes").
US & Canadian Tax Calculation and Address Verification: A third-party package is used to calculate sales taxes and verify addresses for U.S. and Canadian shipments.
Table of Denial Validation: For shipments outside the U.S., delivery to some nations, organizations, and individuals is denied (see the section "Interface and Batch Processes").
Un-Acceptable Word List Validation: Delivery addresses are rejected if they contain words, such as obscenities, that are on the Un-Acceptable Word List.
Credit Card Validation: The fulfillment Vendor does the actual credit card processing.
Inventory and Estimated Delivery Date Management
Email Notification of New Orders
Encrypted Feed Services to Vendors

Customer Service

The Customer Service component includes two applications:

Internet Customer Service. This permits the shopper to view order lists, view order and item status, request returns, and to send e-mail to customer service personnel.
Customer Service Representative. This permits a customer service representative to search for a particular order or shopper, and to view order/item information.

The business justification for Microsoft Direct depends on the great majority of shoppers being able to resolve their own queries using the Internet Customer Service application.

A shopper unable to resolve a query, for example, because of a forgotten password or order number, may contact a customer service representative by phone. A voice response system offers opportunities to resolve queries before speaking with a live representative. The Customer Service Representative application includes the functionality of Internet Customer Service, plus the ability to search across the database for specific orders or shoppers.

Figure 2 shows an example of the initial Internet Customer Service page. The shopper may choose to view an order, request customer assistance, or find answers to frequently asked questions.

This page displays all orders that have been placed by the shopper for the past year with a colored icon flag indicating the status of the order. The shopper can click on either the order number or the order status icon for detailed information about the order.

Figure 2 Initial Internet Customer Service Page

Figure 3 shows an example of the detailed information available to the shopper on an individual order. This page shows the status associated with individual items as well as the shipping address, method of payment, and order totals.

Figure 3 Order Status Page

Figure 4 shows an example of the detailed information available to the shopper on an individual item. This page shows the associated shipping information, such as shipping date, carrier, and tracking number, if available.

Figure 4 Item Status Page

Clicking on the shipper logo or the tracking number spawns a new window linked to the shipper's information page for the specified tracking number.

Figure 5 shows an example of the various types of customer assistance available on an order. These range from technical support, to issues, to problems with the order. The shopper chooses the reason for assistance from a drop-down menu, which is then linked to different pages to obtain the appropriate information for the request.

Figure 5 Initial Internet Customer Service Page

Figure 6 shows an example of the Frequently Asked Questions (FAQ) page. Questions are organized in categories and are in a question/answer format.

Figure 6 Frequently Asked Questions Page

Figure 7 shows an example of the initial Customer Service Rep (CSR) page. The CSR sees the identical customer service pages as the shopper sees on the Web site, but in a frame format with additional functionality such as search functions.

Figure 7 Initial Customer Service Rep Page

Microsoft Direct Requirements

Scalability Requirements define how well the system is able to expand to handle increases in the volumes of transactions. For Order Management, this means the design must still perform well as multiple IIS/ASP servers are added in the future to meet the increased load.

The production and development servers are both capable of storing 5+ gigabytes of information. The configuration has the capacity to add storage if and when needs increase.

Performance Requirements define how well the system is supposed to work. The Order Management pages are characterized by a mix of (1) pages that require database access or data entry and (2) static dead-end error message pages. Performance requirements include:

The ability to display every page within 5 seconds at 56K Baud.
The ability to respond to all data entry within 2 seconds.
The ability to process between 5000–10000 committed purchase transactions per day.

Reliability Requirements define how well the system is able to respond to outside events in a consistent and appropriate manner. The system undergoes Usability Testing as the first step of the release process.

The system undergoes Integration Testing before undergoing User Acceptance Testing (UAT) and System Acceptance Testing (SAT) in parallel as the final step before release. The system is Microsoft Y2K compliant.

Full site backup (capacity and replication functions) exist on separate drives to ensure instant replacement in the event of catastrophic failure.

A fault tolerant system provides server redundancy in case of failure. Appropriate backup and recovery procedures are to be followed to enable switching to an alternative system in the event of a catastrophic failure.

Maintainability Requirements define how the system is to be maintained at an operational level once it is put into production. Code maintenance must be considered from the start to avoid unnecessary confusion in future system maintenance.

The system adds new types of Tenants, Vendors, and products through a system admin interface.

Use objects and put common functions into include files. All processing is performed in objects that are separate from the ASP page. In other words, they are stored in separate JavaScript routines that are callable from the main body of the ASP page.

All variable names use the defined naming conventions. All code includes comments identifying the functionality of major sections and complex processing.

Availability Requirements define the accessibility of the system. Microsoft Direct is available to the general public from the Internet 24-hours a day, with occasional shutdowns at pre-determined times and dates being acceptable for regular system maintenance during off-hours (weekends and early morning). Brief page unavailability is acceptable during content updates.

Usability Requirements define the ability of the system to make people comfortable that they are effective when using the system. The system adheres to basic Internet Web conventions. JavaScript is used to validate form input on the clients computers before submission to the server, for example to ensure that numeric values only contain numbers and eliminate any quotation marks.

Client Requirements

Microsoft Direct was designed for Microsoft Internet Explorer 4.0 technology, but with the ability to degrade gracefully to other browsers. The graphic interface is optimized for 800x600 resolution, with gracious scaling to larger sizes (e.g. 1024x768) and workable at 640x480.

Microsoft Direct supports the following client platforms:

Macintosh OS 8.1+
Microsoft® Windows 3.1
Microsoft® Windows 95/98
Microsoft ®Windows NT® 3.51+

Microsoft Direct server hardware and software requirements are defined in the section "Physical Architecture."

Specification

The figure below summarizes the overall application architecture of Microsoft Direct. The components shown in the figure are discussed in more detail in subsequent sections.

Figure 8 Microsoft Direct Application Architecture

Tenant Shoppers

The Tenant Shoppers are individuals who are shopping online at one of the Tenant Store sites, such as shop.microsoft.com. They interact with the Tenant Store and then the Microsoft Direct order management system. This is also the source for customer service interactions.

Tenant Store

This is the online store the shopper interacts with. Microsoft Direct is not directly involved in the development of this component. However, a shopper is brought to the Microsoft Direct system by way of a Tenant Store, so both the Tenant Stores and Microsoft Direct need to understand the interface and how it is implemented.

Online ID Environment

Online ID is the secure authentication system that is used to validate all external users of secure in-house systems. It also manages persistent session routing to the several Microsoft Direct front-end processors.

Microsoft Direct Front End

This represents the order handoff, order management, customer service, and customer rep support pages.

Microsoft Direct OPP

This represents the pipelines the Microsoft Direct system uses to support the order management process.

Microsoft Direct Data Services

This is the database service functionality that provides all database interaction. All interfacing with the database is done via stored procedures.

Microsoft Direct Transaction/Reporting Services

This represents the services that handle the depicted data feeds, import/export processing, order status updating, inventory updates, and so forth.

Transaction Database

This represents the master transaction database that holds all shopper-committed orders that are in process. Completed orders are kept here as well in history tables.

Detailed Process Flows

This section describes the process flows used in the implementation of Microsoft Direct's Order Management and Customer Service components.

Order Management

Figure 9 Microsoft Direct Process Order Management Flows

Order Handoff

The Order Handoff Page provides an application interface for the Tenant to post their shopping basket to the Microsoft Direct System.

Customer checks out of the Tenant's Store by selecting Microsoft Direct as the Reseller on the Merchant Selection page of the storefront. This causes the Tenant to post the transaction data to the Microsoft Direct Order Handoff page.
A receipt confirmation is sent to the Tenant if an order is committed.
The basket received from the Tenant is written to the Microsoft Direct database.

Order Management

The Shopper ID, which is the combination of the Tenant code and the Tenant's transaction ID is passed to the "Checkout" page.
Commerce Server uses the Shopper ID passed in the URL to create the order object in memory and display it on the page by reading the Microsoft Direct Transaction DB.

Commerce Server runs the following processes as part of its plan pipeline:
- Calculates extended item price by multiplying item price * quantity.
- Adds all extended item prices to calculate subtotal.
- Determines shipping and handling based on the selected shipping method or default.
- Calculates tax for the order by using the Tax/AVS DB.
- Calculates the order total by adding the subtotal, shipping and handling, and taxes.

Shipping Information

If the shopper clicks on the "edit Information" button in the shipping section of the "Checkout" page, they are redirected to the "Shipping Address" page with the Shopper ID in the URL.
Using the Shopper ID, the Microsoft Direct Transaction DB is read to display the shipping information on the page.
If the customer enters new information and clicks the "Submit Changes" button, the address (U.S. or Canadian) is validated using the Tax/AVS database. Otherwise, AVS checking is ignored.
If the address is validated, the new information is written to the Microsoft Direct Transaction DB.
If the address does not pass the Table of Denial, a dead end error page is displayed.
If there are no errors in the new billing address, or if the shopper clicks the "Back to My Order" button, the shopper is returned to the "Checkout" page with the Shopper ID in the URL.

Billing Information

If the shopper clicks on the "edit Information" button in the billing section of the "Checkout" page, the shopper is redirected to the "Billing Address" page with the Shopper ID in the URL.
Using the Shopper ID, the Microsoft Direct Transaction DB is read to display the billing information on the page.
If the shopper enters new information and clicks the "Submit Changes" button, the address (U.S. or Canadian) is validated using the Tax/AVS database. Otherwise, AVS checking is ignored.
If the address is validated, the new information is written to the Microsoft Direct Transaction DB.
If the address does not pass the Table of Denial, a dead-end error page is displayed.
If there are no errors in the new billing address, or if the shopper clicks the "Back to My Order" button, the shopper is returned to the "Checkout" page with the Shopper ID in the URL.

Usage Information

If a FAQ hyperlink is clicked, the FAQ page is displayed with the appropriate text highlighted.
Definitions of terms can be obtained by linking from the FAQ page.

Order Confirmation

Upon clicking the "Purchase My Order" button on the "Checkout" page, a check is made of the credit card number and if there are errors, an error message is displayed. If there are still errors after three attempts, the shopper is redirected to "Credit Card Error" page.
If there are no credit card number errors and the order is validated, the order is committed to the Microsoft Direct Transaction DB.
The Order Number is passed to the Order Confirmation page in the URL.
The "Order Confirmation" page uses the order number passed to it in the URL to read the Microsoft Direct Transaction DB to display information about the order.

Customer Service

Figure 10 Microsoft Direct Customer Service Flows

Customer Service

Display Orders: The user's online ID is used to determine what orders are to be displayed on the page. If the user accessing the page is a customer service representative, the customer name is used.
FAQ: The FAQ page is displayed with the appropriate text highlighted. This FAQ is Tenant configurable, and keys off the FAQQuestion and FAQAnswer tables.
Display Order Information: Because shoppers should only have access to their own orders, the combination of user's online ID and order number is used to test whether the shopper is authorized to access a given order.
Display Item Status: The user's online ID and order number combination are tested to confirm that the user is authorized to access a given item within an order. Customer service representatives are given access to all orders.
Customer Assistance: Selecting from a drop-down list box, a shopper may request technical support, change an order, return items from it or cancel it, or report that they can't find the order. A second drop-down list box helps the shopper select a specific order from their list of outstanding orders. Feedback about the site is also collected here; the comments are collected and summarized periodically into management reports.
Return Items: A user may request a return for an item by completing the form on this page. A drop-down list box offers valid reasons why an item is returnable. A check is made that the item has, in fact, been shipped, a return has not already been requested for it, and the total return quantity is not greater than the total originally ordered.
Customer Order Lookup: A customer name search can be made using any combination of name, online ID, and e-mail address. Names may be specified using wildcards. Order numbers are found using either full or partial record numbers.
Customer Search Results: The customer service representative may sort and select from the list of customer names found by a customer name search. Clicking on the selected name retrieves all the orders associated with that name.

Batch Processing

Tenant interface processes are needed to maintain an up-to-date SKU list for the Tenant, to receive the incoming shopper and their basket, and to report back to the Tenant on the final status of the transaction. Tenants may choose the type of interface they prefer. For example, Microsoft Direct's first Tenant, shop.microsoft.com, chose to refer shoppers to Microsoft Direct using the graphic user interface and a flat file containing basket information. Tenant interface processes include:

Tenant's Product. Provides latest SKUs available on the Tenant's site.
Tenant's Shopping Basket. Submits the customer's order to Microsoft Direct.
Tenant's Feedback. Reports the results of all orders submitted to Microsoft Direct.

Internal batch processes are used both in order management, to enforce business logic on a committed order, and for internal housekeeping, for example to periodically remove abandoned shopping baskets. Internal batch processes include:

Table of Denial. Enforce the Table of Denial validation on all new orders that were modified in Microsoft Direct; although the Tenant is expected to have already done this validation before passing the shopper to Microsoft Direct. Enforcing of denial validation is done in real-time if the shopper tries to change their billing or shipping address.
Unacceptable Word List. Enforce unacceptable word validation on all new orders that were modified in Microsoft Direct.
Clean-up. Delete all inactive shopping baskets from Microsoft Direct.
Tax Update Process. Update sales tax rates.

External interfaces create files of new orders, update Vendor inventory and order status, and refer financial data back for end-user reporting. They include:

New Orders. Create a file for the Vendor with all new orders.
Inventory Status. Update the status of inventory from the Vendor to Microsoft Direct.
Order Status. Update the status on existing orders from a specific Vendor.
MERT/KPI. Send required financial data to the Microsoft End-user Reporting Tool (MERT) system.
Customer Incidents. Posts customer questions and issues to the Vendor's issue tracking system.

Figure 11 below shows the main interface and batch processes required for Microsoft Direct.

Figure 11 Microsoft Direct–Interface and Batch Processes

Tenant Interface Processes

Product management is a process where products are added and updated in the Microsoft Direct environment. Microsoft Direct only maintains those product SKUs that are supported by their Tenants.

The Tenant provides a list of SKUs to Microsoft Direct. Microsoft Direct updates the product_sku table based on the Tenant's SKUs. The SKU is associated to the Vendor/Tenant during the inventory status feed. Microsoft Direct utilizes all Tenant fields except availability.

Figure 12 Tenant Interface Process–Product Management

The Tenant can submit an order by user interface or by a batch submission. Each order on the batch process must go through the Accept Order process. The Tenant is assumed to have validated shopper name and address details.

Internal Batch Processes

Table of Denial: Microsoft does not conduct business with individuals or companies appearing on the U.S. Government's Lists of Denied Parties. This is enforced, via standard Embargo Lists and Table of Denied Parties (TDO) processes, on orders to be shipped outside the United States.

Cleanup: For Internet users with HTML clients, it is quite likely that many of these customers, after having selected several items for purchase, will move to another Web location or simply turn off their computer. This situation requires that a scheduled 'clean-up' process be executed to remove all inactive shopping baskets (order forms or objects) that are uncommitted. Uncommitted orders are those orders that have not been committed by the Customer through the 'Purchase My Order' button on the Price Order page.

This process is executed every hour, looking for shopping baskets that have been inactive for 1.5 hours.

Figure 13 Internal Batch Process–Cleanup

All orders that have been successfully purchased by the Customer are sent to the Vendor (orders with the status of 'Order Accepted'). This interface is run approximately four times a day.

External Interfaces

There are six distinct external batch interfaces required to support communication between the Microsoft Direct order management system and its multiple Tenants and fulfillment Vendors. The figure below provides an overview.

Figure 14 Microsoft Direct Batch Interfaces

Product Feed—Tenants update Microsoft Direct with the latest list of product SKUs available on their site.
New Order Feed—New orders are communicated to the appropriate Vendors for fulfillment.
Customer Incident Feed—Customer service issues and return requests are communicated to the Vendors.
Order Status Feed—Vendors provide Microsoft Direct with updated order status information.
Inventory Status Feed—Vendors provide Microsoft Direct with updated inventory information.
Referral Status Feed—Information on items purchased on Microsoft Direct is communicated to the referring Tenant.

Data Architecture

Microsoft Direct is designed to make extensive use of tables, both for business data and for system parameters. The business data architecture is organized into three groups of tables, Order Management, Customer Service, and Feeds. The architecture for each group of tables is shown in the following figures. The stored procedures implemented for each major table are shown at the end of this section.

Figure 15 Order Management Tables

Key to Order Management tables

1. Basket
2. Basket Item
3. Bogus Credit Cards
4. Country
5. Credit Card
6. Currency
7. Denial Country
8. Denial Master
9. Forbidden Country Code
10 Freight Code

11. Next Number
12. Payment Method
13. Product Inventory
14. Product Price
15. Product Sku
16. Receipt
17. Receipt Item
18. Receipt Transaction
19. Ship Method
20. Ship Rate Flat

21. Ship Rate Ord Qty
22. Ship Rate Ord Value
23. Shopper
24. Tenant
25. Tenant Ship Method
26. Unacceptable Word
27. Unit
28. Vendor
29. Vendor Credit Card
30. Vendor Field

Figure 16 Customer Service Tables

Key to Customer Service tables

1. Browser
2. CS Issue
3. CS Issue Comment
4. CS Reason
5. FAQ
6. FAQ Answer
7. FAQ Question

8. Item Status
9. Item Status Reason
10. Operating System
11. Order Status
12. Order Status Reason
13. Receipt

14. Receipt Item
15. Return Reason
16. Return Request
17. Shipper
18. Tenant
19. Tenant Assistance

Figure 17 Feed Tables

Key to Feed tables

1. Feed Completion Status
2. Feed Control
3. Feed Log
4. Feed Schedule
5. Feed Type
6. Incident Feed Stage

7. Inventory Feed Stage
8. New Order Feed Stage
9. Order Status Feed Stage
10. Product Feed Stage
11. Referral Status Feed Stage

Stored Procedures

The Microsoft® SQL Server stored procedures used to select, update, or delete data items in the tables are listed below:

Table 1 Database Tables Used

Table	Stored Procedure	Action Performed
Basket	Delete Shopper	Delete
	Insert Basket	Insert
	Update Basket	Update
	Basket Item Delete	Delete
	Basket Tenant Sel	Select
	Basket Ship Cutoff	Select
	Basket Ship Update	Update
	Receipt Master	Select
	Basket Info	Select
Basket Item	Delete Shopper	Delete
	Insert Basket Item	Insert
	Basket Item Delete	Delete
	Basket Item Qty Update	Update
	Basket Item Remove Item	Delete
	Basket Item Shopper Id	Select & Delete
	Basket Item Shop Id Item Id	Delete
	Receipt Master	Select
	Basket Item	Delete
Bogus Credit Cards	Bogus Credit Cards	Select
Denial Country	Order Denial	Select
Denial Master	Order Denial	Select
FAQ Answer	FAQ Select OM	Select
FAQ Questions	FAQ Select OM	Select
Next Number	Receipt Master	Select & Update
Product Inventory	Inventory Check	Select
	Basket Item Qty Update	Select
	Prod Inv Quantity	Update
	Receipt Master	Update
Receipt	Receipt Tenant Sel	Select
	Receipt Master	Insert
	Receipt Shopper Online ID	Select
	Receipt Shopper Order ID 2	Select
Receipt Item	Receipt Item Get Item	Select
	Receipt Master	Insert
Receipt Transaction	Receipt Master	Insert
Ship Method	Inventory Check	Select
	Tenant Ship Method	Select
Ship Rate Flat	Calculate Shipping	Select
Ship Rate Ord Qty	Calculate Shipping	Select
Ship Rate Ord Value	Calculate Shipping	Select
Shopper	Delete Shopper	Delete
	Insert Shopper	Insert
	Basket Info	Select
System Control	CSR Main Lobby	Select
	System Control Item Value	Select
Tenant	Get Tenant Code	Select
	Tenant Mer Change Page URL	Select
	Tenant Shopping Page URL	Select
	Tenant Ship Method	Select
Tenant Ship Method	Tenant Ship Method	Select
Unacceptable Word	Order Denial	Select
Vendor	Inventory Check	Select
	Basket Item Qty Update	Select
	Basket Ship Cutoff	Select
	Get Vendor Code	Select
Vendor Credit Card	Vendor Credit Card Get CC	Select
Vendor Field	Vendor Fields	Select

Physical Architecture

The Microsoft Direct physical architecture is shown below in Figure 18. It consists of four Web servers, three DB servers (Production, Reporting, and Hot Backup), and a server for Tenant Services and E-mail.

Load balancing services are currently provided through a "BIG/ip" controller that distributes transactions across the IIS server array. The BIG/ip implementation was separate from the Microsoft Direct project. Future plans are to replace BIG/ip with Microsoft's own load balancing solution called Microsoft Windows NT Load Balancing Service (WLBS).

For more information on Microsoft's WLBS (load balancing technology), refer to https://www.microsoft.com/NTServer/ProductInfo/features/WlbsFeat.asp.

Figure 18 Microsoft Direct Physical Architecture

Table 2 Server Configurations

Server	#	Configuration	Hardware	Speed
IIS	4	Microsoft Windows NT 4 SP4, Internet Information Server 4, CS, Taxware	Dual Xeon 400 with 1GB RAM 1MB L2 Cache	400MHz
SQL Production	1	Microsoft Windows NT 4 SP4, Microsoft SQL Server 6.5	Quad Xeon 400 with 1GB RAM 1MB L2 Cache	400MHz
Service/Email	1	Microsoft Windows NT 4 SP4	Dual Pentium II with 196MB RAM 1MB L2 Cache	400MHz
SQL Reporting	1	Microsoft Windows NT 4 SP4, Microsoft SQL Server 6.5	Quad Xeon 400 with 1GB RAM 1MB L2 Cache	400MHz
SQL Hot Backup	1	Microsoft Windows NT 4 SP4, Microsoft SQL Server 6.5	Quad Xeon 400 with 1GB RAM 1MB L2 Cache	400MHz

Security

Microsoft Direct has two main security requirements—ensuring that the appropriate customer is validated, and limiting access to secured data to appropriate individuals only.

Customer Validation

Orders are only viewable by the Authenticated Customer (and the Customer Service Rep, if customer service is later required).

All users must be authenticated through an "Online ID" authentication process, and all ASP pages and databases are maintained in the Online ID secured environment. Online ID is a company-internal authentification service, built using Microsoft technologies, that provides a single way for users to identify themselves to Microsoft's numerous in-house systems.

All confidential information, such as a customer personal information and credit card numbers, are only stored in the transaction; they are not centrally available. Enhanced security of credit card numbers is provided by encrypting the information prior to storing it in the transaction database.

The credit card number field is cleared on re-entry to the Price Order page.

Access to Secured Data

The system supervisor receives reports of successful system administration log-on/off events, as well as unsuccessful attempts.

The administrator group has limited membership. Only a select few employees have administrator privileges to the production servers. A select bigger group has access to the development server necessary to update content. Only Web administrators will have the ability to post new content to production servers.

Auditing of NTFS files and directories is enabled, to ensure that no one has gained unauthorized access to sensitive files.

Secure Sockets Layer (HTTPS) is used to enforce secure data transmissions. This is required for the transfer of shopper profile and shopping basket data between the Tenants and Microsoft Direct.

All the latest Windows NT service packs and security patches were in place before the new system went live. They are maintained as required by the Webmaster.

Implementation

The Microsoft Direct development team implemented the functional specification using Microsoft Site Server 3.0 Commerce Edition with IIS4 and Microsoft SQL Server 6.5, on a Windows NT 4.0 Server to provide the primary functionality of Order Management.

Database access is accomplished using the Active Data Object (ADO). The application is designed to work best with Microsoft Internet Explorer 4.x at a screen resolution of 800x600, but degrades gracefully in all 3.x browsers.

The Customer Service application uses servers running Windows NT 4.0 and IIS4 with Active Server Pages (ASP). Database access is accomplished using the Active Data Object (ADO). The application is designed to work best with Microsoft Internet Explorer 4.x at a screen resolution of 800x600, but degrades gracefully in all 3.x browsers.

The HTML and artwork guidelines were initially provided by a graphics design firm, but the majority of the graphics were created and optimized by the development team.

This section describes the timeline, resources, and main code components needed to meet the application architecture and system requirements of the Microsoft Direct implementation.

Timeline and Resources Used

The Microsoft Direct online site was built using a combination of Microsoft full-time employees and contractors. The following is a breakdown of some major tasks that were performed and how resources were distributed to accomplish them.

Table 3 Development Task

Task	People Resources	Time-frame	% of total effort
Business Analysis	3	7	30%
Technical Analysis	2	7	20%
HTML/ASP Development	2	5	15%
Data Modeling & SQL DB Development	1	5	7%
C++ Development	2	5	15%
Testing	3	3	13%

Code Components

Microsoft Direct implementation began by modifying VCTurbo, an improved version of the Volcano Coffee sample store distributed with Site Server 3.0 Commerce Edition. This Commerce sample stores used two pipelines:

Plan.pcf, the plan pipeline, which calculates shipping, tax, and order total.
Purchase.pcf, the purchase pipeline, which validates credit card information and writes the order to the database.

The VCTurbo sample store splits the plan pipeline into two, Basket.pcf and Total.pcf. Because Microsoft Direct displays basket, shipping, and total information all in one page, the two pipelines were merged into one, Plan.pcf, and executed at the beginning of the page. Basket.pcf is executed to get billing and shipping information.

We did not use Purchase.pcf due to performance considerations with our single-page approach, and due to the way credit checking is currently performed in Microsoft Direct. Since it is a performance hit running the pipeline each time the shopper refreshes the page, the Plan.pcf pipeline is executed in the order_handoff page, where the data is first posted from the Tenant and written into the database. From then on, all the required data such as order total and shipping rate was already in the database, we were able to remove two of Purchase.pcf's three components, SQLItemADO and SQLOrderADO, and replace them with a stored procedure. We removed the third component, ValidateCC Number, since credit checking is currently defined as a Vendor responsibility.

We found that the SimpleUSTax component was not sufficient to calculate sales tax, mainly because it defines tax rates at state level, and there was no way to take into account any small variations in rates between counties within a state. Therefore, we used Taxware's Internet Tax System component to calculate tax. While this was the same component used by our Vendor to calculate tax totals, we initially found some small differences between the totals we calculated for the order_handoff page and those calculated by the Vendor when the credit card was charged. The differences were rounding errors, and were overcome by calculating taxes in our .asp page at line item level and totaling the tax, rather than totaling the order and then calculating the tax total:

For each item in mscsOrderForm.items
Item.[_tax_total] = int(item.[_tax_total]/item.quantity)
Tax_total = tax_total + item.[_tax_total]
Next

In the Billing and Shipping pages, the address is validated using the tax component by means of an ISAPI extension DLL written by a member of the development team, using Microsoft Visual C++®, Microsoft SQL Server 6.5, and ODBC 3.x.

Site Server Implementation

The technical design called for using Site Server 3.0 Commerce Edition in a way that ensured the technology delivered maximum performance benefits. The design is based on several recommendations included in the Microsoft Site Server 3.0 Commerce Edition Performance Kit. The Performance Kit contains detailed technical advice on how to design a Site Server Commerce site while keeping performance a priority.

The Site Foundation Wizard was run to set up the Microsoft Direct foundation and the Site Builder Wizard was used to build the Microsoft Direct Commerce Server site. The VCTurbo site (included in the Performance Kit) was used as a model. This wizard gathered information from the VCTurbo site and generated the files and database for Microsoft Direct using VCTurbo specifications. The database and template files provided by the wizard were then customized to add site-specific functions, and create ASP pages that conform to Microsoft Direct requirements.

Outlined below are the design principles used to get the maximum performance benefit from Site Server 3.0 Commerce Edition. Please refer to the Performance Kit for more details.

Database Schema—The binary marshaled order column was eliminated from the basket table in favor of storing order information in two database tables with explicit columns. These tables, Basket and Basket Item, mirrored the dictionaries for the orders and items, respectively.
Eliminate DBStorage Object—The DBStorage object was not used in Microsoft Direct due to its memory and database overhead. Instead, more traditional database techniques were used that required more ASP script, but yielded a much faster database interaction.
OrderForm Creation—The OrderForm was created by executing queries against the Order and Item tables. A function creates the OrderForm object, and adds the shopper data and any basket items saved to the Basket and Basket Item tables. The function then runs the OrderForm through the pipeline and returns the processed object.
URL Generation—The generation of URLs was optimized using a pageURL function instead of the URL method. This technique runs faster because the base URL string has already been calculated and stored ahead of time.

Re-using Components

Microsoft Direct focused on a design that could be extended to support additional capabilities and store Tenants. Microsoft Direct's first Tenant, shop.microsoft.com, also turned out to be a Commerce Server 3.0 site. It was therefore possible for Microsoft Direct to look at adapting some of the Tenant's components, to minimize development effort and complexity. This possibility was investigated during detailed design, and any benefits were weighed against possible lost functionality and other tradeoffs.

Plan Pipeline Modifications

The following seven stages, which are included in Commerce Server's default Plan Pipeline, were removed from Microsoft Direct pipeline processing. The functionality of some components was removed altogether, while the logic of others was duplicated elsewhere in the site.

Table 4 Plan Pipeline Stages

Stage	Reason for removal from pipeline processing
Product Information	Gathered by executing a query directly in script on an ASP page.
Merchant Information	Removed, functionality not required for Microsoft Direct.
Shopper Information	Gathered by executing a query directly in script on an ASP page.
Order Initialization	Removed, allocate Order ID using order_id identity database column.
Order Check	Removed, functionality not required for Microsoft Direct.
Item Price	Removed, functionality not required for Microsoft Direct.
Item Price Adjust	Removed, functionality not required for Microsoft Direct.

Taxware Component Integration

Taxware is a third-party component that Microsoft Direct is using to compute tax for the different localities in the United States and Canada. In addition, it is used for address verification if either the billing or shipping address is entered after arriving at the Checkout page. It is the Tenant's responsibility to verify addresses they provide to Microsoft Direct.

Controlling Page Caching

We learned how to control the caching of user pages, by overriding automatic page caching on the proxy server and by modifying our .asp pages.

By default, Web pages get cached for performance reasons, both by the proxy server and by the Web browser on the shopper's computer. Problems with this default caching of user pages can arise when a page is revisited soon after information has been edited or added, because the caching mechanism may later restore the original, unedited version of the page. This can affect the shopper in several ways, depending on where they are in their navigation, and on the browser version they are using:

If pages persist in the cache beyond the end of a completed, posted transaction, then pressing the browser's Back button appears to restore the transaction to an incomplete state.
Cached pages can be recalled that contain sensitive data, such as credit card numbers, if they are not cleared immediately.
Data entered in response to a form page may appear to be lost, if the form is recalled but happens to get reloaded in its original "empty" version from cache.

Proxy servers cache Web pages to increase the speed, but this is only good for display/read only pages. We therefore changed their Response.CacheControl configuration parameters from public to:

Response.CacheControl = "private"

We also changed the value of the ExpiresAbsolute property, so as to specify an already-past date and time at which a browser-cached page expires, by including the following line of code in every .asp page:

Response.ExpiresAbsolute=#Jan 01, 1980 00:00:00#

Finally, we removed a Meta tag from our .asp pages that was causing problems for some browser versions:

<META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE">

Implementing the E-mail Service

The Microsoft Direct E-mail Service is used to notify shoppers about the status of their orders. We had to develop an e-mail solution that used the minimum number of Windows NT threads, was data-driven for business reasons, and restarted quickly and automatically after an interruption in server availability. Further, the E-mail Service needed to be automated, and must be capable of working successfully with the wide range of e-mail clients that our shoppers used. Keeping these business requirements in mind, the E-mail Service was developed using Collaboration Data Objects for Windows NT Server (CDONTS) for messaging, Microsoft SQL Server 6.5 for maintaining the delivery of e-mail messages, and custom developed-COM objects created in Microsoft Visual C++ for integration.

Our initial E-mail Service solution used a different Windows NT thread for each distinct e-mail type. Although this solution worked well, we had to modify it because it took an unacceptably long time to exit so many threads whenever the Service was stopped. By grouping most of the less-critical e-mail processing into one thread, we were able to settle on just two threads as the best solution. One thread acts on the most vital transaction, the Order Confirmation E-mail for the new orders received, and the second thread deals with all other types.

Our biggest challenge came as a requirement from our business side that e-mail formats and content, such as the From E-mail address, should be data driven so that they can be set at run time. The NewMail interface of CDONTS.dll proved lightweight and flexible enough to meet this requirement. All parameters to configure and run the E-mail Service are now held in the registry. This gives us the ability to configure the E-mail System to the needs of individual Tenants, and to modify the application by adding or removing any type of e-mail. A new e-mail type can be added by writing a new Stored Procedure and adding the name to the registry.

We introduced exception processing so that that the E-mail Service won't crash even if Microsoft SQL Server goes offline. We made this possible by continuously polling the server until it becomes available again. We also made sure that when we dealt with such a vast amount of data, we were not repeatedly allocating and de-allocating heap memory within the E-mail Service. Based on a flag in our ODBC wrapper class, we allocated memory only once and used it for the entire session.

Browser Support

Microsoft Direct system requirements included the support of a wide range of browsers and Internet technologies, running on many different operating systems (Macintosh OS 8.1+, Microsoft Windows 3.1, Microsoft Windows 95/98, and Microsoft Windows NT 3.51+). A number of development issues needed workarounds because the implementations of HTML and scripting engines vary between these browser versions. The table below itemizes these issues and the workarounds that were required.

Table 5 Browser support workarounds

Browser-dependent issues	Workarounds
Browser does not support JavaScript arrays. Inputs cannot be passed to a subsequent page that processes the values by looping through an array.	All inputs must be explicitly named on the page and passed as such. Client-side validation cannot use arrays to check input fields. Note Internet Explorer 3 and Netscape Navigator 2 both support JavaScript 1.0 (called JScript® 1.0 in Internet Explorer 3), which doesn't support the IMAGE object available in JavaScript 1.1.
Browser does not support the substr(start, end) JavaScript function.	Use the JavaScript substring(start,length) function.
Browser requires functions to always return values if any statement returns a value.	Ensure that statements end with return; return true; or return false; throughout.
Browser does not support js files.	Code must sniff for browser, then return either js file or script on page.
Browser does not always handle query strings passed with posts.	ACTION value should not have query string appended.
Browser requires function to open new window.	<A HREF='javascript:loadWindow("<%= Application("OrderRootStr")%>terms2.asp")'>
Browser does not show tool tips.	Use the ALT and NAME attributes for images.
Browser may ignore hash at end of query string.	Explicitly define hash in onload script.
Browser may cache page or inputs when not desirable.	set INPUT TYPE=hidden flag onunload set Expires META tag set META pragma tag
Browser implements auto-complete, which is undesirable for sensitive credit-card information or personal data.	Set AUTOCOMPLETE = "off" on INPUT
Browser persists form input data.	Set META tags SAVE=history and SAVE=favorites, but do not apply these attributes to any objects on the page.
Browser reserves space for FORM when rendering page, even if no renderable markup within form.	Locate form information where the impact on rendering minimized.
Some browsers display only the image NAME tag text when the cursor is over a button or form object, rather than the informative alternate ALT text.
Nested tables significantly increases download and rendering times for some browsers.	Keep the number of nested tables to a minimum.

Development Tools

The major technologies used in the development of Microsoft Direct included:

Microsoft Windows NT 4.0
Microsoft SQL Server 6.5
Microsoft Internet Information Server 4.0
Microsoft Active Server Pages
Microsoft Site Server 3.0 Commerce Edition
Microsoft Commercial Internet Server (MCIS)
Microsoft Exchange 5.5 Email Server
Microsoft Visual C++
HTML 3.2
JScript and Visual Basic® Scripting Edition
Taxware Commerce Server—Tax and Address Validation Components

Additional development tools are listed below, with an explanation of how they were used.

Table 6 Microsoft Direct Development Tools

Development area	Tool	Explanation
Administrative	Microsoft Visual SourceSafe™ 6.0	Used for source control and maintaining build revisions.
	Microsoft RAID	Bug and issue tracking system.
	Remote Desktop	Used to administer remote servers.
	Microsoft SQL Server Enterprise Manager	Used to administer the Transaction DB.
	Microsoft Commercial Internet Server Admin	Used to install and configure Commerce Server.
	Microsoft Internet Information Server Admin	Used to install and configure IIS 4.0.
	Microsoft Office 98	Test Plans and reports.
Prototyping	Microsoft FrontPage® 98	Quick design look and table creation.
Authoring	Microsoft Visual Studio 5/6 (Microsoft Visual C++, Microsoft Visual InterDev™)	Core development tool.
	Microsoft Visual InterDev	Test Web site development and maintenance.
	Commerce Server Pipeline Editor	Used to install Taxware components.
	Microsoft SQL Enterprise Manager	Used to develop stored procedures.
Testing	HTML Validator	Check validity of HTML code.
	Web Trends	Web site performance monitoring and reporting.
	Microsoft Access 98	Database querying and manipulation.
Graphics	Adobe ImageReady 1.0	Used for optimizing Web graphics, automating batch conversions, and animations.
	Adobe Photoshop 5.0	Used for Web graphics creation and enhancement.
	Visio 5.0	Used for technical drawings.

Performance Evaluation

Performance evaluation was carried out according to quality procedures and a timeline defined by the in-house Enterprise Quality Assurance (EQA) program. The EQA testing philosophy focuses on enterprise-level support, system performance, and system recovery for client-server applications. The EQA strategy was to stress-test servers and the network, using the expected real-world transaction mix, at transaction volumes approximately ten times the peak volumes expected for the production site. The stress-test covered both server and network performance.

This section describes the test methods, provides samples of performance evaluations for servers and the network, and defines the network rating criteria used.

Test Methods

Our goal in stress testing was to see if any of our code components or Windows NT services would fail if large numbers of order transactions were being posted to the Web servers. This was achieved by running a series of stress-tests, and creating performance reports from the measured data.

Stress testing was carried out, using our development servers, by first creating a SKU page to generate an order with randomly-selected product SKUs, then modifying the confirmation page code slightly to redirect back to the start of the same SKU page on completion. The resulting loop posted one order to the database each time it was completed, exercising all the associated components on the way.

Typical order transaction rates tested were approximately 1,500 orders per hour, with each order having one, two, or three items at random. The following diagram and code example illustrate the setup and the stress test script loop.

Figure 19 Posting Data from the End-use Machine to the Database

Stress Test Script Loop

The following were the scripts used in the various Active server pages to 
post the data continuously without user interaction.
----------OrderHandoffSKU46.asp----------
Dim leviathanURL
leviathanURL = "checkoutSKU46.asp" 
leviathanURL = leviathanURL & "?mscssid=" & Shopper_Id & "&use_form=1"
Response.Redirect(leviathanURL)

----------checkoutSKU46.asp-----------
In this page we really did not add any additional code but to simply submit 
the form as soon as the page is loaded.
-------xtl_PurchaseFormSKU46.asp----------
Dim pageRedirect
pageRedirect = "confirmationSKU46.asp?" & mscsPage.URLShopperArgs("order_id", rsOrder("Order_Id"))
call Response.Redirect(pageRedirect)

------confirmationSKU46.asp-----------
Response.Redirect("https://levdev1/smoke/sku46.asp")
Redirects to the beginning page SKU46.asp

Performance reports included Web server processor and memory utilization, ASP and Web service throughput, and processor and memory utilization for the database servers. Samples of these performance reports, with analysis, are shown below.

Network performance reports were based on transmitted data volumes, the number of "round trips" between server and browser, and the average frame size. These measurements were combined to create a network rating (see below) for each test, using the algorithm described in "Network Rating Criteria" at the end of this section.

The servers and network were stress-tested separately, using a similar transaction mix. In each case, the transaction mix was developed to represent the expected profile of production transactions. Transaction volumes were ramped up until either expected peak growth volumes were met, or the system failed.

Microsoft Performance Monitor was used to measure server performance, with Webload 3.0 scripts generating the test transactions. Network performance was measured using Optimal Application Expert and SQL Trace. The following table summarizes the transactions simulated and measurements for both server and network performance testing.

Table 7 Transactions and Measurements

Test	Transactions simulated	Measurements
Server performance	Hit main page, Edit info, Change address, Submit Change Quantity, Recalculate Purchase Customer Service (Order Status) - Item Status, USD link, Order list Customer assistance—Feedback about site, Submit feedback CSR—Search on name, Item status	Individual server resource usage statistics (CPU, disk, memory, and network utilization). Approximated minimum, maximum, and average times required to complete transactions under different stress levels.
Network performance	Same transaction mix as Server performance. Network captures were repeated 3-5 times for each transaction to obtain an average.	Bytes and packets transferred for each transaction including round trips required over network. Response time breakdown—time spent in DB, IIS, Client, Network, and total time for each transaction thread. Client response times at different connection speeds and latencies.

Testing included the Microsoft Direct Order Management application, and other customer assistance applications not covered in this white paper.

Server Performance

Server performance testing used a WebLoad 3.0 script to simulate approximately 10-times the expected load in the production environment. The script ran business transactions within a browser on a test client connected outside BIG/ip, in the same way that end-users connect to the application in production. Microsoft Performance Monitor was used locally on the IIS Server to measure processor utilization during the test.

Future plans to improve performance include replacing BIG/ip with the Microsoft Windows NT Load Balancing Service (WLBS), which is a component of the Windows NT Server 4.0 Enterprise Edition. This service allows you to combine the resources of up to 32 NT servers into a single cluster that can be referenced by a single IP address.

For more information on Microsoft's WLBS (load balancing technology), refer to https://www.microsoft.com/NTServer/ProductInfo/features/WlbsFeat.asp.

Application performance had no adverse effect on the servers. IIS processor and memory utilization was within an acceptable range, as were the database server processor and memory utilization.

Table 8 Sample Results—IIS Server Processor Utilization

IIS Web Server Data	Minimum	Average	Maximum
System – % Total Processor Time	12%	78%	90%
System – % Total Privilege Time	5%	40%	49%
System – % Total User Time	7%	38%	51%
Inetinfo – % Processor Time	16%	100%	100%

Analysis: Standards require System % Total Processor Time to average 80% or less for Web sites that reside on their own IIS Server or IIS Cluster. The average utilization (78%) observed during testing meets this standard.

Table 9 Sample Results—IIS Server Memory Utilization

IIS Web Server Data	Minimum	Average	Maximum
Available Memory (in megabytes)	913	914	919
Pages/sec (in megabytes)	1.5	4	22
Inetinfo Process Private Bytes (in megabytes)	26	31	29
Inetinfo Process Working Set (in megabytes)	28	32	33

Analysis: Memory counters observed during the above test exhibited no signs of memory leakage. The IIS–Working Set counter increased approximately five megabytes during the 20-minutes of test activity while the System–Available Memory and Inetinfo–Private Bytes counters remained constant throughout the test. The pages/sec counter averaged four megabytes, this shows no excessive paging was observed during the IIS Server Memory Test.

Table 10 Sample Results—IIS Server ASP & Web Service Utilization

IIS Web Server Data	Minimum	Average	Maximum
Inetinfo - % Processor Time	16%	100%	100%
ASP – Requests/Second	1	3	9
Web Service – Get Request/Second	4	41	60
Web Service – Post Request/Second	1	2	5

Analysis: Based on the test results Microsoft Direct had average ASP – Request/Second of approximately 3 request/second and maximum of 9 request/second. The Web Service counters, Get Requests/Second and Post Request/Second averaged 41 request/second and 2 request/second respectively. SAT tested using approximately 10-times the amount of stress than the expected rate of the production environment.

Table 11 Sample Results—Database Server Processor Utilization

Database Server Data	Minimum	Average	Maximum
System – % Total Processor Time	1%	2%	4%
System – % Total Privilege Time	1%	1%	2%
System – % Total User Time	1%	1%	2%
Server – % Processor Time	1%	2%	7%

Analysis: System Acceptance Testing (SAT) standards require the System % Total Processor Time to average 80% or less for databases that reside on their own server. The average utilization (2%) observed during testing meets SAT standards. The Server – % Processor Time and other system processor counters exhibit extreme low averages.

Table 12 Sample Results—Server Memory Utilization

Database Server Data	Minimum	Average	Maximum
Available Memory (in megabytes)	834	850	866
Pages/sec (in megabytes)	0	1	19
Process Private Bytes (in megabytes)	798	799	800
Process Working Set (in megabytes)	87	103	119

Analysis: Memory counters observed during the above test exhibited no signs of memory leakage. The Server–Working Set counter increased approximately 35 megabytes during the 20-minutes of test activity while the System–Available Memory counter decreased the same amount. The Server–Private Bytes counter remained constant throughout the entire test. Therefore, it can be assumed that all memory consumed on the server was used for the Process.

Network Performance

For each task, network traffic was captured by a testing tool (Optimal Application Expert), and Microsoft SQL Server activity was recorded with SQL Trace. Seven meaningful tasks were selected for the Test Summary Report; they may represent the best and/or worst use of the network by the application.

The test client configuration used was a P-Pro200 with 128MB RAM, and 4GB HDD. Four iterations of each user action were run to find a median response time.

Due to the nature of the application, captures had to be recorded in two sets. One set of captures was recorded with the client on our back-end LAN (to capture client-to-IIS transmission times, not possible if the client goes through a proxy server). The second set was recorded with a client going through the proxy cluster (to access RegWiz components of the application). There were difficulties in reconfiguring the application to work on our back-end LAN only, and technical difficulties recording some of the network traffic for the proxy server testing.

The application scored a satisfactory network performance rating, using the in-house criteria. See "Network Rating Criteria" below for an example of calculating the network performance rating.

Client processing took the highest percentage of transaction duration in all of the transactions tested (expected). All transaction times were relatively low.

IIS processing for the Change Product Quantity and Change Customer Address functions was higher than average. A duration of this length does not pose any serious performance issues, but a code review of these areas could potentially lead to better IIS performance.

Network Rating Criteria

Since no existing documentation could be found on rating an application for network performance, in-house rating criteria was developed. Since the team was familiar with Microsoft Network Monitor and Optimal Application Expert, these tools were used to collect and analyze the network captures.

Network ratings were developed by identifying the key factors in network performance, taking measurements, and then weighting the results. Some common performance measures were omitted, either because they were judged to be application-specific, or because they did not take all the elements of performance into consideration. The tables below describe the key factors used, the weightings selected, and the performance measures that were omitted.

Table 13 Key Factors and Weightings

Factor	Description	Weighting
Kbytes/Round Trip	Demonstrates how much data the application is moving in an average round trip. The higher the number, the more efficient the application is at transmitting data. A round trip is a complete request-response transaction between client and server, not counting zero length ACKs.	30%
Round Trips	This is the biggest factor in client response times in a slow link WAN environment. The smaller the number of round trips the more efficient the network is.	30%
Average Frame Size	Tells us how efficiently the application is packing its shopping cart. The larger the frame size, the more efficient the application is.	20%
Efficiency Score	This is a subjective rating based on factors such as frame padding, loading redundant meta-data, client caching, data access methodology, use of SQL Batching, offline capabilities, use of sp's vs. dynamic SQL, persistent DB connections, use of local persistent storage, read only data, application performance anomalies, passive (e.g. "keep alive") traffic, and so on.	20%

Reasons for weighting the criteria: Kbytes/Per Round Trip and Round Trip were weighed at a slightly higher percentage because they were directly involved in application performance (response time) on the network. Average Frame Size was weighted at a slightly lower percentage since it doesn't affect application performance as drastically as the first two items, but is still a good indicator of how efficient an application is. Since the Efficiency Score is the only subjective measurement, it was weighted at a lower factor to reduce any undue application bias.

Table 14: Performance Measures Omitted

Measure	Reason for omitting
Total Kbytes	This is application-specific. Due to their nature, some applications may be required to send more data across the wire than others.
Payload vs. Overhead	Does take into consideration frame padding, and does not reflect applications that use a large number of small frames to transmit data.
Total Frames	This is application-specific. This is a direct correlation of the Total Kbytes.
Duration	Does not take into consideration client and server induced delays.

Lessons Learned

Impact of Development Environment

Microsoft Direct was designed from the very beginning to interface with multiple Tenants and Vendors, and to take advantage of a number of internal cross-company development projects for services such as load sharing and user authorization. We learned that interfacing with so many other major projects, many of which were themselves also under development, can repeatedly impact your own development schedule, since it may not match theirs.

Early Stress Testing

It was a good idea to do our stress testing early on, because it gave us time to fix some of the unexpected deadlocks and stability problems that only occurred when components were exposed to very high transaction volumes.
We were able to optimize our stored procedures, for example, after tests that ran high volumes of orders from the Tenants, updates from the Vendors, and inquiries from users all at the same time. These test results were very valuable, even though it had meant creating scripts to simulate many of the key elements—such as Tenant Stores—that were not yet part of Microsoft Direct at the time we ran the tests.

Testing for Scalability

Microsoft Direct was designed from the beginning with the capability of integrating with a large but unknown number of Tenant stores and service Vendors. We learned quickly that testing for this level of scalability meant a great deal of Build Verification Test (BVT) script development from the system design team.
BVT scripts were used not only to verify the user interface for each Microsoft Direct build, but also to test extended functionality for critical areas of external components. These critical areas included all batch and interface services, e-mail services, security verification, Taxware DLL verification, Commerce Pipeline, feed settings, and Tenant/Reseller handoff.

Integration Testing

Testing the integration of our Tenants and Vendors was difficult at times, partly due to the need to generate realistic transaction feeds when no outside source yet existed, and partly due to differences in testing schedules between Microsoft Direct and our future Vendors.
Two transaction feeds from the Tenants, new order feed and SKU feed, required simulation. For the new order feed, the development team designed a pump to simulate the shopper basket handoff. This pump played a key part in giving us the ability to test Microsoft Direct features in their entirety, and was modified over the testing life cycle of Microsoft Direct to simulate orders placed by U.S. customers, as well as multiple Tenants coming onboard to Microsoft Direct.
One of the inbound transaction feeds from the Vendors, the order status feed, was more difficult to test because the interface was encrypted using PGP. The test team developed a process of decrypting a file that had already been sent by the Vendor, and manipulating it to produce status updates to orders in Microsoft Direct's database. By using the appropriate PGP decryption key and modifying the Vendor feed, we were able to test the order status feed logic, initially using a manual process and later by running a continuously looping .asp file.

Browser Support

We learned that supporting a wide range of browsers was more complicated than we had expected because of browser differences. The team encountered a large number of browser workarounds that were needed for Microsoft Direct, due to the differences in browser implementation across different operating system environments, and even among different versions of the same browser (see the Implementation section "Browser Support" above).
Some of these differences, such as the inability of some browsers to support JavaScript arrays or SSL protocols, surfaced early on, but were bypassed by making browser-dependent versions of the affected pages, and, therefore, did not otherwise affect the application logic. One significant browser difference that affected application logic was page persistence where, for some browsers, pages remained in cache and did not expire, even at the end of a transaction (such as committing a purchase). This affected application logic because of its potential for confusing the shopper about whether their transaction was indeed ended, since their basket might reappear, apparently uncommitted, if they pressed the back button on their browser.

Conclusions

The original objectives of the Microsoft Direct project were:

To provide cost-effective order management and customer service to online purchasers of software, hardware, and publications.
To create a single, scalable infrastructure capable of supporting multiple online Tenant stores and fulfillment Vendors.
To showcase Microsoft's own electronic commerce technology.

All of these objectives have been met.

Microsoft Direct successfully processes high daily order volumes for shoppers who wish to obtain their Microsoft products, such as software, hardware, and publications, directly from Microsoft. Microsoft Direct's customer service application successfully allows consumers to query, change, and cancel their own orders, and has been responsible for successfully pushing back to the consumer most of the administrative effort previously handled by internal customer service reps.

Microsoft Direct has created a single infrastructure capable of supporting additional Tenants, fulfillment Vendors, and geographic regions by designing for scalability, recognizing the importance of evaluating future performance from the very beginning, and supporting the widest possible range of browser technologies to meet the needs of the Tenant's customers.

Microsoft Direct clearly showcases Microsoft's electronic commerce technology. It shows how Microsoft commerce 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, can be designed to scale to meet the needs of over 60,000 online order transactions per day.

Appendix A—Troubleshooting

1. Multi-Browser Issues

1.1 Long Downloads and Timeouts

Applies to: HTML with data decryption.

Symptoms: Long download times.

Cause: HTML comments that span multiple lines are causing Data Decryption errors.

Workaround: A patch has been developed that is supposed to fix the problem.

The options are either to remove the multiple lines from the HTML comments, or drop the patch on the client for testing purposes and implement a disclaimer.

Internet Explorer 4.5 for MAC should have this patch and is scheduled for a sign off on 12/11/98 and to be released online on 1/5/98.

1.2 HTTP Could Not Initialize Socket Library

Applies to: Microsoft Windows NT Server version 3.51; Microsoft Internet Information Server version 1.0.

Symptoms: When the World Wide Web Publishing Service cannot start automatically during Microsoft Windows NT boot, you will get the following event viewer error message:

HTTP could not initialize socket library.

The properties of the services in Microsoft Internet Service Manager are not available. When you start the World Wide Web Publishing Service and FTP Server service manually, you will get the following error message:

Data area passed to system call is too small.

Workaround: A workaround is to change the order of protocols listed in the HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Winsock \Parameters \Transports registry key by moving the TCP/IP protocol to the top of the list. Another workaround is to uninstall and then re-install the Windows NT Option Pack.

1.3 Unable to connect to '< >' a connection with the server could not be established

Symptoms: On a Web site with a large number of concurrent users using Secure Sockets Layer (SSL), the client may randomly receive the following error message:

Unable to connect to '<Web site>' a connection with the server could not be established.

Refreshing the page can recover the session.

Cause: The more complex the page, the longer it takes to download the page; therefore, fewer people can enter the site at one time. If you have a site with complex pages, you will encounter this problem with only a small number of concurrent users more frequently than a site with simpler pages.

This problem arises because each individual object on a page creates a separate session to download this object to the client. By default, the SSL component has only sufficient cache to maintain 100 sessions. This limitation is associated with the schannel component (Schannel.dll), used for SSL/PCT.

Workaround: To increase the size of the SSL server cache, modify the following registry entry:

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Control \SecurityProviders \SCHANNEL

Value Name: ServerCache
Data Type: REG_DWORD
Data: 1000 (Default = 100)

1.4 Download Error

Symptoms:

Cause: The server is trying to return a MIME type back to the client that it doesn't say it will accept, therefore, the response fails.

Workaround: Set MIME type on the client to not care about .asp and .txt files. Set Response.CacheControl=Public on all .asp pages.

2. Secure Socket Layer (SSL) Issues

2.1 Registry Changes

Applies to: Windows NT SP4, IIS 4, Microsoft Proxy 2.0 when using SSL.

Symptoms: GPFs.

Workaround: Make the following registry changes:

HKEYLOCALMACHINE \CurrentControlSet \Services \W3SVC \Parameters \ReplyWithHttp1.1REG_DWORD set to 0HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Control \SecurityProviders \SCHANNELValue Name: ServerCacheData Type: RED_DWORDData: 1000 (Default = 100) – Set to 10,000 in Production

2.2 Memory Leak When Using Secure Sockets Layer (SSL)

Applies to: Microsoft Internet Information Server version 4.0. (From Microsoft Knowledge Base Article: 192295).

Symptoms: Memory leaks occur when you use the Secure Sockets Layer. By tracking the amount of private bytes for Inetinfo.exe, you will see that, over time, private bytes increase.

Cause: The memory leak occurs on each client accessed over the HTTP connection. IIS fails to free the memory allocated by Schannel.dll.

Workaround: A supported fix that corrects this problem is now available from Microsoft, but has not been fully regression tested and should be applied only to systems experiencing this specific problem. If you are not severely affected by this specific problem, Microsoft recommends that you wait for the next Windows NT service pack.

To resolve this problem immediately, contact Microsoft Product Support Services to obtain the fix.

2.3 Cannot open the Internet site 1040 Bug

Applies to: Microsoft Internet Explorer version 4.01 for Windows 95; Microsoft Internet Explorer version 4.01 for Windows NT 4.0.

Symptoms: When you use Internet Explorer to connect to a secure Web site with 128-bit encryption, you may receive the following error message, or one similar to it:

"Internet Explorer cannot open the internet site URL:<> the downloaded file is not available. This could be due to your security language setting or because the server was unable to retrieve the requested file."

"Internet Explorer cannot open the internet site URL: <> the connection to the server was reset."

IEXPLORE caused an invalid page fault in module WININET.DLL at 0137:7023d550. Registers: EAX=00489ae0 CS=0137 EIP=7023d550 EFLGS=00010202 EBX=00000000 SS=013f ESP=0086ff38 EBP=00412044 ECX=00000000 DS=013f ESI=0047bdb0 FS=33e7 EDX=0000000f ES=013f EDI=004e25ec GS=0da6

Workaround: A supported fix that corrects this problem is now available from Microsoft, but has not been fully regression tested and should be applied only to computers experiencing this specific problem. To resolve this problem immediately, contact Microsoft Technical Support to obtain the fix. If you are not severely impacted by this specific problem, Microsoft recommends that you wait for the next service pack that contains this fix.

3. IIS Configuration Issues

3.1 Memory Space

Symptoms: You may receive the following error message or one similar to it:

Microsoft OLE DB Provider for ODBC Drivers error '80004005' [Microsoft][ODBC SQL Server Driver][SQL Server] Login failed //global.asa, line 27 Response object error 'ASP 0156 : 80004005' Header Error /include/error.asp, line 18

Cause: The HTTP headers are already written to the client browser. Any HTTP header modifications must be made before writing page content.

Workaround: Ensure Web sites are running in their own memory space.

4. Microsoft SQL Server Connection Issues

4.1 ADODB Error

Applies to: Microsoft Visual InterDev, version 6.0.

Symptoms: Attempting to use setSQLText() or setRecordSource() on a recordset that is bound to a stored procedure gives the following Microsoft ActiveX^® Data Objects (ADO) error:

ADODB.Parameters error '800a0cc1' ADO could not find the object in the collection corresponding to the name or ordinal reference requested by the application. /kb/_ScriptLibrary/Recordset.ASP, line 456

Cause: The recordset sets its parameters before opening the recordset. Even though the database object has changed, the routine that sets the parameters is still called.

Workaround: There are two workarounds for this. (1) Use different recordset DTCs for the stored procedure and the new record source, or (2) do not set the parameter for the stored procedure in the Parameters tab. Instead, set the parameter programmatically. A good place to do this is in the onbeforeopen event. Note that if you use this workaround, you need to know which state your recordset is in so you can avoid setting the parameter(s) after changing the recordSource/SQLText.

In a DHTML page, setting the parameter programmatically will not work. Consider using two recordset DTCs.

Status: Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article. We are researching this bug and will post new information in the Microsoft Knowledge Base as it becomes available.

More information: Steps to reproduce behavior:

Create a project with a data connection.
Add a page.
Add a recordset to the page.
Bind the recordset to a stored procedure that takes parameters.
Set the parameters in the Parameters tab.
Use setSQLText() or setRecordSource() to change the record source, for example:

Recordset1.setSQLText("SELECT * FROM AUTHORS")

4.2 Deadlock Error

Applies to: Microsoft SQL Server, version 4.2.

Symptoms: A call to a stored procedure that in turn calls another stored procedure can, in some cases, generate error 925:

Maximum number of used databases for each query has been exceeded. The maximum allowed is %d.

Cause: Microsoft SQL Server is not correctly freeing the data structures used to maintain information for each database when the called stored procedure fails with a deadlock.

Workaround: Reestablish your connection to Microsoft SQL Server in order to get a new spid.

Status: Microsoft has confirmed this to be a problem in Microsoft SQL Server version 4.2. We are researching this problem and will post new information in the Microsoft Knowledge Base as it becomes available.

More information: Given two stored procedures, CALLED and CALLER, where procedure CALLED is called by procedure CALLER, error 925 will occur if:

Procedure CALLER and procedure CALLED exist in two separate databases.
Procedure CALLER calls procedure CALLED repeatedly utilizing the same connection to the server (spid).
Procedure CALLED fails because of a deadlock that generates error 1205:

Your server command (process id #%d) was deadlocked with another process and has been chosen as deadlock victim. Re-run your command.

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada Information Center at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information via the World Wide Web, go to the https://www.microsoft.com site.

Site Server - Direct Technical Deployment

Microsoft Direct

Solution Overview

Order Management

Customer Service

Microsoft Direct Requirements

Client Requirements

Specification

Detailed Process Flows

Order Management

Customer Service

Batch Processing

Tenant Interface Processes

Internal Batch Processes

External Interfaces

Data Architecture

Stored Procedures

Physical Architecture

Security

Customer Validation

Access to Secured Data

Implementation

Timeline and Resources Used

Code Components

Site Server Implementation

Re-using Components

Plan Pipeline Modifications

Taxware Component Integration

Controlling Page Caching

Implementing the E-mail Service

Browser Support

Development Tools

Performance Evaluation

Test Methods

Server Performance

Network Performance

Network Rating Criteria

Lessons Learned

Impact of Development Environment

Early Stress Testing

Testing for Scalability

Integration Testing

Browser Support

Conclusions

Appendix A—Troubleshooting

1. Multi-Browser Issues

1.1 Long Downloads and Timeouts

1.2 HTTP Could Not Initialize Socket Library

1.3 Unable to connect to '< >' a connection with the server could not be established

1.4 Download Error

2. Secure Socket Layer (SSL) Issues

2.1 Registry Changes

2.2 Memory Leak When Using Secure Sockets Layer (SSL)

2.3 Cannot open the Internet site 1040 Bug

3. IIS Configuration Issues

3.1 Memory Space

4. Microsoft SQL Server Connection Issues

4.1 ADODB Error

4.2 Deadlock Error

Additional resources