Microsoft Commerce Server 2000 Catalog Management System: Criteria for Selecting a Catalog Management System

 

Philip Reilly
Senior Consultant, Microsoft Consulting Services

May 2001

Summary: Microsoft Commerce Server 2000's flexibility leads to the following question: "When should a business use Commerce Server's catalog management system, and when should it use an external catalog system?"

This article attempts to answer the question by providing a description of the integrated catalog management system, and offering a set of criteria that should be evaluated to determine whether a business should consider an external catalog system. (50 printed pages)

Contents

Executive Summary
Introduction
Commerce Server 2000 Catalog Management System
Catalog System Planning
Catalog Management Options
Third-Party Catalog Management Systems
Scenarios
Integrating an External Catalog Management System
Conclusions
Appendix: Sample Code

Executive Summary

Microsoft® Commerce Server 2000 provides an integrated catalog management system that enables businesses to define the schema and manage the contents of their catalogs. The catalog management system provides considerable flexibility, scalability, high performance, and a simple, uniform management interface.

Commerce Server 2000 provides an open, extensible, and flexible framework for developing commerce solutions. This approach was adopted for two reasons:

• To enable businesses to customize and extend Commerce Server in order to meet unique business requirements
• To enable integration with existing systems

This approach allows Commerce Server to function using either its integrated catalog management system, or an external catalog system.

Furthermore, a number of software vendors have focused on creating standalone catalog management systems. Commerce Server's flexibility enables businesses to integrate these third-party catalog systems into an overall solution.

Because of Commerce Server 2000's flexibility, the following question arises: "When should a business use Commerce Server's catalog management system, and when should it use an external catalog system?"

This article attempts to answer the question by providing a description of the integrated catalog management system, and offering a set of criteria that should be evaluated to determine whether a business should consider an external catalog system.

Introduction

Background

Commerce Server 2000 represents the next generation of commerce platforms. Its lineage can be traced to Microsoft's previous commerce platform, Site Server. However, Commerce Server has been significantly extended and focused when compared to Site Server.

Commerce Server 2000 is designed to provide a simpler, less time-consuming environment within which to build customized e-commerce solutions. The underlying application framework, integrated feedback mechanisms, and analytical capabilities enable developers to quickly develop e-commerce sites that satisfy three key business goals:

• Optimize the customer experience
• Encourage repeat business
• Forge tighter partner relationships

Commerce Server 2000 provides the necessary infrastructure to build an online business. User profiling and management, product and service management, transaction processing, and targeted marketing and merchandising are integrated to create a system customizable for specific requirements. Functionality is combined to manage product and client information, and to streamline and refine online business processes. The Profile, Targeting, Product Catalog, and Business Process Pipelines systems function together to enhance the customer experience by delivering one-to-one marketing capabilities.

Commerce Server 2000 reduces the complexity and time required to build, deploy, and maintain commerce solutions. Commerce Server provides a set of solution sites, a software development kit (SDK), and administrative tools to simplify the development process.

Business users have the ability to control the operation of their sites through the integrated Business Desk. This enables the business to close the loop with customers and partners by giving them both the decision support processes and data they need in real-time. By closing the loop, businesses can offer highly personalized and relevant content to customers.

One of the most significant changes between Commerce Server and Site Server is the integrated Catalog Management System. The catalog provides the ability to create customized product catalogs that can then be used by customers to browse, search and buy. The catalog system is also integrated with the other Commerce Server systems to enable a broad range of additional capabilities.

Intended Audience

This article is intended for application designers and architects attempting to design an environment capable of supporting the e-business requirements of their business sponsors and stakeholders.

The article provides a detailed description of the functionality available within the Commerce Server catalog. It then provides criteria that can be used to help determine whether the Commerce Server catalog, or an external catalog system, will best satisfy the requirements.

Finally, the article describes the steps necessary to integrate an external catalog with Commerce Server, should your business select an external system.

Commerce Server 2000 Catalog Management System

Architecture

Structure

The Commerce Server Catalog Management System consists of two main functional areas:

• Catalog Schema Designer. Provides the functionality to describe the categories and products in terms of their constituent properties. The catalog schema is available to all catalogs in the site.
• Catalog Editor. Enables the creation and maintenance of catalog instances that contain product information and a physical navigational hierarchy. Each instance represents an implementation of the catalog schema.

Schema

The catalog schema describes the characteristics of the categories and products in a particular type of catalog. The catalog schema can be managed through the Catalog Designer module in the Business Desk, or programmatically via the Catalog Management API.

The catalog schema consists of category definitions, product definition, and property definitions (defined below). Category definitions and product definitions are created using the property definitions.

Category definitions

Describe the specific qualities of the categories in a catalog. These category qualities are called category properties. Category definitions are created using category properties. For example, the Department category definition might have the following category properties: Name, Description, Image File Name, Image Height, and Image Width.

• Product definitions
  Describe the specific qualities of a particular product. These product qualities are called product properties. Product definitions are created using product properties. For example, the product definition "Shirt" could include three product properties: Name, Manufacturer, and Price.
• Property definitions
  Used to create product properties and category properties. A property definition describes information about the property, such as the data type, name, and minimum value.

Catalog schemas can be changed. A catalog schema can be edited even after a catalog contains data.

Catalogs

A catalog is an instance of a catalog schema that contains data about individual products and the categories in which they are organized. A catalog can be created using the Catalog Editor module in Business Desk, or programmatically via the Catalog API.

A catalog consists of four elements:

• Categories. Individual instances of a category definition. For example, a category definition named "Department" might be used to create the category "Soccer Shirts."
• Products. Represent items for sale within the catalog. A product is defined by a combination of property definitions. For example, if a product definition named "Soccer Shirts" has the properties Name, Color, and Size, then an instance of such a product would have a value for name, color, and size. Products can be arranged into groups of closely related items, called product families. A product family contains product variants (see below for definition).
• Properties. Used to define a product within the catalog. (See also "Property definitions" in the section above.)
• Product variants. Represent unique identifiers for a product family. For example, a large-sized, green shirt with the SKU 114 is one product variant of the "Soccer Shirt" product; size, color, and SKU combine to form this one variant. Each product variant is based on the same product definition.

Catalog organization: Hierarchies and relationships

To organize the products within a catalog and make navigation easier, category hierarchies and relationships can be defined among categories and products. For example, a parent category could include two different categories, known as child categories. When customers navigate to the parent category, the child categories are displayed, enabling customers to locate products.

Product identifiers

Products and product variants have unique identifiers. The unique identifiers are either a text or number type of property. For example, the title of a book might be the unique identifier for the product, and the ISBN number might be the unique identifier for the variant.

When a catalog is created, the unique identifiers for the products and variants must be specified.

Base catalogs, custom catalogs, and catalog sets

Two types of catalog can be created: base and custom catalogs. Catalogs can also be combined into catalog sets.

Base catalogs contain categories and products, but do not contain any specific pricing rules.

Custom catalogs are derived from base catalogs, and contain specific pricing rules for the products within the catalog. The prices in a custom catalog override the prices in a base catalog. Custom catalogs can be used to give one or more customers a custom price on certain products.

Catalog sets are created to control the catalogs a customer can access. A catalog set is a group of one or more catalogs that can be assigned to a customer. The catalog set a customer can access is defined via the Users or Organizations module in the Business Desk.

Capabilities

Catalog exchange

The Catalog Management System provides functionality that enables catalog data to be imported, exported, and exchanged. Catalog data can be imported and exported in either XML or comma-separated format. The XML format conforms to a published XML Schema to ensure the validity of imported and exported data. The schema is available for download from the Biztalk community site.

The import and export process can be initiated manually via the Business Desk, or programmatically, using the CatalogManager component. When using the manual approach, it is important to remember that the catalog file must be located on the server hosting the Business Desk application—not on the client machine accessing the Business Desk. Commerce Server automatically creates a folder share called commercecatalogs to facilitate the upload of catalog files.

Biztalk Server can be used to further enhance the catalog exchange functionality. Biztalks data transfer and transformation capabilities can be used to exchange catalogs with business partners even when catalog formats differ. Biztalk also provides extensive management, tracking, and monitoring functionality to ensure catalogs are exchanged correctly and efficiently.

The Commerce Server 2000 solution sites provide a sample ASP page called "ReceiveStandard.asp" that illustrates how catalogs can be received from business partners via HTTP. This page invokes a Biztalk channel to process the received catalog.

Pricing methods

The catalog management system provides three methods to price products:

• Direct pricing. The price of a product is specified in the product definition. For products that have variants, direct pricing can be applied to each variant.
• Indirect pricing. The price is determined by the associated category. When a product is associated with a category defined as a pricing category, the price on the product is replaced by the price defined on the category.
• Custom pricing. This involves creating a custom catalog. There are three types of custom pricing that can be applied via a custom catalog:
  • Percentage adjustment. The percentage of the list price that should be charged.
  • Fixed adjustment. The exact amount to increase or decrease the list price.
  • Set Price. The exact price of the product.

Note   When a price modifier is specified on a category, the modifier applies to all products in the category. If a product belongs to two categories with conflicting price modifiers, the price of the product will not be changed and a warning message will be written to the Application Log in Windows Event Viewer to indicate a conflict.

In addition to the methods described above, product prices can be adjusted using campaign item discounts. This enables dynamic, customer-specific pricing to be applied to products in real-time.

Business analysis

The catalog management system is integrated into Commerce Server's analysis system. At the core of the analysis system is a data warehouse. The data warehouse provides a logical and physical view of the catalog for reporting purposes. A number of pre-defined static and dynamic reports are provided that leverage the catalog information within the data warehouse.

Importing catalog information into the data warehouse is automated through the use of a SQL Server data transformation service (DTS) task. This functionality enables a business to start analyzing the effectiveness of their commerce site as soon as it is deployed.

In addition to reporting functionality, the business analysis system provides a prediction engine and segment modeler. The prediction engine allows businesses to create customer-specific product recommendations based on the contents of the customer's basket and their order history within the data warehouse.

The segment modeler allows businesses to classify customers based upon order history. This can be used to identify customers with similar characteristics. This information can then be used to refine customer profiles and create customer groups that can be targeted within the targeting system.

Application programming interface (API)

The Commerce Server Business Desk, which is available for installation with every Commerce Server-developed site, is the main catalog management system interface for business users. However, functionality exposed via the Business Desk can also be accessed programmatically via the catalog management system APIs.

The primary component used to design catalogs is the CatalogManager. This component provides methods to manage property, product, and category definitions. It is also used to create and manage catalog instances. A series of other components can then be used to maintain and access catalogs. These components include:

