Microsoft Solution for Supplier Enablement

Architecture Guide

Microsoft Corporation
Service Release 1, May 2002

Applies to:
 Microsoft Solution for Supplier Enablement
 Microsoft Commerce Server 2002
 Microsoft BizTalk Server 2002

Summary: This guide provides information about the architecture of the Microsoft Solution for Supplier Enablement (MSSE) and its underlying product, Microsoft BizTalk Accelerator for Suppliers (AFS) Service Release 1. It also describes the various technologies that contribute to the solution. (38 printed pages)

Contents

Introduction
Solution Design
Solution Technologies
Solution Architecture
Performance and Scalability
URL Resources
Appendix A: Performance Characterization Hardware Details
Appendix B: Catalog Publishing Performance Characterization Data
Appendix C: Remote Shopping Performance Characterization Data
Appendix D: Purchase Order Reception Performance Characterization Data

Introduction

The Microsoft® Solution for Supplier Enablement (MSSE) integrates a number of different Microsoft products into a solution that allows suppliers of various sizes to begin trading electronically with their trading partners. These products include Microsoft BizTalk Server®2002, Microsoft Commerce Server®2002, Microsoft SQL Server™ 2000, and Microsoft BizTalk Accelerator for Suppliers (AFS) Service Release 1. AFS provides the integration of the other products required by this solution. Thus, a description of the architecture of the MSSE is the same as a description of the architecture of AFS.

This document consists of three sections. The first describes the design of the MSSE from the perspective of the three-phase design approach used by the Microsoft Solutions Framework (MSF):

• Conceptual Design
• Logical Design
• Physical Design

The second section describes the various underlying technologies that are used to create the MSSE. This includes the Microsoft Windows Server System servers products already mentioned, as well as more general technologies such as XML and the XML-based business document standards upon which the MSSE relies.

The third section describes the architecture of the MSSE. In other words, how all of the constituent products are integrated to achieve the solution.

Reader Guidance

Anyone reading this paper should also read the product documentation for Microsoft BizTalk Accelerator for Suppliers (AFS), Microsoft BizTalk Server, and Microsoft Commerce Server, each of which contains specific and detailed information about the corresponding products. Additionally, the MSSE Deployment Guide specifies network, software, and hardware configuration details, including network diagrams, hardware specifications, and step-by-step software configuration instructions.

Solution Design

The solution design of the MSSE consists of brief descriptions of the sequence of conceptual, logical, and physical designs that resulted in this particular implementation of supplier enablement.

Conceptual Design

The conceptual design of the MSSE can be expressed as a statement of the basic functional requirements of the three areas of functionality in the MSSE: catalog publication, remote shopping, and purchase order reception.

Catalog Publishing Requirements

The basic functional requirement of the catalog publishing functionality in the MSSE is that it provides a product catalog system capable of publishing catalog data to trading partners in the supported XML formats.

Remote Shopping Requirements

The basic functional requirement of the remote shopping functionality in the MSSE is that it provides a Web site capable of supporting relevant remote shopping sessions using the supported protocols.

Purchase Order Reception/Response Requirements

The basic functional requirement of the purchase order reception functionality in the MSSE is that it provides an order processing system capable of receiving purchase orders from trading partners in the supported XML formats.

Logical Design

The logical design of the MSSE can be expressed as a statement of the logical components required to implement the three areas of functionality in the MSSE: catalog publication, remote shopping, and purchase order reception.

The logical components for all three functional areas can be divided into five distinct categories, as follows:

• Data source. A data source is the origin of a type of data that is relevant to the MSSE. For example, the origin of product catalog data.
• Persisted data. Persisted data is the means through which MSSE data is stored and then retrieved at a later time. For example, the means through which catalog data is stored and maintained.
• User interface. A user interface is a way in which users interact with the MSSE. For example, the application used to manipulate catalog data, such as the price of a product.
• External component. An external component is an aspect of the MSSE that, by definition, is outside the control of the solution implementation itself. For example, the various applications and processes created and maintained by trading partners. The MSSE must successfully interact with these applications and processes, but these applications are in the exclusive control of the trading partners.
• Process. A process is an item of work that must be performed by the MSSE. For example, the delivery of a published catalog to a trading partner.

Within each of these categories, there are of course many ways in which, and many degrees to which, the architecture of the MSSE could be divided and analyzed. This document explains the analysis at a fairly high level.

Logical Components of Catalog Publishing

The logical components of the catalog publishing functionality in the MSSE, categorized as described above, are:

Data Sources

• Catalog Source. This logical component is the source of the product catalog data. This is either an XML or CSV file, or manual entry of the catalog data.

Persisted Data

• Catalog Store. This logical component is the place where the product catalog data is maintained. With respect to catalog publishing, it needs to support the ability to publish its contents to trading partners. In general, it needs to support mechanisms for becoming populated in the first place, and then being published repeatedly as it is modified over time.

User Interfaces

• Management Interface. This logical component is the interface through which the product catalogs are managed and published. This includes managing the products in the catalog, dealing with trading partner profiles, and initiating catalog publication.

External Components

• Trading Partner. This logical component is the other entity to which catalogs are published. It might be a peer company or it might be a marketplace of some kind.

Processes

• Catalog Transformation Process. This logical component is the process that transforms a catalog from one XML format to another.
• Catalog Transport Process. This logical component is the process that sends the transformed catalog to the trading partner.

Logical Components of Remote Shopping

The logical components of the remote shopping functionality in the MSSE, categorized as described above, are:

Data Sources

• Catalog Source. This logical component is the source of the product catalog data. This is either an XML or CSV file, or manual entry of the catalog data.

Persisted Data

• Catalog Store. This logical component is where the product catalog is maintained. With respect to remote shopping, it needs to support Web site browsing of catalog data. In general, it needs to support mechanisms for becoming populated in the first place, and then modified over time.

User Interfaces

• Remote Shopping Interface. This logical component is the interface through which products are chosen for purchase or through which products chosen elsewhere for purchase are configured. In other words, it is an e-commerce Web site that supports remote shopping sessions based on the protocols supported by the MSSE.

External Components

• Trading Partner. This logical component is the other entity that initiates remote shopping sessions, and properly handles their termination, using one of the supported protocols.

Processes

• Remote Shopping Process. This logical component is the process that handles the temporary redirection of the buyer to the supplier Web site. In other words, the processing required to begin and end a remote shopping session using one of the supported protocols.

Logical Components of Purchase Order Reception

The logical components of the purchase order reception functionality in the MSSE, categorized as described above, are:

Data Sources

• Purchase Order Source. This logical component is the source of the purchase order. The immediate source of the purchase order is the trading partner. Another important source of data in the purchase is the product data from a previously published catalog or remote shopping session.

Persisted Data

• Orders Store. This logical component is where purchase orders are maintained. With respect to the MSSE, it needs to support:
  • A mechanism for receiving order data supplied in purchase orders from trading partners.
  • A mechanism for accessing and modifying order data in the course of order fulfillment, for example, updating order status.

  In general, it needs to support mechanisms for becoming populated in the first place, and then modified over time.

User Interfaces

• Management Interface. This logical component is the interface through which the purchase orders are managed. This includes dealing with trading partner profiles and managing received purchase orders.

External Components

• Trading Partner. This logical component is the other entity from which purchase orders are received. It might be a peer company or it might be a marketplace of some kind.

Processes

