Microsoft Corporation
Service Release 1, May 2002
Applies to:
Microsoft Solution for Supplier
Enablement
Microsoft Commerce Server 2002
Microsoft
BizTalk Server 2002
Summary: Learn about the operational aspects of the Microsoft Solution for Supplier Enablement (MSSE). Installation and efficient operation of MSSE are described. (49 pages)
Introduction
Operational Reference Model
Operational Activities
URL Resources
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 has the distinction of being the product that provides the integration of the other products required by this solution. Thus, a description of the operational aspects of the MSSE is the same as a description of the operational aspects of AFS.
This document consists of two main sections. The first describes the reference model for the operation of the MSSE, and the second describes a variety of operational activities related to the MSSE.
Anyone reading this document 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.
The operational reference model for the MSSE uses the Microsoft Operations Framework and the related process model, both of which are reviewed in this section. This section also describes the operations infrastructure, reporting, change management, and people skills required for operating an MSSE installation.
Microsoft Operations Framework (MOF) is a collection of best practices, principles, and models. It provides comprehensive technical guidance for achieving mission-critical production system reliability, availability, supportability, and manageability for solutions and services built on Microsoft products and technologies. Thus, MOF is the reference model for this Operations Guide
For a comprehensive introduction to the MOF, see the "Microsoft Operations Framework Executive Overview" white paper that can be found at the following URL:
Organizations that deploy a business-to-business e-commerce solution must keep the deployment functioning 24 hours a day, 7 days a week. Indeed it has become increasingly common for enterprise application integration to have a similar up-time requirement. This document outlines the administrative tasks a system administrator must perform to keep an installation of Microsoft BizTalk Accelerator for Suppliers (AFS) running on a continual basis. Also discussed are important concepts and common administrative issues about which system administrators must be aware.
The major areas of administration and management related to BizTalk Accelerator for Suppliers are:
The operations team should generate various reports to study the health and behavior of the system. The following is a list of system and application level reports.
System level reporting for the MSSE consists of the following:
There are numerous application level reports that can be run against the system. Many of these reports are available out of the box using Commerce Server reporting and analysis features.
You use Analysis to run reports on the user and site data stored in your Data Warehouse, and you use the results of those reports to perform business analytics on the performance of your Web site, or in this case, your business-to-business (B2B) supplier enablement system and activities. For example, you can run reports that show you the characteristics and past behavior of your users during remote shopping sessions, and then update your site to target advertisements or complimentary products to those corporate users. AFS provides additional documentation about extending Commerce Server Analysis to include many of these supplier enablement-specific reports.
In addition to running analysis reports, you can use the Segment Viewer module in Commerce Server Business Desk to analyze segments of your user population. Segments represent groups of users with similar characteristics or behavior. You use the Segment Viewer module to analyze segments to identify these specific characteristics or behaviors, such as usage trends. You can then use the results of your analysis to make marketing decisions based upon similarities among users. In a B2B scenario, for example, you could decide to re-work your remote shopping checkout process or change the configuration process for specific product families.
Commerce Server provides you with several report definitions. You can change dynamic reports to create new reports and add your newly created dynamic reports to the Reports module. For more information about creating a new dynamic report definition, see "Creating a New Dynamic Report" in Commerce Server 2002 Help. In addition, your site developer or system administrator can create custom reports as needed.
Different business disciplines are tasked with undertaking various roles in managing an AFS deployment. Each of these disciplines is discussed in the following topics:
Business managers add, change, and delete site content using Commerce Server Business Desk in the development environment. These users also define business rules for processing orders and other business processes. Business managers work with the following types of content:
Site developers add, change, or delete site content using Microsoft® Visual Studio® and other tools in the development environment. These users also develop XML documents and configure BizTalk Messaging and Orchestrations. Site developers work with the following types of content:
Testers test newly developed content in the test/staging environment, prior to deployment, in an effort to identify any potential problems arising from the incorporation of the new content.
System administrators administer change requests from both business managers and site developers by using Commerce Server Manager resources or Business Desk modules. These users also configure and maintain BizTalk Messaging and Orchestration services. System administrators are responsible for:
Change management for this application should be done through a well-defined change management process such as the following:
This process usually contains the activities listed in the following table.
| Activity | Description |
|---|---|
| Design | Define the content that authors should publish on the Web site. |
| Author | Develop and produce the content. People who create this content include graphic artists, videotape production crews, photographers, technical writers, advertising writers, application developers, Web page developers, lawyers, human resource personnel, marketers, or anyone else who produces original material for the Web site. You usually use a source code management system, such as Microsoft® Visual SourceSafe®, to track the authored content. |
| Review | Review content. You must make sure that reviewer responsibilities are well defined and that technical reviewers are identified before content is created and deployed. |
| Approve | Approve content for deployment. Because of the cross-functional nature of Web content, it is important to have a well-defined content-approval process and assigned approvers, beginning with the earliest stages of content creation through final deployment. |
| Convert | Transform content from the format in which an author created it to the format in which you can display it on your site. For example, you must convert word processor documents to formatted HTML text, modify bitmapped images so that they load faster on the Web, and perhaps change image formats. Site developers use templates, layouts, themes, and other methods to convert text into uniformly formatted Web pages. |
| Store | Place content in file systems, version-control systems, or other types of repositories. Integrated application development systems store varied Web content in the file system that replicates the hierarchical structure of the Web site. |
| Stage | Assemble all content (if you have a separate staging environment) after the content has been thoroughly tested and before you move it to the production environment. |
| Test | Test the finished content. For example, testing should include identifying broken and missing links, identifying pages that load slowly, load testing, component testing, database access testing, script testing, and performance testing. You should perform comprehensive, final integration testing in a test/staging environment that is exactly the same as the production environment. Developers must make sure that database connections are valid for the test/staging environment and the production environment. |
| Deploy and replicate content | Place new content into production. You must be sure that all content, including middle-tier components and transactional packages, is moved to the live system. |
| Monitor and update | Monitor your production site and update the content when necessary. The content management process does not end when you install content in the production environment. You must continuously monitor and update content in order to keep the site current and working properly. |
| Remove and archive | Remove stale or out-of-date content from the production environment and archive it for a predetermined length of time. |
| Analyze | Analyze the site and user traffic on an ongoing basis. |
This section describes the various operational activities associated with running an MSSE installation. These activities are divided into the following categories:
This section describes the various ongoing operational procedures to be performed for an MSSE installation. These procedures include catalog creation and modification, trading partner configuration, catalog publishing, order processing, organization management, and report analysis. Each of these procedures is discussed in the following topics:
By default, the MSSE uses the Commerce Server Product Catalog System as the primary tool for storing and maintaining product data. Business managers use the associated catalog modules in Commerce Server Business Desk to create and modify product data. These modules can also be used to import catalog data from other data sources and to export catalog data for use in other applications.
Business managers can update product information, such as the product price, and then publish the changes to the Web site. For example, if buyers have added the product to their baskets, and the Web site is updated before they check out, Commerce Server applies the new price to their basket. If buyers have saved their baskets, and then return to them after the price has been updated, the new price is displayed.
The catalog modules in Business Desk allow business managers to easily find products by performing a property search or a free-text search.
For information about using the catalog modules, see the AFS Business Desk online help, or see "Business Desk Accelerator for Suppliers" in the AFS online Help.
Developers can also access the Commerce Server Product Catalog System programmatically, using the following Commerce Server objects: CatalogManager, CatalogSets, CatalogToVendorAssociation, Category, Product, and ProductCatalog.
For more information about programming with these objects, see "Product Catalog Objects" and "COM Object Reference" in Commerce Server 2002 Help.
Trading partner configuration information defines how catalogs are published and how purchase orders are received. Business managers configure and maintain trading partner configuration information using the Trading Partner Manager module in Commerce Server Business Desk. For information about using this module, see the AFS Business Desk online help, or see "Business Desk Accelerator for Suppliers" in the AFS online Help.
One of the main aspects of the functionality provided by the MSSE is publishing electronic product catalogs to trading partners. Business managers configure and initiate catalog publishing using the Catalog Publisher module in Commerce Server Business Desk. For information about using this module, see the AFS Business Desk online help, or see "Business Desk Accelerator for Suppliers" in the AFS online Help.
One of the main aspects of the functionality provided by the MSSE is receiving electronic purchase orders from trading partners. Business managers view and process these purchase orders in the course of fulfilling the orders using the Orders Manager module in Commerce Server Business Desk. All such orders can be viewed in a list, and the details of a particular order can be displayed and modified. For information about using this module, see the AFS Business Desk online help, or see "Business Desk Accelerator for Suppliers" in the AFS online Help.
One aspect of order processing that requires consideration is duplicate purchase orders. Duplicate purchase orders can occur in two ways. First, a trading partner might erroneously send the same purchase order more than once. Second, duplicate purchase orders can occur if BizTalk Server becomes disconnected or is otherwise unavailable while processing an order. When BizTalk Server is restarted, it will sometimes re-process an order that has already been successfully entered into the Commerce Server orders database.
To help detect and identify duplicate purchase orders, the AFS SDK includes SQL scripts that create a SQL Agent job that searches the orders database for duplicate purchase orders and changes their order status to "Duplicate Order". These scripts can be found within the following folder beneath the AFS installation folder: SDK\Sample\SQLAgentJob.
The folder contains the following four scripts:
Maintaining information about the various organizations with which a company interacts is a standard business requirement. This includes the trading partners with which electronic business documents are exchanged using the MSSE. Similar information must be maintained about the supplier organizations as well. Business managers create, view, and modify relevant information about business organizations by creating organization profiles using the Organizations module in Commerce Server Business Desk. For information about using this module, see the AFS Business Desk online help, or see "Business Desk Accelerator for Suppliers" in the AFS online Help.
The type of information maintained for organizations includes such items as the name of the organization, the name of the primary contact, the address and phone number for the organization, the name of the purchasing manager, the catalog set available to the organization, and so on. The exact information to be maintained is defined in an Organization profile definition. You can use the Profile Definition Designer module in Business Desk to customize the Organization profile definition to meet your own needs.
Business reporting is an important aspect of analyzing and altering business practices to optimize profitability. Business managers use the Reports module in Business Desk to run both dynamic reports and static reports.
The system administrator must perform several tasks before a business manager can run and view reports. For example, system administrators must import data into the Data Warehouse and run the report preparation process on a regular basis. This ensures that the reports run by business managers are using the most up-to-date data.
Business managers can run Commerce Server reports to identify the top-selling products by units sold and by total sales, and to identify the top-selling categories by units sold and by total sales. The results of this analysis can be used, for example, to discount products that are not selling well, or to promote accessories for products that are selling well. In addition, developers can use this information to customize the Web site to suggest up sells and intelligent cross-sells to prospective buyers.
This section describes aspects of the MSSE that are likely to evolve over time, changing periodically during the lifecycle of an MSSE solution. Detailed information is provided for the following:
BizTalk Messaging Services, included in Microsoft BizTalk Server 2002, can be used to send documents to, and receive documents from, trading partners and other applications. These documents can be parsed and tracked as well. In addition, BizTalk Messaging Services generates receipts for certain file formats, correlates and maps data, verify the integrity of documents, and provides secure methods for exchanging documents.
To implement BizTalk Messaging Services, BizTalk Server uses messaging objects, receive functions, parsers, and the BizTalk Tracking database. Messaging objects, such as channels and messaging ports, are configured to describe the types of processing to be performed on the documents submitted to BizTalk Server. Receive functions and the methods Submit and SubmitSync are used to submit incoming documents to BizTalk Server for processing. After a document is submitted, it is processed, which sometimes includes converting it to a different format. Finally, the Tracking database records the processing performed on incoming and outgoing documents.
The properties of a messaging object describe the types of processing to be performed on a document by that object. BizTalk Messaging Manager is used to configure the properties of the following types of messaging objects:
Receive functions are another important aspect of BizTalk Messaging Services. There are two types of receive functions, one type that receives documents from message queues, and another type that receives documents through the file system. Both types of receive functions are configured using the BizTalk Server Administration MMC snap-in.
The following table shows the configuration information associated with these five Message Queuing receive functions:
| Source Format | Source Message Queuing Suffix | Destination BizTalk Channel Name |
|---|---|---|
| xCBL 3.0 | xCBL3.0_OrderReceive | AFS_Channel_xCBL3.0_Order_To_CS_Order |
| cXML 1.1 | cXML1.1_OrderReceive | AFS_Channel_cXML1.1_Order_To_CS_Order |
| cXML 1.2 | cXML1.2_OrderReceive | AFS_Channel_cXML1.2_Order_To_CS_Order |
| SAP XML | SAPXML_OrderReceive | AFS_Channel_SAPXML_Order_To_CS_Order |
| CSXML | CS_ORReceive | None |
Messages containing purchase order XML documents are placed in one of four different message queues by an ASP receive page (ReceivePO.asp). A query string parameter in the posted purchase order indicates the format of the purchase order XML document, and is used to determine into which of the four message queues the document should be placed. For more information about the processing that occurs in the page ReceivePO.asp, see "Purchase Order Reception from the Trading Partner" in the AFS online Help.
Each of the format-specific message queue receive functions is associated with a unique transform channel, to which it passes the dequeued document. For more information about the transform channel and its associated message port, see "Transform Channel and Messaging Port" in the AFS online Help.
The fifth message queue is used for order response messages. For more information about the order response message, see "Purchase Order Reception/Response Feature" in the AFS online Help.
The following table shows the configuration information associated with these three file receive functions:
| Source Format | Source File Suffix | Destination BizTalk Channel Name |
|---|---|---|
| xCML 3.0 | *xCBL3_0.xml | AFS_Channel_CS2002_Cat_To_xCBL3.0_Cat |
| cXML 1.1 | *cXML1_1.xml | AFS_Channel_CS2002_Cat_To_cXML1.1_Cat |
| cXML 1.2 | *cXML1_2.xml | AFS_Channel_CS2002_Cat_To_cXML1.2_Cat |
The name of the shared directory is AFSCatalogPub and the default path for this share on the BizTalk server is:
%systemdrive%\Documents and Settings\All Users\Application Data\AFSCatalogPub\
For more information about the naming scheme used for these files, see "Writing the Catalog to the Receive Directory" in the AFS online Help.
If you have modified your Commerce Server catalog schema such that the BizTalk map files provided with Microsoft BizTalk Accelerator for Suppliers (AFS) no longer work, or if you have extended the schema with properties that you want reflected in the transformed XML, you will need to perform the following tasks:
For catalogs, AFS includes XML schemas and BizTalk maps based on the sample hardware catalog included in the AFS SDK. The SDK also contains a Visual Basic Scripting Edition (VBScript) file that can be used to export an XDR file that contains the current schema for the Commerce Server 2002 catalog. The script and readme.txt file can be found in the following path:
%systemdrive%\Program Files\Microsoft BizTalk Accelerator for Suppliers\SDK\ExportCatalogXDR\
The following line of code shows the command line arguments for this script:
cscript ExportCatalogXDR.vbs <SiteName> <CatalogName> <Path ending with .xml> Example: exportcatalogXDR.vbs supplieraccelerator AdvW cat.xml
For purchase order and purchase order response documents, you can simply update the XML schemas provided and add new schemas.
The default document definition (schema) path in the WebDAV is:
%systemdrive%\Program Files\Microsoft BizTalk Server\BizTalkServerRepository\DocSpecs\Microsoft\
The default BizTalk map path is:
%systemdrive%\Program Files\Microsoft BizTalk Server\BizTalkServerRepository\Maps\Microsoft\
To add support for an additional XML document standard in AFS requires several configuration steps.
Refer to the names of the existing BizTalk channels, messaging ports, message queues, and receive functions for examples of standardized naming schemes.
It is important that you use the Import process to get the schema into BizTalk Editor. All schemas, regardless of whether you make changes or not, should be imported into BizTalk Editor and saved as XML to the BizTalk WebDAV repository.
If the new document standard is a new version of an existing standard, as would be the case for xCBL 3.5, the easiest way to create a new map is to open the existing map for the older version of that standard in BizTalk Mapper. In the pane that shows the standard to be updated, right-click and select Update Specification. Depending on whether the document is outgoing or incoming from the perspective of AFS, the corresponding pane will be either the right pane or the left pane, respectively. When the new specification is loaded, mappings are retained for any fields that are the same as for the previous version. You then use BizTalk Mapper to create any additional mappings that are required.
If the document standard is completely new, create a new BizTalk map using the new document schema and the schema for the corresponding Commerce Server document. You will need to create all of the mappings manually. Even during this process, it may be useful to open an existing, similar map in a different instance of BizTalk Mapper and use it as a point of reference. The xCBL maps are better for reference because they include and map more fields than those available in the cXML maps.
Using the example of xCBL3.5, you would need to create the following documents:
AICs for catalog publication perform the following processing on the outgoing catalog document:
After you create the new AIC, you configure a corresponding BizTalk application artifact. To create this artifact, open BizTalk Message Manager, search for organizations, and open the home organization. Create a new application for the AIC under the home organization, and provide a name for it. This name is only used for tracking purposes.
For purchase order reception, create one new BizTalk messaging port. The transform messaging port should be associated with the appropriate XLANG schedule. If no custom business workflow processing is defined, this XLANG schedule can be the schedule installed by AFS.
For purchase order reception, create one new BizTalk channel. The transform channel should be configured to use the corresponding BizTalk map, created in a previous step, to transform a purchase order in the XML format used by the trading partner into the Commerce Server Order XML format. The channel configuration should also include the individual document definitions to validate before and after the transformation. The transform channel should be associated with the transform messaging port.
When you create BizTalk channels, it is recommended for performance reasons that you enable tracking only while debugging.
For purchase order reception, create a new message queuing receive function using BizTalk Server Administration. When you specify the polling location, provide the name of the message queue created in a previous step using the following format:
Direct=OS:<ServerName>\private$\<QueueName>
In the Advanced options dialog box, specify the purchase order reception transformation channel that was defined in a previous step.
All orders in the Commerce Server orders database have an associated order status. When an order is first created, either directly through a supplier Web site or through AFS, it is given the order status associated with the following constant, defined in the AFS Solution Sites file services\include\const.asp:
Const ORDER_STATUS_NEW_ORDER = 4
By default, the value "4" is associated with the string "New Order", so that this string is displayed for new orders in various modules in Commerce Server Business Desk. To change the available status codes for orders, use the Data Codes module in Business Desk to add, delete, or modify the existing status string to value mappings. To change the order status used for new orders to be associated with a different value, change the constant definition shown above.
Orders in the Commerce Server orders database that are created through AFS and displayed in the Orders Manager module in Business Desk also have an associated fulfillment status. The fulfillment status is stored in the order_fulfill_code column of the OrderGroup table, which is one of several new columns added to the table by the AFS installation program (other added columns include order_requisition_number and marketplace_name). The value of the default fulfillment status is defined by the following constant in the page _recvpo.asp:
Const MANUAL_FULFILLMENT_STATUS_CODE = "102"
The available choices for fulfillment codes are defined in the SE_FulfillmentStatus table, also created by the installation application. This table contains columns for the status value and the associated display name. To modify the available choices, modify this table as appropriate. To change the default fulfillment status, modify the constant definition shown above to reference the appropriate value in the SE_FulfillmentStatus table.
Use Commerce Server Site Packager to initially deploy the AFS Web site. To update the content of the AFS Web site, use a method that is appropriate for the type of component underlying the content that you are updating. The following table shows the tool(s) appropriate for updating the various types of components that contribute to the content of the AFS Web site.
| Type of component responsible for Web site content | Web site update methodology |
|---|---|
| Web pages (ASP and HTML files) | Microsoft Visual Studio or other Web-page editing/publishing tool. |
| Component Object Model (COM) objects | Transfer the appropriate dynamic-link
libraries (DLLs) to the Web server, and then register them using the
command: regsvr32 <dll-filename> |
| Catalog data, campaigns, advertisements, and discounts | Create and run a Data Transformation Services (DTS) task. When updating campaigns, advertisements, and discounts, move only the tables containing these records. Do not overwrite the performance table. |
| Pipelines | Copy the appropriate pipeline (.pcf) files. |
The AFS installation program asks for a User account to be used as the Identity (the account under which the COM+ application runs) for the following AFS COM+ applications:
The Accelerator for Suppliers COM+ application is used by the Catalog Publisher module in Commerce Server Business Desk to write exported catalogs in Commerce Server Catalog XML v2.0 format to the shared directory on the BizTalk Server computer. This shared directory is created so that it is hidden and only this user account is given permission to write to it.
The AFS installation program also uses this account to configure the Anonymous User Account when creating the AFSChannels virtual directory on the BizTalk Server. This virtual directory hosts an ASP page which, while running under the security context of this User account, calls the BTConfig object to return a list of available BizTalk Messaging Channels.
Note This Windows account must be a member of the BizTalk Server Administrators group and have users permissions to write to the temp folder on the system drive.
Both BizTalk Server and Commerce Server also create COM+ applications that can be configured to use interactive, local, or domain user accounts. These COM+ applications are also configured in the Component Services MMCsnap-in.
Note By default, BizTalk Server does not process purchase orders unless a user is logged in to the computer on which BizTalk Server is running. This is because the XLANG Scheduler runs as the interactive user. When no one is logged in, an error appears in the event log ("Invalid XLANG..."). The solution is to modify the XLANG Scheduler COM+ component to run as a valid domain user.
For additional information, see the Microsoft Knowledge Base (KB) articles Q292317 and Q275849 at http://support.microsoft.com/directory/.
To change the account or password associated with a COM+ application, use the Component Services administrative tool. Find the relevant COM+ application on your computer, and modify the user name and password properties on the Identity tab in the Properties dialog box.
Note If property changes do not taking effect, ensure that the Disable changes check box on the Advanced tab in the Properties dialog box is not checked.
In addition to the COM+ applications, Windows Services also uses local and domain user accounts. It is important to ensure that each of the following Windows Services is running under a valid local or domain user account:
AFS uses several SQL connection strings. These connection strings are managed by the underlying Windows Server System servers and accessed through their APIs. The Commerce Server and BizTalk Server SQL connection strings are managed thorough the Commerce Server Manager and BizTalk Server Administrator MMC snap-ins.
Commerce Server SQL Connection Strings
Commerce Server connection strings, including the login user names and passwords, are stored in the Commerce Server Administration database.
Administration database. During Commerce Server installation, you enter the login user names and passwords for the Administration database. After installation, you make changes to these values using Commerce Server Manager.
Databases used by resources. In the site unpacking process, Commerce Server Site Packager prompts for several connection strings. These connection strings can be changed after installation by making configuration changes in Commerce Server Manager. The Predictor, Direct Mailer, Profiles, and Data Warehouse each has its own global resource that includes the connection string. The following table shows the connection strings for each Commerce Server site resource.
| Resource | Connection String |
|---|---|
| Product Catalog | Catalog Database |
| Campaigns | Campaigns Database |
| Transactions | Transactions Database |
| Transaction Config | Transactions Config Database |
| Profiles | s_BizDataStoreConnectionString
s_CommerceProviderConnectionString s_ProfileServiceConnectionString |
| Data Warehouse | The connection string is not named in the user interface because the Data Warehouse has its own snap-in extension |
Service packs and hot fixes are the means by which product updates are distributed. Service packs and hot fixes may contain updates for system reliability, program compatibility, security, and more.
MSSE has been tested with the service packs and hot fixes listed in the "MSSE Deployment Guide." If a service pack or hot fix is required to fix a known issue, that service pack or hot fix should be installed and tested in a test environment before being applied to production environments.
The first step in implementing an effective backup and recovery strategy is to precisely identify the entities that need to be backed up. In the MSSE, there are two types of entities that require a backup strategy:
The following sections discuss some strategies for both types of entities:
The implementation of the MSSE consists of BizTalk Server WebDav content and Commerce Server site content, each of which needs to be backed up.
BizTalk Server WebDAV Content
All of the BizTalk Server document definitions and maps used by AFS are stored in WebDAV. WebDAV can be configured to store the files locally on the BizTalk Server computer, or remotely on a separate WebDAV Web server. There are two backup strategies that make sense for this type of entity. First, these files could exist in a second WebDAV that is also used for staging when changes to these entities are being tested. Second, these files could be updated on the production supplier Web site, and then backed up daily along with any other Web site entities that are saved. Because these documents tend to be quite stable, the first option may be the best choice.
Commerce Server Site Content
It is likely that there is an e-commerce Web site associated with the MSSE. This Web site is likely to have originated in one of the following three ways:
In any event, the Web site is likely to be built using a number of different types of components. These components are generally created in the development environment, tested and proofed in the test/staging environment, and then published to the production Web site. The following are examples of these types of components:
Note The data that supports the creation of dynamic Web pages or enables customers to complete transactions, such as product catalogs, purchase orders, and user profiles are all stored in SQL Server, and are considered to be part of the data backup, not the implementation backup.
After you deploy and configure a supplier Web site, you should back up all the files in the site so that it can be restored in the event of a server failure. If the site is small, the easiest way to back it up is to re-package it using Commerce Server Site Packager. The new package will save many of the configuration settings specific to that site. Site Packager does not package all of the properties that are specific to the particular computer on which it is run. For example, Web server properties and some application properties that are set in Commerce Server Manager are not packaged. For a list of data that is packaged for each resource, see Commerce Server 2002 Help.
Remember to re-package the Web site every time it is changed, including configuration changes. For information about how to package a site, see Commerce Server 2002 Help.
If the supplier Web site is large, creating a package file for it may not be practical. In this case, you should consider using one of the following techniques:
In addition to the site content, users should back up the Internet Information Services (IIS) 5.0 metabase and log files, and Windows Registry. This can be done using the Windows Backup Wizard or a third-party utility.
It is recommended that you back up your Commerce Server configuration every time it changes so that you can easily return it to a previous state should you experience a hardware or software problem.
To restore Commerce Server
To restore BizTalk Server
Backing up data consists of backing up the various SQL Server databases used by the MSSE. These databases, categorized according to the Windows Server System servers with which they are associated, are:
BizTalk Databases
Commerce Server Databases
When you create a database backup, the backup operation copies only the data in the database to the backup file; it does not copy unused space in the database. Because the database backup contains only the actual data in the database, and no empty space, the database backup is likely to be smaller than the database itself. An estimate of the size of the database backup can be determined using the sp_spaceused system-stored procedure; the reserved value indicates the estimated size.
When backing up databases, the backup interval should be long enough to keep the backup overhead from affecting production work, yet short enough to prevent the loss of significant amounts of data. Databases that do not contain critical data and have few modifications can be backed up on a weekly or biweekly basis. Data that is more critical or more volatile may need to be backed up daily, or even more frequently. Some databases that are usually read-only may need to be backed up only after a periodic refresh with new data.
It is also prudent to have more than one backup of the database. It is recommended that you maintain a rotating series of backup media, so that you have two or more versions of the database that you can restore. This allows you to address situations in which a user may make some incorrect modifications that are not detected for some time, or to fall back to an earlier backup if backup media is damaged.
To create a backup of a SQL Server database
| Use this | To do this |
|---|---|
| Append to media | Append the backup to any existing backups on the backup device. |
| Overwrite existing media | Overwrite any existing backups on the backup device. |
| Schedule | Optionally, select to schedule the backup operation for later or periodic execution. |
When you restore a database backup, you return the database to the same state it was in when the backup was created. When you restore a database, SQL Server recreates the database and all of its associated files automatically by performing the following steps:
This process ensures that the restored database is a copy of the database as it existed when the backup operation completed, except that all incomplete transactions have been rolled back. This is required to restore the integrity of the database.
Additionally, to prevent overwriting a database unintentionally, the restore operation can perform a safety check automatically. The restore operation fails if:
These safety checks can be disabled if the intention is to overwrite another database.
To restore a SQL Server backup from a backup device
Note Specifying a new name for the database determines automatically the new names for the database files restored from the database backup.
If no devices appear, click Add to add an existing backup device or to create a new one. In the Restore Database dialog box, click View Contents and select the backup set to restore.
Note This option scans the backup set for the backup content information and can be time consuming, especially for tape devices. If you already know the backup set to restore, type the backup set number in the Backup number box instead.
Mission-critical environments often require that the database be available continuously, or for extended periods of time with minimal downtime. Therefore, the duration of unexpected situations, such as a hardware failure, that require the database to be restored need to be kept as short as possible. Additionally, mission-critical databases are often large, requiring longer periods of time to back up and restore. Microsoft SQL Server offers several methods for increasing the speed of backup and restore operations, thereby minimizing the effect on users during both operations. These methods are:
There are three categories of maintenance to be performed for MSSE installations:
You use the Web server log import Data Transformation Services (DTS) task to import Web log file data from your site. You determine the import frequency for the data by analyzing traffic on your site. The more traffic your Web site has, the more frequently you should import Web log file data.
Before you import Web log file data, you must synchronize your site configuration with the Data Warehouse by executing the Configuration synchronization DTS task. After you import Web log file data, you must run the Report preparation DTS task, which organizes the imported data into designated online analytical processing (OLAP) cubes. See Commerce Server 2002 Help for more information.
After you deploy AFS, you might need to change the following settings associated with your SQL Server databases:
You can change the Auto shrink setting in SQL Server Enterprise Manager in the <Database Name> Properties dialog box on the Options tab. You can change the Automatically grow file setting in SQL Server Enterprise Manager in the <Database Name> Properties dialog box on the Settings tab.
The Auto shrink setting controls disk space allocation. If you want to avoid unnecessary disk space allocation, enable the Auto shrink option in SQL Server.
The Automatically grow file setting enables the SQL Server databases to grow in size if necessary. When SQL Server is installed, the Automatically grow file setting is enabled by default. Keep this setting enabled under the following conditions:
Although it is recommended that you leave the Automatically grow file setting enabled, you might need to turn this setting off in the following situations:
There are three categories of maintenance to be performed on BizTalk Server databases:
Maintaining the BTS Tracking Database
If you configured tracking options for a server group in the BizTalk Server Administration tool, and if you configured any channels or document definitions to track specific fields, your Tracking database will grow in size very quickly. To maintain the Tracking database, you can use the sample SQL script DTA_SampleJobs.sql to remove records from the Tracking database. This script removes copies of the intermediary XML records stored in the dta_debug_doc table if the number of records in the table is greater than 25,000. This script also monitors the dta_outdoc_details table for records that are expecting receipts, but the waiting period has elapsed. You can find this sample script in the BizTalk Server SDK in the Messaging Samples\SQLServerAgentJobs folder. Review the readme file included with this sample for more information about how to tailor the script to your specific BizTalk Server deployment.
Replicating the BTS Tracking Database
It is recommended that your database maintenance plan includes automatic replication of the Tracking database. If the Tracking database grows too large, BizTalk Server performance is adversely affected. You can use the SQL Server Enterprise Manager console to set up replication and to set up jobs to remove transactions from the database based on criteria that you specify.
Important It is strongly suggested that you do not change the code, such as stored procedures or triggers, in the Tracking database, that you do not access the Tracking database directly, and that you do not directly call the stored procedures or add triggers. Making changes to the Tracking database in this way could cause BizTalk Server to function incorrectly, cause the loss of data, or corrupt the Tracking database.
Maintaining the BTS Orchestration Persistence Database
Scripts to clean up old XLANG schedule instances along with other utilities to manage the persistence database used by BizTalk Orchestration Services are not currently included with BizTalk Server. For information about maintaining the persistence database, white papers, and the most recent updates on the availability of such scripts, see the Microsoft BizTalk Server Web site at http://www.microsoft.com/biztalk/.
Important It is strongly suggested that you do not attempt to create your own tool(s) to maintain the Orchestration Persistence database(s). If you access the Orchestration Persistence database in this way, you could delete important production data or corrupt the Orchestration Persistence database.
When you troubleshoot an MSSE installation, you can begin in one of a number of places, referred to here as "check points." Check points are divided into the following three categories:
The following three general check points should be considered when troubleshooting a problem with an MSSE installation:
Event Log
The Event Log is the first place to look when attempting to troubleshoot a problem with an MSSE installation. All of the underlying applications, including AFS, log errors to the Event Log.
BizTalk Document Tracking
You can use BizTalk Document Tracking to track interchanges and associated documents processed by BizTalk Server as an aid to troubleshooting.
Documents can be tracked either in batches or as single transactions. BizTalk Document Tracking automatically stores the metadata associated with an interchange, such as source and destination information, document type, and date and time parameters. Metadata is stored automatically; however additional fields, such as Purchase Order Date or Purchase Order Total, are captured only if you configure the BizTalk Messaging Configuration object model or BizTalk Messaging Manager to capture this information. For more information about configuring selected fields to be tracked, see "Set Channel Properties" and "Set Tracking for Inbound Document Properties" in the BizTalk Server Help.
Although performance is degraded when tracking is enabled, it remains a powerful tool for resolving issues related to XML document transformation and BizTalk Messaging in general.
Date/Time Settings
Date and time settings should be synchronized across all of your Web servers. Discrepancies in date and time settings can result in premature time-outs for users accessing the Web site.
When a product catalog is published, there are several ways in which errors can occur. This section describes these errors and their causes, as well as how to detect and resolve them.
The following three catalog publishing check points should be considered when troubleshooting a problem with an MSSE installation:
Business Desk
The Catalog Publisher module in Commerce Server Business Desk allows users to configure catalog publications and initiate publication of the associated catalogs. This module shows the status of the catalog publication. A catalog publication status of "Published" indicates that the catalog has been exported from the Commerce Server database and written as an XML file to the configured shared directory on the BizTalk Server computer. A catalog publication status of "Failed" indicates that the Catalog Publisher module was unable to write the XML catalog file to the shared directory. This may be due to loss of connectivity between the Commerce Server computer hosting the Business Desk and the BizTalk Server computer.
Publication failure may also occur if the AFS File Utility COM+ application is not configured to run under the same domain user account for which write permission has been granted on the shared directory.
An unchanged catalog publication status and last published date may be caused by errors exporting the catalog from the Commerce Server Product Catalog System.
If there is an error in the catalog publishing process after the file is written to the shared directory, the Catalog Publisher module will not be updated to display a status of "Published" for the corresponding catalog publication. However, an error will be written to the Event Log on the BizTalk Server computer.
Note If Business Desk is closed before the status for a catalog publication has been updated to "Published", the asynchronous catalog export processing will continue, creating a temp file on the Commerce Server computer hosting Business Desk. However, this file will not be copied to the shared directory.
Shared Directory
Check the directory associated with the "AFSCatalogPub$" file share on the BizTalk Server computer. The Catalog Publisher module in Commerce Server Business Desk writes the exported catalog to this directory. If an exported XML catalog remains in this directory, check to see whether the appropriate BizTalk Server file receive function is enabled and properly configured.
Intentionally inducing this behavior is another way in which catalog publishing can be debugged: disable the BizTalk Server file receive function and then publish a catalog. An XML catalog document should be written to the shared directory, and then remain there, due to the fact that no BizTalk Server file receive function is configured to process it. If the document is not properly written to the shared directory, the problem exists somewhere in Business Desk or elsewhere in Commerce Server. Begin by debugging the page publish.asp in the Catalog Publisher module as a catalog is published.
BizTalk Server File Receive Functions
If errors occur in BizTalk Messaging, the message is left in the suspended queue. These errors can include transformation errors or failure to transport the message to the end destination, either the post-processing catalog publishing AIC or the trading partner.
When a purchase order is received, there are several ways in which errors can occur. This section describes these errors and their causes, as well as how to detect and resolve them.
The following three purchase order reception check points should be considered when troubleshooting a problem with an MSSE installation:
The Page ReceivePO.asp
The page ReceivePO.asp processes purchase orders posted using HTTP or secure HTTP (https://) from a trading partner. This page verifies that the purchase order is coming from a known trading partner. If the verification fails, such as when the database is unavailable, or when the trading partner name is not valid, the purchase order is not discarded, an error is logged to the Event Log, and a negative HTTP response is sent.
If the page ReceivePO.asp is unable to place the purchase order document into the appropriate message queue, due to reasons such as message queuing connectivity or security issues, the same actions are taken: an error is written to the Event Log and a negative HTTP response is sent.
Message Queuing
The page ReceivePO.asp places the purchase order document in the configured message queue on the BizTalk Server computer. When debugging problems with purchase order reception, target journaling can be enabled to log all messages passing through these message queues.
Target journaling is the process of storing copies of incoming messages on the destination computer. Target journaling is configured on a queue-by-queue basis. If it is enabled, a copy of each incoming message is placed in the target journal queue when the message is dequeued.
Note Journaling should only be enabled while debugging and not under normal production conditions. When the configurable journal storage size limit is reached, journal messages cannot be sent to any journal queues on the computer until the cumulative size of journal messages in all queues drops below the specified limit.
To enable or disable target journaling
To disable target journaling for the selected queue, clear the Enabled option.
If errors occur in BizTalk Messaging, the message is left in the suspended queue. These errors can include transformation errors or failure to transport the message to the XLANG schedule.
Note Message queues depend on the Microsoft Distributed Transaction Coordinator (MS DTC) resource. They will not function unless the MS DTC resource is running.
XLANG Schedule
The XLANG schedule that is included in the MSSE does not, by default, include any business logic. Rather, it serves as a place into which custom business logic can be added. As delivered, this XLANG schedule only forwards the purchase order document passed to it to the page _recvpo.asp. Any errors that occur during this simple processing will result in the document being placed in the BizTalk Suspended Queue and an error being logged to the Event Log on the BizTalk Server computer.
The Page _recvpo.asp
The page _recvpo.asp processes purchase orders posted to it from the transport messaging port in BizTalk Server. This processing involves running the Order Processing pipeline and saving the order to the orders database. Any errors that occur due to connectivity problems will result in the purchase order message being left in the BizTalk Suspended Queue.
Several different failure scenarios are possible with an MSSE installation. These scenarios are related to the various Windows Server System servers used in the MSSE, and what happens when one or more of them is not functioning correctly. The following scenarios are described:
If the Commerce Server computer that is hosting the AFS Solution Site is unavailable, the MSSE cannot receive purchase orders and will not support remote shopping. All orders posted to the Solution Site would not be processed and HTTP errors would be returned to the trading partner. Catalog publishing does not rely on the AFS Solution Site and would continue to function.
To recover from this failure, administrators should:
If the Commerce Server computer that is hosting the AFS Business Desk is unavailable, the MSSE will be able to receive purchase orders (and buyers will be able to engage in remote shopping), but the orders will not be processed and saved to the orders database. All orders posted to the AFS Solution Site would be accepted and stored in the message queue on the BizTalk Server computer. BizTalk Server message queue receive functions would continue to retrieve the purchase orders and transform them into the Commerce Server Order XML v1.0 format. However, these orders would end up in the BizTalk Suspended Queue after failed attempts to post the order to the page _recvpo.asp on the Commerce Server computer that is hosting Business Desk.
Catalog publishing is not possible without access to Business Desk.
To recover from this failure, administrators should:
If the BizTalk Server computer is unavailable, the system cannot receive purchase orders, but will be able to support remote shopping. If the Commerce Server computer is unable to write the purchase order to the message queue on the BizTalk Server computer, the page ReceivePO.asp will return a negative HTTP response to the sender. Catalog publishing is unavailable because the page Publish.asp is not able to write the XML catalog to the shared directory on the BizTalk Server computer.
To recover from this failure, administrators should:
If the SQL Server computer is unavailable, the system cannot receive purchase orders, support remote shopping, or publish catalogs. All orders would be rejected and the AFS Solution Site and AFS Business Desk would be unavailable.
To recover from this failure, administrators should:
Service monitoring allows the operations staff to observe the health of an IT service in real time. Accurate monitoring of a system is a complicated puzzle within a distributed process environment, complicated even more by the integration with systems operated by trading partners. With this in mind, the following list is an example of system components that are typically monitored to ensure the IT service remains available:
However, knowing the current health of a service or determining that a service outage may occur is of little benefit unless the operations staff has the ability to do something about it, or at the very least notify the appropriate group that a specific type of reactive or proactive action needs to occur. This is what is meant by the term "control." When combined and implemented properly, this service management function provides the critical capability to ensure that service levels are always in a state of compliance.
The Event Log is the main error message repository for the Windows Server System products used in the MSSE. The following table lists some errors that may be encountered.
| Error | Issue/Resolution |
|---|---|
| publish.asp: Failed to write exported AdvW to receive function directory | The catalog was successfully exported from Commerce Server, but there was an error writing that message to the BizTalk Server. |
| _recvpo.asp: Instruct BizTalk Server to resend PO. Failed to process order [3000100162] from [1000] due to connection failure to the SQL server | SQL connection failure. |
| doPurchaseOrderResponse():
SupplierAccelerator
Rejected PO with incorrect shared secret or non-existing trading partner from AN21000004000T. Rejected PO can be found at \\MSSE\AFSRejectedOrders$\RejectedOrder1.xml |
Inbound purchase order was rejected as described. The order message was storedlocally on a Web server so administrators can review the message. A negative transport level acknowledgement was sent back to the sender in the HTTP response. |
| _recvpo.asp: Rejected order [61-258] from [xCBLTP] because price of one or more line items does not match with current catalog | Inbound purchase order was rejected as described. The order message remains in the BizTalk Server message queue where administrators can view and resubmit the message if needed. A negative application level acknowledgement was sent back to the sender if the order response message was configured for this trading partner. |
| _recvpo.asp: Rejected order [61-258] from [xCBLTP] because one or more line items refer to a catalog that does not exist any more | Inbound purchase order was rejected as described. The order message remains in the BizTalk Server message queue where administrators can view and resubmit the message if needed. A negative application level acknowledgement was sent back to the sender if the order response message was configured for this trading partner. |
Use System Monitor to measure the performance of your own computer or other computers on a network. System Monitor uses a series of counters that track data, such as the number of processes waiting for disk time, the number of network packets transmitted per second, and the percentage of processor use. With this data, you can create charts, set alerts, and format reports that enable you to gauge and tune system performance. Data can be displayed as it is collected, stored in log files for later use and comparison, or both.
Relevant performance counters can be categorized into the following groups:
Active Server Pages
The following table shows the Active Server Pages (ASP) performance counters that are of interest in the context of the MSSE, and observations to be made related to each counter.
| Counter | Observation |
|---|---|
| Requests queued | There should not be a significant queue except at peak periods. |
| Requests/sec | Indicates the volume of ASP requests the HTTP transport services are receiving (if you are using ASP). If files are posted to an HTTP page, this counter does not provide any pertinent information. |
| Request wait time | Close to zero. |
Network Segment
The following table shows the network segment performance counters that are of interest in the context of the MSSE, and observations to be made related to each counter.
| Counter | Observation |
|---|---|
| Bytes sent and Bytes received/ second | If this number is close to the capacity of the connection, and processor and memory use are moderate, the connection may affect performance. |
Process, Inetinfo Instance
The following table shows the process performance counters that are of interest in the context of the MSSE, and observations to be made related to each counter. The number of bytes, and especially changes to this number of bytes, associated with the Inetinfo process are particularly interesting.
| Counter | Observation |
|---|---|
| Private bytes | Monitor this for memory leaks or size approaching maximum available RAM. |
Memory
The following table shows the memory performance counters that are of interest in the context of the MSSE, and observations to be made related to each counter.
| Counter | Observation |
|---|---|
| Available bytes | Available byes should not stay below 10 MB consistently. If so, a memory spike would cause paging to disk to begin. |
| Page Faults/second, Pages Input/second, Page Reads/second | If these numbers are low, the server should be responding to requests quickly. If they are high, an increase the amount of RAM on your server may be needed. |
Physical Disk
The following table shows the physical disk performance counters that are of interest in the context of the MSSE, and observations to be made related to each counter.
| Counter | Observation |
|---|---|
| Disk read and writes/ second | Combined, these two counters should be significantly under the maximum capacity for the disk device. To enable this counter, on the Start menu, point to Programs, point to Accessories, and then click Command Prompt. At the command prompt, type diskperf –y, press Enter, and. then, restart the computer. |
| % Disk time | This counter should be well below 100 percent. If it is above this value (and it can go into the 1000 percent range), add more physical disks or move one of the databases to another server. |
| Current Disk Queue Length | This counter is the number of requests outstanding on the disk at the time the performance data is collected. This counter should average less than 2 for good performance. |
SQL Server
The following table shows the SQL Server segment performance counters that are of interest in the context of the MSSE, and observations to be made related to each counter.
| Counter | Observation |
|---|---|
| I/O transactions/second | Indicates how much activity the SQL Server actually performs. |
BizTalk Server
The following table shows the BizTalk Server performance counters that are of interest in the context of the MSSE, and observations to be made related to each counter.
| Counter | Observation |
|---|---|
| Documents Processed/second | Indicates how quickly BizTalk Server is polling documents from its Work queue and sending them. |
| Documents Received/second | Indicates how quickly BizTalk Server is sending documents to the Work queue. This number reflects only the number of documents BizTalk Server has received (this includes documents that fail parsing), not the number of documents BizTalk Server checkpoints to its Work queue. The number of documents that are check pointed to the Work queue is essentially equal to the Documents Processed/sec counter. |
| Synchronous Submissions/ second, Asynchronous Submissions/ second |
Indicates how quickly the Submit method and/or the SubmitSync method calls occur. Because each interchange can contain any number of documents, this counter is not useful for determining documents processed. If pass-through (processing interchanges without parsing them) is being used exclusively, use this counter to monitor inbound performance. |
Commerce Server
The following table shows Commerce Server performance counters that are of interest in the context of the MSSE, and observations to be made related to each counter.
| Counter | Observation |
|---|---|
| Pipeline: Executions per second | The number of executions made by the particular pipeline component per second. |
| Pipeline: Average execution time | The average execution time in microseconds for the particular component of the pipeline. |
| Catalog: Catalog Queries per second | The number of queries made to the Product Catalog System per second. The Query and FreeTextSearch methods are used to record the values for the performance monitor counters. No other methods record the counters. |
The Catalog Queries per Second counter is the rate of queries per second through the CS2000: Marketing and Catalog object on a server. These queries include all category and product related queries, as well as free-text search. You can reduce queries made to the Product Catalog System by using a product cache or search cache to improve performance. Free-text search can also be tracked with the Microsoft search>queries/sec counter.
The catalog query rate is the uncached rate. If this rate is high, then the application code should be changed to take advantage of a local caching mechanism, such as the LRUCache counter.
Note For an extensive list of performance counters available in Commerce Server, see Commerce Server 2002 Help.
Message Queuing
The following table shows Message Queuing performance counters that are of interest in the context of the MSSE, and observations to be made related to each counter.
| Counter | Observation |
|---|---|
| Messages in queue | This number should not go over 50,000; it will cause excessive memory use on the Message Queuing server and degrade the performance of the entire system. |
System
The following table shows system performance counters that are of interest in the context of the MSSE, and observations to be made related to each counter.
| Counter | Observation |
|---|---|
| Processor Queue Length | This counter displays the number of threads waiting to be executed in the queue that are shared by all processors on the system. If this counter has a sustained value of two or more threads, the processor is degrading the performance of the entire system. |
| Context switches/sec | If this is a high number on BizTalk Server, it could be because send and receive functions are running on the same server. If this is the case, consider separating the send and receive functions to separate servers. |
| %Processor Time | If the value of this counter is high, while the network adapter card and disk I/O remain well below capacity, the processor is affecting performance. On a multiprocessor computer, examine this counter to identify any imbalance. Additionally, while peak use can be 100 percent, sustained use should be below this value. All server elements can be scaled horizontally. |
XML Web Service
The following table shows XML Web Service performance counters that are of interest in the context of the MSSE, and observations to be made related to each counter.
| Counter | Observation |
|---|---|
| Get or post requests/sec | Indicates the volume of files being received through the HTTP get/post methods. |
| Non-anonymous users per second | Tracks the number of authenticated user requests on a site. |
| Total connections | The number of active Transmission Control Protocol (TCP) connections to the server. |
When the XLANG Scheduler Engine executes XLANG schedules, it generates many types of events, showing the progress of the schedule instances. BizTalk Server provides a tool that you can use to monitor XLANG schedule events and to see the progress of the schedule instances. You can monitor the default XLANG Scheduler application, or you can monitor the custom COM+ applications that you create to host XLANG schedules. XLANG Event Monitor can subscribe to all events published by the host applications on local or remote computers. XLANG Event Monitor can also store these events to a file for future analysis.
XLANG Event Monitor has the capability to receive events from all XLANG schedule host applications on the local computer or from XLANG schedule host applications on one or more remote computers. When XLANG Event Monitor is installed, the default behavior is to receive events from the XLANG schedule host applications on the local computer. If you want to include events from XLANG schedule hosts on remote computers, you must update the event sources by clicking the EventSources option on the Recording menu to include remote computers.
If you want to use XLANG Event Monitor, you must install it separately. You can find the XLANG Event Monitor application in the \Program Files\Microsoft BizTalk Server\SDK\XLANG Tools folder. Review the readme located in the same folder for more information about how to use XLANG Event Monitor.
The BizTalk Server Administration snap-in enables users to monitor the status of BizTalk message queues, receive functions, and the BizTalk Messaging Service running on the BizTalk Server computers.
BizTalk Message Queues
BizTalk Server provides shared queue management capabilities in BizTalk Server Administration. BizTalk Server administrators can move documents from any other queue to the Suspended queue. From the Suspended queue, documents can be deleted, resubmitted, or viewed, depending on the processing state of the document. BizTalk Server administrators can sort and display error messages for documents in the Suspended queue.
The following queues are used to contain incoming and outgoing documents that are in various stages of routing and processing in BizTalk Server:
Note Interchanges and documents appear in BizTalk Server Administration in the order of "first in, first out." That is, the oldest items in a queue appear first and the newest items appear last. Additionally, up to 15,000 interchanges and/or documents can appear in a queue at one time. If there are more than 15,000 actual items in a queue, you must remove or resubmit current items in the queue so that newer items can be displayed. The queue count in the console tree—the number next to the queue in parentheses—represents how many actual items there are in the queue. You can resubmit or delete documents to remove them from a queue.
Receive Functions
Receive functions enable BizTalk Server to monitor directories and queues, and then submit documents found therein to BizTalk Server for processing. BizTalk Server 2002 supports file and Message Queuing receive functions.
BizTalk Messaging Service
BizTalk Messaging Services, included in Microsoft BizTalk Server 2002, can be used to send documents to, and receive documents from, trading partners and other applications. For more information about BizTalk Messaging Services, see "BizTalk Messaging Services" in this document.
When BizTalk Server is installed, the ability to track metadata for interchanges is automatically activated. However, the capability to store whole copies of documents or specific or custom fields, or to track action events related to messages processed by XLANG schedules must be configured separately. This section provides an overview of the available tracking settings in BizTalk Server and provides recommendations for configuring and/or adjusting those settings.
Tracking Settings for a Server Group
When BizTalk Server is installed, or when you add a new server group, the following tracking options for a server group are enabled by default:
These settings allow BizTalk Server to store the metadata for interchanges and documents to the Tracking database. The metadata for interchanges and documents includes source organization information, destination organization information, document type, date and time the interchange was processed by BizTalk Server, document count, error information, and control ID.
This tracking setting applies to a server group and is configured in BizTalk Server Administration.
Tracking Settings in Channels and Document Definitions
The ability to store whole copies of documents or to store standard and/or custom fields is not automatically enabled. These options are configured in the appropriate channel or document definition. If channels and document definitions were not configured to track documents or standard and/or custom fields as part of the initial BizTalk Server deployment, be judicious about configuring these settings. Configure tracking settings in BizTalk Messaging Manager only if you need to:
If you turn all the tracking settings on in a channel and/or document, you will store redundant data. This will cause the Tracking database to grow quickly. If the Tracking database becomes too large and you do not regularly maintain it, the performance of BizTalk Server will be degraded.
There are a number of different aspects to the security of an MSSE installation. They can be categorized as follows:
IIS Lockdown Tool is a tool released by Microsoft that system administrators can use to close unused ports, services, and file extensions. You can also obtain this tool from the Microsoft Security Toolkit or from http://www.microsoft.com/technet/security/tools/locktool.asp.
You must run the IIS Lockdown Tool on the BizTalk Server, the Business Desk server, and the Web servers.
To run the IIS Lockdown Tool on the BizTalk Server
Your BizTalk Server is secured with the IIS Lockdown Tool.
To run the IIS Lockdown Tool on the Business Desk server and the Web servers
Your Business Desk server and Web servers are secured with the IIS Lockdown Tool.
You should run BizTalk Server under service accounts rather than interactive user accounts. With interactive user accounts, a user must be logged on to the computer for the application to run. In other words, if BizTalk Server is set up to run under an interactive user account, and if that particular user is not logged on, BizTalk Server will not process any documents.
When BizTalk Server is installed, the account identity is automatically configured to run under a service account. However, the default XLANG Scheduler application, any new COM+ applications that you create, and the BizTalk Server Interchange Application default to an interactive user account. There are several potential problems with using an interactive user account, including:
For more information about settings for service accounts, see "Create a service account" in the BizTalk Server Help.
Controlling the ability of a user to submit interchanges and documents to BizTalk Server provides yet another layer of security. The following properties for the BizTalk Server Interchange Application are configured to control who can send interchanges and documents:
If your deployment of BizTalk Server includes the use of certificates, it is recommended that you associate all certificates with a computer instead of with a specific user. This means that when you issue a certificate, you must do one of the following:
If you associate a certificate with a specific user, BizTalk Server must be configured to run with the credentials of that specific user. Additionally, if you have certificates associated with multiple users, the administration tasks can increase significantly. However, if a certificate is associated with the computer, any valid user can be logged on and the validity of the certificate is not affected.
If your business process requires that you associate certificates with specific users, you must store the certificates in the Certificates (Local Computer) item in the Certificates snap-in. BizTalk Server does not check the user store for certificates. In addition, if a password for a user changes and that user is associated with a certificate, you must update the following two applications:
For more information about certificates and BizTalk Server, see "Certificates Overview" in the BizTalk Server Help. Additional information is available in the MSDN Online Library (msdn.microsoft.com/library/); search for the entry "Certificate Services and Components."
Windows 2000 provides the Internet Protocol Security (IPSec) Monitor to confirm whether secured communications are successful. It displays the active security associations on local or remote computers. For example, the IPSec Monitor can be used to determine whether there has been a pattern of authentication or security association failures, possibly indicating incompatible security policy settings.
The IPSec Monitor can be used to monitor SAs, IPSec, and IKE statistics. To start the IPSec Monitor, click Start, click Run, in the Run dialog box, in the Open box, type ipsecmon.
When you create or edit a channel, you can configure the channel to override the messaging port properties if necessary. This allows you to send interchanges and documents to password-protected folders, message queues, ASP pages, and so on. User names and passwords can be associated with a channel and messaging port combination for the following transport services:
To associate a user name and password with a channel and messaging port combination, click the Advanced button on the Advanced Configuration page in the Channel Wizard. Verify that the Primary Transport tab is selected and then click Properties. Type a valid user name and password. If necessary, you can change other relevant information such as the name of the message queue location or the From address if you are using SMTP.
To facilitate the exchange of secure information between trading partners, BizTalk Server uses security features offered through Microsoft Windows 2000 and SQL Server. The following list includes some of the Windows security features used by BizTalk Server:
For more information about planning your public key infrastructure by using Secure Sockets Layer (SSL) and Secure Multipurpose Internet Mail Extensions (S/MIME), search for the phrase "Public Key Infrastructure" on the Microsoft TechNet Web site (http://www.microsoft.com/TechNet/).
For more information about MIME, search for the phrase "About Simple Internet (RFC 822) Messages" on the MSDN Online Library Web site (msdn.microsoft.com/library/).
For more information about SSL, search for the phrase "Using Schannel CSPs" on the MSDN Online Library Web site (msdn.microsoft.com/library/).
For Commerce Server Business Desk users and administrators to access resources, such as the product catalog, they must have sufficient permissions to access the SQL Server database that corresponds to the resource. A user should have a SQL Server login name that is linked to a SQL Server user that has the db_owner database role. Or, to provide greater detail, you can assign the user to the db_ddladmin, db_datareader, and db_datawriter roles.
To check the SQL Server roles assigned to a login name for a resource
Note You can also change these settings by modifying login properties in SQL Server Enterprise Manager. Expand the node for the database server you want, expand Security, and then click Logins to see the list of login names. Double-click a name to modify its database roles.
If the login name you specified does not appear in the list of database users, you can add a new SQL Server user.
To add a new SQL Server user for a resource database
| Use this | To do this |
|---|---|
| Login name | Select or type the login name used to access the database. |
| User name | Type the SQL Server user name that you want to assign to this login name. The user name assigns the new user permissions to objects in the database. |
| Database role membership | Select the roles that the new user should have. Select the db_owner box to give the new user access to the resource. Or, select the db_ddladmin, db_datareader, and db_datawriter boxes. |
It is difficult to predict how variables in site design, coding practices, user behavior, and site architecture will combine to affect site performance. Therefore, it is important to plan and test the capacity and performance of your site before "going live" in a production environment.
Analyzing user capacity is a complex problem. Before you can predict the maximum user capacity, you first need to profile user behavior, and then use the user profile information in conjunction with your performance metrics to calculate capacity. User behavior varies from site to site, depending on the richness of the shopping experience (page design, site design, and response time), as well as the types of products being sold and the extent of the product line. One site may support 1,000 users, while another site installed on an identical platform may support only 200 users because of differences in user behavior.
The following table lists some of the questions that you need to answer in planning system capacity.
| Planning question | Recommendation |
|---|---|
| What are the key items to measure to determine site performance? | Select the factors that closely match your goals for user experience. For example, if it is your goal to enable users to browse the catalog quickly, measure the speed at which a catalog browse request is returned. |
| What are the key usage profiles for measuring site performance? | Determine how you expect users to connect to your site and the expected load. Use this usage profile in your test environment, and then confirm that the profiles are correct when you have collected usage information in the Commerce Server Data Warehouse. |
| What are your expectations about the rate at which your site usage will grow? | Include excess capacity in the early stages of your site deployment. Compare actual growth to projections at regular intervals. |
| How will you balance the load across the servers in you site installation? | See the Windows 2000 Resource Kit for information about using Network Load Balancing (NLB). |
When considering performance, it is important to first determine where performance is needed most. Because tuning techniques vary for the different Windows Server System servers used in the MSSE, they are each discussed separately in this section:
In the MSSE, buyers generally have the most direct contact with Commerce Server.In the Commerce Server portion of the MSSE, performance tuning should focus on the front line Web servers that provide remote shopping facilities and receive purchase orders. These Web servers are configured to receive the inbound orders and pass them to the BizTalk Server computers as quickly as possible. Avoid burdening the front line Web servers with the transformation and processing of these purchase order messages. Further, avoid processing the order message synchronously, such that the Web page must wait for the order to be processed. Rather, order messages are placed in a message queue on the BizTalk Server computer, after which BizTalk Server can retrieve the order message and complete its processing asynchronously.
Another tuning possibility involves moving resource-intensive processing, such as the page _recvpo.asp, onto the AFS Business Desk computer. This allows the front line Web servers to remain free, providing quick responses and support for a greater number of concurrent users.
The Microsoft Web Application Stress (WAS) tool is a simulation tool developed by Web testers to realistically reproduce multiple browsers requesting pages from a Web application. Microsoft has made the tool easy to use by masking some of the complexities of Web server testing. This makes the WAS tool useful for anyone interested in gathering performance data on a Web site.
The WAS tool is a consolidation of many of the best features developed in Web application stress testing over the years, as well as a few new features. In addition, the current version covers the most needed features for stress testing three-tiered, personalized, and ASP page sites running on Windows 2000.
This topic provides general recommendations for optimizing system settings, and includes information for optimizing BizTalk Server settings to increase performance. These recommendations include:
Performance characterization testing has shown that SQL Server is not a cause of poor performance in the MSSE. However, care should be taken to ensure that stored procedures, indexes, tables, and the databases themselves are optimized for performance.
SQL Server Profiler is a tool that captures Microsoft SQL Server events from a server. The events are saved in a trace file that you can analyze or use to replay a specific series of steps later when you are trying to diagnose a problem. You can use SQL Server Profiler to:
The SQL Server Profiler is available in SQL Server Enterprise Manager on the Tools menu.
The following URLs provide additional information about the corresponding subject areas:
Microsoft Operations Framework:
http://www.microsoft.com/business/services/mcsmof.asp
Microsoft BizTalk Server:
http://www.microsoft.com/biztalk
Microsoft Commerce Server:
http://www.microsoft.com/commerceserver
Microsoft Solution for Supplier Enablement: