Typical tasks for a business professional include maintaining products and product catalogs, managing customer orders and profiles, performing analyses of site data, and so forth. Technical professionals usually focus on higher-end site configuration, including database resources, Web server configuration, and so on. Technical professionals are also responsible for background tasks such as disaster recovery operations, performance optimization, and so forth (which I’ll also cover in this chapter).

While business professionals only need to understand how to complete their tasks within Commerce Server’s Business Desk interface, technical professionals working on Commerce Server need to have a wider range of knowledge and experience. Managing Commerce Server also means managing IIS and SQL Server, understanding how to manage Active Directory (if your Commerce Server site is Active Directory-integrated), and working with Windows’s performance and event tools.

The Commerce Server Manager is a Microsoft Management Console (MMC) snap-in, as shown in Figure 18.1. Figure 18.1 actually shows the default Commerce Server Manager console, which is installed by Commerce Server Setup. This console not only includes the Commerce Server Manager snap-in, but also a number of other snap-ins that you’ll use to manage Commerce Server:

Figure 18.1. The Commerce Server Manager console is located under the Commerce Server folder on the Start menu.

These additional snap-ins pretty much make the default Commerce Server Manager console a one-stop shop for Commerce Server management. The trick with the console, though, is that it’s not fully configured out of the gates. By default, the Commerce Server Manager snap-in connects to the local computer; if you want to manage a different Commerce Server computer, you’ll need to manually connect to it by right-clicking the snap-in and selecting Connect from the pop-up menu. The other snap-ins don’t always connect to anything by default. With the SQL Server snap-in in particular, you’ll need to right-click the snap-in name, select New SQL Server Registration from the pop-up menu, and connect to the SQL Server computers that support your Web site.

There’s one snap-in that may be missing from the Commerce Server Manager console: Application Center. If you’re using Application Center to manage your Web servers, I recommend creating a new MMC console from scratch, and including Application Center’s snap-in along with Commerce Server, SQL Server, IIS, and so forth.

Figure 18.2 shows the Commerce Server Business Desk, an HTML Application (HTA) used by business professionals to manage a Commerce Server site. As you can see, the left side of the Business Desk provides a menu of modules that you can select from. Each module—Analysis, Campaigns, Catalogs, Orders, Profiles, and Security—provides management capabilities for a specific area of Commerce Server.

Figure 18.2. Visually impaired users can select a high-contrast theme from the Business Desk home page, which makes the application easier to work with.

Although the Business Desk executes within Internet Explorer (which is a prerequisite for running the application), it doesn’t look or behave like a typical Web page. That’s because HTAs override certain IE security features, enabling IE to look and behave more like a traditional Windows application.

The Business Desk uses a standard visual style for its administration pages. As shown in Figure 18.3, these pages usually include a toolbar across the top of the window, which contains action buttons. The main portion of the window consists of one or more expandable sections. By clicking on the right-pointing arrow icons, you can expand and collapse these sections. Within each section, you’ll find one or more input fields Required fields—those which you must complete in order to save information—are indicated by a red diamond icon. Some fields may include the ability to store values in multiple languages; these are indicated by a small globe icon.

Figure 18.3. This consistent visual style makes it easy to use the Business Desk’s various administration modules.

You will need to install the Business Desk before you can use it. Commerce Server sites all, by default, include an installer. Generally, the installer is configured in the Business Desk Web site. For example, if you unpacked a Commerce Server site on a server named ServerA, and named the site MyStore, Commerce Server will create the Business Desk Web site at http://servera/mystorebizdesk. Visiting that URL with Internet Explorer will enable you to install the Business Desk for the site.

Product and catalog management is probably one of the most complex tasks in Commerce Server, mainly because Commerce Server’s product catalog system is so flexible. I like to start by creating by catalog’s category definitions. Generally, you’ll only use a single category definition: department. All of your products will be organized into departments (such as Books, Clothes, and so forth), and you’ll tier your categories to create sub-departments and sub-sub-departments, as necessary.

Figure 18.4 shows Commerce Server’s list of category definitions, with a Department category already defined.

Figure 18.4. If you unpacked a Commerce Server sample site to start with, it’ll include the Department category definition.

Category definitions include all of the properties associated with the category, such as a title, and perhaps an image that relates to the category. As shown in Figure 18.5, you can edit category definitions to include additional properties. For example, in Figure 18.5 I’ve added units of measure to the category, because I plan to organize my products by unit of measure.