• Purchase Order Transformation Process. This logical component is the process that converts a purchase order from one XML format to another.
• Purchase Order Transport Process. This logical component is the process that allows a purchase order to be received from a trading partner.
• Order Tally Process. This logical component is the process that performs tax and shipping processing, and which persists the order in the Orders Store logical component.
• Order Integration Process. This logical component is the process that integrates order reception with any existing back-end systems.

Physical Design

The physical design of the MSSE can be expressed as a statement of the physical components required to implement the logical components of the design, as described in the previous section.

Physical Components of Catalog Publishing

Like the logical components, the physical components of the catalog publishing functionality in the MSSE are divided into the following categories: data sources, persisted data, user interfaces, external components, and processes.

Data Sources

• Catalog Source. The physical component used to implement this logical component is the Catalog Manager module in Commerce Server Business Desk.

Persisted Data

• Catalog Store. The physical component used to implement this logical component is the Commerce Server catalog database in SQL Server.

User Interfaces

• Management Interface. The physical components used to implement this logical component are the Catalog Manager, Trading Partner Manager, and Catalog Publisher modules in Commerce Server Business Desk.

External Components

• Trading Partner. The physical component(s) used to implement this logical component are in the domain of the trading partner and not under the control of the MSSE.

Processes

• Catalog Transformation Process. The physical component used to implement this logical component is BizTalk Server. Specifically, the particular transform channel, messaging port, application integration component (AIC), and associated maps and document definitions for each supported catalog format.
• Catalog Transport Process. The physical component used to implement this logical component is BizTalk Server. Specifically, the particular transport channel and messaging port for each configured trading partner.

Physical Components of Remote Shopping

Like the logical components, the physical components of the remote shopping functionality in the MSSE are divided into the following categories: data sources, persisted data, user interfaces, external components, and processes.

Data Sources

• Catalog Source. The physical component used to implement this logical component is the Catalog Manager module in Commerce Server Business Desk.

Persisted Data

• Catalog Store. The physical component used to implement this logical component is the Commerce Server catalog database in SQL Server.

User Interfaces

• Remote Shopping Interface. The physical component used to implement this logical component is the AFS Solution Site, and specifically, those pages added or modified to support remote shopping.

External Components

• Trading Partner. The physical component(s) used to implement this logical component are in the domain of the trading partner and not under the control of the MSSE.

Processes

• Remote Shopping Process. The physical component used to implement this logical component is the AFS Solution Site, and specifically, those pages added or modified to support remote shopping.

Physical Components of Purchase Order Reception

Like the logical components, the physical components of the purchase order reception functionality in the MSSE are divided into the following categories: data sources, persisted data, user interfaces, external components, and processes.

Data Sources

• Purchase Order Source. The physical component(s) used to implement this logical component are in the domain of the trading partner and not under the control of the MSSE.

Persisted Data

• Orders Store. The physical component used to implement this logical component is the Commerce Server orders database in SQL Server.

User Interfaces

• Management Interface. The physical components used to implement this logical component are the Trading Partner Manager and Orders Manager modules in Commerce Server Business Desk.

External Components

• Trading Partner. The physical component(s) used to implement this logical component are in the domain of the trading partner and not under the control of the MSSE.

Processes

• Purchase Order Transformation Process. The physical component used to implement this logical component is BizTalk Server. Specifically, the particular transform channel, messaging port, and associated maps and document definitions for each supported purchase order format.
• Purchase Order Transport Process. The physical components used to implement this logical component include the external receive page in the AFS Solution Site, a message queue, and a BizTalk Server message queue receive function.
• Order Tally Process. The physical components used to implement this logical component include the internal receive page in the AFS Solution Site, a Commerce Server OrderGroup object, and the order processing pipeline invoked by that page to process the order.
• Order Integration Process. The physical component used to implement this logical component is BizTalk Server. Specifically, the XLANG schedule that can be extended to support order integration with back-end systems.

Solution Technologies

The MSSE relies on certain technologies about which you must be (or become) familiar. These include several emerging XML standards, the Microsoft BizTalk Accelerator for Suppliers (AFS) product, and several existing Microsoft Windows Server System products.

Developers working with the MSSE must be familiar with Web user interface technologies such as HTML, Active Server Pages (ASP), Visual Basic Scripting Edition (VBScript), Internet Explorer, DHTML, XML data islands, and so on. Familiarity with COM, including development of COM objects using Microsoft Visual Basic, is also required.

This section briefly reviews the main technologies used by the MSSE, including the relevant XML standards, and the roles of AFS, Commerce Server, BizTalk Server, and SQL Server.

XML Standards

XML has quickly become central to business-to-business (B2B) integration efforts. Microsoft Commerce Server 2002 has defined a number of XML formats, including those used to represent product catalogs and purchase orders. Companies like Commerce One and Ariba have also defined standards that include definitions for these same business documents, namely, xCBL and cXML, respectively.

Microsoft has responded to the emerging importance of XML by releasing Microsoft BizTalk Server 2002, one of the primary functions of which is the transformation of one XML format into another, and an associated user interface that makes this task easier.

This section provides an overview of the XML formats, or standards, that are important to the MSSE, including the Commerce Server XML standard, xCBL 3.0, cXML 1.1, cXML 1.2, SAP XML, and other related XML standards.

Commerce Server XML Standard

Microsoft Commerce Server 2002 defines XML formats for two documents that are directly relevant to Microsoft BizTalk Accelerator for Suppliers (AFS) — one for product catalogs and one for purchase orders.

The Commerce Server CatalogManager object has a method called ExportXML that can be used to export the contents of one or more catalogs to a file, formatted as XML. As shipped in Commerce Server 2002, this format is known as Commerce Server Catalog XML v2.0 format.

This updated API also supports export of an XML Data Reduced (XDR) file for the version 2.0 format of the current Commerce Server catalog schema. This file is used when the schema has been changed such that the maps in BizTalk Server need to be regenerated.

Commerce Server also defines an XML format for purchase orders, known as the Commerce Server Orders XML v1.0 format. Version 1.0 of this format can be successfully transformed using maps in BizTalk Server. This version did not change between Commerce Server 2000 and Commerce Server 2002.

These formats are important to AFS processing. The Commerce Server Catalog XML v2.0 format is exported from Commerce Server and submitted to the BizTalk Server transformation process during catalog publishing. The Commerce Server Orders XML v1.0 format is submitted to the Commerce Server Order Processing pipeline by the BizTalk Server transformation process during purchase order reception.

xCBL 3.0 Standard

xCBL (XML Common Business Library) is a non-proprietary, robust standard for business document exchange, and although it is authored and maintained by Commerce One, xCBL data format standards and specifications are available free of charge in prominent XML repositories for anyone to use. Microsoft BizTalk Accelerator for Suppliers (AFS) uses version 3.0 of this standard.

The BizTalk Server specification files (XDR files) for xCBL 3.0 that are included in AFS were obtained from the xCBL 3.0 XDR files available from Commerce One. The specification files were modified to work with BizTalk Editor and BizTalk Mapper. Commerce One periodically updates their XML schema definitions.

For more information about the xCBL standard, see http://www.xcbl.org/.

For remote shopping, Commerce One has adopted and extended the SAP Open Catalog Interface (OCI) 2.0 standard. Although Commerce One uses this standard in conjunction with the xCBL 3.0 standard, it is based on HTML form fields rather than XML.

For more information about the SAP OCI 2.0 standard, see http://www.commerceone.net/.

cXML 1.1 and cXML 1.2 Standards

cXML (commerce eXtensible Markup Language) is a streamlined standard for business document exchange, and although it is authored and maintained by Ariba, any company may freely use all aspects of this specification, subject to the terms of the Ariba license agreement.