• CatalogToVendorAssociation. Enables a catalog to be associated with a particular vendor. This association is used to integrate Commerce Server with Biztalk Server, allowing for catalogs to be exchanged with partner organizations.
• CatalogSets. Provides management functionality for catalog sets. Catalog sets are used to present different groups of catalogs to different types of customer. Once created, a catalog set can be associated with a customer or a customer's organization.
• Category. Categories are used to define a navigational structure to a catalog. Categories are created using the ProductCatalog component. The Category component is used to define the position of a category within the catalog hierarchy and to associate products to the category.
• Product. The product component provides access to the properties of a product. It is also used to define the product's position within the catalog and category hierarchy.
• ProductCatalog. The ProductCatalog is the primary component used to manage and access a catalog. In addition, it provides methods to perform a specification search of the catalog's contents. A specification search is a means of searching a catalog based on customer-entered values for those properties that have been defined as searchable.
• QueryCatalogInfo. QueryCatalogInfo is a pipeline component specifically designed to provide a high performing, scalable interface between the catalog management system and the order processing system. The component provides a means of caching product information, reducing the need to repeatedly query the catalog database for product information.

Caching architecture

Commerce Server provides components that allow sites to make extensive use of server-side caching to improve performance and scalability. The previously-mentioned pipeline component, QueryCatalogInfo, is an example of a component that uses caching.

At the core of the caching architecture is the CacheManager component. The use of this component is demonstrated exhaustively in the solution sites. In terms of the catalog management system, one of the most significant examples of caching is the caching of the HTML content generated to display catalog pages.

Campaign integration

The targeting system enables business users to create campaign items, such as advertisements and discounts, which target particular customers and products. The targeting is performed by the use of expressions. These expressions are evaluated at run-time to determine whether a campaign item should be invoked.

To support the creation of the expressions, the Business Desk provides an expression builder. For catalog-related expressions, the builder provides business users with a point-and-click interface to the properties of the catalogs and the products within the catalogs. This makes the creation of catalog-related expressions simple, fast, and less error prone.

Once the expressions have been created, they can be associated to campaign items to control the triggering of the items. During the normal operation of the commerce site the expressions related to the campaign items will be evaluated using the content selection framework and the order processing system. Both systems use pipelines to control the evaluation of the expressions and the application of the campaign items.

The pipelines enable product information, such as the product being browsed or added to the basket, to be input to processing. This product information is then used to determine whether the expressions evaluate to true and, therefore, whether the campaign item should be applied.

Business Desk modules

The maintenance of a Commerce Server site is performed through the Business Desk. The Business Desk is a Web-based application that provides business users with access to the commerce site's various systems.

The catalog system provides a catalog maintenance module with the following sub-modules:

• Catalog Designer. Used to maintain the definitions of the categories, products and properties that the catalog management system will allow to be used to create catalogs.
• Catalog Editor. Used to create catalogs. Once a catalog has been created it can be populated with products and categories that conform to the definitions defined within the catalog designer module. The hierarchical relationship between products and categories is maintained through this module. The deployment and construction of the associated full-text search catalog is also controlled via this module. This module also enables the creation of custom catalogs. Custom catalogs are versions of a base catalog with revised pricing. Custom catalogs enable the business to offer different levels of pricing to different types of customer. Pricing changes are applied at the category level.
• Catalog Sets. Allows the business user to define combinations of catalogs that can be applied to different classes or types of customer.
• Users/Organizations. The user and organization modules within the Business Desk allow the business user to associate particular catalog sets to particular users and/or organizations.

Search methods

The Catalog System provides a number of methods for searching catalogs, including property-based or free-text searches. The Catalog System search functionality is implemented within both the solution sites and the Business Desk catalog module. The Business Desk catalog module enables products to be located within a catalog using keyword or property based searches. The persistent left-side navigation bar on the solution sites provides access to the full-text and specification search functionality.

Property-based search

The property-based search functionality can be used to perform specification searches, which allows for a progressive drill-down search of products by specifying parameter constraints, such as a category, product, or property. Specification searches are performed by progressively reducing the number of products that match search criteria. The ProductCatalog component provides the necessary methods to construct and perform a specification search. In order for a product property to be included within a specification search its specification search property must be set to true.

The CatalogManager component provides the Query method for performing property searches. In this case the property searches are implemented as SQL-like WHERE clauses.

Free-text search

The free-text search functionality uses a SQL Server full-text catalog index, related to the catalog's product table. The product properties defined as being "free-text searchable" are added to the full-text catalog index definition. Whenever the catalog's content is updated the full-text catalog index must also be updated to reflect the changes. The CatalogManager component provides the FreeTextSearch method for performing free-text searches.

Scalability

In terms of the catalog management system, scalability can be defined as the system's ability to support both larger catalogs, and more concurrent customers. As a consequence of the catalog management system's design, and its ability to leverage the capabilities of other Microsoft products, the system provides both scale up and scale out options.

Scale Up

Scaling up involves utilizing hardware with greater capacity in order to be able to support larger catalogs, and more concurrent customers.

As a result of Commerce Server's support for SQL Server 2000, and the fact that SQL Server 2000 is certified for Windows 2000 Datacenter, it is possible to host the catalog system's database on a server with 32 processors and 64 GB RAM. Not only does this provide considerable scalability, it also provides significant availability benefits, resulting from the certification requirements demanded by the Microsoft Datacenter program.

Scale Out

Scaling out involves utilizing a combined hardware and software based solution to scalability. Multiple, independent hardware devices are combined through the use of software to provide a level of scalability, which can extend far beyond what a single hardware device can achieve.

Due to Commerce Server's support for Windows 2000 Advanced Server, the integrated Network Load Balancing (NLBS) software can be used to combine the capacity of multiple servers in order to achieve higher levels of scalability. Typically, NLBS is used with Commerce Server to create a farm of Web servers, which together provide very high levels of scalability and availability.

This approach can be extended to the data tier of a Commerce Server application in order to increase the scalability of the catalog system. This solution takes advantage of the fact that a typical commerce site will only need to provide a read-only version of its catalog to customers.

The solution involves using NLBS to create a farm of database servers. Each database server hosts a complete instance of the catalog system's database. During normal operation the Web servers forward catalog data requests to the farm of database server. NLBS load balances the requests across the farm of databases enabling a significant increase in scalability.

For such an approach to work, a read/write instance of the catalog database will be required to enable business users to update the catalog. This read/write instance can be used to update the farm of catalog databases through replication or DTS.

Catalog System Planning

Considerations

The following topics are designed to assist a project team in determining whether to utilize the Commerce Server Catalog Management System, or to adopt a custom, or third-party solution.

Project scope

If the scope of your project does not include the product catalog, then you'll need to develop a method of integrating with whatever catalog exists.

Generally, any e-commerce development project would include the product catalog. However, within some organizations, roles and responsibilities are such that different groups are responsible for particular aspects of the overall system.

Tactical verses strategic

Many businesses have traditionally operated within a supply chain that has limited their exposure to customers. Internal processes and systems have been developed to support this business strategy. Thanks to the Internet, there are now more opportunities and channels to businesses.

However, effectively realizing the benefits of these opportunities often requires extensive redevelopment of internal systems. This fact, coupled with the need to remain competitive, may require a business to move rapidly in adopting the Internet as a channel.

These challenges can often force a business to take a near-term tactical rather than strategic view of their business. In such a case it may be more appropriate to leverage a packaged solution, such as the Commerce Server Catalog Management System, rather than to attempt to develop a custom solution.

Customer account integration

For certain businesses it is essential that a long-term relationship be established with the customer. For example, a cable or phone company will need to establish an account for each and every customer they serve. This account will include details of the products and services they have already acquired from the business, and the recurring charges that the customer is required to pay.

In some cases the products and services that the customer has already acquired will need to be factored into determining what a customer can purchase in the future. The customer may be required to replace or discard existing products or services before being able to make a new purchase.

Integrating the Commerce Server Catalog Management System and user profiling system would allow a business to support customer account integration. However, the catalog API does not directly permit the filtering of products based on custom account information.

Required pricing flexibility

The Commerce Server Catalog Management System provides a number of methods for determining the price of a product that a customer will be charged.

For some businesses, however, product pricing rules are extremely complicated and will require either custom development, or a third-party catalog system.

International requirements

The Commerce Server Catalog Management System does not directly support internationalization. Internationalization can be defined as the ability of businesses to provide equal levels of support to customers located within different regions of the world.