Figure 18.5. You can only add predefined properties to a category definition. I’ll show you how to add more properties later.

With your category definitions out of the way, you might create a new catalog. Start by creating a new base catalog, which contains actual products. Figure 18.6 shows how to create a new catalog. As you can see, catalogs don’t have a lot of their own properties. One of their important properties is their starting and ending date, which determines when the catalog becomes valid and when it stops being valid. These properties can help you manage sale catalogs and other short-term catalogs more effectively.

Figure 18.6. Be sure to give your catalogs meaningful names so that you can easily distinguish them from one another.

If you have a number of catalogs in the system, you can use the Business Desk’s Find feature (located in the toolbar) to filter the catalog list. For example, in Figure 18.7, I’ve configured Business Desk to only display catalogs with the word “summer” in their name.

Figure 18.7. Leave the search criteria blank to display all of the catalogs in the system.

With the necessary catalogs in the system, you’ll need to create catalog sets. These are simply groups of catalogs that you use to control catalog access. As shown in Figure 18.8, Commerce Server starts with a catalog set for anonymous users and one for registered users. You can create your own catalog sets as necessary. For example, you might create a catalog set for wholesale customers, one for retail customers, and another for special business partners. When users log on to your site, they’ll have access to the catalogs in their set. Users who don’t log on will have access to the catalogs in the anonymous set.

Figure 18.8. By default, the anonymous catalog set provides access to all catalogs in your system.

When you edit a catalog set, as shown in Figure 18.9, you can either include all catalogs in the set by checking the appropriate checkbox, or decide which catalogs the set will include.

Figure 18.9. I recommend clearing the all catalogs checkbox unless you really want all users to have access to all of your catalogs.

Now that you’ve set up catalogs, you can import product information into them. If you already have a product database—perhaps from another system in your organization—importing the data into Commerce Server can save you from having to hand-enter the data. On the other hand, if you’re just starting out your business, you may need to create your catalogs from scratch. In that case, your next step will be to create product definitions, which define the types of products you will carry. Figure 18.10 shows the list of product definitions included with one of the Commerce Server sample sites. As you can see, product definitions represent types of products, such as books, rather than actual physical products.

Figure 18.10. You can add, edit, or remove items on the default list of product definitions.

Editing a product definition enables you to decide what properties will be associated with that product. Figure 18.11 shows a product definition being edited. As with category definitions, you can only select predefined properties to associate with a product.

Figure 18.11. You can specify which properties must be provided for a product, and specify which are optional.

If you want to add a property—either to a category definition or to a product definition—that isn’t in Commerce Server’s list of default properties, you can use the Business Desk’s Property Definitions editor, shown in Figure 18.12, to add your own properties.

Figure 18.12. Adding property definitions enables you to create the product and category definitions that you need for your site.

Figure 18.13 shows a property definition being edited. When you create property definitions, try to make them as generic as possible. For example, a property definition named “BookTitle” can only be used by a “Book” product definition and make sense; if you create a property definition named “Title,” on the other hand, you might be able to use that property in a variety of product definitions. Creating property definitions that can be reused across many types of products is more efficient.

Figure 18.13. You can determine what types of data each property definition will contain.

Property definitions can contain different types of data. For example, a simple property might require a text or numeric entry. More complex properties, however, can include drop-down lists for users to select values from. For example, you might create a Size property that only allows the values “S,” “M,” “L,” and “XL.” Creating this type of property enables you to ensure that the products using the property all use consistent values.

With a catalog created and your categories definitions, property definitions, and product definitions out of the way, you’re ready to begin creating actual products in your catalog. The first step is to define your product hierarchy by configuring categories. Back in the Catalog Editor, open one of your catalogs and create a new category. Figure 18.14 shows the category creation screen, where you provide values for the category’s properties.

Figure 18.14. Create the categories necessary to organize the products within your catalog.

After you’ve created several categories, you can relate them to one another. A category can contain other categories (called child categories), and a category can be contained by other categories (called its parent categories). Figure 18.15 shows how you can edit the relationships between categories to create a hierarchy.

Figure 18.15. Categories can have multiple parents and children.

Commerce Server’s category structure is infinitely flexible. Each category can have any number of parents, and any number of children. For example, a “Unisex Hats” category might be a child of a “Men’s Clothing” category and a “Women’s Clothing” category. All the products contained in the hats category would then be available to shoppers browsing for either men’s or women’s clothing, increasing the exposure of the products and the likelihood that someone will buy them.

