Commerce Server 2000: Site Development

During the Development phase, you design, scope, and develop your site. You also continue to refine the Project Plan and usage, site, and hardware profiles you created during the Planning phase, based on what you learn during the Development phase.

Design and build your site using the Project Goals and Requirements and Project Plan documents that you created during the Planning phase, as shown in Figure 8.1, a high-level view of the development process.


Figure 8.1 Development phase

The results of each task you complete feed back into the previous task. For example, information you discover while designing the workflow and implementing the user interface (UI) is likely to affect your database design.

In the Development phase, you typically set up a development environment in which you develop and unit-test your code. Following successful unit testing, you move your working system or prototype to a staging area for further testing and performance verification. When the site performs acceptably, you are ready to deploy the site into the production environment.

You update your usage profile by becoming more specific about how users will use your site. It is critical to collect data on user visits to your site, such as frequency and duration of visits and usage patterns, if available, to develop a site that meets your business needs.

To update your site profile, you should specify details such as the size of the data to be searched and returned in queries and typical catalog searches. Your site design should specify the size of each Web page and the number of images and links. To account for overhead, you should also determine the security level for each page at this point.

Based on the pages you develop, determine performance targets for each operation. During the Development phase, you must develop a capacity requirement for each operation in terms of transaction rate or operations per second, as well as acceptable user latency. You might want to adjust hardware specifications, based on any new information you discover during the Development phase.

Development Checklist