From a catalog perspective this would include support for multiple languages, currencies and internationalized product collateral. (Product collateral includes technical and marketing information associated with the product within the catalog. For example, URLs to images and static pages describing a product's features.) The Commerce Server catalog does not directly support modifying the presentation of product information based on the customer's nationality, region, or language preference.

However, Commerce Server does provide support for internationalization through the use of the message manager component and EuroDisplay component. Combining these components with the catalog API could be used as a means of supporting internationalization. The Commerce Server resource kit describes a method of applying this approach.

Regulatory, state and federal considerations

Some businesses operate in highly regulated markets that require the application of complex rules that can directly impact the products and prices that can be offered to customers.

Generally, it is advisable to attempt to apply any complex business rules to the catalog at the time it is created. For example, if rules exist limiting which products or categories can be sold in certain states, standalone catalogs could be created to reflect the availability of products by state. At run-time the customer would be directed to the appropriate category or catalog based upon their location. Such a solution could potentially lead to larger catalogs, or even duplicated product entries. However, the performance benefits and simplified processing may offset any disadvantages.

If it is necessary to apply complex business rules at run-time, custom coding will need to be applied to the Commerce Server Catalog Management System interfaces. The custom code would modify and filter the products and prices returned by the standard catalog system components.

Catalog size

Catalogs can become extremely large, containing many millions of products. The ability to support very large catalogs means far more than simply being able to physically store the products within a database. The following factors must also be addressed:

• Manageability. This includes the ability to load catalogs, and edit catalog contents once the catalog is deployed. The interfaces into the catalog must enable both bulk maintenance operations, and product level modifications to be performed. As the catalog's size increases the ability to maintain the catalog must be retained.
• Searching. The ability to locate products based on parameter or full-text queries. The catalog system must provide functionality to enable the development of search interfaces that can adequately control the scope of searches, limiting the impact of a broad search on the overall system.
• Browsing. The ability to navigate through the catalog hierarchy to the product level. The catalog system must provide interfaces that allow the navigation process to be controlled. For example, limiting the number of items returned at each level and paging for large result sets.
• Analysis/reporting. The ability to import, transform and analyze the catalog data within the data warehouse. This includes the creation of OLAP cubes,******and reports containing catalog information. The system must support incremental updates of the data warehouse, and refreshes of the OLAP cubes to reduce processing time.
• Operations. The infrastructure supporting the catalog must be able to backup and recover the catalog within a reasonable timeframe. In addition, the infrastructure should provide the flexibility to scale, both vertically and horizontally, without disrupting the operation of the commerce site. Integrated monitoring should also be available to support monitoring, capacity planning, performance and availability analysis.

At the core of Commerce Server's catalog system is the SQL Server 2000 database management system. The ability of the catalog management system to support very large catalogs is dependent upon SQL Server's ability to support very large databases. SQL Server 2000 has already demonstrated its ability to scale to support databases exceeding multiple terabytes in size, while still providing high speed, concurrent access.

The catalog system leverages SQL Server allowing the catalog database to be isolated onto its own database server. Further, the catalog system allows for a distributed design, whereby the catalog is maintained in one database, while it is viewed in other databases. The data is synchronized through the use of replication.

During the development of Commerce Server, extensive scalability testing was performed to ensure that the catalog management system was able to support very large catalogs.

Regardless of the catalog solution chosen adequate time must be reserved for testing the performance and scalability of the system.

Number of catalogs

Commerce Server allows up to 256 catalogs to be supported on a single database server. Each catalog is represented physically as a set of three database tables. These tables contain the products and categories and also define the hierarchical structure of the catalog.

The number of full-text search indexes that SQL Server can support on a single database server limits the number of catalogs. This limitation could be overcome by the use of multiple database servers. However, such a solution would necessitate custom coding.

An alternative method to overcoming this limitation is to disable full-text searching. The catalog can still be searched using the CatalogManager Query and ProductCatalog specification search methods, even with full-text searching disabled. If this approach is adopted, careful testing should be performed to ensure that the environment remains manageable in terms of both maintaining catalog content, and managing the underlying database. The actual maximum number of catalogs that can be supported will be a product of the size of the catalogs and the rate of access to the catalogs. Again, this will need to be tested to determine the practical maximum number of catalogs that a system can support.

Product availability rules

Product availability is usually related to inventory. However, for some businesses availability can be related to other factors such as a customer's location.

For example, export regulations restrict what companies can sell to customers located in different countries around the world. Furthermore, the physical capabilities of a business' infrastructure can limit what they can provision in different parts of the world.

Accounting for such rules will require custom development. Determining whether the Commerce Server catalog can be included as part of such a solution requires evaluation of the particular business requirements.

Types of pricing

The Commerce Server Catalog Management System enables products to be priced both directly and indirectly. Direct pricing involves applying prices to the products and product variants, whereas indirect pricing involves adjusting a product's price by its placement in a pricing category, or custom catalog. The Pricing methods section provides more information on pricing functionality within the catalog system.

In addition, a product's price can be adjusted by the application of a discount. Discounts can be created via the targeting system to provide dynamic customer pricing. The catalog system does not provide a means of applying pricing rules other than by discounts.

System migration

Many businesses are already redeveloping aspects of the e-commerce infrastructure. Consequently, issues of migration will need to be considered during the project-planning phase.

Depending upon the business requirements, and the realities of the existing environment, it may be necessary to adopt a phased approach to the redevelopment process. In such a scenario, integrating with an existing catalog system may be necessary.

Product constraints

The products and services offered by businesses can be related in fairly complicated ways. Commerce Server provides the ability to group and relate products through the use of categories and related products.

Categories could be used to define the set of products that must be purchased together. For example, providing DSL service requires a DSL modem, Ethernet card, phone jack and splitter. In this case the category would be DSL service and the products within the category would those required to provide the service.

Custom development would be required to perform such actions as ensuring that a customer didn't already own any of the required products, or that they were not already part of the existing order.

Constraints can also involve defining the products that cannot be purchased or owned together. In this case, the Commerce Server-related products feature could be used.

Should these features not support the level of complexity that the business needs to support, then a custom or third-party solution would need to be adopted.

Product bundles

Commerce Server provides two methods of associating products for bundling purposes.

First, those products that form a bundle could be placed into a category that represents the bundle. Custom coding could be used to allow customers to select the "bundle" category; this would add each of the products within the category to the customer's basket.

Second, the catalog system allows products to be associated with other products using the related products functionality. This functionality could be used to allow a customer to select "add a product;" this would add the related products to the customer's basket.

Generally, handling product bundles requires further control, such as preventing a customer from removing one or more of the constituent products from their basket without removing the entire bundle, or ensuring that a customer does not already have one of the constituent products in their basket. Custom coding is required to handle such scenarios.

Product configurations

The ability to configure a product is often provided by companies that sell complex products, such as personal computers or automobiles.

The complexity of the configuration process will vary from company to company and product to product. Generally, the configuration process will involve providing the customer with multiple sets of optional sub-products from which they can select. In some cases, the configuration process must be able to filter the different sets of options to ensure invalid configurations are not accepted. In addition, once a configuration has been performed, further checks may be needed to ensure the customer did not select an invalid configuration.

The catalog system can be used to present and group products for product configuration. There is no functionality at this time, however, to enable rules to be applied to sets of products in order to control configurations.

Decision Process

The areas for consideration described above should be taken into account during any decision making process. However, the level of emphasis placed on any of the items will depend on a business's particular requirements.

Deciding whether or not the Commerce Server Catalog Management System will form part of the commerce solution may be a simple or complex process. If necessary, a pilot or sub-project could be performed to investigate the items described above, as well as investigating a business' specific, catalog-related requirements.

The following is a recommended list of tasks that should form part of any such pilot or sub-project.

• Requirements. Understanding the requirements of the different groups affected by the catalog management system is essential to being able to make an effective judgment as to whether the Commerce Server catalog will be employed, or an alternative solution adopted.

  • Business. The business stakeholders must be consulted to gather the business-related catalog requirements. A comprehensive understanding of what the business needs to do with the catalog is essential input to the pilot process. Ideally, members of the business community should be included in the pilot process to help avoid misunderstandings and to increase commitment.
  • Operational. The requirements of the groups that will be involved in implementing, maintaining and monitoring the catalog system need to be included in the requirements gathering process to ensure the practicality of the resulting system.
  • Technical. The development teams that will be involved in actually constructing the catalog system or developing a solution based on the catalog system, must be included in the requirements gathering process. It is important to ensure that the development team is able to provide input relating to their ability to create a catalog solution.

• Classify and prioritize. Once the requirements have been gathered they should be classified and prioritized. It is possible that some of the requirements will conflict and very likely that individual requirements will represent very different levels of benefit. Understanding the importance of the requirements, as well as eliminating contradictory requirements, will allow a consolidated set of requirements to be generated. Any decision process can then be based upon these requirements. It is important to ensure that all involved business stakeholders ultimately agree upon the consolidated set of requirements to ensure that the final decision is relevant.

• Define alternatives. A shortlist of alternative approaches should be created that can be evaluated within an acceptable timeframe and at an acceptable cost. These alternatives can then be evaluated during a pilot or assessment process.

• Pilot and assessment. The most effective way to determine whether an alternative solution satisfies the stated requirements is to perform a pilot. The pilot would involve actually creating a solution, which can then be tested to measure its ability to satisfy the requirements. Consideration needs to be given to the pilot's scope. Will it involve a full or partial implementation of the catalog system? Generally, time and cost constraints will limit the scope. In such cases, the results of the pilot need to reflect this fact.

  It is also possible to leverage aspects of the pilot in the final catalog solution. However, care needs to be taken to ensure that this does not undermine the resulting reliability and scalability of the system.

  In those cases where it is not feasible to perform a pilot, an assessment of the alternative solution can be performed. This would involve performing a review of different information sources in an attempt to determine the alternative solution's ability to satisfy the requirements. Vendors can often provide references, demonstrations, and samples to illustrate the their products' abilities. However, considerable care needs to be taken to ensure that when translating the results of any assessment, assumptions are kept to a minimum.

• Classify alternatives. Based upon the findings of the pilot each alternative approach can be classified in terms of its ability to satisfy the requirements, taking into account the underlying effort and cost involved.

• Decision milestone. Deciding which of the alternatives to adopt should involve a formal sign-off by all affected parties. At a minimum, the business stakeholders, project team management, and contributors to the requirements should be involved in the final review and decision process.

• Planning. Once the decision has been made the impact of the decision needs to be reflected in the overall project plan. The tasks necessary to implement the chosen path need to be incorporated into the project plan, with appropriate resources and dependencies identified. It is possible that the overall project's timeline, or resource requirements will need to be adjusted to reflect the catalog approach.

Catalog Management Options

Commerce Server 2000 Catalog Management System

The simplest and quickest approach to providing a catalog solution is to adopt the Commerce Server Catalog Management System. When assessing the capabilities of the Commerce Server Catalog Management System consideration should also be given to external influences, such as time to market, maintenance, and support.

The Commerce Server Catalog Management System has been designed and developed as an integrated sub-system of the overall Commerce Server product. It has been deployed and tested by Microsoft and a large number of businesses. Consequently, the development cycle for a solution using the Commerce Server Catalog Management System will be somewhat shorter than one that uses an alternative solution. Time to market will, therefore, be quicker.

Additionally, a series of pre-built modules and components exist to enable business users to maintain the content and structure of the catalog without IT involvement.

Finally, as a fully supported core component of Commerce Server, the catalog system will be extended, maintained, and supported by Microsoft, through service packs and future releases.

Custom Solution

If it is decided that the business requirements for the catalog are best met by implementing a custom catalog management system, a number of tasks will need to be performed to integrate the custom catalog into Commerce Server. These tasks are described below in Integrating an External Catalog Management System.

During the development cycle sufficient time should be allocated to testing the functionality, robustness, and scalability of the custom solution. In addition, the integration points between Commerce Server and the custom solution should receive particular attention to ensure correctness.

Third-Party Solution

A number of third-party catalog management systems are available. A number of these products have been designed to integrate directly into Commerce Server.

Two such catalog systems are those offered by Mercado and Cohera, described below in Third-Party Catalog Management Systems.

If a custom or third-party catalog system was adopted, the following standard Commerce Server features would no longer function, and would either need to be replaced, or re-enabled by integrating them with the custom catalog.

• Expression builder. The expression builder is used to create rules that can be applied to content, such as discounts and advertisements. The rules are evaluated at run-time to determine whether the content applies to a given situation. The expression builder enables business users to create rules based on the properties of the products within the catalog, and the products themselves. Should a custom catalog be adopted, the expression builder's interface to the catalog's schema and content would need to be modified to target the custom catalog.

• Business Desk catalog module. The catalog module within the Business Desk enables users to define the products' schema within the catalog, plus the catalog's navigational structure and contents. If this functionality is required, the code contained within this module would need to be modified to target the custom catalog.

• Selected analysis reports. A number of the static and dynamic reports provided with Commerce Server utilize catalog content loaded into the data warehouse. If a custom catalog is adopted, these reports would no longer provide product information. However, if the custom catalog's contents were loaded into the data warehouse, and the existing data warehouse schema for products was adopted, then these reports would still function.

  If an alternative data warehouse schema was adopted for the custom catalog, the reports could still be used by modifying their definition within the tables contained in the data warehouse. Rather than editing the existing Commerce Server report definitions, create copies of the definitions and edit them instead.

• Selected analysis cubes. A number of the OLAP cubes provided by Commerce Server include product-related dimensions. As with the analysis reports, these cubes would need to be adapted to accommodate the custom catalog.

• Catalog data transformation service [DTS] routine. The Catalog DTS routine is used to load the data warehouse with the contents of the Commerce Server catalog. A custom DTS routine would need to be developed to allow the custom catalog's contents to be loaded into the data warehouse.

• Catalog API. The Commerce Server catalog components that together form the catalog API are designed to provide access to the Commerce Server catalog. Should a custom catalog be adopted these components could no longer be used.

• Catalog sets. Catalog sets are groupings of catalogs, which can be associated to organizations and/or customers to control the products they can purchase. This is a feature of the Commerce Server catalog API that is leveraged by the profiling system.

• QueryCatalogInfo. This component is used within the basket pipeline to retrieve detailed product information from the catalog. The component is designed to provide very high performance and scalability when communicating with the Commerce Server catalog. It would need to be replaced by a custom component, or by the existing QueryProductInfoADO component, if a custom catalog was adopted.

Combination Catalog Management System

If an external catalog system is deemed necessary to meet the requirements of the business, consideration should be given to combining the external catalog with the Commerce Server Catalog Management System.

The Commerce Server Catalog Management System interfaces with a number of other Commerce Server systems to ease the development of an end-to-end solution. For example, when building catalog expressions within the campaign module, the available set of properties is dictated by the properties defined within the catalog designer.

The following is a list of the Commerce Server systems that interface with the catalog management system. Options are described for how the Commerce Server catalog management system could be used to simplify or compliment the use of an external catalog system.

Catalog navigation

The Commerce Server catalog management system provides an API for defining the structure of a catalog in terms of a hierarchy of categories. A further API is used at run-time to navigate this hierarchy. This functionality allows customer friendly, catalog navigation paths to be created.

Should the external catalog system lack a customer friendly structure, the Commerce Server catalog could be used to provide the upper level category hierarchy. Once a customer reaches a category containing products, the Commerce Server catalog could hand-off the request to the external catalog.

Targeting system

The catalog management system is used by the targeting system to aid the creation of campaign items and determine whether campaign items should be applied. The Business Desk campaign module provides access to both the catalog schema and catalog contents to enable business users to construct campaign items that target specific products, or types of products. During the operation of the site, the targeting system uses a number of pipeline components to determine whether campaign items, such as discounts, should be applied.

If an external catalog system is used, the targeting system can still be utilized. This can be done by replacing the interfaces between the targeting system and the catalog system, or by integrating the external catalog system with Commerce Server's catalog system.

For example, in order to enable the creation of campaign items that target the properties of products (for example, if a customer buys a product with a price over $100 then apply a 10% discount), the property definitions for the external catalog could be added to the Commerce Server catalog system.

To enable the creation of campaign items that target specific products (for example, present an advertisement for extended warranties if a customer views the ACME CD player), the identifiers for the specific products could be added to the Commerce Server catalog system on an as needed basis.

The evaluation of the campaign items is performed at run-time, and involves comparing the properties defined within the campaign item expressions to the properties of the products within the customer's basket, or the products being viewed. At this point the fact that the product information came from an external catalog is irrelevant.

Data warehouse

The Commerce Server data warehouse provides a pre-configured physical and logical schema for product information. By populating this schema, reports can be generated that include product-specific information. A SQL Server DTS routine is provided to import and transform product information from the Commerce Server catalog management system into the data warehouse.

The existing data warehouse schema can still be used with an external catalog management system. Custom routines would need to be written to import the custom catalog product information into the data warehouse. This process must use the Commerce Server OLE-DB provider to import the product data via the data warehouse logical class schema. If necessary, the data warehouse logical class schema can be extended using the same Commerce Server OLE-DB provider.

Adopting a combined catalog management solution raises the issue of synchronization between the catalog systems. Generally, in a combined model the external catalog would be the master in terms of data ownership.

Therefore, processes would be needed to update the Commerce Server catalog to reflect the content and structure of the external catalog system.

Should a combined catalog system approach be chosen, steps must be taken to ensure the catalog systems remain synchronized. This will involve considering both the catalog schema as well as the catalog contents. Generally, the schema will change infrequently, but the contents of the catalog may change daily.

To facilitate the integration of the Commerce Server catalog contents and the external catalog contents, a shared unique product identifier would need to be maintained between the systems. Custom coding would be required to maintain the integrity of the catalog system integration—that is, to ensure that both systems maintain a common set of products, or at least a common set of products available for sale.

Furthermore, one of the catalogs should be identified as the master product source, so that changes to the set of products available for sale is performed through only one of the catalog systems. Whenever a change is performed, the dependent system is updated to reflect the change. For example, if the external catalog is defined as the master and maintained through a nightly batch interface with a legacy system, after each nightly update, the Commerce Server catalog would then need to be updated to reflect any changes made to the external catalog.

Third-Party Catalog Management Systems

Mercado

Capabilities

Mercado offers a search solution called IntuiFind, which can be integrated into Commerce Server 2000 to enhance standard catalog search functionality. The IntuiFind technology can be integrated with Commerce Server with few modifications.

Architecture

The IntuiFind search functionality is based on a technology called the Mercado pyramid. The customer is not required to configure the Mercado pyramid in order to deploy IntuiFind. To support the administration of the product, Mercado provides an MMC Snap-In, which can be used to generate and refresh instances of the Mercado pyramid. The pyramid is based on the XML schema and data exported from Commerce Server 2000 by the Catalog Manager's Export XML method.

Pyramids are refreshed by a process called hot-swapping. On demand, or at scheduled intervals, a new version of the pyramid is created to replace the current version. When modifications are performed to the content of the catalog, Mercado's catalog component passes the requests to Commerce Server. This leads to the IntuiFind pyramid being out-of-sync with the Commerce Server catalog database. The customer controls the duration of the out of sync condition by scheduling pyramid refresh events using the Mercado MMC Snap-In.

Commerce server integration

Commerce Server integration is accomplished by call interception. All catalog requests are intercepted by Mercado's catalog component, which examines the request and either processes it as a search request or passes it through to Commerce Server.

Mercado implements two COM+ interfaces, ICatalogManager and IProductCatalog, that replace the standard Commerce Server 2000 implementations of these interfaces. The Mercado catalog component aggregates the Commerce Server 2000 implementations of ICatalogManager and IProductCatalog. This allows all calls from the application to be intercepted by Mercado code and either passed through to the aggregated Commerce Server 2000 interfaces or handled by Mercado.

Mercado offers a light version of the product to support the integration of IntuiFind with Commerce Server. The light version is bound to Commerce Server 2000's catalog schema. Applications that extend the catalog schema will need to be upgraded to the standard version of IntuiFind.

Cohera

Capabilities

Cohera's Catalog System is a set of services and tools for building, managing, and accessing multi-supplier online catalogs. The system is designed to support the needs of the marketplace and corporate exchanges. The system provides data integration, aggregation, and content management within a single catalog environment.

The Cohera system includes an information broker that provides data abstraction and integration services. The broker enables on-demand retrieval of catalog data from separate sources, and the integration of this data with static information.

Architecture

Cohera's architecture allows the Catalog System to be configured in either a centralized or distributed manner. This architecture supports both tight and loose integration between the marketplace and suppliers. The Catalog System is composed of three components:

• Hub. A set of software servers and tools that handle creating and maintaining catalogs. The Hub contains a number of modules that perform the following functions:
  • CatalogBuilder. Builds and administers the Hub. The Catalog System facilitates transformations via the Java-based CatalogBuilder. The catalog manager can map the suppliers' catalog structure onto the marketplace's catalog structure and define the transformation rules required to standardize the suppliers' product content with the marketplace's structure. These transformations are then applied when the products are retrieved from the suppliers' product catalog.
  • CatalogServer. Parses and optimizes incoming requests for catalog information.
  • Accelerator. Off loads resource-intensive integration, transformation, and aggregation work.
  • CacheServer. Holds frequently accessed catalog information.
  • PowerSearch. Provides search functionality across disparate but related product descriptions.
  • SiteManager. Retrieves data from supplier catalogs, and applies transformations to unify data. The SiteManager also enables the supplier to monitor the query activity against data sources, control access to data, and track what customers are searching for.
  • SecureNetwork. Provides encryption between the Cohera components and the Internet.
• CatalogWorkbench. Provides the tools necessary to build and manage the catalog and its content. CatalogWorkbench allows catalog managers to:
  • Define the catalog structure for the marketplace's catalog
  • Import, cleanse, and transform supplier products
  • Edit and review imported catalog content
  • Create and manage the taxonomy
• CoheraNetQuery. Converts HTML or XML Web data into a relational data source. CoheraNetQuery consists of a browser-based user interface and an ODBC/JDBC driver that enable the catalog manager to search for and retrieve data from a Web site. CoheraNetQuery allows catalog managers to:
  • Scrape HTML and XML data from Web sites
  • Define site maps for each Web site to guide the scraping operations
  • Use standard SQL to scrape Web data

The Catalog System allows the marketplace to define its product catalog, including pricing and product information, and then map that information to the product catalog, independent of where the data resides. If dynamic access is required, the map will point to the supplier catalogs. If access to static data is required, the map will point to the staged data located at the hub. When a buyer searches the catalog, the Catalog System will retrieve the product data based on the map and integrate it as needed.

The Catalog System allows suppliers to offer customized supplier and/or buyer views and pricing specials. It has the ability to take inconsistent SKUs from multiple suppliers and either maintain the supplier SKU or normalize the supplier SKU into a single marketplace SKU. Contract pricing can be handled by passing the buyer's identification details to the supplier when the supplier's catalog is browsed. This method allows adherence to buyer/supplier contract pricing and terms. The exchange can create views for a customer that limits the data accessed to either a set of suppliers or specific products from a supplier or within the exchange.

The Catalog System provides a SQL and an EJB interface for querying the catalog. The Catalog System provides parametric searching against product attributes. In addition, Cohera has embedded the AltaVista technology to provide synonyms, thesaurus, and stemming capabilities for searching.

The schema used by the Catalog System can be either the standard Cohera supplied schema, or a custom-defined schema.

The Catalog System provides workflow to input and maintain the product catalog and associated taxonomy. The Catalog System includes browser-based administration tools. These tools handle inputting product items, as well as importing, transforming, and normalizing supplier catalogs. Cohera also provides a Java-based GUI for administration that steps the catalog administrator through the process of mapping supplier catalogs to the catalog view.

For suppliers with paper-based product catalogs, Cohera provides professional services to assist in digitizing the product catalogs. For suppliers with electronic product catalogs, the SiteManager can connect to the source. SiteManager transforms the catalog data into the master catalog structure and format without changing the supplier's underlying data form and structure.

Scenarios

Personal Computer Manufacturer

Personal computers were among the first items to be made available on the Internet. The PC business has always been highly competitive, requiring constant innovation in terms of products design and product access.

Personal computers can generally be purchased as pre-configured systems from retailers, or as custom-configured solutions direct from the manufacturer. These options are designed to appeal to different types of consumers.

Most PC manufacturers consider it essential to provide an online commerce presence that enables customers to configure and purchase PCs. Due to the complexity of personal computers, the configuration process can be difficult to implement in a customer-friendly manner. As a result, PC manufacturers invest considerable time and effort creating a configuration process that differentiates them from their competitors.

A configurator must be tightly integrated to the product catalog, enabling business users to define the relationships and constraints that exist between the various components that can comprise a personal computer.

The Commerce Server catalog management system provides the ability to define relationships between products and categories, and to control the products that can appear within a category. These features could be employed to build a configurator, but would generally be insufficient to build the type of configurator required by a PC manufacturer.

In this case, it would be appropriate to use a custom catalog solution. This approach would provide the business with the opportunity to establish a competitive advantage by creating a solution tailor made to their requirements.

Customer Account Integration

Businesses generally attempt to establish long-term relationships with their customers. The cost of acquiring a customer is significantly more than retaining a customer. Therefore, emphasis is often placed on providing a personalized view of the business to the customer, in addition to exemplary customer support.

In some cases, maintaining a long-term customer relationship is not only desirable, but a necessary part of doing business. This is generally the case in the services industry.

Customers will generally establish accounts with businesses. These accounts reflect the products and/or services the customer has purchased, and the recurring charges the customer is required to pay.

Whenever a customer wishes to make further purchases, it is sometimes necessary to filter the available set of products and/or services that the business offers to account for what the customer already owns. In addition, should a customer attempt to purchase something they already own, then it may be necessary to prevent them from performing the purchase.

The current Commerce Server Catalog Management System does not support this level of integration with an existing customer account. Instead, the filtering and control processes could be applied once the results of any query had been returned from the catalog system.

Commerce Site Hosting

Over the last few years, the concept of an external company hosting another company's applications led to the creation of a major industry. The term Application Server Provider (ASP) has been coined to describe these external companies.

ASPs are taking many different approaches to the market, from simply providing data center services to small companies to developing complete custom applications for large enterprises. A number of these ASPs focus on providing e-commerce services. For ASPs that provide e-commerce sites to customers, it is typically important to be able to provide these services in the most cost effective manner possible. This means being able to host many sites within the same environment. This, however, must be done carefully to ensure that each customer continues to receive an acceptable level of performance, availability, and security.

Because the core of most commerce sites is a catalog, the ASP must be able to provide catalog services as part of their overall service. These services can include:

• Remote, browser-based access to the catalog system to manage the products and prices offered through the site. The ability to include collateral information, such as downloadable files and images.
• Interfaces to third-party products, such as ERP systems or desktop productivity software, to enable automated upload of catalog information. In addition, these interfaces should provide download capabilities, which include product information as part of the orders.
• Operational reports that include catalog information, such as top-selling products.

More extensive catalog services may include the ability to perform product discounting, personalized product presentation, and targeting—or customized catalogs to different groups of site customers.

The ASP will want to maximize the use of their resources in the hope of achieving profitability. This means they will need to be able to minimize the amount of software, hardware and administration necessary to support as many catalogs as possible. The catalog system should not contain any inherent limitations to its use.

This means that to support small-scale customers, the catalog system needs to be able to support many instances of the catalog system operating concurrently on the same platform; the system must also be able to scale up to support the catalogs of larger customers operating on a dedicated platform.

Supplier Catalog Integration

Internet-based marketplaces started to appear a number of years ago. As with the hosting industry, marketplaces have evolved into a major industry, with many different approaches being applied. Generally, an Internet-based marketplace is operated by a company focusing on a vertical or horizontal sector of the market. This company attempts to gather a critical mass of suppliers and buyers to the marketplace by providing services to both the buyer and supplier.

For the supplier, one of the most important services a marketplace can provide is a flexible catalog management system. Many of the same catalog services provided by ASPs need to be provided by marketplaces. However, there is generally a greater importance placed on the need to integrate the marketplace catalogs with the supplier's internal systems. This is necessary to ease the management of the catalog, as well as to ensure that the catalog reflects the current status of product availability and pricing.

It is also important for the marketplace to provide the buyer with catalog-related services, such as the ability to search and browse aggregate sets of supplier catalogs. In addition, the marketplace may need to support the integration of the catalogs into the buyer's internal systems for the purposes of accounting and workflow management.

Integrating an External Catalog Management System

Integrating an existing catalog system with Commerce Server 2000 requires programming to modify or replace components of Commerce Server. The following is a description of the areas of Commerce Server that will need to be modified in order to achieve the integration.

Integrating with Campaigns

The expression evaluator component is used to determine which discounts, if any, should be applied to products placed in a customer's shopping cart. The expression evaluator processes the set of catalog expressions that have been created via the expression builder within the campaign manager. Adding the product's properties with a _product_ prefix enables the expression evaluator to include the properties in the evaluation of the expressions.

In order to use catalog expressions when creating discounts against products from an external catalog, it is necessary to create property definitions within the catalog designer for the properties that will be added to the shopping cart for the products selected from the external catalog.

Integrating with the Data Warehouse

The following Data Warehouse components may need to be extended in order to use an external product catalog:

• Define schema. The data schema must be defined appropriately by using the Commerce Server OLE database provider. Alternatively, the existing catalog DW schema entries could be used to store the product information.
• Import data. A custom script or application will be needed to import data from the external catalog into the Data Warehouse.
• Prepare data for analysis. Create and populate any additional OLAP cubes required to support reporting against the external catalog's products.
• Modify or create reports. Modify or replace any reports that use product catalog data so that they can use third-party catalogs.

Integrating with Baskets

In order to transfer product information from the existing catalog to the basket, custom component will need to be created and added to the basket pipeline, replacing the QueryCatalogInfo component. The existing QueryProductInfoADO pipeline component could be used to provide the integration with the external catalog, depending on the complexity of the data structure.

The substitute component must copy appropriate catalog data to each line item in the basket based on a product key (for example, the SKU). When the component copies this catalog data, it should prefix each written dictionary key with "_product_". For example, the description of the product would be copied to "item._product_description". Typically, at a minimum, this written data should include "_product_list_price". It could also include any other information necessary to inform the customer of their purchase details and to support fulfillment.

To support removing non-existent products from a shopping cart, the component should write the key delete with a value of 1 onto the line item. The RequiredProdInfo pipeline component then handles the error condition.

To increase overall performance and scalability the QueryCatalogInfo component caches product data. This is achieved by using the CacheManager component, which is passed into the pipeline as part of the context object. When replacing this component, consideration should be given to implementing a similar caching strategy.

Integrating Applications

The Commerce Server Solution Sites interface directly with the Commerce Server Catalog System. If these applications are to be used with an existing catalog system, all calls to the Commerce Server Catalog API must be replaced.

Integrating with Business Desk Catalog Modules

If it is necessary to manage the external product catalog via the Commerce Server Business Desk then the modules for managing a catalog will need to be replaced or modified.

Conclusions

The Commerce Server Catalog Management System provides a rich and powerful solution to businesses, allowing them to create and manage customized product catalogs.

The integration of the catalog management system into the overall Commerce Server architecture enables the rapid development of commerce solutions that provide a comprehensive, end-to-end solution.

Furthermore, because the catalog management system was developed as part of Commerce Server, it offers a very high performing, scalable solution, with a simple, unified management interface.

Consequently, whenever possible the integrated catalog management system should be adopted. However, should a business find that its unique requirements demand a customized, external catalog system, Commerce Server's open architecture enables its full integration without any loss of functionality.

Appendix: Sample Code

The following are examples of how the Commerce Server catalog object model can be used to manage the catalog. The examples are designed to flow from the definition of a catalog schema, the creation of a catalog, and finally the usage of the catalog.

Create and Initialize the CatalogManager

The following sample code creates an instance of the CatalogManager object and then initializes the object using the connection string to the Retail site's product catalog database.

The Retail site's product catalog database connection string is obtained from the Commerce Server administration database [MSCS_Admin] using the SiteConfigReadOnly object.

In order to use the sample code, references to the following Commerce Server libraries would need to be added to any visual basic or visual C++ project:

• Microsoft Commerce 2000 Configuration Type Library [MSCSCfg.dll]
• Microsoft Commerce 2000 Catalog Type Library [Catalog.dll]
• Microsoft Commerce 2000 Catalog Sets Type Library [CatalogSets.dll]

Set oCatMgr = CreateObject("Commerce.CatalogManager")
Call oCatMgr.Initialize(GetSiteConfigField("Product Catalog", 
"connstr_db_catalog", "retail"), True)
    

Set oCatMgr = Nothing

Private Function GetSiteConfigField(ByVal sResourceName As String, 
ByVal sPropertyName As String, ByVal sSite As String)
Dim oSiteConfig As CS_MSCSCfg.SiteConfigReadOnly
    GetSiteConfigField = ""
    On Error Resume Next
        Set oSiteConfig = CreateObject("commerce.siteconfigreadonly")
        oSiteConfig.Initialize (sSite)
        GetSiteConfigField = oSiteConfig.Fields(CStr(sResourceName))
.Value.Fields(CStr(sPropertyName)).Value
        Set oSiteConfig = Nothing
    On Error GoTo 0
End Function

Create and Populate a Property

The following sample code uses the CatalogManager, created previously, to create a property, which can then be associated to a category or product definition to describe its schema.

Once a property has been created, a recordSet is returned that contains the property's attributes. This recordSet can be used to refine the description of the property. The recordSet contains a single row, with the fields shown in the following table.

Field name	Data type
PropertyName	String
DataType	Small integer
u_DefaultValue	String
i_DefaultValue	Integer
dt_DefaultValue	datetime
cy_DefaultValue	money
f_DefaultValue	bit
fp_DefaultValue	float
i_MinValue	Integer
i_MaxValue	Integer
dt_MinValue	datetime
dt_MaxValue	datetime
fp_MinValue	float
fp_MaxValue	float
IsFreeTextSearchable	bit
IncludeInSpecSearch	bit
MinLength	Integer
MaxLength	Integer
cy_MinValue	money
cy_MaxValue	money
TimeStamp	timestamp
DisplayOnSite	bit
DisplayName	String
AssignAll	bit
ExportToDW	bit
DisplayInProductsList	bit

The CatalogManager object's SetPropertyAttributes method can be used to update the property's description by accepting a recordSet containing the modified property attribute values.

Call createProperty("test1", cscString, 128) 

Private Sub createProperty(ByVal propName As String, 
ByVal dataType As CatalogDataTypeEnum, ByVal MaxLength As Integer)

    Set oRS = oCatMgr.createProperty(propName, dataType, MaxLength)

    oRS.Fields("u_DefaultValue").Value = "testing"
    oRS.Fields("DisplayName").Value = "This is a test"
    
    Call oCatMgr.SetPropertyAttributes(oRS, False)

End Sub
  

A number of different datatypes can be used when creating properties. The following table lists the available datatypes.

Name	Value	Description
cscInteger	0	Indicates an exact numeric value that holds whole numbers from –2[31] (-2,147,483,648) <= n <= 2[31] –1 (2,147,483,647)
cscBigInteger	1	Indicates an exact numeric value with precision 19 (if signed) or 20 (if unsigned) and scale 0 (signed: –2[63] <= n <= 2[63] – 1, unsigned:  0 <= n <= 2[64] – 1) [3], [9].
CscFloat	2	Indicates a positive or negative floating-point number. The range of positive values is approximately 2.23E –308 through 1.79E 308 and the range of negative values is approximately  –2.23E –308 through –1.79E 308.
cscDouble	3	Indicates a positive or negative floating-point number. The range of positive values is approximately 2.23E –308 through 1.79E 308 and the range of negative values is approximately –2.23E –308 through –1.79E 308.
cscBoolean	4	Indicates a Boolean (bit), holds either a 1 or 0. Integer values other than 1 or 0 are accepted but are always interpreted as 1.
cscString	5	Indicates a variable-length character string with a maximum string length of 255 characters.
cscDateTime	6	Indicates a Microsoft SQL Server DateTime data type.
cscCurrency	7	Indicates a Microsoft SQL Server Money data type.
cscFilePath	8	Indicates a String that holds a file path.
cscEnumeration	9	Indicates an Integer associated with a defined constant.
cscInvalid	-1	Reserved for future use.
CscInteger	0	Indicates an exact numeric value that holds whole numbers from –2[31] (-2,147,483,648) <= n <= 2[31] –1 (2,147,483,647)
cscBigInteger	1	Indicates an exact numeric value with precision 19 (if signed) or 20 (if unsigned) and scale 0 (signed: –2[63] <= n <= 2[63] – 1, unsigned:  0 <= n <= 2[64] – 1) [3], [9].
CscFloat	2	Indicates a positive or negative floating-point number. The range of positive values is approximately 2.23E –308 through 1.79E 308 and the range of negative values is approximately  –2.23E –308 through –1.79E 308.
CscDouble	3	Indicates a positive or negative floating-point number. The range of positive values is approximately 2.23E –308 through 1.79E 308 and the range of negative values is approximately –2.23E –308 through –1.79E 308.
CscBoolean	4	Indicates a Boolean (bit), holds either a 1 or 0. Integer values other than 1 or 0 are accepted but are always interpreted as 1.
CscString	5	Indicates a variable-length character string with a maximum string length of 255 characters.
cscDateTime	6	Indicates a Microsoft SQL Server DateTime data type.
cscCurrency	7	Indicates a Microsoft SQL Server Money data type.
CscFilePath	8	Indicates a String that holds a file path.
cscEnumeration	9	Indicates an Integer associated with a defined constant.
CscInvalid	-1	Reserved for future use.

The following sample code demonstrates the creation of a property that uses the cscEnumeration. The CatalogManager's AddPropertyValue method is used to create permitted values for the enumeration.

Call createProperty("test1", cscEnumeration)

Public Sub createProperty(ByVal propName As String, 
ByVal dataType As CatalogDataTypeEnum, 
Optional ByVal MaxLength As Integer)

Set oRS = oCatMgr.createProperty(propName, dataType, MaxLength)

    oRS.Fields("u_DefaultValue").Value = "testing"
    oRS.Fields("DisplayName").Value = "This is a test"
    
    Call oCatMgr.AddPropertyValue(propName, "permittedVal1")
    Call oCatMgr.AddPropertyValue(propName, "permittedVal2")
    Call oCatMgr.AddPropertyValue(propName, "permittedVal3")
    
    Call oCatMgr.SetPropertyAttributes(oRS, False)

End Sub

Create a Product Definition

The following sample code uses the CatalogManager object to create a product definition. Following the creation of the product, the AddDefinitionProperty method is used to add existing properties to the product's definition; the AddDefinitionVariantProperty method is used to add properties to the product's variant definition.

Call createProduct("newProduct")

Public Sub createProduct(ByVal prodName As String)

    Call oCatMgr.CreateProductDefinition(prodName)
    
    Call oCatMgr.AddDefinitionProperty(prodName, "description")
    Call oCatMgr.AddDefinitionProperty(prodName, "ISBN")
    
    Call oCatMgr.AddDefinitionVariantProperty(prodName, "color")
    
    Call iterateRS(oCatMgr.ProductDefinitions, "product")

End Sub

Create a Category Definition

The following sample code uses the CatalogManager object to create a category definition. Following the creation of the category, the AddDefinitionProperty method is used to add existing properties to the category's definition.

Call createCategory("newCategory") 

Public Sub createCategory(ByVal catName As String)

    Call oCatMgr.CreateCategoryDefinition(catName)
    
    Call oCatMgr.AddDefinitionProperty(catName, "image_filename")
    Call oCatMgr.AddDefinitionProperty(catName, "image_width")
    Call oCatMgr.AddDefinitionProperty(catName, "image_height") 

End Sub

Create and Populate a Catalog

The following sample code uses the CatalogManager's createCatalog method to create a catalog. When creating a catalog the property that will be used to identify the products within the catalog must be provided. If the catalog will contain variants then the property that will act as the variant identifier must also be provided.

The createCatalog method returns a ProductCatalog object. It also creates the underlying catalog database tables.

Once the catalog is created, the ProductCatalog's createCategory method is used to add two categories to the catalog. These categories are associated with one another in a parent/child relationship. The categories are based upon an existing category definition ("Department").

The ProductCatalog's CreateProduct method is then used to add two products to the child category. The products are based on an existing product definition. It is important to ensure that the product definition does not violate the catalog's product identification scheme. That is, the product definition can't include a variant identifier, which the catalog uses as the product identifier.

Each product within a catalog is assigned a set of additional properties to those related to its product definition. The following table lists these additional properties.

Field name	Data type	Returned to Application*
CategoryName	String Maximum of 128 characters	Yes
Oid	Integer	No
DefinitionName	String Maximum of 128 characters	Yes
IsSearchable	Small integer	Yes
cy_list_price	Money	Yes
PricingCategoryOID	Integer	Yes
TimeStamp	TimeStamp	Yes
OriginalPrice	Money	Yes
i_ClassType	Integer	Yes
ParentOID	Integer	No
ProductID	String Maximum of 256 characters	Yes
VariantID	String Maximum of 256 characters	Yes

* Indicates whether the property is returned as part of the Product object's ProductProperties recordset.

The product object returned by the CreateProduct method is then used to modify the property values for the products. The product's GetProductProperties method is used to retrieve a recordset containing the properties for the product. This recordSet can be used to modify the property values of the product within the catalog. The recordSet contains a single row, with a field for each property.

The changes to product's property values are then persisted by using the Product object's SetProductProperties.

Call createCatalog("newCatalog", "SKU", "ISBN")

Public Sub createCatalog(ByVal catName As String, 
   ByVal prodID As String, ByVal varID As String)
Dim oProdCat As ProductCatalog
Dim oParentCatgy As Category
Dim oChildCatgy As Category
Dim oProd As Product
Dim oRS As Recordset

    Set oProdCat = oCatMgr.createCatalog(catName, 
prodID, varID, "1033", "USD", "LBS", Now(), DateAdd("m", 12, Now()))

    Set oParentCatgy = oProdCat.createCategory("Department", 
"ParentCategory")
    Set oChildCatgy = oProdCat.createCategory("Department", 
"ChildCategory", "ParentCategory")

    Set oProd = oProdCat.createProduct("Book", "SKU_1234", 49.99, 
"ChildCategory")
    Set oRS = oProd.GetProductProperties
    
    oRS.Fields("Description").Value = "This is a test product"
    oRS.Fields("Author").Value = "Steven Kingly"
    
    Call oProd.SetProductProperties(oRS, True)
    
    Set oProd = oProdCat.createProduct("Book", "SKU_1235", 59.99, 
"ChildCategory")
    
    Set oRS = oProd.GetProductProperties

    oRS.Fields("Description").Value = "This is another test product"
    oRS.Fields("Author").Value = "Steven Kingly II"
    
    Call oProd.SetProductProperties(oRS, True)
    Set oRS = nothing
    Set oProd = nothing
    Set oChildCatgy = nothing
    Set oParentCatgy = nothing
    Set oProdCat = nothing

End Sub

Creating and Using Catalog Sets

The following sample code demonstrates how to create a catalog set, assign it to a user and organization, and then retrieve a list of the catalogs for a user and organization.

Before a catalog set can be created, an instance of the CatalogSet object must be created and initialized. The connection string is obtained in the same manner as demonstrated earlier in the Create and Initialize the CatalogManager section.

Public oCatSet As CS_CtlgSets.CatalogSets
Dim sCatSetid As String

Set oCatSet = CreateObject("commerce.catalogsets")
Call oCatSet.Initialize(GetSiteConfigField("Product Catalog", 
"connstr_db_catalog", "retail"), "")
   
 Call createCatSet(sCatSetid)
    
 Set oCatSet = Nothing

Private Sub createCatSet(ByRef sCatSetid As String)
Dim rsCatNames As Recordset

    Set rsCatNames = CreateObject("ADODB.Recordset")
    Call rsCatNames.Fields.Append("CatalogName", adBSTR)
    rsCatNames.Open
    rsCatNames.AddNew
    rsCatNames.Fields("CatalogName").Value = "Books"
    rsCatNames.Update
    rsCatNames.AddNew
    rsCatNames.Fields("CatalogName").Value = "Software"
    rsCatNames.Update

    sCatSetid = oCatSet.CreateCatalogSet("books_software", 
"Books & Software", False, rsCatNames)

End Sub

Once a catalog set has been created, it can be associated to a customer and/or organization. The following code demonstrates how this can be done. The identifier assigned to the catalog set during its creation must be used to associate the user object and/or organization object to the catalog set.

The first step involves asking the profile system objects what catalog set is to be associated. Once this has been done, the catalog set identifier can be assigned to the user object's user_catalog_set property, and the organization's org_catalog_set property.

Call associatetoUser(sCatSetid)
Public Sub initializePS()
    Set ps = CreateObject("Commerce.ProfileService")
    Set usr = CreateObject("Commerce.ProfileObject")
    Set org = CreateObject("Commerce.ProfileObject")
    
    server = "localhost"
    catalog = "retail_commerce"
    user = "sa"
    pwd = ""
    
    conSTR="Provider=CSOLEDB;PsObjectCacheSize=0;
       PsSchemaCacheSize=0;PsBackgroundThread=0;
       PsObjectAgeoutPeriod=0;Data Source=" & server & ";
       Initial catalog=" & catalog & ";User ID=" & user & ";
    Password=" & pwd & ";"
   
    Call ps.Initialize(conSTR)
    
    Set usr = Nothing
    Set usr = ps.GetProfile("test", "UserObject", False)
    
    Set org = Nothing
    Set org = ps.GetProfile("TestOrg", "Organization", False)
    
End Sub

Public Sub associatetoUser(sCatSetid)

    Call initializePS

    usr.accountInfo.user_Catalog_Set = sCatSetid
    usr.Update

    org.generalinfo.org_catalog_set = sCatSetid
    org.Update
    
End Sub

Identifying a Customer's Catalogs

Identifying the catalog(s) a customer should be able to view involves using the catalogSets object to retrieve the names of the catalogs. This is done by first determining whether the customer has been assigned a catalog set. The logic for accessing the catalog set identifier is implemented as follows within the retail sample site. The structured logic for this function is:

• Get Customer's User Profile
• If profile exists use the customer's assigned catalog set

  • If catalog set not found retrieve the customer's organization object

    - If organization object exists use its catalog set

          If catalog set not found and customer anonymous then assign
           customer the anonymous user catalog set

          Else if catalog set not found and customer registered then assign
           the customer the registered user catalog set

Function mscsUserCatalogsetID()
    Dim rsUser, rsOrg
    Dim org_id

    Set rsUser = GetCurrentUserProfile()
    
    If Not rsUser Is Nothing Then
        mscsUserCatalogsetID = rsUser.Fields.Item(USER_CATALOGSET).Value
        If IsNull(mscsUserCatalogsetID) Then
            ' Get the user's org profile.
            org_id = rsUser.Fields.Item(USER_ORGID).Value
            
            If Not IsNull(org_id) Then
      ' Set rsGetProfile's bForceDBLookUp 
to False to avoid a database look-up.
      Set rsOrg = rsGetProfileByKey(FIELD_ORG_ORG_ID, 
org_id, PROFILE_TYPE_ORG, False)
                If Not rsOrg Is Nothing Then 
                    mscsUserCatalogsetID = 
rsOrg.Fields.Item(ORG_CATALOGSET).Value
                End If
            End If
        End If
    Else
      mscsUserCatalogsetID = Null
    End If
    
    If IsNull(mscsUserCatalogsetID) Then
      ' Get the catalog set to fall back if no 
catalog set was specified at user/org level.
      If m_UserType = AUTH_USER Then
         mscsUserCatalogsetID = 
dictConfig.s_AuthenticatedUserDefaultCatalogSet
      Else
         mscsUserCatalogsetID = 
dictConfig.s_AnonymousUserDefaultCatalogSet
      End If
    End If
End Function

The catalogSet object provides an implementation for the above logic in the form of its GetCatalogSetIDForUser method. The difference being that the third parameter in the method call is the catalog set identifier that should be returned if the user or their organization has no assigned catalog set.

The catalogSet object's GetCatalogsForUser method builds on the previous method by retrieving a recordset containing the names of the catalogs within the appropriate catalog set. The following code demonstrates how to retrieve the catalogs for a customer using this method. The third parameter is the catalog set identifier for the registered user catalog set.

Call getCatalogsForUser
Public Sub getCatalogsForUser()
Dim rsCats As Recordset

    Set rsCats = oCatSet.getCatalogsForUser(ps, 
        "test", "{22222222-2222-2222-2222-222222222222}")
    
    If Not rsCats.EOF Then
        Do While Not rsCats.EOF
            Debug.Print rsCats.Fields(0).Value
            rsCats.MoveNext
        Loop
    End If
    
End Sub

Commerce Server automatically creates two catalog sets, Anonymous User Default Catalog Set and Registered User Default Catalog Set. These catalog sets are used in the sample sites to assign a catalog set to a customer when no other catalog set has been assigned.**

Once the catalog names have been retrieved the CatalogManager object can be used to retrieve the ProductCatalog object using its GetCatalog method.

Navigating a Catalog

The following sample code illustrates how retrieve a catalog and to then navigate the catalog's hierarchy from root categories to base level products. For the purposes of the illustration, the first category and product are used at each step in the hierarchy.

The first step is to retrieve the productCatalog object using the CatalogManager object. This is done using the name of the catalog.

    Dim oProdCat As ProductCatalog
    Set oProdCat = oCatMgr.GetCatalog("books")
    
    Call navigateCatalog(oProdCat)
    
    Set oProdCat = Nothing
    Set oCatMgr = Nothing

The next step iterates through the product catalog's hierarchy of categories using two helper functions. The product catalog's rootCategories recordset is used to retrieve the names of the categories at the root level of the catalog.

The CategoryName field within the recordset is used to retrieve the category object using the product catalog's GetCategory method. A sub-level within the catalog, the parent category's ChildCategories recordset is used to retrieve the names of the categories within that category.

Public Sub navigateCatalog(ByRef oProdCat As ProductCatalog)
Dim oParentCatgy As Category, oChildCatgy As Category
        
    Do While getNextLevel(oProdCat, oParentCatgy, oChildCatgy)
        If Not oChildCatgy Is Nothing Then
            Set oParentCatgy = oChildCatgy
        End If
        Debug.Print oParentCatgy.CategoryName
        Call showProducts(oProdCat, oParentCatgy)
    Loop

End Sub

Public Function getNextLevel(ByRef oProdCat As ProductCatalog, 
    ByRef oParentCatgy As Category, 
    ByRef oChildCatgy As Category) As Boolean
Dim rsCatgy As Recordset
    getNextLevel = False
    If oParentCatgy Is Nothing Then
        Set rsCatgy = oProdCat.RootCategories()
        If Not rsCatgy.EOF Then
             sCatgyName = rsCatgy.Fields("CategoryName").Value
             Set oChildCatgy = oProdCat.GetCategory(sCatgyName)
             Call iterateRS(rsCatgy, "category")
             getNextLevel = True
        End If
    Else
        Set rsCatgy = oParentCatgy.ChildCategories
        If Not rsCatgy.EOF Then
             sCatgyName = rsCatgy.Fields("CategoryName").Value
             Set oChildCatgy = oProdCat.GetCategory(sCatgyName)
             Call iterateRS(rsCatgy, "category")
             getNextLevel = True
        End If
    End If
    Set rsCatgy = Nothing
End Function

It is possible for products to exist at each level in the catalog hierarchy. The above code sample uses a helper routine, called showProducts, which is shown in the following sample, to present the products at each level in the hierarchy.

This routine uses the category object's Products method to retrieve the products contained within the category. This method takes five optional parameters to control the set of products returned.

• Class type required. The type of data to return. This value is an enumeration of type CatalogClassTypeEnum. The following table lists the possible values. These values can be combined using logical OR operators.

Name	Value	Description
cscCategoryClass	1	Requests category data.
cscProductVariantClass	2	Requests product variant data.
cscProductClass	4	Requests product data.
cscProductFamilyClass	8	Requests product family data.
cscProductFamilyForVariantsClass	16	Requests family for variant data, which means the product family of a product variant is being requested.
CscProductVariantsForFamily	32	Requests variants for family data, which means that all of the product variants for a product family are being requested.

• Sort Property. The name of the product property to be used to sort the recordset.
• Starting Record. The number of the first record within the resultset to be returned in the recordset.
• Records to Retrieve. The number of records to retrieve.
• Total Count. The total number of records in the result set.

Once the products have been retrieved, the productID property is used to retrieve the Product object using the product catalog's GetProduct method.

The product object is then used to retrieve the set of variants and product properties for the product, using the Variants and GetProductProperties methods respectively.

Public Sub showProducts(ByRef oProdCat As ProductCatalog, 
    ByRef oParentCatgy As Category)
Dim rsProd As Recordset, oProd As Product
Dim rsProp As Recordset, rsVarnts As Recordset
Dim iTotal As Integer, sProductId As String

    Set rsProd = oParentCatgy.Products(, "ProductID", 1, 10, iTotal)
    If Not rsProd.EOF Then
        sProdName = rsProd.Fields("ProductID").Value
        Call iterateRS(rsProd, "product")
        
        Set oProd = oProdCat.GetProduct(sProdName)
        Debug.Print oProd.ProductID
        
        Set rsVarnts = oProd.Variants
        If Not rsVarnts.EOF Then
            Call iterateRS(rsVarnts, "Variants")
        End If
        Set rsProp = oProd.GetProductProperties
        If Not rsProp.EOF Then
            Call iterateRS(rsProp, "productProperties")
        End If
    End If
    
    Set rsProd = Nothing
    
End Sub

Note   iterateRS is a simple helper routine which iterates through a recordset writing out the field name and value pairs for each row in a recordset.

Query a Catalog

The catalogManager object provides a Query method that can be used to search the contents of a catalog, or catalogs.

Note   Restricting the scope of searches is recommended for optimum performance. For example, avoid providing customers with unrestricted ability to search across multiple catalogs.

The following sample code illustrates how to use the Query method to search for products. The Query method takes eight parameters, all of which are optional, except the search phrase.

• Search phrase. A string containing the properties and values used to perform a search. The phrase is structured in the same manner as a SQL WHERE clause. The properties used must be present in the catalogs being searched, and any string values must be enclosed in single quotes. For example, "color = 'blue'".
• Catalogs to search. A comma-separated list containing the names of the catalogs to search. An empty string means ALL catalogs.
• Class type required. The type of data to return. This value is an enumeration of type CatalogClassTypeEnum. The following table lists the possible values. These values can be combined using logical OR operators.

Name	Value	Description
cscCategoryClass	1	Requests category data.
cscProductVariantClass	2	Requests product variant data.
cscProductClass	4	Requests product data.
cscProductFamilyClass	8	Requests product family data.
cscProductFamilyForVariantsClass	16	Requests family for variant data, which means the product family of a product variant is being requested.
CscProductVariantsForFamily	32	Requests variants for family data, which means that all of the product variants for a product family are being requested.

• Properties to return. A comma-separated list of the properties to return. If multiple catalogs are searched, this property is required.
• Sort property. The name of the product property used to sort the recordset.
• Sort direction. A Boolean indicating the sort direction. The default value is ascending [true].
• Starting record. The number of the first record within the resultset to be returned in the recordset.
• Records to retrieve. The number of records to retrieve.
• Total count. The total number of records in the result set.

Call searchCat

Public Sub searchCat()
Dim rsResults As Recordset
Dim iTotal As Integer

    Set rsResults = oCatMgr.Query("cy_list_price > 40", 
        "Books", , , "cy_list_price", False, 1, 100, iTotal)
    If Not rsResults Is Nothing Then
        If Not rsResults.EOF Then
            Call iterateRS(rsResults, "searchResults")
        End If
    End If
    
   Set rsResults = oCatMgr.Query("SKU = '0-7356-0811-3'", 
      "Books", , , "cy_list_price", False, 1, 100, iTotal)
   If Not rsResults Is Nothing Then
        If Not rsResults.EOF Then
            Call iterateRS(rsResults, "searchResults")
        End If
   End If
   
   Set rsResults = oCatMgr.Query(
      "Publisher ='Microsoft Press' and [Reading Level] 
   ='Beginner/Intermediate'", 
      "Books", , , "cy_list_price", False, 1, 100, iTotal)
   If Not rsResults Is Nothing Then
        If Not rsResults.EOF Then
            Call iterateRS(rsResults, "searchResults")
        End If
   End If
    
   Set rsResults = Nothing

End Sub
 

Full-text Search a Catalog

The catalogManager object also provides the FullTextSearch method, which can be used to search the contents of a catalog, or catalogs. This method differs from the Query method in that it uses the catalog's SQL Server full-text search indexes to resolve the search. As a consequence, the format of the search phrase should be a free form language statement, rather than a set of name value pairs.

Note   Restricting the scope of searches is recommended for optimum performance. For example, avoid providing customers with unrestricted ability to search across multiple catalogs.

The following sample code illustrates how to use the FullTextSearch method to search for products. The FullTextSearch method takes eight parameters, all of which are optional, except the search phrase.

• Search Phrase. A free form language statement on which to perform the search. The search phrase can employ the same operators as available via the SQL Server CONTAINS full-text search function.
• Catalogs to search. A comma-separated list containing the names of the catalogs to search. An empty string means ALL catalogs.
• Class Type Required. The type of data to return. This value is an enumeration of type CatalogClassTypeEnum. The following table lists the possible values. These values can be combined using logical OR operators.

Name	Value	Description
cscCategoryClass	1	Requests category data.
cscProductVariantClass	2	Requests product variant data.
cscProductClass	4	Requests product data.
cscProductFamilyClass	8	Requests product family data.
cscProductFamilyForVariantsClass	16	Requests family for variant data, which means the product family of a product variant is being requested.
CscProductVariantsForFamily	32	Requests variants for family data, which means that all of the product variants for a product family are being requested.

• Properties to Return. A comma separated list of the properties to return. If multiple catalogs are searched this property is required.
• Sort Property. The name of the product property to be used to sort the recordset.
• Sort Direction. A Boolean indicating the sort direction. The default value is ascending [true].
• Starting Record. The number of the first record within the resultset to be returned in the recordset.
• Records to Retrieve. The number of records to retrieve.
• Total Count. The total number of records in the result set.

Call fulltextsearchCat

Public Sub fulltextsearchCat()
Dim rsResults As Recordset
Dim iTotal As Integer

    Set rsResults = oCatMgr.FreeTextSearch("Microsoft", 
        "Books", , , "cy_list_price", False, 1, 100, iTotal)
    If Not rsResults Is Nothing Then
        If Not rsResults.EOF Then
            Call iterateRS(rsResults, "searchResults")
        End If
    End If
    
   Set rsResults = oCatMgr.FreeTextSearch("'Big' near 'Small'", 
      "Books", , , "cy_list_price", False, 1, 100, iTotal)
   If Not rsResults Is Nothing Then
        If Not rsResults.EOF Then
            Call iterateRS(rsResults, "searchResults")
        End If
   End If
   
   Set rsResults = oCatMgr.FreeTextSearch("'FORMSOF(INFLECTIONAL, 
'book')", "Books", , , "cy_list_price", False, 1, 100, iTotal)
   If Not rsResults Is Nothing Then
        If Not rsResults.EOF Then
            Call iterateRS(rsResults, "searchResults")
        End If
   End If
    
   Set rsResults = Nothing

End Sub

Specification Search a Catalog

A specification search is a means of performing a series of related searches, each subsequent search being performed against the results of the previous to further refine the resultset. The ProductCatalog object's*****PerformSpecificationSearch* method is used to perform the search. The method indicates the total number of matching records.

Note   A specification search can only be performed in the context of a single catalog.

The following sample code illustrates how to perform a specification search. The first step is to call the ProductCatalog's BeginSpecificationSearch method to create a search handle.

Sub PrepareSpecificationSearch()

   sSearchHandle = oCatalog.BeginSpecificationSearch(
            "Internet development tools", rsFields, iMatchesFound)
   If Not (rsFields Is Nothing) Then
      Call AddSpecificationSearchClause (sSearchHandle, 
               rsFields, oProdCat )
      bNoValues = True
      Call PerformSpecificationSearch ( oProdCat, rsResults, 
iMatchesFound, sSearchHandle)
   End If
End Sub

The recordset [rsFields] returned by the BeginSpecificationSearch method contains a list of the properties that can be included in a specification search. These are the properties whose Specification Searchable attribute has been set to true. Each field in the recordset contains a SafeArray containing the available values for that property.

This information is designed to be displayed to the user as a series of drop-down lists. After the user has made their selection and posted the form, the selected values are added as specification clauses for each selected value. The following code illustrates how to add a search clause.

Sub GetSpecificationSearchClauses(ByRef sSearchHandle, ByRef oProdCat,)

        '  Field is a Search Constraint
   sPropertyName = "Licencetype"

   sSearchClause = ""         

   '  Add Specification Search Clause
   sSearchClause = "[" & sPropertyName & "]" & " IN (" & "Single User 
License" & ")"

   Call oCatalog.AddSpecificationSearchClause(sSearchClause, 
sSearchHandle)

