Microsoft Commerce Server 2000: A Retail Scenario

Planning, developing, and deploying a retail Web site is an exciting, yet substantial, undertaking. In this chapter, you can look over the shoulders of the team members of a fictitious company – Contoso, Ltd.– as they plan, develop, and deploy their retail Web site. The content for this chapter is drawn from real deployments of Microsoft Commerce Server 2000. For detailed information about these deployments, see https://www.microsoft.com/commerceserver/ . The purpose of this scenario is to help you understand the planning and development required to deploy a Commerce Server retail (business-to-consumer) site, and to familiarize you with the extensive resources found in Commerce Server 2000 Help and in this Commerce Server 2000 Resource Kit.

Although every company has its own specific needs and objectives and no two commercial Web sites are exactly the same, there are many common areas that most retail sites need to address. For an example of a supplier (business-to-business) Web site, see Chapter 3, "A Supplier Scenario."

Putting Together the Contoso Team

Contoso, Ltd. is a healthy international catalog business that generates significant revenues from mail order and toll-free telephone business. When mail order and telephone customers began asking why the company didn't have a Web site, Contoso decided that it was risking the loss of a significant sector of its market if it didn't make the move to the Web.

To begin the project, a group of Contoso senior executives put together a cross-discipline team to plan, develop, and deploy a Web site that would enable customers to browse an online version of their existing catalog, make credit card purchases, and specify types of shipments. The senior executives wanted their team to create a site that would easily scale for growth and from which they could gather data that would enable them to anticipate and plan to meet their customers' needs.

Contoso created a cross-functional team to ensure that the Web site would integrate with their company's existing infrastructure, that it could be scaled to handle growth, and that it would integrate successfully with the rest of their company's business. The team was comprised of the following members:

• System administrator. Responsible for making sure the new Web site integrates well with existing enterprise systems and for planning operational procedures to support the new site.

• Site designers. Responsible for designing an attractive site that maintains the existing Contoso look, feel, and branding.

• Interface designers. Responsible for creating an intuitive, easy-to-navigate environment in which customers can find what they need without becoming overwhelmed, frustrated, or lost.

• Site developers. Responsible for maximizing the benefits of Commerce Server and its supporting infrastructure, and for creating custom code where needed.

• Testers. Responsible for working with the site developers to ensure that the site is stable and robust before final deployment.

• Marketing staff. Responsible for maximizing the benefits of the Commerce Server Business Analytics and Targeting Systems.

• Technical writers. Responsible for writing and editing on-screen content to simplify and enhance the customer experience.

• Accounting staff. Responsible for working with site developers to modify the Business Process Pipelines System so that it integrates with existing systems.

• Security staff. Responsible for designing security for the Web site and working with the site developers to implement security.

• Third-party systems integrator. Responsible for integrating third-party software solutions with Commerce Server functionality.

Planning

The Contoso team had two main goals: to deploy their retail Web site as soon as possible, and to deploy a site that was well designed, thoroughly tested, and seamlessly integrated with the company's existing infrastructure.

Planning was essential to meet these goals. Planning facilitated development by clearly delineating what needed to be done and helping to ensure that the site integrated well with the existing infrastructure.

The Contoso team divided into the following planning groups:

• Commerce Server Installation Planning. Chose which Commerce Server features to use.

• Site Architecture and Security Planning. Planned how to integrate with existing systems and identified the custom code, including Active Server Pages (ASP) pages, that had to be written.

• Deployment Planning. Developed checklists to make sure that all systems were ready for deployment.

The members of each group researched their area, and then reported back to the full team. The full team then worked together to create a comprehensive Project Plan and to ensure that all the parts would come together for final deployment.

Commerce Server Installation Planning

The Contoso Commerce Server Installation Planning group used Commerce Server 2000 Help to research the following features:

• Administration and Management Tools

• Business Analytics System

• Business Process Pipelines

• Product Catalog System

• Profiling System

• Targeting System

Administration and Management Tools

Commerce Server 2000 provides two tools for managing and administering the Contoso Web site: Commerce Server Business Desk and Commerce Server Manager.

Business Desk is a site management tool that hosts business management modules for managing day-to-day operations and analyzing site activity. The following table summarizes how Contoso decided to use the Business Desk to manage its site.