You should complete the following tasks during the Development phase:

  • Decide whether to develop your site "from scratch" (in which case, you'll need a site design) or use your own existing site as a basis. Alternatively, you can use one of the Commerce Server Solution Sites as a basis for development, and then customize your code for that site.

  • Establish your configuration management infrastructure. For more information, see the section "Managing Site Configuration" later in this chapter.

  • Establish change management processes and infrastructure. For more information, see the section "Managing Change" later in this chapter.

  • Analyze data and finalize your database schema using Commerce Server objects and integrating any external databases your site requires.

  • Determine the attributes to be stored for each user.

  • Design the UI framework.

  • Design detailed network architecture.

  • Develop operation-specific workflow diagrams and event-sequence charts.

  • Design security for each feature.

  • Design, implement, and unit-test code, including:

    • Active Server Pages (ASP) code

    • HTML code

    • Custom objects

    • Additional Microsoft Management Console (MMC) snap-ins

  • Design business processing pipelines.

  • Design interfaces with existing systems and processes (external payment systems, delivery systems, inventory systems, corporate mainframe, and so on).

  • Develop test plans. Test your site in a test/staging environment.

  • Create load scripts and test scripts, measure the latency for each user operation, then test your site under load and compare response time with performance and availability goals set in the Planning phase.

  • Review site readiness. Determining readiness is an exercise in risk management, balancing risks associated with schedule and quality. If you spend too much time correcting all the errors, you risk missing the window of opportunity for the market; if you release the product too soon, you risk losing customers because the quality of your site is too low.

The Development section of this book contains the chapters listed in the following table.





Developer Notes

  • Example describing how to add a feature to one of the Solution Sites

  • Best practices for using the Profiling System

  • Conceptual overview of the advertisement scoring system

  • Description of the Profiles Schema management tools


Integrating Third-Party ERP Systems with Commerce Server Applications

Best practices for integrating Commerce Server with existing corporate systems


Migrating from Site Server to Commerce Server 2000

Best practices for migrating an existing site built with Site Server to Commerce Server 2000


Developing an International Site

Best practices for extending a Commerce Server site for an international audience


Integrating Commerce Server with BizTalk Server

How to integrate Commerce Server with Microsoft BizTalk Server 2000

Completing the Development Phase

The following table lists criteria for determining when development is complete and your site is ready for deployment.




Success criteria

Functional test complete

Execute function/feature test cases.

After code freeze.

All tests pass.

Deployment test complete

Install the site in a staging environment, as described in your installation documentation.

After code freeze.

Installation documentation verified.

Manageability test complete

Validate that business managers or site administrators can manage the site, as appropriate.

After code freeze.

All tests pass.

System integration test complete

Validate that the site works in the staging environment with specified software, network, and hardware.

After deployment and functional tests.

All tests pass.

Stress test complete

Validate that the site performs at the specified level of performance when fully loaded (normal load expected), for an extended period of time (usually three to five days).

When system integration tests are successful. Sometimes stress testing is done in conjunction with integration testing, if necessary, to shorten time to market.

System runs at targeted stress level for entire period with no performance degradation or excessive system resource consumption.

Performance test complete

Validate that the site performs well at peak, targeted capacity (peak user and transaction load).

When system integration tests are successful.

System runs at targeted capacity level.

Support process established, staffed, and tested

  • Design and implement process for support team to handle expected volume of service calls, including metrics and response time.

  • Design and deploy support hardware and infrastructure.

Start training before code complete. Support should be in place before any client pilot programs or before you put the site in production.

Customer problems resolved within targeted timeframes.

Escalation process established, staffed, and tested

Design and implement process for support staff to escalate problems to the development team for evaluation and correction, when necessary.

Before any client pilot programs, or before you put the site in production.

Customer problems are solved in a timely manner.

Site approved by program managers, developers, test, and support

Managers and leads of key areas agree that the site meets its design goals and can be supported in a production environment.

Last verification before you deploy the site to production.

Successful deployment of the site.

Selecting a Development Methodology


You can choose any of the following methodologies as the basis for developing your Commerce Server site:

  • Solution Site. The advantage of using a Solution Site as the basis for your site development effort is that it contains pre-implemented core functionality that has already been tested.

  • SDK sitelet. The advantage of using an SDK sitelet as the basis for your site development effort is that it is a good starting point for learning how to use each Commerce Server feature, although some features have been omitted, to simplify the code.

  • Microsoft Reference Architecture for Commerce. The advantage of using Microsoft Reference Architecture for Commerce is that it is similar to a Solution Site, but it is more focused on Microsoft® .NET integration and is designed to be a reference architecture for .NET. For more information about the Microsoft Reference Architecture for Commerce, see

  • Start from scratch. Developing your site from scratch might be necessary if your site must be completely customized, and is a valid approach if you have the necessary time and resources. However, this approach is much more time-consuming and means that you must begin at the beginning to test and refine the performance of your new site, instead of implementing proven methods.

Jump-Starting Development with the Solution Sites

If you use a Solution Site as the basis for development, you develop your Commerce Server site in two steps:

  • Create a site that interfaces with the Commerce Server application management infrastructure by using Commerce Server Site Packager to unpack one of the Solution Sites.

  • Modify the implementation of features in the Solution Site you unpacked and add any new features you identified in the Planning phase.

The choice you need to make before you start development is whether to start with the Blank site or start with one of the scenario-based Solution Sites (Retail or Supplier).

The Blank site is installed in the Commerce Server\Pup Packages folder by Commerce Server 2000 Setup. If you unpack this site with Site Packager, you have a site that is integrated with the Commerce Server application management framework, but does not have any features implemented. The Blank site contains placeholder files that you can use to help you start your development. If you navigate to the Blank site after unpacking, you should see the message, "Hello World, from BlankSite."

The scenario-based Solution Sites, available from, already have an initial set of features implemented, and you just need to modify those features to meet your specific requirements. The advantage of using a scenario-based Solution Site is that it reduces development time. If there are aspects of the site's design that don't meet your requirements, however, it might be better to start with the Blank site.

The Retail and Supplier Solution Sites provide the most common set of features found in business-to-consumer and business-to-business Internet sites. The two sites employ a common code base and use site configuration information to determine which code path to execute. Site configuration information is retrieved from a data dictionary known as the Options dictionary. The Options dictionary is a simple name/value pair data structure that contains configuration information retrieved from the Commerce Server 2000 application management infrastructure. The following code snippet shows you how to retrieve the Options dictionary:

<%   Dim oOptionsDict, dictConfig   Set oOptionsDict = Server.CreateObject("Commerce.AppConfig")   Set dictConfig = oOptionsDict.GetOptionsDictionary("") %>

A complete listing of the items stored in the Options dictionary is provided in the reference page for the AppConfig.GetOptionsDictionary method in Commerce Server 2000 Help.

The power of a common code base driven by configuration information is that it enables you to prototype your solutions rapidly. For example, by simply changing the Add items redirect options value from 0 to 1, you can have your site immediately redirect a customer to the basket page after adding an item to the basket, instead of returning to the page displaying the product. You can set any of the application configuration settings through the App Default Config resource in Commerce Server Manager.

You can change back and forth between the two code paths by making changes with the App Default Config resource. Your development process will be smoother, however, if you start with the Solution Site that most closely matches your site. For more information about setting up the Supplier Solution Site, see Chapter 14, "Deploying Your Site."

Managing Site Configurations


Configuration management is the process of identifying, recording, tracking, and reporting on key system components, called configuration items (CIs). You should manage configuration throughout the life of your site. The following table lists the core components of configuration management.

Core component


Configuration item (CI)

Key system component or asset, such as hardware, system software, application software, and documentation. The information you record and track depends on the type of CI, but usually includes the following:

  • Description

  • Version

  • Constituent components

  • Relationships to other CIs

  • Location and assignment

  • Status

Configuration Management database

The single logical data repository for CI information. Whenever possible, this database should be self-maintaining, with automated updates from CIs.

The following table lists the core processes you should use to manage your configuration.

Core process



Plan and define the scope, objectives, policies, procedures, and organizational and technical context for managing your configuration.


Select and identify the structures for all the CIs, including the following:

  • Owners

  • Interrelationships

  • Documentation

Assign identifiers to CIs and their versions.

Controlling changes

Accept and track only authorized and identifiable CIs. This process should also ensure that no CI is added, modified, replaced, or removed without an approved change request. For more information about change requests, see the "Managing Change" section.

Status accounting

Report on all current and historical data for each CI throughout its life cycle.

Verification and auditing

Verify the physical existence of CIs to make sure that they are correctly recorded in the configuration management process.

Configuration Items

As you plan development of your site, you should review the CIs that are part of your proposed site. A software component, for example, might either be a stand-alone CI or part of a larger CI. You should answer the following types of questions about each CI:

  • Is it practical to manage this component as a CI?

  • Is information about the item required by a number of people?

  • Will the CI need to be replicated?

  • Does this CI depend on others?

  • Is this CI likely to change?

  • Do we understand how this CI is to be used?

  • Are other CIs dependent on the state of this CI?

  • Does the CI have adjustable properties?

This section lists some common types of CIs. You might want to track additional CIs associated with your site, as well. You should track any key item associated with the development and management of your site.


Track the hardware components that make up the identified CI, such as a server, which might have the following components:

  • Server ID

  • Date purchased

  • Version

  • Basic input/output system (BIOS)

  • Model

  • Firmware

  • Serial number

A hard disk drive inside a server would be considered a hardware component CI subordinate to the server hardware CI. The hard disk drive CI might have the following components:

  • Hardware component ID

  • Primary hardware ID (such as the server)

  • Component type

  • Date installed

  • Version

  • Serial number


Track lists of files and versions, build scripts, installation scripts, and settings, such as .ini files, registry settings, or miscellaneous configuration files. For example, a service pack for a software release might include the following components:

  • Software CI ID

  • Software type

  • Application name

  • Date installed

  • Version

  • Service pack

  • Hot fix

  • Debugging symbols for Windows 2000 and Commerce Server

    You can download Windows 2000 debugging symbols from

    Commerce Server debugging symbols are located on the Commerce Server 2000 CD in the \bin directory.


You might decide to track anything from a network device, such as a router, to a structured cabling setup. For example, a router CI should include the hardware specifications and inventory of items it contains, such as specific interface cards. It should also include all build and configuration scripts.


Track information needed to identify users and their permissions. For example, a CI for a server cluster administrator might include the following:

  • User name

  • Role

  • Contact information

  • Backup person when the administrator can't be reached

Configuration Management Database

The Configuration Management database is usually a relational database with associated support tools in which information about the CIs is stored and related. The Configuration Management database should also store information about changes, problems, incidents, and known errors. (For more information about storing incidents in the Configuration Management database, see Chapter 18, "Problem Management.") The Configuration Management database should contain tables such as those described in the following table.




The name of the line-of-business (LOB) application described in the Configuration Management database. For example, a Commerce Server Web site is a type of LOB application.

System function

A description of the function performed by each server. For example, one server might be a Web server, one a database server, and so on.

System hardware details

Details of the system hardware.

Physical hardware components

Details of the physical hardware components installed on the server.

Drivers for hardware components

Lists of drivers for each hardware component.


Information about each hardware vendor.

System server software

Information about the software installed on the system servers.


Descriptions of all changes since the functional specification was approved and coding began.


Information about documents the system administrator needs to manage the application, such as change management documentation, disaster recovery plans, escalation procedures, and so on.

Parameters stored in the registry

Information about parameters stored in the operating system registry for each specific registry key.


Information about services run by the software applications.

Registry entries for the service

Information about registry entries specific to each service identified in the Services table.

Dependent services

Information about services dependent on the primary services. For example, dependent services for the IISADMIN service include the W3SVC, File Transfer Protocol (FTP), and Simple Mail Transfer Protocol (SMTP) services.

Files running the service

Information about .exe, .sys, or .dll files responsible for running the application.

Operational processes

Information about operational processes associated with the application, such as capacity management, configuration management, and change management.


Information about key personnel responsible for supporting the application.


Information about each application support role.

Employee details

Contact information for each person listed in the Employee table.

Core Configuration Management Processes

If your configuration management process is an integral part of your development strategy, your processes for managing configurations will be in place before you develop or deploy a new site. Your development team can then use the configuration information as they build the software, to ensure that they have constructed the system correctly. As you move from phase to phase developing your site, you should update your configuration information.

This section describes the following core configuration management processes:

  • Identification

  • Status accounting

  • Verification and auditing


There are three major tasks in identifying a configuration item:

  • Determining CI scope, level, and relationships

  • Implementing standard naming conventions

  • Recording CI information in the Configuration Management database

The task of identifying CI scope, level, and relationships can vary by environment. The following table describes the three identification factors.



CI scope

The portion of a site that you intend to manage as a single configuration item. If the scope is too narrow, some parts of the configuration won't be managed properly; if the scope is too broad, the configuration will be too unwieldy to manage. For example, a server might be a configuration item.

CI level

The level of detail you use to describe a CI. If the level of detail is too low, maintenance will be excessive; if the level is too high, the process won't be useful.

For example, you might optimize the CI level by creating and tracking a build kit for a component rather than tracking each .dll or file separately.

CI relationships

Descriptions of the dependencies between CIs (such as "is connected to", "is a copy of," and "is a part of"). If you identify too few relationships, the Configuration Management database becomes merely an asset database or a list of components; if you identify too many relationships, the database becomes too complex to maintain.

Use standard naming conventions to uniquely identify each CI. For instance, a hardware CI for an e-commerce site that spans multiple data centers could be something like the following:

DDAATTNN, whereDD = Data center ID
AA = Application ID
TT = Server type ID (for example, SQ for SQL Server or WB for Web server)
NN = Unique identifier (01, 02, and so forth)

You should record CI information in the Configuration Management database. We recommend that you automate this process as much as possible. Microsoft Windows Management Instrumentation (WMI), for example, enables you to identify components within the infrastructure, covering the identification of both infrastructure and software components. For more information about configuration tools, see the "Configuration Management Tools" section later in this chapter.

Status Accounting

It is important to track the status of CIs throughout the time they are in use. The first objective of status accounting is to identify hardware and software and add this information to your site inventory. The best way to do this is to automatically discover the item, identify it, and record it in the site inventory. Automatic procedures for doing this are best, if you have them; however, there might be CIs that you must track manually. The ideal system periodically reruns inventory processes automatically, documenting changes to the configuration as they occur. (For more information about inventory processes, see the "Configuration Management Tools" section in this chapter.) You should, however, check the automated processes on a regular basis. It is a good practice to create a script that periodically extracts the data for you to examine.

Verification and Auditing

The only way to maintain performance standards is to periodically run a comprehensive system audit. You must also verify the physical existence of CIs to make sure that they are recorded correctly. For example, you should audit the builds on all servers at regular intervals, such as once a week, to look for discrepancies. For a description of tools that Microsoft provides to help you manage site configuration, see the section on "Configuration Management Tools" at the end of this chapter.

Managing Change


Managing change is especially important for companies that do business on the Web because of the high rate of change in e-commerce applications and environments. The change management process provides procedures for safeguarding existing services, while safely introducing new services.

Most systems are heavily interrelated, so any changes made in one part of a system can have profound impacts on another. The change management process attempts to identify all systems and processes affected by a change so that everyone affected, such as business managers and system administrators, has an opportunity to mitigate or eliminate adverse effects before the change is put into effect. You should manage changes in all of your environments: production, development, and test/staging.

The categories of assets that you should place under change control include, but are not limited to, hardware, communications equipment and software, system software, applications software, processes, procedures, roles, responsibilities, and documentation relevant to the development, support, and maintenance of systems in the managed environment. In other words, any asset that exists in the environment and is necessary for meeting the service level requirements of the site should be placed under change control.

The following are key components of the change management process:

  • Change requests

  • Change database

  • Change advisory board

  • Change process

Change Requests

Change requests are the formal documentation of the change control process, and should include the following elements:

  • ID (a unique identifier for the request)

  • Configuration item ID(s)

  • Reason for change

  • Version of components to be changed

  • Name, location, and contact information for the person proposing the change

  • Date change proposed

  • Change priority

  • Impact and resource assessment

  • Change advisory board recommendations

  • Authorization signature, time, and date

  • Schedule for implementation

  • Details of change builder/implementer

  • Implementation time and date

  • Review date

  • Review results

Change Database

Requests for change are registered and tracked in a central repository, preferably in the Configuration Management database, because the change management and configuration management processes are closely related. If at all possible, you should consider automating the process of adding change requests to the database.

Change Advisory Board

The change advisory board is a cross-functional group that evaluates change requests for business need, priority, cost versus benefit, and potential impacts to other systems or processes. Typically, the change advisory board recommends implementation, further analysis, deferment, or cancellation of the change. The change advisory board should meet regularly — as often as necessary to prevent bottlenecks in implementing changes and decrease the number of urgent changes.

Change Process

You should create a process for making changes, so that all team members for the site understand the escalation path when a change needs to be made. Figure 8.2 shows a sample process for making changes.


Figure 8.2 Sample change process

The process shown in Figure 8.2 is as follows:

  1. The requester submits the change request to the change manager.

  2. The change manager reviews the change request, assigns a priority, and enters it in the change database.

    If the change is a regular priority, go to step 4.

    If the change is urgent, go to step 3.

  3. The change manager convenes a special meeting of the change advisory board to review the change request. Go to step 5.

  4. The change manager sends the change request to the regular meeting of the change advisory board for review.

  5. The change advisory board reviews the change request, including the following elements: cost, resources, priority, severity, business commitment, risk, and possibility of recovery.

    If the change is approved, go to step 6.

    If the change is not approved, the process ends.

  6. The change manager schedules the change and updates the Change database.

    Scheduling should be done on a single change calendar so that planned changes can be seen in the context of other changes that are being planned or are currently being worked on.

  7. The developer implements and tests the change.

  8. The change advisory board reviews the completed change.

    If the change is satisfactory, go to step 9.

    If the change is not satisfactory, return to step 7.

  9. The change manager closes the change request and updates the Change database.

Development Tools and Resources


The following resources can help you accomplish development tasks:

  • Commerce Server 2000 Help

  • Commerce Server 2000 Software Development Kit (SDK)

  • Commerce Server tools

  • Other Microsoft tools

  • Configuration management tools

  • Other references

Commerce Server 2000 Help

The information listed in the following table is available through Commerce Server 2000 Help.


Explains how to

Setting Up Your Development Workstation

Set up your Commerce Server development environment.

Programming with Commerce Server Objects

Use Commerce Server objects to program your site.

Working with Pipelines

Use Commerce Server pipelines to link one or more components and run them in sequence. Commerce Server provides three pipeline models: the Order Processing pipeline (OPP), the Direct Mailer pipeline, and the Content Selection pipeline (CSP).

Integrating with BizTalk Server

Use BizTalk Server in conjunction with your Commerce Server site.

Customizing Style Sheets

Customize Commerce Server style sheets.

Modifying Your Site for an International Audience

Localize error messages, dates, times, and currencies for an international audience.

Extending Commerce Server

Extend any of the following Commerce Server resources:

  • MMC extension snap-ins

  • Commerce Server Business Desk modules

  • Administrative tools

  • Pipeline components

  • Third-party catalogs

  • Content Selection Framework (CSF)

  • Custom resources

  • Custom reports

  • Commerce Server Data Warehouse logical schema, metadata, or physical data store

Programmer's Reference

Use each Commerce Server object.

Commerce Server SDK

You use the Commerce Server 2000 SDK to develop e-commerce solutions with Commerce Server. The Commerce Server 2000 SDK contains tools, code samples, and documentation that explains how to customize and extend Commerce Server tools.

Before you use the samples and tools in the Commerce Server 2000 SDK, you must download the Microsoft Platform SDK from the following location:

The Commerce Server 2000 SDK is shipped on the Commerce Server 2000 CD. You can access it from the Start Menu at Start/Program Files/Microsoft Commerce Server/Software Development Kit if you use the Complete installation option.

The SDK contains the samples listed in the following table.



Demonstrates how to

Business Analytics

Create SchemaObject.vbs

Use the OLE DB Provider for Commerce Server to modify the Business Analytics System logical schema.

  • Analysis – New dynamic OLAP report script.sql

  • Analysis – New dynamic SQL report script.sql

  • Analysis – New static OLAP report script.sql

  • Analysis – New static SQL report script.sql

Create new reports of various types in the Business Analytics System.

Schema Tool

Use the OLE DB Provider for Commerce Server to access the logical schema of the Data Warehouse.



Use XML data islands, including Business Desk HTML Components (HTCs) for site administration.

BizDesk Installer

Automate the process of adding configuration information for a new module to an existing Business Desk installation.

PuP Resource

Package a specified set of tables from a single SQL Server database.


Add the configuration information for a custom resource to the Administration database.

Site Status

Extend the Commerce Server Manager interface and open or close the Commerce Server installations into which this MMC extension snap-in is installed.


Construct pages for the various HTCs provided with the Business Desk Framework.



Remove the following tables and related objects from a SQL Server database:

  • Campaigns-drop.sql

  • Expression-store-drop.sql

  • Listmanager-drop.sql


Dump the contents of a CSF cache and trace the scoring logic applied to a content request.


Extend the Targeting System using custom CSF cache loading and scoring components.

Order Processing


Add a new pipeline component to the OPP.



Use the OLE DB Provider for Commerce Server to delete detailed data about a particular user from the Data Warehouse.

Disconnect Detailed Data.vbs

Use the OLE DB Provider for Commerce Server to disassociate detailed data about a particular user without deleting the data itself.



Use the Profiling System in combination with the Targeting System to display targeted advertisements.


Use the Auction object to implement Winning Bid auctions.


Use the Product Catalog System to offer catalog browse and search functionality.


Offer targeted discounts during order processing.


Implement an order capture process.


Integrate Passport Single Sign-In (SSI) capability with the Profiling System.


Use the Profiling System to register and authenticate users.

In addition to the samples, the AppConsts.idl file in the SolutionSites folder provides constants used by the Solution Sites.

The SDK also contains the tools listed in the following table.


Use to

ATL Pipe Wizard

Install a new wizard in your Microsoft Visual C++ 6.0 installation to automate the creation of Commerce Server pipeline components.

Membership Migration

Migrate user profiles from a Site Server Membership Directory into a Commerce Server 2000 user profile store.

Migration: Ad Server

Migrate campaigns from Site Server Ad Server to the Commerce Server 2000 CSF.


Register pipeline components for stage affinity.

VB Pipe Wizard

Install a new wizard in your Microsoft Visual Basic 6.0 installation to automate the creation of Commerce Server pipeline components.

Commerce Server Management Tools

You can use the Commerce Server tools described in the following table to develop your site.

Commerce Server tool

Use to

Commerce Server Business Desk

Host business management modules for managing and analyzing your site. For example, you can update pricing information in your catalog, target new ads to specific users, and then run reports to measure how these changes affect site productivity with Business Desk.

Commerce Server Manager

Manage and configure Commerce Server resources, sites, applications, and Web servers. The MMC hosts Commerce Server Manager.

Commerce Server Site Packager

Package a site, including applications and resources, into a single file (package) so you can move the site to another environment. Site Packager provides a convenient way for site developers to move sites to staging and production environments or to deliver sites to customers.

Pipeline Component Wizard

Automate the creation of Commerce Server pipeline components. The Pipeline Component Wizard consists of a group of files that you add to a Visual C++ installation to create object definition and implementation files. These files contain the function prototypes for all of the interfaces you need to create a fully functional pipeline component. In addition, the Pipeline Component Wizard creates a property page for your project, to which you add the controls through which users set component properties.

Solution Sites

Build a site. After you install Commerce Server, you can unpack one of the Solution Sites, and then use it as a foundation for building your own site.

When you purchase Commerce Server, you receive the Blank site to help you build your own custom site. Also, the following Solution Sites are also available for download from

  • Retail Solution Site. Commerce Server resource for building a retail site.

  • Supplier Solution Site. Commerce Server resource for building a Microsoft Active Directory-enabled supplier site.

Other Microsoft Tools

The Microsoft tools listed in the following table can also be helpful for developing your site.

Microsoft tool

Use to

Microsoft Management Console (MMC) snap-in for Microsoft Windows 2000

Determine the status of a server or workstation. For more information, see

Microsoft Visual InterDev

Develop Web sites. For more information, see

Microsoft Web Application Stress (WAS) tool

Simulate Web stress for sites under load. For more information, see

Microsoft Windows 2000 Server Resource Kit support tools

Isolate, diagnose, and in some cases repair problems. For more information, see

Network Monitor

Detect and troubleshoot problems, and analyze data on LANs and WANs. Network Monitor is a component of Microsoft Systems Management Server (SMS). For more information, see

SQL Profiler

Capture SQL Server events from a server and save them in a trace file for analysis and problem diagnosis. For more information, see

System Monitor

Collect and view data about hardware and system service usage. For more information, see

Visual Studio Analyzer

Analyze performance, isolate faults, and analyze the structure of distributed applications. Visual Studio Analyzer is one tool in the Microsoft Visual Studio 6.0 suite of tools. For more information, see

Configuration Management Tools

The following table describes the configuration management tools that Microsoft provides.



Windows Management Instrumentation (WMI)

Part of the Windows 2000 platform, WMI helps you manage your enterprise systems, applications, and networks. For more information, see

Microsoft Visio 2000 Enterprise Edition

Helps you monitor your network, manage network user accounts, and get a hierarchical view of your directory structure. For more information, see

Metabase Editor (MetaEdit)

Helps you edit Internet Information Services (IIS) 5.0 configuration files.

Other Resources

The following table lists other resources you might find useful for developing your site.



Third-party software

The latest information about software developed especially to work with Commerce Server 2000. For more information, see


Advanced utilities, technical information, and source code related to Windows 2000 internals. For more information, see

The following table lists related Web sites that contain design tips and code samples, tools that you can download, and sample sites.



Information about installing and maintaining Microsoft FrontPage Server extensions on multiple platforms.;EN-US;kbhowto&sd=GN&ln=EN-US&FR=0

The latest articles about FrontPage Server extensions and using FrontPage in conjunction with IIS.

Free daily articles on writing ASP code.

Suggestions and tips for adapting software for an international audience.

Updates and information for the system administrator.

Information about Rainbow Technologies' CryptoSwift, a tool for improving secure Web server response time.

A list of tool vendors that offer generalized XML support.

Tips and sample code for accessing SQL Server through ADO and ASP, in the article, "Top Ten Tips: Accessing SQL Through ADO and ASP," by J.D. Meier.

Information about WAS, a Web stress tool that realistically simulates multiple browsers requesting pages from a Web application.

Information about optimizing Web server performance.

A number of resources, learning tools, and a complete end-to-end sample application for developers who want to learn how to integrate Windows-based applications with other platforms, including IBM mainframe, AS/400, Unix, structured and unstructured data sources, and Enterprise Resource Planning (ERP) systems.