End Sub

The next step is to perform the specification search using the ProductCatalog's PerformSpecificationSearch method. The method takes six parameters, all of which are optional, except the search handle. The sample code also illustrates how the ProductCatalog's GuaranteedSpecificationSearch method can be used to ensure that a search always results in a response. This method works by removing search clauses in the reverse order to which they were applied until a match is found.

• Search Handle. A free form language statement on which to perform the search. The search phrase can employ the same operators as available via the SQL Server CONTAINS full-text search function.
• Class Type Required. The type of data to return. This value is an enumeration of type CatalogClassTypeEnum. The following table lists the possible values. These values can be combined using logical OR operators.

Name	Value	Description
cscCategoryClass	1	Requests category data.
cscProductVariantClass	2	Requests product variant data.
cscProductClass	4	Requests product data.
cscProductFamilyClass	8	Requests product family data.
cscProductFamilyForVariantsClass	16	Requests family for variant data, which means the product family of a product variant is being requested.
CscProductVariantsForFamily	32	Requests variants for family data, which means that all of the product variants for a product family are being requested.

• Records to Retrieve. The number of records to retrieve.
• Total Count. The total number of records in the result set.
• Properties to Return. A recordset [rsFields] containing a refined list of the properties that can be included in a subsequent specification search. Each field in the recordset contains a SafeArray containing the available values for that property.
• Required Properties. The properties to be retrieved from those products satisfying the specification search.