With your categories set up, you can begin entering products into the catalog, as shown in Figure 18.16. You’ll provide all of the values for the product, based on the properties contained within the product’s product definition.

Figure 18.16. All products contain a unique identifying number, which is the SKU in this example.

Some products may contain variants. A variant is some version of a product. For example, a book might be available in hardcover, paperback, and audio CD editions. It’s the same book either way, just slightly different packaging. Each version becomes a variant in your catalog. Each product variant shares certain properties, such as title, and has variant properties, such as binding type and price. Figure 18.17 shows how to configure product variants.

Figure 18.17. Assign products to at least one category to make them available to your customers.

Figure 18.17 also shows how you can assign a product to one or more categories. Assign a product to the categories that it belongs to. Avoid assigning a product to two categories that share a parent-child relationship; doing so will make your product appear in two places in your catalog’s hierarchy and might confuse your customers.

Once your products are entered, you’re done! You’ve got a completely populated catalog that includes categories and products that your customers can browse.

Campaigns can nearly rival catalogs in their complexity. Campaigns are managed using the Business Desk’s Campaigns module, which includes six sub-modules. The most important of these is the Campaign Manager, shown in Figure 18.18.

Figure 18.18. Campaigns can include multiple different types of campaign items.

In Figure 18.18, you’re looking at a company with only one campaign customer, itself. That’s not unusual for many online retailers, who only want to promote their own products. Commerce Server, however, also enables you to set up multiple campaign customers for Web sites that accept paid advertising. Each campaign customer can have multiple marketing campaigns running at once. Each marketing campaign—such as the Back to School and Spring Fling campaigns shown in Figure 18.18—have their own start and end dates and their own goals. For example, a campaign might have a goal to target ten thousand shoppers. Once the campaign reaches its goal, Commerce Server will stop displaying the campaign’s items as aggressively.

Each campaign can have multiple campaign items, and there are three types of campaign items to choose from:

Each campaign item can have its own goals and weight within the campaign. These values determine how often Commerce Server will display the item. Commerce Server uses a complex Content Selection Framework (CSF) to decide what ads to display. For example, the CSF can ensure that ads from competing companies aren’t displayed on the same page, and that ads with high goals are displayed more frequently than ones with lower goals.

The Campaigns module has other sub-modules:

Commerce Server’s campaigns system can also track campaign results, telling you how many shoppers clicked on an ad, how many responded to an email message, or how many took advantage of a discount. This information is all exported to Commerce Server’s Analysis system, where you can easily evaluate the success of your campaigns.

Commerce Server’s Orders modules enable you to view orders that have been placed on your site and configure information relating to customer orders. For example, the Shipping Methods sub-module enables you to define the shipping methods and charges available to your customers, and the Tax Rates sub-module enables you to define the taxes you must charge your customers. Figure 18.19 shows the Shipping Methods sub-module.

Figure 18.19. You can enter a variety of shipping methods and costs on your site, and you can create separate entries for different languages.

Here’s what the Orders module enables you to do:

The Business Desk’s Analysis module enables you to work with reports and other analysis tools. As shown in Figure 18.20, Commerce Server comes preloaded with several different kinds of reports. Many of these reports are dynamic, which means they enable you to interact with the report to analyze the data more effectively. These reports rely on Commerce Server’s data warehouse, which I’ll cover in more detail in a bit. Static reports are more traditional types of reports, and may take longer to run. When you run a static report, its results appear in the Complete Reports sub-module of the Analysis module.

Figure 18.20. You can create your own custom reports in addition to the reports provided by Commerce Server.

Commerce Server’s data warehouse is the key to most of Commerce Server’s reports. The data warehouse doesn’t contain a real-time copy of your site’s data, but instead contains a specially constructed copy of that data. The data warehouse can return report results much more quickly than the site’s transactional database, but the data warehouse must be populated before it can be used. Populating the data warehouse requires the use of several SQL Server Data Transformation Services (DTS) tasks, which read data from your site’s transaction database, Web server log files, and other sources, and reconstruct the data into the data warehouse.