Business Desk category	Implementation
Analysis	The Contoso team decided to use Commerce Server standard reports. They don't plan to integrate a third-party reporting solution in the initial deployment of the site, but will re-evaluate this decision after running the site for six months. The specific requirements for Analysis are explained in "Planning the Business Analytics System" later in this chapter.
Campaigns	Contoso will sell advertisements and offer house ads to suppliers. The team will create direct-mail campaigns to send sales announcements to regular customers.
Catalog	Contoso must convert its existing catalog structure into the appropriate Extensible Markup Language (XML) format and then import it, using the Catalog Editor module. The team established a process for keeping the two catalog systems synchronized. For more information about updating catalog data, see Chapter 15, "Deploying Content."
Orders	Contoso has a contract with a shipping company, so it simply added the appropriate billing information using the Shipping Methods module. The team entered tax information required by a third-party tax component using the Tax Rates module.
Users	The Contoso team defined additional User properties for analyzing its customer base and targeting content.

Contoso used Commerce Server Manager to manage and configure the Commerce Server resources, sites, applications, and Web servers it would need to administer its site. The following table describes the site resources Contoso implemented.

Resource	Implementation
App Default Config	Contoso used the App Default Config resource to set up site functionality, such as currency and billing options. For more details, see "Adjusting Settings in the App Default Config Resource" later in this chapter.
Commerce Server Data Warehouse	Contoso decided to use Microsoft SQL Server 2000 for its Data Warehouse. It installed the Data Warehouse on a dedicated computer. For more details, see "Deployment" later in this chapter.
Commerce Server Direct Mailer	Contoso set up a direct-mail campaign to send mail about special offerings to customers who signed up for this service.
CS Authentication	Contoso based its site on the Retail Solution Site, using the default authentication scheme provided. The Retail Solution Site enables customers to shop without accepting cookies. This was a significant factor for Contoso; it didn't want to force customers to accept cookies.
Predictor	Contoso chose not to use the Predictor resource in its initial deployment, but plans to incorporate it later, when there is sufficient information in the Data Warehouse.
Profiles	Contoso extended the User profile to track customers who have signed up to be notified about special offerings.

Business Analytics System

The Business Desk Analysis modules and the Data Warehouse provide the foundation for a powerful Business Analytics System. Business analytics provides you with a way to analyze the performance of your Web site. You can use the information provided by the Commerce Server Business Analytics System to improve your customer service and to target content to users.

The Data Warehouse is a combination of a SQL Server database, an online analytical processing (OLAP) database, and a set of processes that a system administrator uses to import and maintain large amounts of data from multiple data sources. This data is gathered from Web server logs, the Commerce Server databases (Profiles, Catalogs, Campaigns, and Transactions) and other data sources that you can specify. You can use the Data Warehouse to manage, query, and analyze the data in the SQL Server and OLAP databases. The Analysis modules use Data Warehouse information to identify user trends, analyze the effectiveness of a campaign, and monitor user click patterns and a host of other information.

You can use the standard reports provided by the Reports module to answer the following types of questions:

• What Uniform Resource Locator (URL) did the customer visit before arriving at our site (referring URL)?

• What type of advertising works?

• What pages on our site are the most popular?

• Which products sell the best?

• Which customers buy the most?

You can use this information to increase sales and retain customers. For example, after displaying an advertisement to promote a new product for a week, you might decide to run a report to determine whether the ad increased sales. If it didn't, you might decide to add a 10-percent discount and then, after a week, once again analyze sales results.

The data that populates the Data Warehouse can come from multiple data sources: Web server logs, Commerce Server databases, and other data sources that you specify. Because the Data Warehouse isn't part of your run-time environment, you must decide how frequently to import operational data into the Data Warehouse. For example, you can set up the Data Warehouse so that it automatically imports new data every day or every week, depending on the amount of new data you collect every day. Commerce Server provides custom Data Transformation Services (DTS) tasks to simplify the data importing process.

The Contoso Commerce Server Installation Planning group interviewed the members of the executive committee to determine success criteria for the site. The success criteria were then used to establish reporting requirements. The Installation Planning group read the "Business Desk Analysis" section of Commerce Server 2000 Help to evaluate the standard reports provided by Commerce Server. As a result of their research and interviews, they decided to provide the reports listed in the following table to upper management on a monthly basis.

Report	Success criteria
Product Sales	Minimum average monthly revenue of $250,000
Buyer Browse to Purchase	30 percent of browsers make a purchase
User Visit Trends	20 percent increase per month in number of site visits

The team also identified other reports, such as those listed in the following table, to help them monitor and maintain the site.

Report	Purpose
Registered Users by Date Registered	Monitor capacity requirements for the back-end data store
User Visit Trends	Determine whether customers are returning to the site
Usage Summary Reports	Determine best days and times to perform maintenance operations
Entry Path Analysis	Identify site pages that receive the most traffic

