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.
Chapter |
Title |
Description |
---|---|---|
9 |
Developer Notes |
|
10 |
Integrating Third-Party ERP Systems with Commerce Server Applications |
Best practices for integrating Commerce Server with existing corporate systems |
11 |
Migrating from Site Server to Commerce Server 2000 |
Best practices for migrating an existing site built with Site Server to Commerce Server 2000 |
12 |
Developing an International Site |
Best practices for extending a Commerce Server site for an international audience |
13 |
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.
Milestone |
Action |
Timing |
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 |
|
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 https://msdn.microsoft.com/library/en-us/dnrac/html/mracv2_ch00.asp.
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 https://www.microsoft.com/commerceserver/downloads/solutionsites(fromCS2K).asp, 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 |
Description |
---|---|
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:
|
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 |
Activities |
---|---|
Planning |
Plan and define the scope, objectives, policies, procedures, and organizational and technical context for managing your configuration. |
Identification |
Select and identify the structures for all the CIs, including the following:
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.
Hardware
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
Software
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 https://msdn.microsoft.com/downloads/default.aspx.
Commerce Server debugging symbols are located on the Commerce Server 2000 CD in the \bin directory.
Network
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.
User
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.
Table |
Contains |
---|---|
Line-of–business |
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. |
Vendors |
Information about each hardware vendor. |
System server software |
Information about the software installed on the system servers. |
Changes |
Descriptions of all changes since the functional specification was approved and coding began. |
Documents |
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. |
Services |
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. |
Employees |
Information about key personnel responsible for supporting the application. |
Roles |
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
Identification
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.
Factor |
Description |
---|---|
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:
The requester submits the change request to the change manager.
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.
The change manager convenes a special meeting of the change advisory board to review the change request. Go to step 5.
The change manager sends the change request to the regular meeting of the change advisory board for review.
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.
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.
The developer implements and tests the change.
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.
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.
Section |
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:
|
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: https://msdn.microsoft.com/downloads/default.aspx.
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.
Folder |
Sample |
Demonstrates how to |
---|---|---|
Business Analytics |
Create SchemaObject.vbs |
Use the OLE DB Provider for Commerce Server to modify the Business Analytics System logical schema. |
|
|
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. |
Management |
BizDesk |
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. |
|
ResourceConfig |
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. |
|
Widgets |
Construct pages for the various HTCs provided with the Business Desk Framework. |
Marketing |
Dbscripts |
Remove the following tables and related objects from a SQL Server database:
|
|
Debug |
Dump the contents of a CSF cache and trace the scoring logic applied to a content request. |
|
Headlines |
Extend the Targeting System using custom CSF cache loading and scoring components. |
Order Processing |
MinMaxShip |
Add a new pipeline component to the OPP. |
Privacy |
DeleteDetailedData.vbs |
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. |
Sitelets |
Ad |
Use the Profiling System in combination with the Targeting System to display targeted advertisements. |
|
Auction |
Use the Auction object to implement Winning Bid auctions. |
|
Catalog |
Use the Product Catalog System to offer catalog browse and search functionality. |
|
Discount |
Offer targeted discounts during order processing. |
|
Order |
Implement an order capture process. |
|
Passport |
Integrate Passport Single Sign-In (SSI) capability with the Profiling System. |
|
Profile |
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.
Tool |
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. |
Registration |
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 https://www.microsoft.com/commerceserver/downloads/solutionsites(fromCS2K).asp:
|
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 https://www.microsoft.com/technet/archive/itsolutions/intranet/downloads/webstres.mspx. |
Microsoft Visual InterDev |
Develop Web sites. For more information, see https://www.microsoft.com/technet/archive/itsolutions/intranet/downloads/webstres.mspx. |
Microsoft Web Application Stress (WAS) tool |
Simulate Web stress for sites under load. For more information, see https://www.microsoft.com/technet/archive/itsolutions/intranet/downloads/webstres.mspx. |
Microsoft Windows 2000 Server Resource Kit support tools |
Isolate, diagnose, and in some cases repair problems. For more information, see https://www.microsoft.com/windows2000/techinfo/reskit/default.asp. |
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 https://msdn.microsoft.com/library/en-us/netmon/netmon/network_monitor.asp. |
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 https://www.microsoft.com/sql/evaluation/default.asp. |
System Monitor |
Collect and view data about hardware and system service usage. For more information, seehttps://www.microsoft.com/technet/prodtechnol/windows2000serv/maintain/featusability/mngwmi.mspx. |
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, seehttps://www.microsoft.com/technet/prodtechnol/windows2000serv/maintain/featusability/mngwmi.mspx. |
Configuration Management Tools
The following table describes the configuration management tools that Microsoft provides.
Tool |
Description |
---|---|
Windows Management Instrumentation (WMI) |
Part of the Windows 2000 platform, WMI helps you manage your enterprise systems, applications, and networks. For more information, see https://www.microsoft.com/technet/prodtechnol/windows2000serv/maintain/featusability/mngwmi.mspx. |
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 https://www.Microsoft.com/catalog/. |
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.
Resource |
Provides |
---|---|
Third-party software |
The latest information about software developed especially to work with Commerce Server 2000. For more information, see https://www.microsoft.com/commerceserver/. |
Sysinternals |
Advanced utilities, technical information, and source code related to Windows 2000 internals. For more information, see https://www.sysinternals.com/. |
Related Web Sites
The following table lists related Web sites that contain design tips and code samples, tools that you can download, and sample sites.
Site |
Provides |
---|---|
Information about installing and maintaining Microsoft FrontPage Server extensions on multiple platforms. |
|
https://support.microsoft.com/default.aspx?scid=fh;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. |
|
https://www.microsoft.com/technet/archive/itsolutions/intranet/downloads/webstres.mspx |
A list of tool vendors that offer generalized XML support. |
https://www.microsoft.com/technet/archive/itsolutions/intranet/downloads/webstres.mspx |
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. |
https://www.microsoft.com/technet/archive/itsolutions/intranet/downloads/webstres.mspx |
Information about WAS, a Web stress tool that realistically simulates multiple browsers requesting pages from a Web application. |
|
Information about optimizing Web server performance. |
https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/anch_entdev.asp |
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. |