Sub PerformSpecificationSearch(ByRef oCatalog, 
    ByRef rsResults, ByRef iMatchesFound, ByVal sSearchHandle)
Dim rs
Dim sColList

sColList = "CategoryName,Name,i_classtype,SKU"

Set rsResults = oCatalog.PerformSpecificationSearch(sSearchHandle, 
cscProductClass + cscProductFamilyClass, , iMatchesFound, rs, 
sColList)
If (True = rsResults.EOF) Then
   Set rsResults = oCatalog.GuaranteedSpecificationSearch(
         sSearchHandle, cscProductClass + cscProductFamilyClass, , 
          iMatchesFound, rs, sColList)
End If 
End Sub

Note   It is recommended that a limit be placed on the size of the returned recordset to minimize the impact on overall performance.

Import/Export a Catalog

The Commerce Server catalogManager object supports the import and export of catalogs in XML and comma-separated [CSV] formats. The following code illustrates how to use the available import and export methods.

When importing catalog data in the form of XML, the source XML must conform to the published Commerce Server catalog XML schema [catalogXMLschema.xml]. Furthermore, when exporting catalog data in XML, the generated XML will conform to the same XML schema.

When exporting a catalog using the CSV format, the first line in the file contains a list of property names used by the products. The CSV file contains only products; no categories are exported or imported.