The Installation Planning group also reviewed the extensions to the Commerce Server reporting capabilities offered by third parties (located at https://www.microsoft.com/commerceserver/partners ). Although the group felt that these third-party reports might add greater depth to their analysis, they decided to use only the standard reports during the initial phase of the project.

Business Process Pipelines

The Contoso team was pleased with the Commerce Server Business Process Pipelines System. They saw many opportunities for bundling their business processes into pipelines. They planned to use the pipelines to define and link together the stages of their business processes, and then run them in sequence to complete each task.

A pipeline is a way of stacking up tasks into a list for processing. For example, the Order Processing pipeline (OPP) contains the sequence of steps necessary to process orders. For example, in the first stage in the OPP, you retrieve product information from the Catalogs database. In the next stage, you add the customer's address to the order. Each stage in the pipeline represents a task. The sequence of the stages determines the sequence in which the tasks are done.

Commerce Server provides a set of pipelines that perform much of the standard processing required by a Commerce Server site. You can tailor the pipelines to meet your specific needs. For example, you can add new stages to the pipeline, integrate pipeline components with your existing system, or replace pipeline components with other components supplied by third parties.

The Installation Planning group studied the pipelines provided by Commerce Server very carefully. They downloaded the Retail Solution Site from https://www.microsoft.com/commerceserver/solutionsites and used Commerce Server Site Packager to unpack it on their development Web server. After examining the way in which the pipelines were implemented in the Retail site, they decided to use the pipelines in the following table.

Pipeline	Purpose
Product	Retrieve product information from the product catalog (OPP)
Basket	Manage the customer's shopping basket (OPP)
Checkout	Complete a purchase (OPP)
Advertising	Display appropriate advertisements (Content Selection pipeline (CSP))
Discounts	Apply appropriate discounts to an order (CSP)
Direct Mailer	Send e-mail messages announcing special discounts to registered customers who have signed up for this service (Direct Mailer pipeline)

The Installation Planning group also discovered that the Retail Solution Site provided template files for all of the pipelines they had selected except the Direct Mailer pipeline. They used the DMLPipe.pcf file (provided by Commerce Server Setup) to create their Direct Mailer pipeline. The team also examined the list of pipeline component vendors at https://www.microsoft.com/commerceserver/partners/default.mspx to find the pipeline components they needed for their tax and credit card processing requirements.

Product Catalog System

The Contoso team was especially interested in the Commerce Server Product Catalog System, because the product catalog is the mainstay of their business. One assignment was to bring their existing catalog online and to make sure that the online and offline versions were always the same. They had to be sure that customers were always presented with the same products and product numbers, whether shopping online or from the mail order catalog.

The team used the Catalog Editor module from the Product Catalog System to import catalogs and to create, modify, and delete categories and catalogs. They used an XML file to import their existing catalog information. The following code fragment, taken from their XML file, illustrates how they imported catalog information:

<?xml version="1.0" ?>
<MSCommerceCatalogCollection>
<CatalogSchema>
<AttributeDefinition name="RequiredProperty" dataType="string" />
<PropertiesDefinition>
<Property name="Artist" dataType="string" IsFreeTextSearchable="1"
IncludeInSpecSearch="0" MinValue="0" MaxValue="100"
DisplayOnSite="0" DisplayName="Artist" AssignAll="0" ExportToDW="0"
DisplayInProductsList="0" id="CatalogProperty0" />
...
</PropertiesDefinition>
</AttributeDefinition>
</CatalogSchema>
</MSCommerceCatalogCollection>

Contoso purchases books for resale in its catalog from ten different book and software distributors and eight hardware suppliers. Their primary supplier for books is Ferguson and Bardell Book Distributors. Contoso currently receives catalog information from Ferguson and Bardell by an e-mail update sent once a week. Contoso incorporates the information from the Ferguson and Bardell e-mail into the mail-order catalogs they publish quarterly. Prior to publishing their catalog, Contoso contacts all of their suppliers by phone or e-mail to verify product availability.

The following table summarizes the structure and product property requirements for the Contoso online catalog.

Feature	Implementation
Catalog schema	Contoso's catalog schema was already well established, so they simply had to recreate that schema in the XML file they imported. The schema includes three high-level product categories, with variant properties for each: Books, Hardware, and Software.
Custom catalogs	Contoso has decided to provide custom catalogs for registered users, based on user preferences. The custom catalogs will provide discounted prices.
Pricing rules	Prices are set at both the category and individual-product level.

Profiling System

The marketing members of the Installation Planning group were very interested in the Commerce Server Profiling System because they felt that it was extremely important to gather additional information about the company's customer base.

You can use Commerce Server profiles to collect and store information about the customers who visit your Web site. A profile is a set of characteristics that define any business-related item, such as a user, a company, or a context (date and time). For example, a user profile can include characteristics such as first name, last name, city, and e-mail address. A context profile can include characteristics such as the date and time when a page is displayed, and the path a customer takes to get to that page. The data that forms a profile comes from multiple sources, such as Web log files and Commerce Server databases. You can import profile data into the Data Warehouse for analysis, and then use the results to target content to groups of users.

The Installation Planning group realized that they had to be sure that the data entities they used to construct the profiles were consistent with entities that already existed in the database. They decided to add some properties to the user object to make targeting advertisements and discounts to their customers easier. For example, they added a Preferences property for targeting music and book advertisements. They made this a multi-value property because they knew they would want to allow multiple entries for user preferences.

The following table summarizes the property requirements for the user profile.

Property	Attributes, values, and usage
Preference	Preferences are multi-valued strings used to target ads and discounts to customers.
Custom catalog	Custom catalog is a string. There are eight different custom catalogs. Customers specify a custom catalog preference when they register.

Targeting System

Targeting and personalization are the processes used to deliver personalized content to one or more customers, or any other business entity that has a profile. Contoso decided to deliver advertisements and announcements about special discounts that were targeted to customer preferences.

The Targeting System has four sub-systems:

• Content Selection Framework (CSF)

• Direct Mailer

• Expression Evaluator

• Predictor resource

Content Selection Framework

The Content Selection Framework (CSF), based on the Commerce Server pipeline architecture, is a platform-level framework that contains the components and pipelines you use to specify the content you want to deliver for advertising and discount campaigns. You use CSF primarily to manage campaigns (the delivery of advertisements and promotions), but you can also use it to rank, select, and schedule any type of content.

The CSF architecture supports an open scoring system that enables you to change the algorithm you use to determine which piece of content to deliver. In addition, CSF supports a trace mode so that you can see exactly how the content has been scored and that enables you to adjust the algorithms accordingly.

Business Desk Campaigns modules provide a user interface that you can use to create campaign items such as advertisements, discounts, and direct mail. You can use the Expression Builder to build expressions for targeting an ad or discount to a specific group. The campaign items and expressions you create with Business Desk are then stored in the Campaigns database.

Contoso decided to provide house advertisements for partners and for discounted items, and to sell advertisements. They also decided to target these ads to registered customers. They defined the requirements listed in the following table for targeting these advertisements.

Content	Target
House ads	None. House ads aren't targeted; they are shown when there aren't sufficient paid advertisements to display.
Discounts	Registered customers, based on their preferences. For example, registered customers who prefer mystery books will be offered discounts on the mystery titles they add to their baskets. In addition, they will be shown advertisements for these discounts when they visit the site.
Paid ads	Customers, based on properties requested by advertisers. Advertisers can select three profile properties to which their ads will be targeted.

Direct Mailer

You use Direct Mailer to manage user mailing lists and to coordinate the sending of direct e-mail to list members. The e-mail you create can be personalized using ASP or it can be sent from a static file. The List Manager service can import e-mail addresses from either a flat file or a SQL Server database into a mailing database.

Direct Mailer is a Microsoft Windows 2000 service that can be installed with Commerce Server as part of a Complete or a Custom installation. There can be only one instance of Direct Mailer per server. However, you can include more than one Direct Mailer resource in your Commerce Server implementation by defining multiple instances at the Global Resource level. (Global resources are available for use by all sites. Global resources expose an object at the global level in Commerce Server Manager, and at the site level for those sites that are using the global resource.)

Direct Mailer performs the following tasks:

• Manages Direct Mailer jobs

• Constructs personalized and non-personalized messages

• Formats e-mail message headers

• Sets the code-page value (language) and converts messages to the correct type (MIME Encapsulation of Aggregate HTML Documents (MHTML), Multipurpose Internet Mail Extensions (MIME), or text)

• Sends e-mail messages to recipients

You can supply a list of recipients to Direct Mailer by using the List Manager module in Business Desk or you can run Direct Mailer in stand-alone mode from the command line and specify a list by file name or SQL Server query. You can use Direct Mailer to send personalized e-mail messages from a Web page or non-personalized mailings from a flat text file to large groups of recipients.

Contoso's marketing team decided to create the direct mail campaigns described in the following table.

Direct Mailer feature	Implementation
Target group	Contoso identified target groups for each of their three catalog categories: Books, Hardware, and Software. They might expand this list in the future.
Custom content	Contoso decided to provide custom e-mail content for registered users. The Custom content feature selects monthly discounts based on the preferences stored in the user's profile and sends them to users through e-mail.

Expression Evaluator

You can use expression-based targeting (also known as explicit targeting) when you know the profile properties of the users to whom you are delivering content, or you know the context and the content that is to be delivered. You use the Expression Evaluator to create business rules for personalized ad targeting, promotions, direct mail campaigns, and content targeting, based on the evaluations of conditional expressions.

You use the Campaigns modules in Business Desk to define expressions and deliver the content to the user. For example, if the Contoso site has a sale on books about snowstorm survival, they could use expression-based targeting to notify customers in North Dakota, but not send notifications to customers in Florida. If Contoso were trying to move their golf manuals, they could target customers who listed golf as a hobby.

Contoso's marketing team decided to create expressions to target the preferences they collect from customers at registration. For example, they created the expression Preference Contains "Mystery" to display discount information about mystery novels to registered customers who are mystery fans.

Predictor Resource

You use prediction, also known as implicit targeting, when you don't know all of the necessary profile properties to use to target a group of customers, or you don't have specific content to deliver. You can use the Commerce Server Predictor resource to extrapolate this information from existing data so that you can deliver content specific to each customer. For example, you can use the Predictor resource to discover what type of content, ads, and cross sells might interest your customers.

The Predictor resource is a Windows 2000 service that you can install with Commerce Server as part of a Complete or a Custom installation. Commerce Server supports multiple instances of the Predictor resource per commerce site, but only one instance per computer. You can install the Predictor resource on each computer that contains your Data Warehouse, or you can install it on separate computers, to save system memory.

Both expression-based targeting and prediction make it easier for you to deliver content to your customers. Customers are more likely to return to your site when they expect to receive a personalized experience.

Contoso decided not to implement the Predictor resource in its initial deployment, but the team realizes that they should plan to use it in the near future. Before Contoso can successfully implement the Predictor resource, they need to gather sufficient data in the Data Warehouse to build the required analysis models. The following table describes the models that the Contoso marketing team plans to build and the data those models require.

Model	Description	Data required
User preference	A Prediction model to determine which products to recommend on the Basket page.	Click history Transactions User preferences
User demographics	A Segment model for ongoing analysis of the site's audience.	The following properties from registered users: Country and postal code Age bracket Gender The team added age bracket and gender to the user profile, and added fields to capture these properties to the user registration form.

Capacity and Performance

It is difficult to predict how variables in site design, coding practices, user behavior, and site architecture will combine to affect site performance, so it is important to plan and test the capacity and performance of your site before deploying to a live production environment.

Performance planning and capacity planning go hand in hand; however, each addresses site usage from a different perspective. Performance planning addresses the technical aspects of the site, focusing on performance metrics, such as ASP page throughput and ASP latency. Capacity planning addresses both the technical aspects and the business perspective, focusing on maximizing the number of users that the site can handle.

Of the two, performance planning is the more straightforward. It is relatively easy to measure the number of checkout transactions per second and make comparisons to other commerce sites.

Analyzing user capacity is a little more complex. Before you can predict maximum user capacity, you first need to profile user behavior, and then use the user profile information in conjunction with your performance metrics to calculate capacity. User behavior varies from site to site, depending on the richness of the shopping experience (page design, site design, and response time), as well as the types of products being sold and the extent of the product line. One site may support 1,000 users, while another site installed on an identical platform may support only 200 users because of differences in user behavior. For more information about planning for capacity and performance, see Chapter 19, "Maximizing Performance."

The following table lists Contoso architecture and performance requirements.

Area	Description
Customer experience	Contoso realized that their biggest asset is their extensive catalog. They believe that providing fast access to catalog items is critical to their success. They agreed that the maximum time for returning an item from a free-text catalog search should be one second when the site is running at full capacity.
Usage profile	The Contoso team created a usage profile for measuring site performance, which includes the following factors: Total user base = 1,000,000 Concurrent user % = 1% (10,000) Average length of a session = 10 minutes Average number of operations per session = 10 The team also developed detailed usage profiles for each page on the site.
Web server configuration	They decided to begin with two front-end Web servers, based on the following calculation: Number of concurrent users/server capacity 10,000/5,000 = 2 Note The complete hardware configuration is summarized in "Deployment" later in this chapter.
Growth forecast	Contoso used the growth in their mail-order business to project the growth of their Web site. Their customer base is currently growing at a 20 percent annual rate. They project that they will reach a base of 1,000,000 customers by the end of the first year and maintain a 20 percent growth rate from that point on.
Integration with existing systems	The team decided to integrate the Web business with their existing systems in a series of stages. In the first stage, they integrated the product catalog. In subsequent stages, they plan to integrate their accounting system and their order-fulfillment system.
Availability	To provide for failover capabilities for the Contoso database, the team set up their two database servers using Windows 2000 Cluster service and SQL Server 2000 replication features.

Security

When you plan for Commerce Server security, you begin by deciding how to defeat security threats for each feature you deploy and by selecting the policies and tools necessary to achieve the level of security you want. To build a secure site, you need to configure Secure Sockets Layer (SSL) so that certain pages (such as pages that request credit card information) are served through SSL. To set this up, you need to get a server certificate and configure Internet Information Services (IIS) 5.0 to use SSL.

You should also specify a Secure Host Name for each Commerce Server application in the Microsoft Management Console (MMC). The AuthManager object uses the Secure Host Name to create links to secure pages. The links could lead to a different Commerce Server application or to a secure section of the same application.

To minimize the likelihood of a security breach, you must be able to:

• Lock down the site (control access to files, pages, and applications with access control lists (ACLs) on files that use the NTFS file system (NTFS)).

• Control access to reading or running scripts, and write access on various folders defined in your site for IIS security.

• Authenticate site visitors.

The Contoso team agreed that they must be able to guarantee the integrity of transactions conducted through their site. To accomplish this, they planned methods of locking down the site and creating a secure environment. They also decided to support a variety of authentication schemes. The following table describes the security decisions the Contoso team made.

Security issue	Description
Authentication	The team decided to allow customers to shop without registering, so the authentication system had to support both registered and anonymous users. The team determined that the authentication system built into the Retail Solution Site does exactly what they wanted.
Identification	Contoso elected to use cookies to identify users if a user's browser is configured to support cookies or to append an identification ticket to the QueryString data member if cookie support has been disabled. The Retail Solution Site also provides this functionality.
Firewall placement	The team consulted with a network expert to design the appropriate firewall configuration. Their configuration included two firewalls, one to isolate the data center from the Internet, and another one to isolate the database layer from the Web servers.

Completing the Planning Process

The Commerce Server Installation Planning group met regularly to describe what they had learned and to make a case for the features and functionalities they wanted to include in their site. The group had a reserved project room where they charted their plans and hung them on the wall, and then converted the charts into a project specification. Their project specification included the Commerce Server features described in the following table.

Feature	To be used to
Business Desk	Host business management modules for configuring site options and for managing the day-to-day marketing and analysis of site activity.
Commerce Server Manager	Manage and configure Commerce Server resources, sites, applications, and Web servers.
Data Warehouse	Import and maintain data in a combination of a SQL Server database and an OLAP database.
Business Process Pipelines	Define and link together the stages of their business processes, and then run them in sequence to complete each task.
Product Catalog System	Import their existing catalog and then manage the catalog online.
Profiling System	Collect and store information about the customers who visit their site.
Targeting System	Deliver personalized content to one or more customers.
CSF	Determine the content to be delivered for advertising and discount campaigns.
Direct Mailer	Manage mailing lists and coordinate the sending of direct mail to customers on the mailing lists.
Expression Evaluator	Target ads, promotions, and other campaigns.
Predictor resource	Extrapolate targeting information from the user data collected in the Data Warehouse. (This feature won't be implemented until the Contoso team determines that they have sufficient data in the Data Warehouse.)

The Installation Planning group also identified architectural and security requirements:

• High capacity and performance

• Ability to grow

• Integration with existing systems

• High availability

• Security

• Microsoft Active Directory integration

With these areas identified, the next step was to begin development.

Development

The Contoso development team began developing the new site by downloading the Retail Solution Site (from https://www.microsoft.com/commerceserver/solutionsites ) and experimenting with the built-in and extendable functionality. They also reviewed the Blank Solution Site which, when unpacked, provides a Web site which is essentially empty. The Blank site contains Business Desk and the set of empty databases upon which the site ultimately depends. They decided that the Retail Solution Site provided the most appropriate foundation for their site.

Using the Retail Solution Site as a starting point, the Contoso team identified the following areas in which they wanted to take advantage of the extensible design provided by Commerce Server:

• Importing the catalog

• Acquiring new pipeline components

• Modifying site look and feel

• Adjusting settings in the App Default Config resource

Importing the Catalog

Before the Contoso development team could import their catalog, they had to create an XML file that matched the Commerce Server Catalog XML structure. The development team examined the structure specified in the "Programmer's Reference" section of Commerce Server 2000 Help and the sample XML files provided as part of the Business Desk tutorial. They based their XML file on these two sources. When they were satisfied that they had structured their XML file appropriately, they used the Business Desk Catalog Editor module to import it.

Acquiring New Pipeline Components

A pipeline component is a Component Object Model (COM) object that supports a standard set of interfaces that you can invoke in a uniform fashion during the execution of the pipeline. The pipeline architecture enables you to create new pipeline components and "plug" them into existing pipelines. When you do this, you often replace an existing pipeline component and alter the processing that pipeline is performing.

A common example of this type of pipeline component replacement is the pipeline that is executed when a customer decides to check out, and the basket is processed to complete the transaction. The Retail Solution Site provides a complete pipeline for calculating the order total when a customer clicks the Check out button on the Basket page. This pipeline includes the SampleRegionalTax component to demonstrate the tax stage of the Purchase pipeline. Contoso acquired a tax component from ProseWare Corporation to replace this demonstration component. They also replaced the Scriptor – Payment Info component included in the Checkout pipeline with one of the payment components offered by a third-party.

Modifying Site Look and Feel

The development team studied the documentation for the Retail Solution Site to determine the best way to customize it. They decided to do the following to customize the site:

• Modify the site name

• Create new site styles by modifying the dictionary of styles in the Global_ui_lib.asp file

• Change the layout for the standard page by modifying the HTML in the Layout1.asp file.

• Change strings as necessary in the Rc.xml file

Figure 2.1 shows the Contoso home page after the team finished modifying the Retail Solution Site.

 

Figure 2.1 The new Contoso home page 

Adjusting Settings in the App Default Config Resource

The App Default Config resource is a Commerce Server resource with site-level properties that you manage through Commerce Server Manager. You can use App Default Config to set properties that determine site functionality in areas such as currency options, billing options, and Microsoft BizTalk Server 2000 integration.

The Contoso development team found that they didn't need to adjust many of the settings in the App Default Config resource. The majority of the values set by unpacking the Retail Solution Site package, Retail.pup, met their requirements. The following table describes the settings they decided to adjust.

Setting	Description
BizTalk Catalog Doc Type	The document definition name that BizTalk Server requires for catalogs.
BizTalk options	Options that determine whether or not a site can integrate with BizTalk Server. In the Retail Solution Site, the default value is 0 to disable integration. The development team set it to 1.
Add item redirect options	Options that determine whether or not a browser is redirected to the Basket page after a customer adds an item to the basket. In the Retail Solution Site, the default value is 1, which means that the product page will continue to be displayed. The development team set the value to 0 to enable them to redirect the customer to a different page.
Site privacy options	Options that determine whether or not to track profile information. The team consulted with the executive committee, and then decided that they didn't need this information. In the Retail Solution Site, the default value is 1, which means that anonymous users are tracked. The development team set this value to 0 to disable this feature.

Setting Up the Development Environment

The Contoso team created a development environment centered on Microsoft Windows Server 2003 technology, Microsoft Visual Studio and other development tools, and the Commerce Server 2000 Software Development Kit (SDK). The team also created a three-tiered testbed with IIS running on the user interface layer (top tier), Commerce Server 2000 and COM/COM+ objects providing the business logic (middle tier), and SQL Server on the database layer (bottom tier). Although the application architecture continues to be three-tiered, the developers decided to combine Web servers and application servers on the same computer, to prevent invoking objects over-the-wire in a separate application server scenario. That is, Commerce Server and other objects reside directly on the Web servers.

Deployment

By the end of the development and testing process, the Contoso team had created a system in their test environment that exactly duplicated the system they had decided to use for production. The test site consisted of the items listed in the following table.

Servers	Software
Two Web servers	Windows 2000 Advanced Server with Network Load Balancing IIS 5.0 Microsoft Internet Explorer 5.5 Commerce Server 2000 Windows 2000 Terminal Services (to support remote access to Business Desk) Note Both servers use Active Directory and serve as replicated domain controllers.
Two database servers	Windows 2000 Advanced Server with Windows Cluster service Microsoft SQL Server 7.0 Enterprise Edition and Microsoft SQL Server Analysis Services (OLAP) Notes The Contoso team used SQL Server replication to synchronize their database servers. They used Open Database Connectivity (ODBC) communication for retrieving information, such as order status, from their IBM AS/400 system. They replicated their catalog data, which the AS/400 also stores and manages, to the Commerce Server catalog schema residing in a SQL Server database.
One server for firewall and proxy services	Windows 2000 Advanced Server using proxy and firewall services.

Figure 2.2 shows the site architecture for the deployed site.

 

Figure 2.2 Contoso's site architecture 

Performing Final Testing

The Contoso test team tested the site continually as part of the development process, but when the tested site was completed and ready to move into production, they did final site testing, verifying the following:

• Content

• Browser compatibility

• Performance

• Server load

• Databases

• Search options

• Query response time

• Data validity and integrity

• System recovery

• Visual consistency

• Links

• Routers

• Stress testing (using the Microsoft Web Application Stress (WAS) tool)

Preparing for Business

The Contoso team ensured that all team members were prepared for the site to go live by reviewing with them the processes described in the following table.

Team members	Description
Business managers	Reviewed and tested workflows Completed the Business Desk tutorial
System administrators	Received training on how to administer the site
Entire team	Reviewed operational procedures (change requests, change control logs, maintenance schedules, problem escalation procedures, and so on)

Verifying Security

The Contoso team verified security in the following areas prior to placing their tested site into production:

• Securing Business Desk sessions. When Site Packager unpacks a Business Desk application, it is configured to use Integrated Windows authentication. Although this secures client authentication, the Business Desk session itself passes data in clear text. To provide security for their Business Desk sessions, Contoso set up their Business Desk client computers inside their firewall.

• Setting up Data Warehouse permissions. One way to give Business Desk users the ability to read and modify objects in the Data Warehouse is to give them a Windows Administrator account. However, Contoso wanted some Business Desk users to be able only to read reports. They accomplished this by assigning the following SQL Server database roles to each of their system users:

  • Db_datareader role. User can see all data from all tables in a database.

  • Db_datawriter role. User can add, change, or delete data from tables in the database.

• Securing cookies. By default, cookies travel in clear text. It is possible for hackers to intercept information contained in cookies and use that information to impersonate users. Cookies can be encrypted. Commerce Server uses encrypted authentication and anonymous cookies to enhance security. To help secure cookies, Contoso used encryption and embedded the Internet Protocol (IP) address of the client in the cookies so that the Web server could verify that the correct user actually sent the cookies.

• Setting permissions on folders that contain the site. Site Packager doesn't package or unpack any NTFS folder or file permissions (ACLs). Contoso secured the files and folders that contain their site.

Going Live

When the development site was completely tested and ready for production, the Contoso team used Site Packager to prepare their site for deployment in the production environment. The production environment was an exact duplicate of their test environment.

In addition to site resources, applications, and the IIS settings needed to recreate the Web server configurations, Site Packager also includes the property values from the Administration database. For example, when you package the App Default Config resource, all of the current property values are also packaged. When you unpack the App Default Config resource, the property values are unpacked onto the Administration database. The package includes global resource pointers but not the global resources themselves. Connection strings are packaged without the user name and password fields.

During the application packaging process, Site Packager searches the IIS metabase on your local computer, and finds the physical directory that is the root for that application. It then starts at that root directory and packages all the subdirectories below into a new file with a .pup file name extension. Site Packager preserves certain settings in IIS, such as authorizations and access permissions. Site Packager doesn't package properties that are specific to the computer you are working on. For example, Web server properties and some application properties set in Commerce Server Manager aren't packaged.

Closing the Loop

The Contoso team realized from the beginning of the project that an e-commerce Web site is a corporate asset that business managers must continuously manage, analyze, and enhance in order to keep their Web site competitive. Business managers need to quickly analyze customer activity to measure the effectiveness of their sites, and then use the results to fine-tune the sites. By analyzing customer data, the business manager can make decisions about how to improve the site and meet business goals. Post-deployment responsibilities fall into the following three basic areas:

• Collecting and storing customer data

• Analyzing customer data

• Implementing the site management cycle

Collecting and Storing Customer Data

Contoso is collecting three types of data, listed in the following table, about the customers who visit their site.

Data type	Description
Explicit profile data	Obtained when customers provide information about themselves by completing online forms, surveys, and polls.
Click history	Obtained when customers visit the site and click links to site pages. The click history includes the length of time spent visiting the site, referring URLs, ad clicks, ad reach, click frequency, and the path of the user through the site (including entry and exit pages). For example, Contoso recorded the following information for a typical user session: Time on the site = 17 minutes Catalog product descriptions viewed = 3 Item selected = special promotion
Transaction history	Products a customer purchased. The transaction history records baskets and orders. The transaction history Contoso is tracking includes customer name, shipping address, date and time of purchase, product purchased, and order total.

This data is collected in the Web server log files and the Commerce Server databases. On a regular basis Contoso's system administration team imports the data from the Web server log files and Commerce Server databases into their Data Warehouse.

Analyzing Customer Data

Contoso's site administration team analyzes customer data from the Data Warehouse, then provides this information to the management team. They use the data to identify the types of customers who visit the site, what is selling well, and which advertising campaigns are successful.

Implementing the Site Management Cycle

To effectively implement the site management cycle, the business management, site development, and system administration teams agreed to inform each other about the updates they make to the site. They established a process to facilitate this communication. For example, to update a large set of user profiles in bulk, the business management team contacts the system administration team, who then performs this task. To add new functionality to Business Desk, such as a module for selling gift certificates, the business management team sends their requirements to the site development team.

The teams have a process for requesting changes. (For more information about designing a process for requesting changes, see Chapter 8, "Developing Your Site.") They also established a regular meeting schedule to resolve any communication issues that might arise as they continue to refine their site.