Commerce Server’s dynamic reports utilize the Office XP Web Controls, which are included with both Commerce Server 2002 and Office XP. Specifically, Commerce Server relies on the PivotTable control, which is normally a part of Excel 2002. The PivotTable enables you to customize dynamic reports to display the exact information you need, making data analysis more convenient and efficient.

Because Commerce Server’s data warehouse is preconfigured, you won’t need a skilled data warehouse architect or administrator. That means the data warehouse—and thus, the entire Analysis module—can be a powerful, inexpensive addition to your Web site.

The Business Desk’s Profiles module provides access to the profiles contained within Commerce Server. Profiles are mainly used to represent the users of your site—primarily shoppers, in other words. Commerce Server can be configured to use either its own database for profiles, an external database, or Active Directory.

One of the most important tasks in the Profiles system is using the Profile Definition Designer to decide exactly what type of information you’ll store in your profiles. For example, you might track age, gender, and annual income for your shoppers. By storing that information in shoppers’ profiles, you’ll enable Commerce Server to target ads and other content to shoppers based on that demographic information. Figure 18.21 shows the Profile Definition Designer in action.

Figure 18.21. Once you extend a profile object with room for additional properties, you can start populating those properties using surveys and other techniques.

Global resources are configured in a Commerce Server administrative database and can potentially be used by multiple Commerce Server sites utilizing that same database. For example, suppose you have two distinct Web sites running on the same computer: one for the public, and one for private wholesale customers. Both might share the same profiles system, making it easier to convert a public customer into a private wholesale customer. By configuring both sites to utilize the same global profile resource, you can accomplish this goal.

Global resources are managed through the Commerce Server Manager snap-in, as shown in Figure 18.22. On the left side of the MMC, you’ll see the list of available global resources; details appear in the right pane. You can also right-click any global resource and select Properties from the pop-up menu to edit the resource. In Figure 18.22, for example, the profile resource’s connection string is being edited.

Figure 18.22. Changes to global resources usually require you to restart the Web sites that utilize those resources in order for the changes to take effect.

Figure 18.23 shows another important global resource property being edited: partitioning. Available for the profiles resource only, partitions enable you to split your profiles data across multiple data sources. Generally, a single SQL Server computer can support profile systems with up to 25 million users; Active Directory can support about 10 million. If you have more profiles than that—and large Web sites often do—partitioning is necessary. Figure 18.23 shows that this server’s global profiles resource is configured with only a single partition; you can click the Add button to create another one.

Figure 18.23. Partitions are a key to creating more scalable Commerce Server Web sites.

It’s not common for a large company to run multiple Web sites from a single Commerce Server administrative database. Typically, companies will use a single back-end administrative database to manage a single Web site, which means the database’s global resources won’t be shared. In a development environment, you may find multiple sites sharing the same administrative database, but not usually in a production environment.

Individual Web sites maintain their own private resources, as well, which you manage with the Commerce Server Manager snap-in. Figure 18.24 shows a site (or local) resource’s properties. As with global resources, much of what you’ll manage with site resources are connection strings.

Figure 18.24. Changes to a site resource usually require restarting that site’s Web site in order for the changes to take effect.

Why might you need to edit connection strings? It’s not unusual for a Web site to start small, with all of its databases on a single SQL Server computer. As the site grows, that computer may not be adequate for the site’s needs. Commerce Server enables you to distribute its databases across multiple SQL Servers. For example, you might keep your profiles on one server, your Direct Mail database on another, and your site’s primary transaction database on a third. Because the Commerce Server Manager snap-in enables you to modify these resources’ connection strings, you can program your site to look at the new servers for the appropriate data.

Site management also requires individual application management. Most sites have two Web applications: one for the site itself, and another for the Business Desk application. As shown in Figure 18.25, you can use the Commerce Server Manager snap-in to manage the properties of these applications.

Figure 18.25. Sites can have any number of Web applications, depending on how the site is configured.

You can think of Commerce Server applications as distinct portions of the overall Commerce Server Web site. For example, the main application is the one that users utilize to browse your product catalog and make purchases; the Business Desk application is the one you use to manage your site’s catalog, orders, and other features. Both exist within the same Commerce Server site, although they serve distinct purposes. Also, you probably won’t have the Business Desk application physically installed on every Web server. For security reasons, it makes far more sense to only install the Business Desk application on an internal Web server where only your employees can access it.

