|
|
|
|
|
|
|
|
|
|
|
| Building Solutions with Microsoft® Commerce Server 2002 |
|
|
|
|||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||
Chapter 4: Designing Catalogs
- Creating the Catalog Definition
- Organizing Products by Using Categories
- Managing Products
- Using Multiple Catalogs
- Building Catalogs for the Enterprise
- Summary
4 Designing Catalogs
The goal of any commerce site is to sell products—either physical goods or services. The Commerce Server catalog provides a structure to organize your products and make them available to customers. A good catalog design is the key to a successful site. The catalog affects every aspect of a commerce site, so this is not an area in which to cut corners.The catalog and the user profiles form the foundation of a commerce site. It doesn't really matter whether you create your catalog first or your profiles first—these are distinct tasks that can be split easily among separate developers or teams. (We'll put these pieces together in later chapters when we discuss targeting users and creating site pages.)
Good catalog design is not merely a technical issue. You also must consider business issues, such as what products will be stored in the catalog, the relationships between products, who buys them, and why and how the products are used. The catalog structure defines how users will navigate through your site and how they'll find products. If this structure is not intuitive, your sales will suffer. Do not trust a developer to decide how to organize categories or determine what properties should be available for products. This task might be better performed by a usability expert. Of course, when you design a catalog you must also make many important technical decisions that will affect the performance, maintainability, and extensibility of the catalog as well as how easily developers can create pages based on the catalog.
In this chapter, we'll first consider how to create a catalog, and then we'll look at some advanced catalog topics, including controlling access to specific catalogs, categories, and products by using catalog sets and virtual catalogs, and creating international catalogs for multilingual and multicurrency sites. We'll conclude by looking at special considerations for enterprise-level catalogs, including sharing catalogs with trading partners and integrating a catalog with external systems.
Creating the Catalog Definition
Before you can create categories or add products to a catalog, you must create the catalog definition. A catalog definition has three primary parts: property definitions, category definitions, and product definitions. The relationships between these parts are shown in Figure 4-1. Properties describe the catalog and the products within it. Categories form the hierarchical organization for the products. Products describe items you sell—anything from physical goods to membership in an organization to hours of a consultant's time.Category definitions and product definitions can share properties—you need not create separate properties for each. We'll discuss how to determine what properties you need for your site later in this chapter.
Click to view graphic
Figure 4-1 A catalog definition hierarchy
A property definition consists of attributes such as the following: internal name and display name, data type, default value, minimum and maximum length (for strings), value (for numbers), or date and time. It indicates whether the property is searchable, required or optional, and visible in Business Desk.
For example, our Fourth Coffee commerce site will need a field that describes both products and categories. You'll therefore create a Description property, as shown in Figure 4-2, which you can then use in a category definition, a product definition, or both. To create the property, you'll fill in the property attributes, such as the string length and other display characteristics.
Click to view graphic
Figure 4-2 Creating a property definition
Creating a property is as simple as filling in the attributes in Business Desk, as shown in Figure 4-2. If these attributes do not sufficiently describe the property you want to create, you can also define your own custom attributes. These custom attributes can control how your site displays a property. For example, you can use a custom attribute to define the control type (text box, list box, or check box). Or you can use a custom attribute to define a reference to a lookup list of allowable values for the property if you do not want to enter those values in the property definition.
Creating a custom attribute is not the most straightforward task. Unlike the Profile module, Business Desk does not have an interface for creating custom attributes. You must add the attribute using the Catalog API or by importing a modified XML file into the Catalog Manager. To add a custom attribute using the Catalog API, you add the attribute using the AddPropertyAttribute method of the Catalog Manager:
using Microsoft.CommerceServer.Interop.Catalog;
// add code here to create object instances
.
// myCatalogManager is a valid Catalog Object
myCatalogManager.AddPropertyAttribute("DisplayType",
CatalogDataType.String, 30)
Alternatively, you can modify the XML file for a catalog, adding AttributeDefinition tags with your custom attributes. Export the catalog from Business Desk, make any modifications, and then import the XML file to create a new catalog or modify an existing catalog. Note that you're limited to 100 property attributes per catalog.
Although you can use the same property in both a category definition and a product definition, it's sometimes safer to create separate properties for each. For example, it's perfectly acceptable to create a Description property and use it for both categories and products, but you might want a category description to be limited to 100 characters but allow product descriptions to be much longer. Or you might want to require that a product have a description but make a description optional for the category. In these cases, you should create two properties, CategoryDescription and ProductDescription. Of course, if you're certain that a property will have the same meaning for both a product and a category, you should create a single property and avoid the unnecessary clutter.
Organizing Products by Using Categories
You use categories to organize the products in your catalog. The category structure in Commerce Server is very flexible, which also means it can become exceedingly complex. A category can have not only multiple children but multiple parents as well. The same category can be a child to categories at different levels within the hierarchy, making it a second-level and third-level category at the same time. Good luck to the user who tries to navigate through such a hierarchy!
Creating Category Definitions
We'll use the properties we created in the previous section to create a category definition. In Business Desk, you can simply select the properties you want from a list.The properties you select for your category definition will depend primarily on how users will navigate through categories and what information they'll see on category-level pages of the site. For example, if your site shows a list of all products in a category underneath the category name, you probably won't need any properties except the name of the category. However, if you want to create a splash page for each category that displays a description of the category and an image for that category, you'll also need properties for the description and image attributes. You might want some categories to be "hidden" so they do not appear in the site navigation—users will have to navigate to them through a hyperlink. In the Fourth Coffee Web site, we'll create a special sale department that is not visible in the list of categories on the site. We can then send an e-mail to a list of "preferred" customers that includes a direct link to the department. To accomplish this, we can include a Hidden property for the category definition. We can render the department list using the following code:
using Microsoft.CommerceServer.Runtime.Catalog;
// add code here to create object instances
.
// myCategory is a valid Category object
try
{
DataSet categoryProperties = myCategory.GetCategoryProperties();
if(categoryProperties.Tables[0].Rows[0]["Hidden"] == 0)
{
// Code to display category in navigation
.
}
}
catch(CatalogException)
{
// Handle error - this category does not exist or has been deleted
}
For most sites, a single category definition will probably meet your needs and will make category management easier. However, some circumstances will call for a different category definition. The following example demonstrates such a case.
For the Fourth Coffee site, you want to organize the products into logical departments, including Coffee Beans, Cups and Mugs, and Coffee Makers. The site uses a standard page template to display the products for each department. The home page displays the department name, a description, and an image. The Department category definition will therefore include Name, Description, and Image_filename properties, as shown in Figure 4-3.
Click to view graphic
Figure 4-3 Fourth Coffee Company category definitions
Fourth Coffee also has Special Feature departments that are displayed for a brief time. For example, the site might have a Featured Coffee Of The Week department or a department with suggested gifts for Mother's Day. These special departments have a custom page that displays the products, so the category definition must include the filename of the custom page for each Special Feature department. Because the site displays these departments for a limited time, the category definition also includes Start_date and End_date properties that the site can use to control the display of the department.
Creating the Category Hierarchy
The categories of your commerce site will typically provide users with the primary means of navigating and finding products. For this reason, it is particularly important that you spend time planning a logical category structure that corresponds to the way users think. In a consumer-facing application, users will become frustrated and leave your site if they cannot find the products they want quickly and easily. In a business application, poor organization will be a barrier to user acceptance.When you define the categories for your site, it's good practice to keep things as simple as possible. Commerce Server allows you to nest categories up to five levels deep, but navigating to a product buried in a fifth-level category would probably require too many clicks. The depth of the category hierarchy should depend on the types of users you expect, but a good rule of thumb is to make sure a user can reach any product in no more than three clicks.
The flexibility of Commerce Server also makes it tempting to make the same category a child of multiple categories. Although this approach can be used to good effect (for example, making a Holiday Mugs category a child of both Equipment and Gifts), it's easy to get carried away. Users will be confused if they continually find the same category in multiple places, particularly if it's at a different level of the hierarchy in each place. If you do decide to create a category with multiple parents, you should designate one category as the primary parent category. This step is not required, but it's good practice because it allows a common path to a product.
For example, if you implement a product search on your site, the search results might display the category in which each product resides and that category's place in the hierarchy. In the example above, if a user searched for a mug that was located in the Holiday Mugs category, the primary parent category would indicate whether the site should display the product location as "Equipment | Holiday Mugs" or "Gifts | Holiday Mugs." The primary parent category is also used in conjunction with indirect pricing (discussed in the upcoming section). If you've designated category-level pricing, the primary parent category will determine the price of the products.
Managing Products
The products in the catalog are the bread and butter of the commerce site, and building a successful site means finding the best way to present and describe those products to users. But products change, and your site must be continually updated with new information. Good design requires that you build in the ability to easily manage changing product definitions and descriptions.
Creating Product Definitions
You set up product definitions much like you set up category definitions. Unlike when you create user profile definitions, you do not need to create the underlying data store. Commerce Server will manage creation of the tables in the SQL Server database, so you need only work with the Business Desk interface.To add products to your catalog, you must first create one or more product definitions using the catalog properties you've already defined. You use Business Desk to select the properties that will be part of the product definition. Every product definition will automatically include a List Price property. Figure 4-4 shows two product definitions for the Fourth Coffee example.
Click to view graphic
Figure 4-4 Fourth Coffee product definitions
Unless your catalog is small and homogeneous, you'll need multiple product definitions. In the example shown in Figure 4-4, coffee beans have different properties than mugs. You should create a new product definition for every different kind of product in the catalog. If you have two products that are similar but have some differences, do not try to force one to fit the definition of the other. You'll end up paying the price with more complex code on your site pages. Even when you have a product whose properties are a subset of another product's properties, you should avoid adding extra product fields that are required for some products and optional for others. You should simply create two product definitions—each with the properties that are required and important for that product. If you follow this practice, your catalog will have better data integrity and you'll be able to fulfill data validation requirements more easily.
Product Variants
So far, we've considered products as forming the lowest level of the hierarchy. However, products will often have different colors, sizes, or flavors. These are called variants. The base product is a product family. The products in the product family will have many identical properties (such as a name) and some properties that differ by variant. Figure 4-5 shows the Fourth Coffee product definitions with color variants for the Equipment definition.
Click to view graphic
Figure 4-5 Fourth Coffee product definitions with color variants
You create a product family definition the same way you create a product definition, but you add one or more properties to the variants section of the product definition screen, as shown in Figure 4-6. You should add only properties that differ by variant. If your product description includes the product's color, the Description property should be in the variants section. If the description is the same for all variants, it should be in the products section. If you create variants, the variants section will need a unique identifier property. It cannot be the same unique identifier used at the product level. In Figure 4-6, we use the SKU as the unique identifier.
Click to view graphic
Figure 4-6 Creating a product definition with variants
Some types of products will have multiple properties in the variants section. For example, clothing has both a size variant and a color variant. Unfortunately, Commerce Server offers no way to separate these variants. For example, the description of a product might differ based on the product's color, but it will not vary for different sizes. However, you must still enter a description for every combination of color and size. If your product has 3 colors and 10 sizes, for example, instead of entering 3 descriptions you must enter 30. You can either bite the bullet and enter the description 30 times, or you can create a custom administrative interface that allows you to enter the description once and automatically populate all sizes for a particular color. You must weigh the relative costs for your particular situation. (Part IV of this book discusses how to customize Business Desk and how to create your own custom administrative interface.)
Pricing
In our opinion, pricing is the most complex aspect of building a commerce site. You can choose from two pricing models: direct pricing, where you set the price for every product, and indirect pricing, where you set the price per category. You can create multiple price properties for a product to allow regular and sale prices for products. You can set the price at the product or variant level. With virtual catalogs (discussed later in this chapter), you can create pricing rules that apply different prices to the same catalog based on who is browsing the site. In addition, the Commerce Server campaign engine can apply dollar-off discounts (discounts of a specific amount) to any products. When you combine all these options, it's no wonder that designing the pricing for a catalog can get tricky.Direct Pricing
If your products do not have variants, you can use a simple direct pricing strategy in which you define the price of each product in the List Price property. Business Desk displays this property as the Default Price.
If your products have variants, pricing will be at the variant level. A product will still have a default price at the product level, and Commerce Server will assign a default price to each variant when you create the variant. This default value is not retroactive: if you change the default price at the product level, the price of any variants already created will not change. In this case, you must either change each variant manually or customize the interface to do the job for you.
Most sites we've developed have required pricing at the variant level. However, as we discussed earlier, we often want to set pricing according to one variant dimension but not another. In the apparel industry, it's common to set prices according to the color. For example, if the pink shirt is not selling well, the company can reduce the price on pink shirts. The same style of shirt in a black color, if it is selling well, will not have a price reduction. However, the price will typically not vary according to the size. In the food industry, by contrast, pricing is set by the product size but not by the flavor. In both of these cases, the catalog can support pricing according to the necessary rules, but the Business Desk interface cannot support it without customization.
Indirect Pricing
You use indirect pricing when you want to set the same price for all products in a category. You set the price in the category definition, and all products that are members of this category or its child categories will be sold for this price. The category price overrides any product-level or variant-level prices the product might already have. When you remove a product from the category, its price will return to the price originally set for the product.
Indirect pricing is most useful when you have a special sale on multiple products with all products having the same sale price. For example, Fourth Coffee could sell all coffee at $9.99 per pound by creating a sale category with indirect pricing. Any products that are members of this department would be sold for this price, despite having different original prices. If you were to implement this type of sale using campaigns, you'd need to create a different discount for every product that has a different price because the discount engine works by applying a discount (dollars off or percentage off) to a price; it cannot set an absolute price.
Discounts
Commerce Server 2000, the previous version of Commerce Server, could apply only one discount to an item at a time. If you used a discount to put an item on sale, you could not apply an order-level discount, such as free shipping, if any items in the order were on sale. Because of this limitation, developers usually implemented a sale price as a second property of the product. They maintained the original price as a property so the user interface could display both prices to the customer.
This design is not necessary in Commerce Server 2002 because you can apply multiple discounts to the same order. You can use just the campaign engine for sale items, but this approach might not always be the best design choice. One issue is the administrative interface. The campaign engine is very powerful, but it takes some time to set up a new discount. If you need to put several items on sale, the task can take a substantial amount of time. Changing the value of a property for a product would take much less time. The second issue with using discounts is Web site performance. It doesn't do much good to put an item on sale unless you can display the sale price to customers as they browse the catalog. To display the sale price, you must run the Commerce Server discount pipeline for every page that displays product prices. If your catalog is large, with a significant number of products that are on sale, there will be a large number of discounts, which will further degrade performance. (You can address this performance issue to some extent using caching, however, which we'll discuss in Chapter 7.)
Despite these issues, using discounts for sales does have some advantages. If your sales have defined start and end dates, you can define these dates when you create the discount, and no additional coding will be needed. If you were to implement the sale using a second price property on the product, you'd either have to change the price at exactly the right time or add code to your administrative interface and Web site to properly handle the start and end dates. If you implement sales through the campaign engine, you'll also have more control over the interactions of the sale with other discounts, such as not allowing discounts on sale items.
There is no right or wrong way to implement sales. If the sale is a true price reduction—that is, you don't intend to return the item to the original price—you should implement it by changing the price in the catalog. Otherwise, you can pick the method that meets your requirements and weigh the amount of effort required to develop the site and administrative tools against the amount of effort required to create and maintain sales.
Product Relationships
Cross-selling is an effective strategy for increasing sales. Cross-selling means creating relationships between products so that when a user buys or even just browses a product, the system will suggest other products that might interest that user.You can implement cross-selling on your site in two ways. The first way is to define the relationships yourself. You can define a product relationship manually using Business Desk. (See Figure 4-7.) On the product page in the Product Family Relationships section, you can add a product and name the relationship type. The relationship name can be any text string. You can use this relationship name on the site to identify different types of relationships. For example, you might create a cross-sell relationship that identifies products that users might buy in addition to the item they have already bought. Or you might create an up-sell relationship that identifies more expensive products that users might buy instead of the item they're currently browsing. If you plan to use only a single relationship type on your site, the name is unimportant. In Chapter 8, we'll discuss how to display the related products on your site pages.
Click to view graphic
Figure 4-7 Creating a product relationship
The second approach to cross-selling is to let Commerce Server determine the relationships for you. You can use the Predictor resource in Commerce Server to build models that predict what products a customer might be interested in, based on the customer's profile or previous purchases and the profiles and purchases of other customers. You can use the prediction models to display real-time recommendations on your Web site, or you can view the models and create the relationships manually as described earlier.
Creating a prediction model that accurately predicts customers' buying habits is a complicated task and is outside the scope of this book. Displaying the results of a prediction model on your site, however, is straightforward. The following code displays five products that the Predictor resource recommends, based on the most recent item added to the user's shopping basket:
using Microsoft.CommerceServer.Interop.Targeting;
using Microsoft.CommerceServer.Interop;
// other code for the page
.
Dictionary currentCase = new DictionaryClass();
// Set up user context
currentCase["UserID"] = userID;
currentCase["ZipCode"] = zipCode;
currentCase["State"] = state;
// Set up basket context
// Insert for every item in basket
currentCase["QTY(productId)"] = productQty;
// List of properties to predict
SimpleList propsToPredict = new SimpleListClass();
propsToPredict = "SKU";
// Arrays to hold the predicted values
Array[] predictedProps;
Array[] predictedValues;
// Number of predictions
int maxPredictions = 5;
// myPredictorClient is a valid PredictorClient object
myPredictorClient.Predict(currentCase, propsToPredict, ref predictedProps,
ref predictedVals, maxPredictions, System.DBNull);
// Iterate through predictedValues object and display product information
.
// Clean up the object
CommerceContext.Current.RegisterDispose(myPredictorClient)
The advantage of using the Predictor resource for cross-selling is that you can automate the process of creating the recommendations. However, this approach also has several drawbacks, so creating the relationships manually might meet your business requirements more effectively. The first disadvantage is that the Predictor resource requires a set of initial data in order to build a prediction model. The amount of data it requires depends on several factors, such as the number of products, number of users, and number of transactions, but you'll likely need at least three to six months of data before you can begin using the Predictor resource. If you want to implement product recommendations from the beginning, you must define the relationships manually until the data warehouse has collected enough data.
Another potential problem with prediction models is that even with large amounts of data, the model might be inaccurate due to inconsistent data. If a customer buys items for himself and someone else, the Predictor resource will consider these purchases to be for the same person. For example, if a science fiction fan buys a romance novel for his friend, the Predictor resource might predict that users who like science fiction books also like romance novels. A large amount of data should overcome a single anomaly such as this, but if a significant number of purchases on your site are gifts, the prediction model will probably be inaccurate.
Finally, letting the Predictor resource determine the relationships between products takes the marketing control away from the business. In your site, you might want to create relationships based on other business drivers besides customer purchase habits. For example, you might want to highlight a new product by relating it to several other products. The Predictor resource will never display new products because the model will not contain any data on them.
A good compromise we often use is to view relationships using the Predictor but manually configure the relationships on the site. This approach allows us to address the business need for featuring specific products and to do a reality check on the relationships the Predictor derives. You can also list the items recommended by the Predictor separately from those recommended by the business—for example, by listing Predictor recommendations under Products Others Have Purchased and by listing business recommendations under Our Picks.
Product Sets
Another strategy for increasing sales is to group products together and sell them as a set. The customer can buy any of the products separately or buy all of them in a single step. You might also want to offer a lower total price for the items if they're purchased as a set.You can implement product sets in three ways with Commerce Server. Your requirements for product sets will help you determine the best approach for your site. The simplest approach is to use the product relationships discussed earlier. For each product in a set, you create relationships with the other products in the set. On your browse pages, when the user selects a product, your code will also display the related products. Your code can allow the user to select one or more items from the set, or you can automatically add all the products in the set to the shopping basket. If a product can be a part of multiple product sets, you can distinguish between the sets by naming the product relationships. This approach requires that the price of the product set be the same as the sum of the individual product prices. It is an appropriate approach if you do not plan to have the browse pages show the products as a set. A user must select an individual product, and the site will then display all the products in the set. If you want to display product sets in the browse path before a user selects a product, one of the next two approaches will be easier to use.
The second approach to implementing product sets is to use catalog categories to group the products into sets. You first must create a category definition for these sets. Include all the properties needed to display the product set. Depending on the requirements for your site, this might include the product set name, description, image characteristics, and other properties. On a site index page that displays several product sets and products, you can use the category properties to display the product set. On a product detail page that shows the items in the product set, you can retrieve the list of products in the category by stepping through each product that is a member of the category. You can determine the price of the product set dynamically by summing the prices of the items in the set. Figure 4-8 shows the logical design of two product sets sold by the Fourth Coffee company: a Coffee Sampler containing House Blend and French Roast coffees and a Coffee Starter Kit containing House Blend coffee, a logo mug, and a four-cup coffeemaker.
Click to view graphic
Figure 4-8 Using categories to define product sets
This approach is appropriate if the price of the product set will be the same as the sum of the individual product prices and you want to also allow users to select individual items from the set. Each product will still be managed individually in the shopping basket and the purchase pipeline, so you need not worry about keeping the products in the set together as a unit.
If you want to keep the products together as a unit throughout the checkout process, you should consider the third approach. You create a new product definition for the product set and store a list of the members of the product set as a property of the product. You can store this data as XML in a property of type String. Your product index page can show the product sets in the same manner as other products. The product detail page will need code to extract the individual products from this property and display details for each product. The price of the product set is stored at the product set level in the List Price property automatically included by Commerce Server. Figure 4-9 shows the logical design for the Fourth Coffee product sets using a product definition.
Click to view graphic
Figure 4-9 Using a new product definition for a product set
This approach is appropriate if the product set will have a different price from the sum of the prices of the individual products. Although you can still allow users to purchase a subset of the products, doing so will increase the complexity of your solution significantly. You would probably need to create pricing rules that define the product set price if only certain products are selected.
Both of the latter two approaches require a significant amount of code to implement, both on the administrative side and on the consumer-facing side. The challenges of using categories include the following:
- If an index page displays both the individual products and product sets, you'll need custom code to retrieve the two lists. You can create a custom class that retrieves all products from a category along with the child categories with the Product Set definition.
- Any code on your site that retrieves a list of categories will need to consider which categories are used for navigation and the department hierarchy and which categories are used for product sets. The site should not display product sets in navigation trees.
The challenges of using a product definition for product sets include the following:
- You must write code to display the individual items in the set. You can create a custom class that consumes the product definition type and exposes a collection of products.
- The checkout pipelines will need to retrieve the list of products in the set so the pipeline can send the individual products to the fulfillment system and inventory management system.
- The complexity will increase further if products have different pricing at the variant level. In this case, you must store your XML documents as a variant property and include a list of variants in the product set.
- You will probably need to allow for back orders and returns on a single product in the set. If the price of the set is different from the sum of the products, you'll need pricing rules that determine the price of the individual item in the set.
- You'll need to create a custom administrative interface for setting up product sets unless site administrators can directly enter XML strings that define the products in the set.
At first glance, you might wonder why anyone would use a product definition for sets. After all, if the only requirement pushing us toward this approach is to allow the price for the set to be different from the sum of the individual prices, we could simply implement a campaign that offers a discount when the customer buys all the items in the set. However, despite the complexity of this approach, it offers some significant advantages. First, even though using a campaign is a valid approach to setting a discounted price for the set, you'll run into problems if you implement multiple campaigns. For example, what will happen if one of the products goes on sale individually? What if a product is part of more than one set? These complicating factors might preclude the use of campaigns.
From a business standpoint, collecting accurate data on the shopping patterns of your customers is crucial to marketing your products effectively. If you manage product sets as product relationships or categories, you'll have difficulty accurately tracking how many users are buying sets compared to the individual products. In addition, if you allow users to purchase only a subset of the products in the set, you're potentially losing sales. Your interface might force users to add all the items to their shopping baskets, but without some complex code you can't stop them from subsequently removing an item.
Finally, the product definition approach is the only way to easily communicate to your users that they have purchased a set rather than the individual items. The other approaches result in multiple line items appearing in the shopping basket, which might confuse a user who thinks she has just purchased a single item.
Using Multiple Catalogs
Our discussion of catalogs so far has centered on a single catalog and the categories and products within it. However, Commerce Server also supports multiple catalogs for a single commerce site as well as different types of catalogs:
- Base catalog A single catalog that contains category and product data.
- Catalog set A group of one or more catalogs. You can grant permissions to view a catalog set to users and organizations. A catalog set can contain base catalogs, virtual catalogs, and aggregated catalogs.
- Virtual catalog An extension of a base catalog. It references some or all of the products in a base catalog but does not actually contain the products itself. The virtual catalog can override certain properties of the products in the base catalog.
- Aggregated catalog A catalog that combines multiple catalogs into a single virtual catalog. You cannot set viewing permissions for an aggregated catalog unless it is a member of a catalog set.
Base Catalogs
A single base catalog should encompass all logically grouped products. The meaning of "logically grouped" will depend on the business requirements of your site. Requirements that might cause you to split your products into different base catalogs include:
- If you receive catalog imports from different suppliers. It might make sense to keep each supplier's products in a separate catalog to facilitate the import process.
- If your product line is seasonal. You should consider using a separate base catalog for each season so you can easily roll out a new season and retire an old one.
- If you have diverse display requirements, such as a simple catalog for suppliers and a visually rich catalog for consumers. It might make sense to create separate base catalogs with different property definitions for both the categories and products, which will enable you to store the same product in two different definitions while maintaining the uniqueness of the product in each catalog. This approach can be especially useful if the data is imported from an external system.
Remember that a single base catalog can support multiple category definitions and multiple product definitions. Unless you want to store the same product in multiple product definitions, you need not create separate catalogs.
Catalog Sets
Catalog sets are groupings of catalogs. The individual catalogs in a catalog set are still distinct entities, and your site must manage them as separate catalogs. For example, you cannot directly retrieve a list of all categories in a catalog set using the Catalog Manager. Instead, you must retrieve the categories from each catalog individually. You should use aggregated catalogs, not catalog sets, if your goal is to create what appears to be a single catalog.You must create one or more catalog sets if your site grants different permissions to catalogs or products based on the user or the user's organization. You cannot define permissions on base catalogs or virtual catalogs. If you need to define permissions on base catalogs, first add each base catalog to its own catalog set and then define the permissions on the set. Figure 4-10 shows the logical catalog set design for a company that receives products from two suppliers. One supplier provides discounted products. Regular users can view only regular products, and preferred customers can view both regular products and discounted products.
Click to view graphic
Figure 4-10 A catalog set logical design
You actually define such permissions on the User or Organization profile, not on the catalog set. To define permissions to view a catalog set at the user level, select the catalog set in the User Catalog Set drop-down list in the Account Info section of the User profile, as shown in Figure 4-11. If you want to set the permissions at the organization level, select the catalog set in the Organization Catalog Set property in the General Information section of the organization's profile. Note that a user or organization can have permissions for only a single catalog set.
Click to view graphic
Figure 4-11 Setting the catalog set for a site user
You must enforce catalog set permission completely in code. Commerce Server provides the tools, but it does not have a mechanism to ensure that only authorized users see catalogs they are supposed to see. In your site, you can use the following code to determine a user's catalog set and return a collection of catalogs within that set:
using Microsoft.CommerceServer.Runtime;
ReadOnlyStringCollection catalogList =
CommerceContext.Current.GetCatalogsForUser();
Virtual Catalogs
A virtual catalog references products in a base catalog. When you create a virtual catalog from a base catalog, it inherits all the products and categories from the base catalog (unless you set an inclusion rule, as described shortly). Commerce Server automatically reflects changes to the base catalog in the virtual catalog.The real power of virtual catalogs is that they allow you to create differences in product pricing without having to create and maintain a new product for each price. They also allow you to define permissions for specific categories or products in a catalog. Your site code uses virtual catalogs exactly like base catalogs.
Inclusion Rules
When you add a base catalog to a virtual catalog, you can define an inclusion rule that determines which products from the base catalog are included in the virtual catalog. By default, all categories and all products are included. If you want to limit the products in the virtual catalog, you can select the products to include or exclude. You can also include or exclude categories. If a product is a member of two categories and you exclude one of the categories but include the other, the product will still be part of the virtual catalog.
A virtual catalog can have only one inclusion rule at a time. If you create a new inclusion rule, it will replace any rule that already exists.
Creating a virtual catalog with inclusion rules is appropriate for a site in which you want to provide a subset of products to certain users or organizations—for example, if you're acting as a supplier and want to provide different sets of products to different distributors. If you sell the same products to two or more distributors, you cannot implement this scenario using catalog sets. Figure 4-12 shows an example of an apparel supplier that supplies apparel to two distributors—one that sells only shoes and one that sells both shoes and clothes. In this example, you can provide a virtual catalog to the shoe distributor consisting of only the Shoes category.
Click to view graphic
Figure 4-12 A virtual catalog with an inclusion rule
Pricing Rules
A virtual catalog can have multiple pricing rules so that products have a different price than in the base catalog. You can apply pricing rules to all products in the catalog, to all products within a category, or to individual products. Unlike Commerce Server discounts, which allow only dollar off or percentage off, the virtual catalog pricing rules provide more options:
- Set Price Sets an absolute value for the product(s)
- Add Specifies a dollar amount to be added to the item price
- Add Percentage Specifies the percentage by which to increase the item price
- Discount Specifies a dollar amount to be subtracted from the item price
- Discount Percentage Specifies the percentage by which to decrease the item price
Virtual catalogs with pricing rules are useful when you want to provide the same product to different buyers at different prices—for example, if you're a supplier to multiple distributors, if you sell products to both consumers and wholesalers, or if you have different tiers of preferred customers. Figure 4-13 shows an example of providing a catalog to both consumers and wholesalers. Consumers pay the regular price for all items, and wholesalers receive special pricing on all items.
Click to view graphic
Figure 4-13 A virtual catalog with pricing rules
Depending on the type of pricing you need, it might be easier to implement a discount campaign rather than create a virtual catalog. You can create a discount campaign that targets an attribute of the user profile such as the user type or the user's organization and apply a percentage discount to all items in the catalog. However, you're limited to either a percentage-off or dollar-off discount, so it is impractical to set pricing at a product or category level. You should use a campaign only if the discount offered to certain users is a set percentage for all products and if the same products are offered to all users.
You can also use pricing rules to create a catalog with multiple currencies. Each virtual catalog has its own default currency, which you can use to control pricing display on the site. To set the actual prices, you can create pricing rules that adjust the base price of each product by a conversion factor or rules that specify the difference between the base price and the price in the other currency. We'll discuss some specific implementations of a multicurrency catalog shortly.
Aggregated Catalogs
Aggregated catalogs are simply a type of virtual catalog that combines products and categories from multiple catalogs so they appear to be from a single catalog. Commerce Server does not distinguish between a virtual catalog that inherits from a single base catalog and an aggregated catalog that inherits from multiple base catalogs.
International Catalogs
International catalogs are a business concept, not a concept in Commerce Server. There are two aspects to making a catalog international. The first is having multilingual attributes, and the second is having multiple currencies. A catalog can be multilingual, multicurrency, or both. For example, if you sell products exclusively in Canada using Canadian currency, you might need to display products in both English and French. Or if you sell products in the United States and the United Kingdom, the catalog can be in English but you'll need to support both U.S. dollars and British pounds.You can define up to 10 languages for a single catalog. Each category and product property you define as multilingual will have a value for each language you've defined. Other properties will be the same for each language. For a multilingual product, you should define any text property that the site will display to the user as multilingual. If any images associated with the product contain text or will have a different appearance in the other language, you should also define them as multilingual. Figure 4-14 shows the Business Desk interface for setting up multilingual properties.
Click to view graphic
Figure 4-14 Multilingual properties in Business Desk
The following code shows how to determine the user's preferred language from the Preferred_Language property in the user profile and set this language on the catalog:
using Microsoft.CommerceServer.Runtime;
using Microsoft.CommerceServer.Runtime.Profiles;
using Microsoft.CommerceServer.Runtime.Catalog;
// code to create object instances, etc.
.
// userProfile is the current UserObject profile
// myCatalog is a valid ProductCatalog object
myCatalog.ActiveLanguage = userProfile["Preferred_Language"];
Any language-specific properties of the catalog will now be in the language you've defined.
To implement a multicurrency catalog, you must use virtual catalogs. The first step is to define the currency of each virtual catalog in the catalog properties. You must then create the pricing rules for the products in the catalog. You can choose between two approaches. The first approach is to create pricing rules that dynamically set the product price by applying a conversion factor to all products. You can set the conversion factor manually, or you can retrieve it from a lookup table that is periodically updated. The second method of setting pricing is to manually set and maintain the price for every product. The disadvantage of this method is clear: if you have a large product catalog, you have a lot of work ahead of you to set all the prices and maintain them as both product prices and currency exchange rates fluctuate. However, the advantage of setting the prices manually is that you have absolute control over the prices. An important part of sales is pricing products attractively at numbers like $5.99 or $29.95 or simple round numbers. You must write some complex rounding logic to achieve such prices. Commerce Server dynamically calculates the prices, but you'll never have the control you would have by setting the prices manually.
Building Catalogs for the Enterprise
Enterprise-level companies face additional challenges in the design of their catalogs. Two key challenges are providing catalogs to trading partners and working with external point of sale (POS) systems.
Providing Catalogs to Trading Partners
If you're a supplier of any size, you'll need a way to provide your catalog to your distributors. If your company is small and you have few items in your catalog or the items do not change frequently, you can probably get away with exporting your catalog and transmitting it electronically to the distributors on a scheduled basis. Commerce Server provides export functionality for catalogs: you can choose Export from the toolbar in the Catalog Editor or Catalog Sets modules and choose to export the catalog in XML or as a comma-separated value (CSV) file. Commerce Server 2002 also allows incremental exports. You can define the export date, and the file will include only changes to the catalog and products since that date.
If you want to export a subset of the products in the catalog, you should create a virtual catalog containing only the products you want to provide. When you export a virtual catalog, Commerce Server will export it just like a base catalog. If you reimport the XML file, Commerce Server will create a base catalog. Any pricing rules will be lost. The export file will include the prices with the pricing rules applied, but the prices will be absolute, not calculated from the base catalog prices.
Exporting the catalog is fine for the majority of supplier scenarios. However, if you're an enterprise company, if you have multiple distributors, or if your catalog changes frequently, you'll need to move beyond a simple export and transmit implementation. One approach you can take is to add Microsoft BizTalk Server to broker the catalog exchange between you and your trading partners. BizTalk Server will allow you to automate the process and will help with any data transformation needed.
If you're acting strictly as a supplier—if you export your catalog to distributors but you don't need to import other partners' catalogs—you should consider creating a Web service for your catalog rather than a scheduled export. One advantage of a Web service is that the catalog is always up-to-date; you don't have to send a new export file every time a product changes. A Web service relieves you of the task of sending the catalog to your distributors. They have the responsibility for retrieving it. It also gives distributors more flexibility: they do not have to maintain a copy of your catalog on their system because they'll have ready access to the live data in your system. A Web service does require that your distributors comply with your data format, but if you're an enterprise-level company, you can act as the 800-pound gorilla and force compliance by distributors who want to do business with you. If you cannot force compliance, you can assist distributors with data transformation, using either BizTalk Server or a custom implementation.
With Microsoft .NET and the .NET-compatibility of Commerce Server 2002, creating a Web service for your catalog is not overly complex. The Web service will effectively be a wrapper for the Commerce Server catalog API, exposing the minimum methods a distributor would need to retrieve your catalog data. For example, the Web service should expose the following data:
- A list of all catalogs available to the user
- A list of all categories and child categories (a category tree) for a specified catalog
- A list of all products within each category for a specified catalog
- A list of product properties for a specified catalog
With this Web service, distributors can access the data in your catalog and use it in the way that best matches their own business model. Distributors can import the catalog into their own catalog or display the data directly on their Web site. The following Code Candy sidebar introduces a sample catalog Web service.
Integrating Your Catalog with an External System
Companies of any size, but particularly enterprise-size companies, might have an external POS system that manages products and inventory. The Commerce Server catalog is an effective catalog for e-business distribution, but it might not have the features you need for a full-scale POS system or other applications. On the other hand, the Commerce Server catalog provides many Web-only features that are probably not part of the POS system, such as product images and category navigation. If you cannot replace your POS system with Commerce Server, your best option is to implement a hybrid approach where you maintain some data in the POS catalog and some in the Commerce Server catalog. To minimize issues with data synchronization, we recommend that you choose one catalog to be the master catalog and always add or delete products from the master and propagate changes to the other catalog. One-way synchronization is always simpler than two-way, because you do not need to consider merging changes from multiple sources.In most cases, the POS catalog will be the master because the Commerce Server application will probably be easier to modify. You should evaluate the relative costs and benefits of both approaches for your situation. The following steps assume that the POS catalog will be the master, but you can simply reverse the direction of the steps if you want the Commerce Server catalog to be the master:
- Determine what data from the POS catalog you'll need in the Commerce Server catalog.
- Create your product definition with fields for the pertinent data from the POS catalog, as well as any fields you'll need for your commerce site. Fields that will contain data imported from the POS system should not be editable from within Business Desk.
- Write data load routines for adding new products, updating existing products, and deleting products.
- Implement a strategy for these routines. Will they be scheduled, on demand, or triggered by a change to the POS catalog?
- Maintain Commerce Server-only data using Business Desk.
You can import catalog data from your POS or external catalog system using several methods, including importing XML or CSV or scripting the API. The best method in our experience is to export your external system data in XML and then import it into the Commerce Server catalog system.
Summary
In this chapter, we discussed designing and creating the product catalog for a commerce site. To create the catalog definition, we first defined the catalog properties. With these properties, we created the category definitions and product definitions. In particular, we looked at various pricing strategies for products. Product variants, sales, and product sets all add complexity to the pricing model. We also considered different types of catalogs, such as base catalogs, virtual catalogs, and catalogs sets, and the uses for each, such as limiting access to specific categories or products and creating multilingual and multicurrency catalogs. We concluded with some special considerations for enterprise-level catalogs such as catalog exchange and integration with external systems.The Commerce Server catalog is a powerful system for managing large catalogs. However, it does not directly address the challenge of managing the assets that go along with the products, such as product images. We'll look at tools for managing this content in the next chapter.
Last Updated: March 11, 2003
| Top of Page |