The import and export methods can be configured to operate synchronously or asynchronously.

Call exportCatalog

Public Sub exportCatalog()
Dim sDest As String
Dim sCatalogName As String

    sDest = "c:\temp\exportedCatalog"
    sCatalogName = "Books"

    Call oCatMgr.ExportCSV(sDest & ".txt", sCatalogName, True)
    Call oCatMgr.ExportXML(sDest & ".xml", sCatalogName, True)

End Sub 

Due to the limited descriptive capabilities of the CSV format, the ImportCSV method requires the product identifier property, list price property, and catalog name to be specified. The importXML method does not require these parameters.

The import methods allow updates to be performed to an existing catalog. However, the import methods do not support the concept of removing deleted products during the update process.

Call importCatalog 

Public Sub importCatalog()
Dim sDest As String
Dim sCatalogName As String
Dim sProductId As String
Dim sPriceProperty As String

    sDest = "c:\temp\exportedCatalog"
    sCatalogName = "ImportedCSVBooks"
    sProductId = "SKU"
    sPriceProperty = "cy_list_price"
    
    Call oCatMgr.ImportCSV(sDest & ".txt", sProductId, sPriceProperty, 
sCatalogName, True, True)
    
    Call oCatMgr.ImportXML(sDest & ".xml", True, True)

End Sub

**Note   **Each of these methods posts entries to the Windows Event Log, indicating the start and completion of the process.

© Microsoft Corporation. All rights reserved.