Microsoft BizTalk Accelerator for Suppliers (AFS) supports versions 1.1 and 1.2 of this standard in its implementation.

Clarus has fully implemented version 1.1 of cXML.

The BizTalk Server specification files (XDR files) for cXML 1.1 and cXML 1.2 that are included in AFS were derived from the cXML 1.1 and cXML 1.2 DTD files available from Ariba. The specification files were modified to work with BizTalk Editor and BizTalk Mapper. Ariba periodically updates their XML schema definitions.

For more information about the cXML standards, see http://www.cxml.org/.

SAP Interface Repository Standard

The XML-based Interface Repository (IFR) is part of the Internet Business Framework. Its aim is to publish all standard SAP interfaces centrally as XML interfaces in agreement on W3C standards, and to provide the customer with the necessary infrastructure for business scenarios.

SAP Open Catalog Interface Standard

Open Catalog Interface (OCI) is the interface between catalogs and Commerce Server 2002. The SAP OCI uses standard Internet protocols, which have been configured to work with AFS. The OCI standard consists of two separate and distinct sections: the outbound section and the inbound section.

The outbound section sends and defines information from AFS to the catalog application. The information you send can include URLs and login data.

The inbound section sends and defines information from the catalog to AFS. The information you send can include items selected from the catalog, such as item descriptions, quantities ordered, and prices.

The following figure shows how catalogs are integrated with AFS using the SAP OCI standard.

Figure 1

Other XML Standards

The MSSE does not directly support other XML standards. But because BizTalk Server is used for XML transformation, and because BizTalk Server is designed to support generic XML transformation, it is straightforward to extend the AFS architecture to support other standards.

Maps and orchestrations in BizTalk Server can be customized to support other XML standards such as:

• RosettaNet (http://www.rosettanet.org/)
• Health Insurance Portability and Accountability Act, or HIPAA (http://cms.hhs.gov/hipaa/)

Also, specific vertical industries or individual companies may have developed their own private XML data formats.

Role of Microsoft BizTalk Accelerator for Suppliers

Microsoft BizTalk Accelerator for Suppliers (AFS) is essentially the same as the MSSE. This new accelerator product for BizTalk Server is what provides the basic functionality of the MSSE.

AFS includes:

• The various BizTalk maps, document definitions, channels, messaging ports, AICs, and receive functions that allow the transformation of a product catalog in a default catalog schema into the supported XML catalog format, and that allow purchase orders in the supported purchase order format to be transformed and processed into the Commerce Server orders database.
• Three new modules for Commerce Server Business Desk, designed specifically for managing the catalogs and orders related to supplier enablement.
• A new Commerce Server Solution Site, called the AFS Solution Site, that incorporates the functionality required to support purchase order reception and remote shopping using either of the supported protocols.
• Extensive online documentation that provides detailed instructions about how to use the various functional areas of AFS.
• Additional documents that provide guidance about how to extend AFS in several ways.

Role of Commerce Server 2002

Microsoft Commerce Server 2002 is central to the MSSE. For example, AFS assumes that you are using the Commerce Server Product Catalog System for the catalog you want to provide to your trading partner. One of the new Commerce Server Business Desk modules supplied with AFS, called Catalog Publisher, is used to initiate the process of transforming and transporting your Commerce Server catalog to your trading partner.

AFS also assumes that you are using the Commerce Server orders database to store and manage the orders you receive from your trading partners. Orders, when received, are transformed and placed into the orders database, and another new Business Desk module provided with AFS, called Orders Manager, is used to view and process those orders.

Specifically, AFS and the MSSE extend Commerce Server in the following ways:

• AFS extends Business Desk by adding a new category called Accelerator for Suppliers that contains three new Business Desk modules: Trading Partner Manager, Catalog Publisher, and Orders Manager.

  The Trading Partner Manager module is used to create and maintain trading partner profiles. Such profiles define the name of the trading partner, the format of the XML catalog the trading partner can process, and the name of BizTalk Server transport channel used to deliver the catalog to the trading partner.

  The Catalog Publisher module is used to send the contents of a Commerce Server 2002 catalog in an XML format that is suitable for a particular trading partner. The required catalog transformation is accomplished using BizTalk Server 2002.

  The Orders Manager module is used to manage purchase orders received from trading partners that are selling your products and/or services using the catalogs you have published.

• AFS extends the Commerce Server Solution Sites by adding new pages and replacing some existing pages in order to provide purchase order reception and remote shopping functionality.

Another way in which AFS makes explicit use of Commerce Server is its use of a Commerce Server pipeline object to move order details from a purchase order received from a trading partner into the Commerce Server orders database.

Role of BizTalk Server 2002

Microsoft BizTalk Accelerator for Suppliers (AFS) uses BizTalk Server 2002 to transform XML files from one format into a different XML format. This includes the transformation of Commerce Server Catalog XML v2.0 files into their xCBL 3.0, cXML 1.1, or cXML 1.2 equivalent. It also includes the transformation of purchase orders formatted using the xCBL 3.0 standard, the SAP XML standard, the cXML 1.1 standard, or the cXML 1.2 standard into their Commerce Server Order XML v1.0 equivalent.

BizTalk Server also provides a mechanism for sending transformed catalogs to your trading partners. The mechanism chosen largely depends on the capabilities of your trading partners. They might have a URL to which you can post the transformed catalog for automated processing. On the other hand, some trading partners might require you to transmit the catalog by some other means, such as a file upload, after which manual processing may be required.

For order reception, the BizTalk Orchestration Designer and an associated XLANG schedule are used to control the sequence of processing steps that are performed in the course of converting a xCBL 3.0, SAP XML, cXML 1.1, or cXML 1.2 purchase order into a form that can be stored in your Commerce Server orders database.

BizTalk Server application integration components (AICs) are used in several situations where special processing is required to properly complete a catalog transformation.

Role of SQL Server 2000

Microsoft SQL Server 2000 provides the underlying data persistence for catalog and order data within the MSSE. This dependency is inherited from the Commerce Server dependency on SQL Server.

Solution Architecture

This section provides a description of the architecture of the MSSE, first from a high-level, and then in a detailed manner for each of the functional areas of the MSSE: catalog publishing, remote shopping, and purchase order reception/response. Readers should also review the MSSE Deployment Guide for more information about the MSSE network, software, and hardware configuration details. The MSSE Deployment Guide provides the implementation details for deploying a core-medium or medium-level solution.

The following figure illustrates the architecture of the MSSE and shows the Commerce Server Business Desk tasks required to create a trading partner profile, publish a catalog to a trading partner, and work with purchase orders received from a trading partner. These tasks are labeled with circled numbers and are explained following the figure.

The figure also shows how data flows between various entities in the course of catalog publication and purchase order reception. Particular data flows are labeled with letters and are explained following the figure.

Figure 2

The workflow for catalog publication and purchase order reception for MSSE consists of the following tasks:

1. In order to publish a catalog to a trading partner using AFS, your catalog data must be in the Commerce Server Product Catalog System. You can either create a new catalog and its products using Business Desk interactively, or you can import a catalog from another source.
2. You use the Trading Partner Manager module in Business Desk to create a trading partner profile. A trading partner profile contains information about the catalog publication format (protocol) and target location for your catalogs. It also contains your account information, for example, the shared secret for authentication at the targeted trading partner.
3. You use the Catalog Publisher module in Business Desk to create a catalog publication. A catalog publication contains information about your Commerce Server catalog, the trading partner profile, your supplier identifier, the catalog language, and the credential domain of your supplier identifier. An example of a credential domain is the Dun & Bradstreet Data Universal Numbering System (DUNS). For more information, see Publishing Catalogs to Trading Partners.
4. In the Catalog Publisher module, you select the catalog publication you created and publish the catalog to a trading partner.
5. You view and update the fulfillment status of your orders received from trading partners in the Orders Manager module in Business Desk.

Data flows through AFS and between AFS, trading partners, and buyers occur in the following sequence:

1. A. Catalog Editor module reads and writes catalog data.
   The Catalog Editor module can be used to interactively enter catalog data, or to import catalog data from an XML or CSV (comma-separated values) file. Catalog data is read from and written to the catalog database using Commerce Server catalog objects.
2. B. Catalog Publisher module exports catalog data.
   When a catalog is published, the Catalog Publisher module uses the ExportXML method of the Commerce Server CatalogManager object.
3. C. Catalog data is placed in a shared directory as an XML file.
   The catalog data is copied to a shared directory as an XML file in Commerce Server Catalog XML v2.0 format. BizTalk Server (BTS) uses a file receive function to retrieve the file from the shared directory.
4. D. BTS sends the transformed catalog data to the trading partner.
   BTS transforms the catalog data to one of the following formats: xCBL 3.0, cXML 1.1, or cXML 1.2, depending on what the trading partner accepts, as configured in the trading partner profile.
5. E. Buyer and trading partner interact through a buyer application.
   The buyer shops in the buyer application provided by the trading partner, using a data format that is not known, nor particularly relevant, to AFS.
6. F. Trading partner initiates remote shopping when configured.
   If the scenario includes remote shopping, the trading partner initiates (and the supplier terminates) remote shopping using one of the standards: SAP OCI 2.0, cXML 1.1, or cXML 1.2.
7. G. Buyer shops directly on the supplier Web site.
   If the scenario includes remote shopping, the buyer shops directly on the supplier Web site.
8. H. Trading partner sends a purchase order to the supplier.
   The trading partner sends purchase order data to a receive page in the AFS Solution Site in xCBL 3.0, cXML 1.1, cXML 1.2, or SAP XML format.
9. I. Purchase order is routed to BTS for transformation.
   The receive page in the AFS Solution Site places the purchase order data, still in xCBL 3.0, cXML 1.1, cXML 1.2, or SAP XML format, into a message queue, from which a BTS receive function retrieves it.
10. J. BTS sends the transformed purchase order to Commerce Server.
    BTS transforms the purchase order data into Commerce Server Order XML v1.0 format and sends it to another receive page in the AFS Solution Site.
11. K. Commerce Server processes and saves the purchase order.
    After running the Order Processing pipeline, the second receive page saves the purchase order data to the orders database using Commerce Server order objects (for example, the OrderGroup object).
12. L. Orders Manager module manipulates the purchase orders.
    The Orders Manager module reads and writes purchase order data to and from the orders database using Commerce Server order objects.
13. M. Commerce Server writes an order response message to a Message Queuing queue.
    After order processing is complete Commerce Server writes an order response message to a Message Queuing queue on the BizTalk Server.

    Note An asynchronous order response message is supported for xCBL 3.0 and SAP XML formatted messages.

14. N. BizTalk Server sends an order response message back to the trading partner.
    The BizTalk Server Message Queuing receive function retrieves the message from the queue and then BizTalk Messaging transforms and transports the order response message to the trading partner.

Catalog Publishing Architecture

In the MSSE, catalog publishing begins when a business manager clicks the Refresh button in Commerce Server Business Desk. The following figure shows a supplier using Commerce Server 2002, BizTalk Server 2002, and the extensions provided by Microsoft BizTalk Accelerator for Suppliers (AFS) to upload their product catalog to a trading partner. An important aspect of the flow concerns the format of the data at various points, as shown by the lettered circles and the data format key that follows the figure.

Figure 3

Data Format Key:

A: Commerce Server Catalog XML v2.0, or CSV

B: XML file

C: Commerce Server Catalog XML v2.0

D: xCBL3.0, cXML 1.1, or cXML 1.2 catalog

Starting at the top and working toward the bottom, the figure above shows the following steps in publishing catalogs:

1. Using the Refresh Catalog task in the Commerce Server Business Desk Catalog Editor module (supplied with AFS), the catalog data is exported from the Commerce Server catalog database by the ExportXML method, in the Commerce Server Catalog XML v2.0 format, and sent to BizTalk Server 2002.
2. BizTalk Server transforms the catalog data into one of the following three formats, depending on the target trading partner: xCBL 3.0, cXML 1.1, or cXML 1.2. It then posts the catalog to a URL provided by the trading partner. Alternatively, BizTalk Server can be configured to write the transformed XML to a file, after which some other method of trading partner upload can be used.
3. The trading partner processes the catalog data in preparation for making the associated products and/or services available for sale.

Preparation for catalog publishing involves the following steps, many of which are performed automatically by the installation process, or which can be done manually using files and instructions provided in the AFS Software Development Kit (SDK):

1. Establish a Commerce Server 2002 catalog. Use the Commerce Server Business Desk Catalog Manager module (supplied with Commerce Server 2002) to import a catalog that is in either XML or CSV (comma-separated value) format. Alternatively, catalogs can be created and populated with products directly using Business Desk.
2. Configure BizTalk Server. The installation process performs much of the BizTalk Server configuration automatically. Alternatively, these steps can be performed manually using BizTalk Messaging Manager:
   • Create organizations to define the source (Commerce Server 2002 Product Catalog System) and destination (for example, Commerce One marketplace) trading partners.
   • Configure messaging ports. Messaging ports define how documents are enveloped, secured, and transported to a designated destination organization or application.
   • Configure channels in BizTalk Server. Channels define the source of documents and specific processing steps that are performed by BizTalk Messaging Services before a document is delivered to the destination designated by the messaging port with which the channel is associated. These services include document transformation and validation using XML transformation maps and schemas, respectively. These channels should be given friendly names as they appear in the Business Desk modules for users to select from.
3. Configure Commerce Server. Perform the following configuration steps in the Business Desk Trading Partner Manager module (supplied with AFS) to establish a sales channel:
   • Select the appropriate destination catalog format.
   • Select the appropriate channel in BizTalk Server for the trading partner to which the catalog will be published.

The installation process performs much of the configuration required for catalog publishing automatically. For more information about the installation process and the configuration that must be performed following installation, see the Microsoft BizTalk Accelerator for Suppliers Installation Guide (a separate HTML file) and the "Operations Overview" topic in the AFS Online Help.

For installations where manual configuration is required, the AFS Software Development Kit (SDK) provides source code files and various XML files for configuring Commerce Server and BizTalk Server. These files include:

• ASP files that implement the Catalog Publisher module. The process of publishing a catalog is initiated when a business manager clicks the Publish button in this module.

  New Business Desk configuration files are also included that may be used to ease the integration of the new modules into Business Desk.

• Maps in BizTalk Server used to perform the transformation of a Commerce Server Catalog XML v2.0 file into the xCBL 3.0 format, the cXML 1.1 format, or the cXML 1.2 format.

  You will need to create new map files in BizTalk Server if you have added product properties that you want mapped, or removed product properties that are currently mapped. The product properties in the Commerce Server map are based on those properties in the sample catalog AdventureWorks.xml.

• BizTalk Server specification files for the default Commerce Server catalog schema, the xCBL 3.0 catalog schema, the cXML 1.1 catalog schema, and the cXML 1.2 catalog schema. These files are required if you have modified your Commerce Server catalog schema and need to use BizTalk Mapper to create custom versions of the map files required for the catalog transformations.
• Microsoft Visual Basic source files for three BizTalk Server application integration components (AICs), one for xCBL and one for each supported version of cXML. These AICs are invoked to perform minor post-transformation processing to ensure that the resulting XML is completely conformant to the xCBL 3.0, cXML 1.1, and cXML 1.2 standards. This is essentially a work-around for certain minor flaws in the transformation processing, but serves as a good example of how such work-arounds can be effectively implemented.
• Microsoft Visual Basic source files for a COM component used to wrap published catalogs in a BizTalk Framework 2.0 envelope. The envelope stores information used by the AICs and is stripped before the catalog is sent to the trading partner.

Remote Shopping Architecture

The architecture of the remote shopping functionality within the MSSE differs enough between the two supported protocols that they are presented separately in the sub-sections that follow.

Open Catalog Interface (OCI) Remote Shopping Architecture

Microsoft BizTalk Accelerator for Suppliers (AFS) validates the organization user for trading partners based on the Open Catalog Interface (OCI) 2.0 Outbound Section message. The OCI Outbound Section could be originated either on the Commerce One EBD application or the SAP EBP application. Validation is successful if the trading partner is pre-registered in Commerce Server Business Desk. Anonymous users are not validated and, therefore, are denied access to the supplier AFS site.

OCI supports remote shopping at the supplier level, but not at the product level. When a user chooses to initiate a remote shopping session, a new browser opens (or their existing browser is re-directed) to the chosen supplier site. On the supplier site, they can shop normally, viewing products, and adding and removing products from their remote basket. When they check out of the remote basket, information about the remotely selected products is returned to their buyer application and displayed in its basket.

The following figure, and the associated numbered descriptions that follow, provides a more detailed, step-by-step account of this process.

Figure 4

1. A user shopping on an OCI-based Web site chooses to initiate a remote shopping session with a supplier site that is using AFS. This results in a new browser window opening, or the current browser redirecting to the established starting page for a remote shopping session.
2. The starting page for a remote shopping session is the page OCIAccept.asp. This page processes the OCI Outbound Section, extracting the required information from the form fields.
3. The starting page also creates a remote shopping session and a remote basket for the session. It validates the extracted information against the organization profile and uses the purchasing manager credential of the organization to create a registered user session. It verifies the user name and password from the OCI outbound message.
4. The page OCIAccept.asp ends by redirecting the user to the page RemoteBasketNav.asp.
5. For OCI-based remote shopping sessions, the page RemoteBasketNav.asp always redirects the user to the page RemoteBasket.asp.
6. From the page RemoteBasket.asp, the user shops on the supplier site, freely adding and removing products from their remote basket, and visiting the other pages on the site.
7. Upon remote shopping checkout, the page FormPostRemoteBasket.asp runs. This page displays a form in the user browser with the contents of the remote basket stored as hidden form fields (as defined by the inbound section of the OCI 2.0 standard). The action page associated with the form is a URL supplied with the outbound section, and specifies the page in the buying application that is used to process the inbound section.

When the user clicks the submit button on the page FormPostRemoteBasket.asp, or when it automatically submits itself, the form containing the products chosen in the remote shopping session is (HTTP) posted to the OCI-based Web site. This completes the RoundTrip process.

For more detailed information about the RoundTrip remote shopping architecture, see "Implementation Details" in the AFS Online Help.

Punchout (cXML 1.1 and 1.2) Remote Shopping Architecture

MSSE includes remote shopping functionality for Punchout using the cXML 1.1 and cXML 1.2 standards. This format can be used with processing for Ariba Punchout or for Clarus Tap Out.

Ariba Punchout

In the Microsoft BizTalk Accelerator for Suppliers (AFS) implementation, when users shop in the Ariba buyer application and choose to add a product to their shopping basket that the associated supplier has designated as remotely configurable, the buyer application opens a browser that displays a remote basket page on the supplier Web site. The remote basket already contains the chosen product.

As provided in AFS, the remote basket page allows users to freely manipulate their remote basket, adding or removing products as they choose. When the users check out of the remote basket, the browser is closed and they are returned to the Ariba buyer application where their remotely selected products are now displayed.

The following figure provides a more detailed, step-by-step account of this process.

Figure 5

1. A user using an Ariba buyer application adds an item to their local basket that has been configured for Punchout. This results in a Punchout setup request being sent to the page punchout.asp on your supplier Web site. The request typically specifies a particular product for which the Punchout session is being initiated.
2. Remote shopping sessions are authenticated based on the sender node (organization and shared secret) in the XML PunchOutSetupRequest message.
3. The page punchout.asp builds a remote basket for the Punchout session and puts any items included in the Punchout setup request into that basket. It then sends back a Punchout setup response message (cXML PunchOutSetupResponse messsage) to the buyer application. This response includes the URL for the page RemoteBasketNav.asp. This URL includes an ID generated for this user as one of the query string arguments.
4. A Punchout browser is launched by the Ariba buyer application.
5. The browser is directed to the URL provided in the Punchout setup response (step 2). The URL includes the Auth Ticket of the user, which uniquely identifies the user to the supplier site and displays the associated catalog set.
6. Logic in the page RemoteBasketNav.asp redirects the user to one of five different pages, based on the specified operation (Create, Edit, or Inspect), and whether or not a selected item has been specified.

   In the AFS implementation, the Create and Edit operations are handled in the same manner.

7. In the AFS Solution Site, Inspect operations only allow navigation between the pages InspectBasket.asp and InspectProduct.asp. The Create and Edit operations allow the user to freely navigate between the home page, the product catalog pages, and the basket page.
8. If the specified operation is Create or Edit, the user can also navigate to and from other pages in the site. If the specified operation is Inspect, the user is restricted to the basket and product pages, and is not allowed to add additional products to their basket. If a problem was detected when the remote shopping session began, and the user was redirected to the page default.asp, continuing on to enter the supplier site does not constitute a remote shopping session.
9. When the user clicks the checkout button on either the page RemoteBasket.asp or the page InspectBasket.asp, the page FormPostRemoteBasket.asp is invoked. The page FormPostRemoteBasket.asp displays a button for submitting the order to the trading partner. Usually, before the user has a chance to click this button, client-side script on the page will automatically submit the order for them. During the Inspect Operation, the Punchout message does not contain the item in the details.
10. The page FormPostRemoteBasket.asp builds the Punchout order message (cXML PunchOutOrderMessage), which includes the details of the items to be purchased, and generates an auto-submitting form that posts itself to the URL supplied in the original Punchout setup request. It then logs the user out of the site, ending the Punchout session. During Inspect operations the PunchOutOrderMessage does not contain the <itemln> node. For example, the item/product details are not returned to the buyer application.

For more detailed information about the Punchout remote shopping architecture, see "Implementation Details" in the AFS Online Help.

Clarus Tap Out

Remote shopping from the Clarus trading partner is known as Tap Out and uses the cXML 1.1 standard.

Users can return to the same supplier Web site and update the contents of their remote shopping basket created during a prior remote shopping session using the Edit operation. An Edit operation is used so that those products are shown again in their remote basket.

As with the Ariba implementation, remote shopping users can freely manipulate their remote basket, adding or removing products as they choose. When they check out of the remote basket, the browser is closed and the users are returned to the Clarus buyer application, where their remotely selected products are now displayed.

Purchase Order Reception Architecture

In Microsoft BizTalk Accelerator for Suppliers (AFS), purchase order reception begins when a trading partner (HTTP) posts a purchase order to the ASP page you have established for that purpose. The reception of a purchase order ends when the purchase order data is saved to the Commerce Server orders database. Processing of the purchase order continues as the order is fulfilled and shipped to the customer.

The following figure, and the associated numbered descriptions that follow, describe the steps involved in the purchase order reception process.

Figure 6

1. Purchase order reception begins when the trading partner (HTTP) posts a purchase order in one of the supported XML formats to the URL you provided them for this purpose. The trading partner must include the XML format being used in the query string argument in the URL.
2. In the page ReceivePO.asp the purchase order undergoes preprocessing so that BizTalk Server (BTS) can properly transform it; this preprocessing is different for each supported standard. Next, the XML comprising the purchase order is enclosed in a BizTalk Framework 2.0 envelope, and the trading partner name and standard are stored as an envelope property. For xCBL 3.0 and SAP XML purchase orders, the OrderResponse message is constructed (using XSL to transform the Order Response message) and placed in another envelope property.

   The purchase order XML document is then placed in one of four different Message Queuing queues, based on the standard used. (Each of the four protocol-specific receive functions in BTS is watching a different message queue, waiting for purchase orders to be placed there.) The page then waits (polls) for the Message Queuing acknowledgement (dotted line from the Message Queuing queue to 2).

   Note If Commerce Server and BTS are installed on different computers, Message Queuing is responsible for moving the purchase order XML document from the former to the latter.

   For xCBL 3.0 and SAP XML purchase orders, the HTTP response (dotted line from 2 to 1) only contains the HTTP status indicating whether the purchase order was successfully received and passed to the Message Queuing queue.

   For cXML 1.1 and 1.2 purchase orders, the HTTP response also includes the OrderResponse message (constructed using XSL to transform the OrderRequest message).

   For more information about the page ReceivePO.asp, see "Purchase Order Reception from the Trading Partner" in AFS Online Help.

3. One of four different BTS Message Queuing receive functions retrieves the purchase order from its corresponding message queue and passes it to the corresponding transform channel. This is the start of BTS processing.
4. Using the appropriate map, the BTS transform channel converts the purchase order from its source XML format (xCBL 3.0, SAP XML, cXML 1.1, or cXML 1.2) to the Commerce Server Order XML v1.0 format. AFS provides distinct maps for use by BTS for transformation from each of the four supported formats. You can create maps for transforming from other XML formats.

   Next, the transformed XML document is passed to the corresponding transform messaging port.

   Note Due to the architecture of BTS, there are four distinct combinations of transform channel and messaging port, one for each of the four supported source XML formats. All four of these channel/messaging port pairs pass the transformed XML document to an instance of the same XLANG schedule.

   For more information about transform channel processing, see "Transform Channel and Messaging Port" in the AFS Online Help.

5. The transform messaging port passes the transformed XML document to an instance of the XLANG schedule. The transform messaging port does not perform any additional processing of the document. The same XLANG schedule is used for all of the different XML formats.

   For more information about transform messaging port processing, see "Transform Channel and Messaging Port" in the AFS Online Help.

6. As delivered, the XLANG schedule only performs a single action: (HTTP) posting the transformed XML document to the configured ASP receive page (_recvpo.asp) in the Commerce Server 2002 supplier site. This is accomplished by passing the transformed XML document to a transport channel.

   For more information about XLANG schedule processing, see "XLANG Schedule" in the AFS Online Help.

7. The transport channel does not perform any processing on the transformed XML document. It passes the document through to the transport messaging port.

   Note Because the document has already been transformed to the Commerce Server Order XML v1.0 format, and because it is being posted to a single ASP receive page regardless of the source XML format, a single transport channel/messaging port pair is used.

   For more information about transport channel processing, see "Transport Channel and Messaging Port" in the AFS Online Help.

8. The transport messaging port sends the transformed XML document to the ASP receive page _recvpo.asp.
9. The ASP receive page (_recvpo.asp) in the Commerce Server supplier site retrieves the trading partner name and originating message standard from the BTF 2.0 envelope. For xCBL3.0 and SAP XML purchase orders, the OrderResponse message is also retrieved from the BTF 2.0 envelope. Then the envelope itself is removed. The trading partner is verified, and if necessary, an organization profile is created for the trading partner.

   For more information about how the trading partner is identified so that its organization profile object can be retrieved, see the "VerifyOrganization" routine in the AFS Online Help.

   The purchase order XML document is then converted into an equivalent Dictionary object, which is passed to the Order Processing pipeline. If the pipeline completes successfully, the following steps are taken:

   • The order is saved to the Commerce Server orders database.
   • If the purchase order originated as an xCBL 3.0 OrderRequest, the OrderResponse message passed in the BTF 2.0 envelope is sent to the trading partner.

   For more information about the processing that occurs in the page _recvpo.asp, see "Purchase Order Reception from BizTalk Server" in the AFS Online Help.

10. The Order Processing pipeline runs to process the purchase order.
11. After the order has been saved to the Commerce Server orders database, you can use the Orders Manager module in Commerce Server Business Desk to manage the order during the fulfillment process.
12. A BizTalk Server Message Queuing receive function retrieves the messages and BizTalk Messaging delivers the message to the trading partner, routing the message to the appropriate channel and message port based on the destination organization configured in the header of the envelope message.

For more detailed information about the purchase order reception architecture, see "Implementation Details" in the AFS Online Help.

Performance and Scalability

This section provides a high-level review of the performance and scalability characteristics of the Microsoft Solution for Supplier Enablement (MSSE).

Summary

The Microsoft BizTalk Accelerator for Suppliers (AFS) Solution Site included in the MSSE is based on the Commerce Server Retail Solution Site. Although the MSSE usage profile suggests that the B2B-oriented MSSE site will experience less Web browsing traffic than a retail Web site, an important performance goal of the MSSE was to maintain Web site performance (insignificant performance degradation) while also processing the additional B2B transactions that occur in the MSSE.

The medium deployment configuration, as defined in the MSSE Deployment Guide, is the base configuration for the site profile. It is recommended that users determine capacity requirements based on the methodology defined in the document "Microsoft Commerce Server 2000 Supplier Site Performance Characteristics: Transaction Cost Analysis," which can be found at http://www.microsoft.com/commerceserver/performance.

Users can refer to this document to review the relative impact of the MSSE B2B transactions on Solution Site performance. MSSE B2B transaction performance is CPU-bound.

The core-medium deployment configuration is intended for small businesses that do not anticipate a need to scale.

Performance characterization data for the three main feature areas (catalog publishing, remote shopping, and purchase order reception/response) on the two supported deployments (core-medium and medium) is included in the appendices.

Interactions in the AFS Solution Site

This section provides details about the interactions that occur between the MSSE and a trading partner.

Retail Shopping

Retail shopping interactions are simulated using the Application Center Testing (ACT) tool to stress the site to a "steady state" of approximately 65%-75% CPU utilization, which represents the performance "baseline." Retail shopping includes the interactions of many concurrent users visiting the site. The interactions include:

• Default page. Browsing the first page of the site.
• Checkout. Browsing the catalog, adding products to the basket, and checking out.
• Basket Management. Adding a product to the basket, deleting a product from the basket, and viewing the basket.
• Search. All interactions related to searching for products.

Catalog Publishing

Catalog publishing interactions include publishing catalogs of various sizes to a file in both the cXML 1.2 and xCBL 3.0 formats. The performance data includes:

• Time in seconds required to export the catalog from the Commerce Server database and write the XML catalog document file to the BizTalk Server (BTS) file share.
• Time in seconds required for BTS to retrieve the XML catalog document from the BTS file share, transform it to the cXML 1.2 or xCBL 3.0 format, and write it to the file share configured for the trading partner.

Additionally, the impact of this processing on the AFS Solution Site was measured by determining the number of ASP pages served before and during the processing of these interactions.

There is an impact on performance while publishing catalogs, but the duration of that impact is relatively short when publishing catalogs of less than 60,000 SKUs. It is recommended that catalogs containing more than 60,000 SKUs be broken into multiple, smaller catalogs.

Note Performance characterization was not performed for the cXML 1.1 standard, although it is reasonable to assume that it would be very similar to the results for cXML 1.2 standard.

For performance data related to catalog publishing, see APPENDIX B: Catalog Publishing Performance Characterization Data.

Remote Shopping

Remote shopping interactions include the remote shopping setup requests and checking out remote shopping baskets of various sizes. The performance data includes:

• Time in seconds required to make a remote basket setup request on the AFS Solution Site.
• Time in seconds required to checkout remote shopping baskets of various sizes.

Performance was characterized for both the cXML 1.2 and OCI 2.0 protocols.

Additionally, the impact of this processing on the AFS Solution Site was measured by determining the number of ASP pages served before and during the processing of these transactions.

There is an impact on performance while processing remote shopping interactions, but the duration of that impact is relatively short. If it is anticipated that remote shopping baskets will include more than 100 line items, administrators should consider scaling the Commerce Server Web servers by adding additional Web servers to a Web farm or by using faster processors.

Note Performance characterization was not performed for the cXML 1.1 standard, although it is reasonable to assume that it would be very similar to the results for cXML 1.2 standard.

For performance data related to remote shopping, see APPENDIX C: Remote Shopping Performance Characterization Data.

Purchase Order Reception/Response

Purchase order reception interactions include receiving and processing purchase orders of various sizes and in various frequencies in the cXML 1.2, SAP XML, and xCBL 3.0 formats. The performance data includes:

• Time in seconds required for the AFS Solution Site to receive a purchase order through HTTP post and write that XML purchase order document to the Message Queuing queue on the BizTalk Server (BTS).
• Total time in seconds required for the AFS Solution Site to receive a purchase order through HTTP post, write that XML purchase order document to the Message Queuing queue, retrieve the XML purchase order document from the queue, transform that document from the cXML 1.2, SAP XML, or the xCBL 3.0 format into the Commerce Server XML format, and write it to the Commerce Server database through the Commerce Server Order Processing pipeline (OPP).

The impact of this processing on the AFS Solution Site has been measured by determining the number of ASP pages served before and during processing of these transactions.

Note Performance characterization was not performed for the cXML 1.1 standard, although it is reasonable to assume that it would be very similar to the results for cXML 1.2 standard.

NoteThe xCBL 3.0 and SAP XML formats are significantly more complex than the cXML 1.2 format, which results in larger XML documents. The larger documents require additional time and resources to process and thus have a greater impact on performance.

For performance data related to purchase order reception, see APPENDIX D: Purchase Order Reception Performance Characterization Data.

Usage Profile

The performance of the MSSE exceeds the following usage profile:

• Expected catalog publication activities include publishing a 10,000 SKU catalog to 10 trading partners in a week. One half of the catalogs are published in the cXML 1.2 format and the other half in the xCBL 3.0 format.
• Expected purchase order volume is 100 purchase orders per day, each containing 10 to 100 line items. The purchase orders are evenly distributed in the cXML 1.2, SAP XML, and the xCBL 3.0 formats..
• Expected remote shopping volume is 1000 remote shopping sessions per day. It is expected that 100 percent of the purchase orders come from remote shopping sessions. Therefore, the expected remote shopping checkout volume is also 100 remote shopping checkouts per day, each containing 10 to 100 line items. One half of the remote shopping sessions are using the cXML 1.2 standard and the other half are using the OCI 2.0 standard.
• Expected Web site usage is significantly less than the traffic projected for the Commerce Server Retail Solution Site, upon which the AFS Solution Site is based.

For more information on the process of developing an online usage profile, see the document "Commerce Server 2000: Creating a Usage Profile for Capacity Planning," which can be found at:http://www.microsoft.com/commerceserver/performance.

Site Profile

The site profile addresses a medium-sized business with the following characteristics:

• Catalog contains 10,000 SKUs
• 10 trading partners
• 10 catalog publications
• The trading partners use orders in the cXML 1.2, SAP XML, and xCBL 3.0 formats.
• The trading partners use remote shopping in the cXML 1.2 and OCI 2.0 formats.

Test Tools

The Application Center Testing (ACT) tool was used to perform these tests.

Scalability Considerations

This section considers a number of factors related to the scalability of various technologies used by the MSSE.

Commerce Server (AFS Solution Site)

The AFS Solution Site is typically deployed on a separate Web server than the Business Desk Web site. Administrators can scale-out the AFS Solution Site by creating a Web farm that uses Network Load Balancing (NLB). Availability will be enhanced through the redundancy provided by the Web farm and performance will be enhanced because the load will be distributed across the servers in the Web farm. Increased Web site traffic and increased complexity of the content in the Web site will both impact performance. If CPU utilization remains consistently above 80 percent, additional servers should be added to the Web farm. Alternatively, performance can be scaled-up by substituting Web servers with faster CPUs.

Commerce Server (Business Desk Site)

The Business Desk Web site hosts the administration user interface and is typically subject to less traffic than the AFS Solution Site. As required, this Web site can be scaled using similar means as the AFS Solution Site.

BizTalk Server

BizTalk Server (BTS) can be scaled-up by adding additional memory and by increasing CPU speed. BTS also supports scaling-out the Messaging Services by adding multiple BTS Servers into BizTalk Groups. The MSSE has not been tested with this configuration.

SQL Server

SQL Server can be scaled-up by adding additional memory and by increasing CPU speed. Commerce Server and BTS product documentation defines how to improve performance by scaling-out the deployment of the databases used by these applications across multiple SQL servers. The MSSE has not been tested with this configuration.

URL Resources

The following URL provides additional information:

Microsoft Solution for Supplier Enablement:

http://www.microsoft.com/business/solutions/MSSE/

Appendix A: Performance Characterization Hardware Details

Results of this type of performance testing may vary depending on the hardware and software configuration details of each MSSE implementation.

This appendix shows the hardware used for performance characterization in each of the two tested deployments: core-medium and medium.

Core-Medium Deployment Hardware Configuration

The following table lists the tested hardware configuration for the core-medium deployment configuration.

* Network adapters are all 100baseT.

Medium Deployment Hardware Configuration

The following table lists the tested hardware configuration for the medium deployment configuration.

* Network adapters are all 100baseT.

Note In the medium deployment, SQL Server experiences greater load than in the core-medium deployment. This is because there are three DMZ Web servers accessing it rather than just one. The performance characteristics presented in appendices B, C, and D reflect this configuration.

Appendix B: Catalog Publishing Performance Characterization Data

This appendix shows the performance characterization for the catalog publishing feature of the MSSE. It contains two sets of tables.

These tests were performed using Commerce Server catalogs based on the AdventureWorks catalog provided in the AFS SDK.

Time to Publish Catalogs

The following tables show the amount of time taken to publish catalogs of various sizes in each of the two tested deployments: core-medium, and medium. The total time taken to publish a catalog is shown as the sum of two distinct phases of the publication process:

• Commerce Server exporting a catalog in Commerce Server Catalog XML Format v2.0 (TE).
• BizTalk Server transforming the catalog into either the cXML 1.2 format or the xCBL 3.0 format, and then "transporting" the result to a file (TT).

Core-Medium

Medium

Table Key:

• TE – Time to export from Commerce Server and write the XML catalog document to the BizTalk Server receive directory. Time is shown in seconds. Although distinct times are shown for each document format, no difference is expected because the export processing is the same for both formats.
• TT – Time to transform the Commerce Server XML catalog to the cXML 1.2 and xCBL 3.0 formats and then transport the XML catalog document to a trading partner. In this test, the catalog is published to a local directory. Time is shown in seconds.
• Total – Addition of the TE and TT, which represents the total time to publish an XML catalog document.

Performance Impact During Catalog Publication

The following tables show the performance impact of publishing catalogs of various sizes in each of the two tested deployments: core-medium and medium. Relative to a baseline measurement, the average and minimum number of ASP pages served per second by the AFS Solution Site while catalogs are being published are shown. For the minimum number of ASP pages served, the duration of the minimum measurement is also shown.

Core-Medium

Note The impact on site performance was a brief spike representing less than a second in elapse time.

Medium

Note The impact on site performance was a brief spike representing less than a second in elapse time.

Table Key:

• Base – Using the Application Center Testing (ACT) tool prior to the actual performance test case being run, the system is brought up to a "steady state," and a "baseline" average number of ASP/second served is determined. The CPU utilization was 75% (+/- 5%) for the core-medium deployment and was 68% (+/- 5%) for the medium deployment.
• (CU) – Concurrent users. This is an estimate of the number of concurrent users that can be supported, based on the number of ASP pages being served per second.
• Avg – Average number of ASP/second served during the publishing of the catalog.
• Min – Minimum number of ASP/second served during the publishing of the catalog.

  For the medium deployment environment, the Min values represent the number of ASP pages served per second by the DMZ Web server that experienced the greatest momentary performance drop. In these tests, the DMZ Web servers did not experience their momentary performance drops at the same time.

• Dur at Min – Duration of time for which the DMZ Web server whose performance is shown in the Min column performed at that level. The time is shown in seconds.

Appendix C: Remote Shopping Performance Characterization Data

This appendix shows the performance characterization for the remote shopping feature of the MSSE in each of the tested deployments: core-medium and medium. It contains a set of tables that show, relative to a baseline measurement, the average and minimum number of ASP pages served per second by the AFS Solution Site while certain remote shopping operations are being performed. For the minimum number of ASP pages served, the duration of the minimum measurement is also shown.

This test was performed using products from the AdventureWorks catalog provided in the MSSE SDK.

Core-Medium

Note The impact on site performance was a brief spike representing less than a second in elapse time.

Medium

Note The impact on site performance was a brief spike representing less than a second in elapse time.

Note For the medium deployment environment, the Avg values are larger than the Base values. This is because the CPU utilization never reached 100%, and was thus able to support the additional load of the simulated remote shopping users.

Table Key:

• Base – Using the Application Center Testing (ACT) tool prior to the actual performance test case being run, the system is brought up to a "steady state", and a "baseline" average number of ASP/second served is determined. The CPU utilization was 70% (+/- 5%) for the core-medium and medium deployment environments.
• (CU) – Concurrent users. This is an estimate of the number of concurrent users that can be supported, based on the number of ASP pages being served per second.
• Avg – Average number of ASP/second served during remote shopping.
• Min – Minimum number of ASP/second served during remote shopping.

  In these tests, the DMZ Web servers did not experience their momentary performance drops at the same time.

• Dur at Min – Duration of time for which the DMZ Web server whose performance is shown in the Min column performed at that level. The time is shown in seconds.
• 100 setup requests – 100 remote shopping session setup requests were made at intervals of 1 request every 5 seconds.
• 100 x 10 checkout – 100 remote baskets, each containing 10 line items, were checked out at intervals of 1 remote basket every 5 seconds.
• 100 x 100 checkout – 100 remote baskets, each containing 100 line items, were checked out at intervals of 1 remote basket every 7.5 seconds.

Appendix D: Purchase Order Reception Performance Characterization Data

This appendix shows the performance characterization for the purchase order reception feature of the MSSE. It contains two sets of tables.

These tests were performed using cXML 1.2 , xCBL 3.0, and SAP XML purchase orders similar to those provided in the AFS SDK.

Time to Receive and Process Purchase Orders

The following tables show the amount of time taken to receive purchase orders of various sizes in each of the deployments: core-medium and medium.Times were recorded for the following processes.

• (TR) Receiving the purchase order, placing in the queue from which BizTalk Server retrieves it, and sending an HTTP response.
• (Total) The total time taken to receive an order; this is the time taken from the moment the first order is sent until all of the orders are saved in the Commerce Server database.

Core-Medium

Medium

Note For the medium deployment environment, the Avg values are larger than the Base values. This is because the CPU utilization never reached 100%, and was thus able to support the additional load of the simulated purchase orders.

Table Key:

• TR – Time to receive a purchase order that has been (HTTP) posted to the page ReceivePO.asp and to respond to sender with an HTTP Response. The ReceivePO.asp page writes the purchase order to a Message Queue on the BizTalk Server. Time is shown in seconds.
• Total –The total time to receive a purchase order into the Commerce Server database.
• 100 x 10 continuous – 100 purchase orders containing 10 line items each were posted at intervals of 1 purchase order every 1 second.
• 100 x 100 continuous – 100 purchase orders containing 100 line items each were posted at intervals of 1 purchase order every 10 seconds.
• 100 x 10 burst – 100 purchase orders containing 10 line items each were posted at the same time in a single burst.
• 100 x 100 burst – 100 purchase orders containing 100 line items each were posted at the same time in a single burst.

Performance Impact During Purchase Order Reception

The following tables show the performance impact of receiving purchase orders of various sizes at various speeds in the tested deployments: core-medium and medium. Relative to a baseline measurement, the average and minimum number of ASP pages served per second by the MSSE Solution Site while receiving purchase orders are shown. Please note that the average is measured over Total processing time, where Total is the elapse time between sending the first order until all of the orders are in the Commerce Server database.

Core-Medium

Note The impact on site performance was a brief spike representing less than a second in elapse time.

Medium

Note The impact on site performance was a brief spike representing less than a second in elapse time.

Table Key:

• Base – Using the Application (ACT) tool prior to the actual performance test case being run, the system is brought up to a "steady state", and a "baseline" average number of ASP/second served is determined. The CPU utilization was 70% (+/- 5%) for the core-medium deployment and 81% (+/- 5%) for the medium deployment.

  For the medium deployment, the Base values represent the number of ASP pages served per second by all three DMZ Web servers combined.

• (CU) – Concurrent users. This is an estimate of the number of concurrent users that can be supported, based on the number of ASP pages being served per second.
• Avg – Average number of ASP/second served during PO Processing
• Min – Minimum number of ASP/second served during PO Processing

  In these tests, the DMZ Web servers did not experience their momentary performance drops at the same time.

• Dur at Min – Duration of time for which the DMZ Web server whose performance is shown in the Min column performed at that level. The time is shown in seconds.
• 100 x 10 continuous – 100 purchase orders each containing 10 line items were posted at intervals of 1 purchase order every 1 second.
• 100 x 100 continuous – 100 purchase orders each containing 100 line items were posted at intervals of 1 purchase order every 10 seconds.
• 100 x 10 burst – 100 purchase orders each containing 10 line items were posted at the same time in a single burst.
• 100 x 100 burst – 100 purchase orders each containing 100 line items were posted at the same time in a single burst.