Perhaps the biggest pain in the neck when it comes to Web sites is deploying them. Commerce Server sites can be especially difficult because they involve so many different components: COM objects, Web pages, data sources, and much more. Fortunately, Microsoft provides a Site Packager with Commerce Server. The Site Packager knows about all the little components that a Commerce Server site uses, and it knows how to search them out and bundle them all up into a single, easy-to-distribute PUP file, called a package.

Running the Site Packager couldn’t be easier. Just run it from the Start menu (under the Commerce Server folder), and, as shown in Figure 18.26, select the site you want to package and a location for the PUP file to be created. The Site Packager will do its thing and you’ll end up with a fully packaged Web site ready to be deployed.

Figure 18.26. Packaging sites is the easiest way to deploy them to a new server.

The Site Packager is probably the best way to deploy a site to a freshly installed Commerce Server computer. Deploying incremental changes to a site—new Web pages, a change to a data source, and so forth—is completely unsuited to the Site Packager. Incremental changes and ongoing site maintenance are best handled by Application Center, which is designed to synchronize the content and configuration settings within a Web farm.

The Commerce Server Manager console includes the Windows System Monitor, which enables you to manage multiple performance counters in real-time. As shown in Figure 18.27, there are a number of performance counters I like to watch on a regular basis.

Figure 18.27. You can also launch the System Monitor by itself from the Performance console, located in the Administrative Tools folder of the Start menu.

My preferred counters include

Local network utilization is rarely an issue in Web applications, because the local network’s bandwidth usually far exceeds the Internet bandwidth to begin with. Where local network utilization can become an issue is on the back-end, between the Web servers and your middle-tier servers of back-end SQL Server computers. Optimizing that connection lies mostly on the developer, although there are a few things that you as an administrator can do:

Optimizing your Internet connection’s utilization is solely a matter for your Web developers. They should create Web pages that are as small as possible, use size-optimized graphics, and ideally serve graphics from a distributed network such as Akamai (www.akamai.com) so that the graphics don’t consume your site’s own Internet bandwidth.

There are two ways to improve Commerce Server database performance: efficiency and scaling. From an efficiency standpoint, developers should use stored procedures instead of ad-hoc queries, because SQL Server can execute stored procedures more efficiently. All queries should return the minimum amount of information required, and should be optimized to use indexes and other SQL Server features to improve performance.

Scaling is another means of improving SQL Server performance. Scaling up simply means using more powerful hardware for SQL Server, while scaling out means using more SQL Server computers. Commerce Server lends itself especially well to scaling out by enabling you to split the various Commerce Server databases among several servers. You can even use read-only copies of databases such as the product catalog to improve performance.

There are two ways to get better performance from a Web server. The first is to simply add another Web server and load balance between them, a feature provided by Windows’s Network Load Balancing (NLB) software (which is also included with Application Center). The second, more subtle way is to dedicate Web servers to a task, effectively partitioning your Web site. For example, you might have one set of servers dedicated to serving up product pages, while another set handles the checkout process. A third set might handle customer searching. Partitioning enables a Web server to focus on a single task, and also enables you to scale the individual tasks more easily. For example, if your search servers are overloaded, you can simply add another dedicated search server.

I can connect to the Business Desk installation page, but it just sits there and doesn’t actually install the Business Desk.

The Business Desk install page uses an ActiveX control to install the Business Desk HTA on your computer. Your browser must be configured to allow ActiveX controls to load and execute, and your browser must obviously support the use of ActiveX controls (Internet Explorer does; most other browsers do not). If the Business Desk install page isn’t prompting you for an installation location after a couple of minutes, you probably have ActiveX controls disabled in Internet Explorer’s Security options. Modify your options to permit ActiveX controls to execute, close Internet Explorer, and try again.

I run the Site Packager, but it quits almost immediately and just says there was an error.

The most likely cause is that the path you provided for the destination PUP file doesn’t exist. The folder you want the PUP package to be created in must exist before you run the Site Packager tool. Other common problems include an inability to connect to the SQL Server computers supporting your site; make sure your site is fully functional before running the Packager and you should have no problems.

You can troubleshoot the Site Package by using its log file, which is c:pup.log. Every time the Packager runs—whether packing or unpacking a site—it appends information to this log. I recommend that you archive or delete this log file before running the Packager; that way, the log file will only contain your most recent Packager session and you won’t have to scroll through a huge log file looking for relevant information. When packaging a site, the relevant errors will usually appear near the bottom of the log file, so start looking there first.