Microsoft BizTalk Server 2000 Operations
Summary: This article describes the concepts, tasks, and administrative issues a system administrator needs to know to operate and maintain a Microsoft BizTalk Server 2000 installation. An overview of the BizTalk Messaging Services and BizTalk Orchestration Services concepts relevant to administering BizTalk Server 2000 is provided. Additionally, this article outlines the administrative tasks and issues that system administrators might encounter. Anyone reading this article should also read the "Microsoft BizTalk Server 2000 Deployment Considerations" article, which contains important background information for this topic. (33 printed pages)
BizTalk Messaging Services Concepts
BizTalk Server Orchestration Services Concepts
Administering BizTalk Server
Administering Transport Services
Tracking Interchanges and Documents
Monitor a BizTalk Server 2000 Deployment
Troubleshooting BizTalk Server
For More Information
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 more common for enterprise application integration to have a similar up-time requirement. This article outlines the administrative tasks a system administrator must perform to keep an installation of Microsoft® BizTalk™ Server 2000 running on a continual basis. Also discussed are important concepts and common administrative issues about which system administrators must be aware.
The eight major areas of administration and management related to BizTalk Server 2000 are:
- Server administration. You can use BizTalk Server Administration to manage server groups and adjust server properties for maximum performance.
- Database administration. You can use scripts and tools to maintain the following four types of databases associated with BizTalk Server: BizTalk Messaging Management, Tracking, Shared Queue, and Orchestration Persistence.
- Messaging objects administration. You can use BizTalk Messaging Manager or the BizTalk Messaging Configuration object model to update messaging objects, such as channels and messaging ports. You can also use BizTalk Messaging Manager or the BizTalk Messaging Configuration object model to facilitate the processing and transmission of interchanges and documents.
- Receive function and parser administration. You can use BizTalk Server Administration to manage receive functions and parsers.
- Application administration. You can use Component Services to manage the default XLANG Scheduler application, or to add and configure additional COM+ applications that host XLANG schedules.
- Tracking interchanges and documents. You can use BizTalk Server Administration to change the tracking settings for a server group. Additional tracking settings can be set by using BizTalk Messaging Manager or the BizTalk Messaging Configuration object model. Tracking results can be viewed by using BizTalk Document Tracking.
- Monitoring a BizTalk Server deployment. You can use System Monitor, Microsoft® Windows®
- Troubleshooting. You can use BizTalk Server Administration to view the Suspended queue for processing and transmission errors. You can use Event Monitor to troubleshoot server errors, BizTalk Server application errors, XLANG Scheduler errors, and other COM+ application errors.
In addition to the administrative tasks associated with managing a BizTalk Server installation, all system administrators must be aware of the following concepts and administrative issues:
- BizTalk Messaging Services. How to submit interchanges and documents to BizTalk Server and how the appropriate properties must be configured to process and transmit submitted interchanges and documents.
- BizTalk Orchestration Services. The difference between XLANG schedule drawings and XLANG schedules and how XLANG schedules work.
- Tracking overview. How interchanges, documents, and action events related to messages processed by XLANG schedules are tracked in the Tracking database and viewed in BizTalk Document Tracking. After BizTalk Server is implemented, settings might need to be reconfigured to accommodate changes in business processes.
- Transport services. Common implementation and maintenance issues for a variety of transport services that should be considered when administering a BizTalk Server 2000 installation.
- Security. The security features that BizTalk Server uses and the configuration changes that might be necessary when managing a BizTalk Server 2000 installation.
BizTalk Messaging Services are services included in Microsoft BizTalk Server 2000 that enable you to send, receive, parse, and track interchanges and documents from other organizations or applications. In addition, BizTalk Messaging Services include the ability to generate receipts for certain file formats, correlate and map data, verify the integrity of documents, and provide secure methods for exchanging documents with trading partners and applications.
To implement BizTalk Messaging Services, BizTalk Server uses messaging objects, receive functions, COM methods, parsers, and a Microsoft® SQL Server™ database (version 7.0 with SP2 or SQL Server 2000). Messaging objects, such as channels and messaging ports, are used to configure the necessary properties to process and transmit interchanges and documents submitted to BizTalk Server. Receive functions and in some cases the Submit and SubmitSync methods are used to submit incoming documents to BizTalk Server for processing. Once a document is submitted, the appropriate parser parses it and, if necessary, converts it to XML. Finally, the Tracking database stores interchange and document records for incoming and outgoing interchanges and documents that are processed by BizTalk Server.
BizTalk Server uses the following messaging objects to configure the necessary properties to process and transmit submitted work items:
- Channels. A set of properties that directs BizTalk Server through the appropriate steps to process documents. Channel properties include a source organization or application, a document definition, a map, and field and document tracking settings.
- Messaging ports. A set of properties that specifies how an interchange or document is transported to a destination organization or application. Messaging port properties include transport services, destination organization or application, security settings, and envelope settings.
- Distribution lists. A group of messaging ports. Use a distribution list to send the same document to more than one trading partner organization or application. In the BizTalk Messaging Configuration object model, a distribution list is called a port group.
- Organizations. The trading partners with which your business exchanges interchanges and documents. An organization can be internal, such as an application in another division of your company. Or an organization can be external, such as a different business.
- Document definitions. A set of properties that represents an inbound or outbound document and that might provide a pointer to a specification. A specification defines the document structure, document type, and version. However, a pointer from the document definition to a specification is not required.
- Envelopes. A set of properties that can represent the transport information for a document. An envelope associated with an inbound interchange or document provides BizTalk Server with the information that it needs to interpret the submitted document. For example, the envelope can contain a pointer to the document definition. An envelope associated with an outbound interchange or document gives BizTalk Server the information that it needs to create the document. Envelope properties are optional for most file formats.
Submitting Interchanges and Documents
Interchanges and documents must be submitted to BizTalk Server by using receive functions or the Submit or SubmitSync method of the IInterchange interface. Once an interchange or document is submitted, the appropriate parser in BizTalk Server parses it, unless the interchange or document is submitted with the pass-through flag enabled. BizTalk Server does not parse interchanges and documents submitted with the pass-through flag enabled.
Using Receive Functions
It is recommended that you use receive functions to submit interchanges and documents to BizTalk Server. Receive functions can take advantage of caching, thus optimizing the performance of BizTalk Server. BizTalk Server supports two types of receive functions: File and Message Queuing.
Receive functions are event-based. This means that a receive function waits for an event in a specified folder or message queue. When an interchange or document is placed in the folder or message queue, the receive function immediately picks up the interchange or document and submits it to BizTalk Server for processing. If the interchange or document is large and it takes more than a few seconds to write the interchange or document to the folder or message queue, the receive function locks the file and goes into a polling mode until the interchange or document is completely copied to the receive location. Once the interchange or document is completely copied, the receive function submits it to BizTalk Server for processing and deletes the document from the message queue or the file system.
Using the Submit and SubmitSync methods
You can use the Submit and SubmitSync methods if the application that submits interchanges and documents to BizTalk Server meets the following criteria:
- The application is a Microsoft Windows-based application.
- The application is capable of invoking methods on COM objects.
- The application can be designed to support direct calls to BizTalk Server 2000.
Again, it is recommended that you use receive functions to submit interchanges and documents to BizTalk Server. Use the Submit or SubmitSync method only if you cannot use a receive function.
Once an interchange or document is submitted to BizTalk Server, it is parsed. If the document is in a non-XML format, such as EDI or flat file, the parser converts the submitted interchange or document into an intermediary XML format for processing. Four specialty parsers are included with BizTalk Server to parse the following document type formats: XML, X12, EDIFACT, and flat file.
Included in BizTalk Server 2000 is the capability to track:
- Metadata for interchanges, such as source and destination organization, time the interchange or document was processed, and so on.
- Whole copies of documents in their native or XML format.
- Specific fields.
- Custom fields.
- Action events related to messages processed by XLANG schedules.
For more information about tracking documents and interchanges, see "Tracking Interchanges and Documents" later in this paper.
To facilitate the exchange of secure information between trading partners, BizTalk Server 2000 uses security features offered through Microsoft Windows 2000 and Microsoft SQL Server. Some of the security features used by BizTalk Server 2000 are included in the following list:
- Authentication. Authentication verifies the identity of a user who is logging on to a computer.
- Public key infrastructure. Public key infrastructure is a set of policies and procedures used to securely exchange information between trading partners. Elements of public key infrastructure include a public key, a private key, Certification Authorities, and digital signing.
For more information about planning your public key infrastructure by using Secure Sockets Layer (SSL) and Secure Multipurpose Internet Mail Extensions (S/MIME), go to the Microsoft TechNet Web site (www.microsoft.com/TechNet/) and search for "Public Key Infrastructure."
- Digital signatures. Digital signatures are a guarantee that a document has not been altered after the digital signature was added. Digital certificates are used to ensure that the sender is not an impersonator.
- Multipurpose Internet Mail Extensions (MIME). MIME is a standard encoding method used to transmit data through Internet e-mail. When data is sent, it is encoded. When data is received, it is decoded. The file header includes the information that the recipient needs to decode the information.
For more information about MIME, go to the MSDN Online Library Web site (msdn.microsoft.com/library/default.asp) and search for "About Simple Internet (RFC 822) Messages."
- Secure/Multipurpose Internet Mail Extensions (S/MIME). S/MIME is the secure version of MIME. Before data is sent, it is encrypted to guarantee secure transmission.
- Secure Sockets Layer (SSL). Secure Sockets Layer uses a randomly generated private key that can be used only for that session. At the beginning of a session, the server sends the public key to the browser. The browser randomly generates a private key and sends it back to the server.
For more information about SSL, go to the MSDN Online Library Web site (msdn.microsoft.com/library/default.asp) and search for "Using Schannel CSPs."
In addition to the security features listed here, BizTalk Server 2000 uses logon properties, local policies, service accounts, control of a user's ability to send interchanges and documents to BizTalk Server 2000, and certificates to enhance security. These issues are described in "Security Issues)" later in this article.
BizTalk Orchestration Services are composed of tools and services included in BizTalk Server that enable you to design, compile, and run XLANG schedules. Typically, a business analyst and a developer are involved in designing and compiling XLANG schedules. The system administrator manages the deployment and operation of XLANG schedules. Additionally, the system administrator might create custom COM+ applications to host XLANG schedules and create persistence databases to store dehydrated XLANG schedule states.
There are eight concepts related to understanding and running XLANG schedules. They are:
- XLANG language. An XML-based language that describes the logical sequencing of business processes. The XLANG language also describes the implementation of the business process by using various application services.
- XLANG schedule drawing. A representation of all the different steps in a business process. For example, if an employee requests a new computer, an XLANG schedule can be used to show the flow of information from the initial request from the employee, to the acceptance or denial of the request, to the purchase of the computer—if the request is accepted—to the generation of the invoice and the payment of the invoice. The XLANG schedule drawing includes the protocol that trading partners agree to use to exchange data and the flow of data between message fields. A completed drawing can be compiled and run as an XLANG schedule. An XLANG schedule drawing is saved with the file extension .skv.
- XLANG schedule. Specific business processes expressed in the XLANG language. An XLANG schedule is saved with the file extension .skx.
- XLANG schedule instance. A particular occurrence of an XLANG schedule. The XLANG Scheduler Engine can run a single instance, or multiple instances, of an XLANG schedule. Different instances of the same XLANG schedule contain different messages, but all instances follow the same business-process rules.
- XLANG identity. A globally unique identifier that is used to distinguish version instances of an XLANG schedule drawing. This property is read-only and cannot be changed by users. Each time an XLANG schedule drawing is updated, the identity is also updated. The XLANG identity can be used to correlate an XLANG schedule with the specific version of an XLANG schedule drawing from which the schedule was compiled.
- XLANG schedule state. The information contained in an XLANG schedule instance. This information includes:
- Messages that have been sent or received by that instance.
- Any COM objects used by that instance that contain state information and are able to preserve state information.
- The progress of that instance toward the completion of the business process.
- XLANG Scheduler. The default COM+ application that is installed when you install BizTalk Server 2000. This application is used to host running instances of XLANG schedules.
- XLANG Scheduler Engine. A service that runs XLANG schedule instances and controls the activation, execution, dehydration, and rehydration of an XLANG schedule.
Dehydration and Rehydration
When an instance of an XLANG schedule is running, it is processed in memory. Because XLANG schedules are designed to support long-running, loosely coupled, executable business processes, it can become impractical to have thousands of XLANG schedule instances continuously running over a long period of time because it would be a poor use of resources. In addition, if an XLANG schedule runs only in memory, data is lost or possibly corrupted if the server on which the XLANG schedule is running fails. In these situations, the XLANG Scheduler Engine infrastructure dehydrates or rehydrates XLANG schedule instances.
An XLANG schedule is dehydrated when an XLANG schedule instance is waiting for a message and no other activity is occurring in the schedule instance. Dehydration means that the instance-specific state information is stored in the appropriate persistence database and the XLANG schedule no longer resides in memory.
An XLANG schedule is rehydrated when the message for which the XLANG schedule instance is waiting arrives. At this time the XLANG schedule instance is rehydrated, the instance-specific state information is removed from the persistence database, and the schedule instance resides in memory again.
An XLANG schedule instance remains dehydrated until it is either rehydrated or explicitly terminated by an administrator. This enables a business process to run reliably for an extended time period.
The following five areas of administration are related to maintaining BizTalk Server in a state of continuous operation:
- Administering servers. Administrative tasks include managing server groups and servers.
- Administering databases. Administrative tasks include maintaining the four types of databases associated with BizTalk Server.
- Administering messaging objects. Administrative tasks include managing messaging objects such as channels, messaging ports, and envelopes.
- Administering receive functions and parsers. Administrative tasks include managing receive functions and changing the parser order.
- Administering applications. Administrative tasks include managing the default XLANG Scheduler, creating and managing COM+ applications to host new XLANG schedules, and managing application identities.
Some of the most common tasks related to server administration include:
- Adding and managing server groups.
- Adding and managing servers installed with BizTalk Server 2000.
- Managing interchanges and documents in the Shared Queue database.
Use BizTalk Server Administration to perform these server administration tasks. Or perform many of these tasks programmatically by using the Windows Management Instrumentation (WMI) layer.
Managing Server Groups
Server groups are the basic organizing principle for server administration in BizTalk Server 2000. Servers are organized into groups to increase performance and provide a level of redundancy and fault tolerance. Server groups have eight properties that can be configured to manage the servers within the group. There are many reasons why you might need to modify one or more of these properties after the initial deployment of BizTalk Server. For example, you might need to associate a server group with a new and/or replicated Tracking or Shared Queue database, or you might need to update the SMTP host that a server group uses.
Server group properties can be modified in BizTalk Server Administration in the <Server Group Name> Properties dialog box. The following table lists some of the common configuration updates and which property you must modify to implement the update.
|If you need to do this||Modify this server group property||On this tab|
|Change the SMTP host that a server group uses.||SMTP Host||General|
|Change the URL the server group uses to receive reliable messaging receipts.||Reliable messaging reply-to URL||General|
|Modify how often the Messaging Management object cache is refreshed.||Messaging Management object cache interval||General|
|Add and/or change the proxy server that the server group uses.||Proxy server||General|
|Change the Tracking database that the server group uses.||Tracking database||Connection|
|Change the Shared Queue database that the server group uses.||Shared Queue database||Connection|
|Turn on or off tracking settings.||Enable document tracking||Tracking|
|Turn on or off the ability to log incoming interchanges.||Log incoming interchange||Tracking|
|Turn on or off the ability to log outgoing interchanges.||Log outgoing interchange||Tracking|
|Turn on or off the ability to log original MIME-encoded messages.||Log the original MIME-encoded message||Tracking|
|Change the parser order or refresh the parser list from the registry.||Arrange the server call sequence||Parser|
There are two situations that require you to change server properties:
- Adding a server to a group
- Changing the balance between throughput and performance for one or more servers in one or more groups
Servers in a server group are configured to balance server performance and maximum throughput. If your business needs change, you might need to adjust the server settings that were configured when BizTalk Server was installed. For example, you might be required to process more documents more quickly. Or you might need to configure a server in a group to receive only interchanges and documents. When you adjust server properties, experiment with various combinations in a test environment before you change the server properties on your production BizTalk Servers.
You can change server properties in BizTalk Server Administration in the <Server name> Properties dialog box. The following list describes each of the server properties and the implications of changing the settings:
- Maximum number of receive function threads allowed. Specifies the maximum number of receive function threads on a per-processor basis. Increasing this number increases the throughput of the receive functions on the server. In general, if a BizTalk Server is receiving and processing documents or just processing documents, set this property to 1. However, if a BizTalk Server is configured to receive only, set this property to 4 to optimize throughput.
- Participate in work-item processing. Specifies whether the server is processing interchanges and documents. If the Participate in work-item processing check box is selected, the server processes interchanges and documents in the Work queue. If this check box is cleared, the server does not process any interchanges or documents in the Work queue.
If you need to configure a server so it receives only documents, clear the Participate in work-item processing check box. Or if you need to dedicate a server in one of the server groups to administration, clear the check box for this option on that server.
- Maximum number of worker threads per processor allowed. Specifies the maximum number of worker threads on a per-processor basis. A low setting might cause a bottleneck if your BizTalk Server installation processes a high volume of documents and interchanges. Increase the setting to relieve the bottleneck. However, if the setting is too high, performance degradation might occur. In general, setting this property to 14 or 16 provides the best throughput.
- Time between BizTalk Server Scheduler calls. Specifies the range for time between BizTalk Server Scheduler calls. A thread polls the Work queue for interchanges and documents that need to be processed. This option controls how often that thread polls the Work queue. If the amount of data that you receive increases, you might need to lower this number. If the amount of data that you receive decreases, you might need to increase this setting.
The Maximum number of worker threads per processor allowed and the Time between BizTalk Server Scheduler calls settings are two factors that influence how often BizTalk Server accesses the Shared Queue database. If the amount of data that you receive and process has changed since you installed BizTalk Server 2000, you might need to adjust these settings. For example, if you need to limit how often the Shared Queue database is accessed, set the number lower for Maximum number of worker threads per processor allowed and higher for Time between BizTalk Server Scheduler calls. Similarly, if you need to increase the volume to the databases, increase the number for the maximum number of worker threads and decrease the setting for the time between scheduler calls. Again, test the new configurations in a simulated environment before you implement the changes on your production BizTalk Servers.
When an interchange or document is submitted to BizTalk Server 2000, it is stored in the Shared Queue database until it is completely processed. The Shared Queue SQL Server database is graphically represented in BizTalk Server Administration as the Queues item in each server group. The Queues item, also called the Shared Queue, contains four subitems that represent the four queues of the Shared Queue. They are the Work, Scheduled, Retry, and Suspended queues. By accessing these queues, you can determine what stage of processing the interchange or document is in. For example, you can determine if a document has been processed and is waiting for transmission or if an interchange or document failed processing.
Managing the Work queue
The Work queue contains interchanges and documents that are currently in process. Unless you are continually processing a large number of documents, this queue usually is empty. Interchanges and documents placed in this queue are processed upon arrival, and they are not in the queue for very long.
Any item in the Work queue can be moved to the Suspended queue. Move interchanges and documents to the Suspended queue only if you want to prevent them from being processed. Once an interchange or document is moved to the Suspended queue, it can be deleted, resubmitted, or retransmitted to the Work queue to complete processing.
Managing the Scheduled queue
The Scheduled queue contains interchanges and documents that have been processed by BizTalk Server and are waiting for transmission based on the service window. Like the Work queue, any item in the Scheduled queue can be moved to the Suspended queue.
Managing the Retry queue
The Retry queue contains interchanges and documents to be resubmitted for delivery and documents that are waiting for reliable messaging receipts. You cannot tell the difference between the two types of transmissions. By default, failed transmissions are retried every five minutes for a maximum of three tries before they are moved to the Suspended queue. If your business process requires that you change this default setting, you can change the number of retries available and the interval in the appropriate channel in BizTalk Messaging Manager. Or you can change the interval number of retries programmatically by using the RetryCount and RetryInterval properties of the BizTalk Messaging Configuration object model.
Managing the Suspended queue
The Suspended queue stores and displays interchanges and documents that have failed processing for reasons such as parsing errors, serialization errors, missing channels, and so on. Most interchanges or documents in this queue can be deleted, resubmitted, or retransmitted to BizTalk Server for processing. Interchanges and documents that failed parsing cannot be resubmitted or retransmitted. You must delete these documents and submit them to BizTalk Server again from the original application or organization. In addition, the Suspended queue is a source of information to help you troubleshoot BizTalk Server errors and processing problems. For more information about troubleshooting, see "Troubleshooting BizTalk Server" later in this paper.
Accessing and viewing the Shared Queue
You can access the Shared Queue by viewing the Queues item in each server group in BizTalk Server Administration. You can also access the Shared Queue by using the Windows Management Instrumentation (WMI) layer. Interchanges and documents appear in each of the queues in the order of "first in, first out." That is, the oldest items in the Work, Retry, Scheduled, or Suspended queue appear first and the newest items appear last. Additionally, up to 15,000 interchanges and/or documents appear in a queue at a time. In BizTalk Server Administration, the queue count in the console tree—the number in parentheses next to each queue—represents how many actual items are in that particular queue. If there are more than 15,000 actual items in a queue, remove or resubmit current items in the queue so that newer items can be displayed. For example, if there are 16,000 items in the Retry queue, you must move at least 1,000 items from the Retry queue to the Suspended queue to view the newest 1,000 items in the Retry queue. From the Suspended queue, you can resubmit or delete the interchanges or documents that were in the Retry queue.
Refreshing BizTalk Server Administration
There is no automatic refresh cycle for BizTalk Server Administration. If you want to view the current status of server groups, servers, receive functions, the number of items in a queue, and so on, you must refresh BizTalk Server Administration. You can perform this procedure on any item in the console tree or on an individual item. For example, when you refresh the Microsoft BizTalk Server Administration item, all items in BizTalk Server Administration are refreshed. When you refresh a server group, only the items in that server group are refreshed.
The second aspect of administration that relates to BizTalk Server is database administration. The following four types of Microsoft SQL Server databases are associated with BizTalk Server 2000:
- BizTalk Messaging Management database. This database stores information for all server and messaging configuration. Server configuration information includes server group and server settings, and receive functions. Messaging configuration includes channels, messaging ports, document definitions, organizations, and so on.
- Tracking database. This database stores all interchanges, documents, and receipts that are processed by BizTalk Server if tracking settings for a server group, channel, and/or document definition are turned on.
- Shared Queue database. This database holds documents while they are being processed or waiting to be processed. Documents are removed from this database after they have been processed.
- Orchestration Persistence database. This database stores the XLANG schedule state when an XLANG schedule is dehydrated.
BizTalk Server 2000 stores the four types of databases it uses in SQL Server, so a majority of the administrative tasks associated with managing the databases are associated with managing SQL Server. Because there is a large amount of information published about SQL Server administration, this paper will not repeat that information with the exception of the following topics:
- Database replication
- SQL Server settings
- Database administration issues
For more information about administering SQL Server, see the Microsoft SQL Server Web site (www.microsoft.com/sql).
A general administrative task that can be performed with databases is replication. It is recommended that you replicate and provide a backup facility for the four types of databases associated with BizTalk Server. You can make duplicate copies of your data, move those copies to different locations, and synchronize the data automatically. This ensures that all copies have the same data values. Replication can be implemented between databases on the same server, or on different servers that are connected by a local area network (LAN).
SQL Server Settings
After you deploy BizTalk Server 2000, you might need to change the following settings associated with your SQL Server databases:
- Auto shrink
- Truncate log on checkpoint
- Automatically grow file
You can change the Auto shrink and Truncate log on checkpoint settings 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 and Truncate log on checkpoint settings control disk space allocation. If you want to avoid unnecessary disk space allocation, enable the Auto shrink and Truncate log on checkpoint options in SQL Server. The Truncate log option is available only in SQL Server 7.0.
The Automatically grow file setting enables the four types of SQL Server databases associated with BizTalk Server 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:
- If you want SQL Server to handle low database space conditions automatically.
- If SQL Server is the only application using disk space and when ample disk space exists to grow databases.
- If you want to use disk Quota Alerts to alert you that a database is nearing its capacity limits. This enables you to prevent a BizTalk Server from failing because one of the databases it uses reaches capacity.
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:
- If you must have control over how much space SQL Server uses.
- If SQL Server shares the same disk with other applications and those applications must have disk space available at all times.
- If you want BizTalk Server or other processes to stop when SQL Server is out of space. This allows clean-up processes to run, and BizTalk Server can be restarted when the clean-up process is complete.
Database Administration Issues
Of the four types of databases associated with BizTalk Server, two require special maintenance attention: the Tracking and Orchestration Persistence databases. These two types of databases can grow in size quickly and require regular maintenance.
Maintaining the Tracking database
If you configured all tracking options for a server group in BizTalk Server Administration 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 DTA_SampleJobs.sql, a sample SQL Server script that is provided 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 \Program Files\Microsoft BizTalk Server\SDK\Messaging Samples\SQLServerAgentJobs folder. Review the readme included with this sample for more information about how to tailor the script to your specific BizTalk Server deployment.
Note If you are using SQL Server 7.0 with SP2, the tables that have image or text columns might not shrink in size, even if you delete rows from those tables in the Tracking database. SQL Server SP3 helps to alleviate this issue. SP3 is available at the Microsoft SQL Server Web site (www.microsoft.com/sql/downloads/sp3.htm).
This issue does not occur in SQL Server 2000.
Replicating the 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 greatly 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.
Caution Do not change the code, such as stored procedures or triggers, in the Tracking database. Do not access the Tracking database directly. Do not directly call the stored procedures or add triggers. Making changes to the Tracking database in this way might cause BizTalk Server to function incorrectly, cause the loss of data, or corrupt the Tracking database.
Maintaining the 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 included with BizTalk Server. However, this issue will be corrected in a future release. For information about maintaining the persistence database, articles, and the most recent updates on the availability of such scripts, go to the Microsoft BizTalk Server Web site (www.microsoft.com/biztalk/).
Caution 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.
Administering Messaging Objects
You can use BizTalk Messaging Manager or the BizTalk Messaging Configuration object model to configure additional messaging objects or to update and manage current messaging objects. For example, you might need to update the URL for the HTTP transport service in a messaging port. Or you might want to change the fields that you track in a channel or document definition.
The following table lists some of the messaging object properties that a system administrator might need to update or reconfigure.
|If you need to do this||Configure this property||On this messaging object|
|Update or reconfigure a transport service.||Primary transport, Backup transport||Messaging ports or distribution lists (port groups)|
|Change where an interchange or document is sent.||Open destination, Organization, New XLANG schedule, Running XLANG schedule, Application||Messaging port or distribution list (port group)|
|Change the envelope for an interchange or document instance for a specific trading partner.||Envelope information||Messaging port or distribution list (port group)|
|Change or update an envelope format.||Envelope format||Envelope|
|Set the option so an interchange or document generates a receipt when it is received from a trading partner.||Generate receipt||Channel|
|Set the option for an interchange or document to expect a receipt when it is sent to a trading partner.||Expect receipt||Channel|
|Change from whom an interchange or document is expected.||XLANG schedule, Application, Open source, Organization||Channel|
|Change the name of an organization.||Organization name||Organization|
|Change fields that are tracked.||Fields to track||Channel or document definition|
|Change the name of a document definition.||Document definition name||Document definition|
Administering Receive Functions and Parsers
In addition to messaging objects, receive functions and parsers must also be managed in BizTalk Server 2000. You can use BizTalk Server Administration to manage receive functions and parsers.
Receive Function Administration issues
For many different reasons, you might need to delete a server from a server group. For example, you might need to replace a server with a new one. Or you might need to move a server from one group to another to provide better load balancing in the new server group. If you plan to delete a server from a server group, you must first complete one of the following tasks:
- Reconfigure all receive functions that point to the server that you want to delete to point to a different server in the server group.
- Delete the receive functions that point to the server you want to delete if they can no longer be used.
You are prevented from deleting a server from a server group if one or more receive functions point to it.
Parser administration issues
If you receive files in formats other than XML, X12, EDIFACT, or flat file, you must create your own parser and register it on the appropriate BizTalk Server. If you create a custom parser, it appears at the bottom of the parser list after the parser is registered and the list is refreshed. This list can only be refreshed locally. That is, if you registered the custom parser on BizTalk Server A, you must refresh the parser list on BizTalk Server A. You cannot refresh the parser list from a remote computer.
When BizTalk Server is installed, parsers appear in the parser list in the following order:
Again, if you add any custom parsers, they appear at the end of this list unless you change the parser order. To maximize BizTalk Server performance, for the document format that you receive most frequently, put the corresponding parser at the top of the list. For example, if you receive mostly flat files, change the parser order so that the flat-file parser is at the top of the list.
The focus of application administration is managing the COM+ applications that host XLANG schedules. When BizTalk Server is installed, two COM+ applications are installed that you must administer:
- The default XLANG Scheduler application. This application hosts the default instance of the XLANG Scheduler Engine.
- The BizTalk Server Interchange Application. This application hosts the roles that limit who can send interchanges and documents to BizTalk Server.
Tasks related to application administration include:
- Changing the configuration of the default XLANG Scheduler application.
- Adding new COM+ applications.
- Changing the application identity.
- Changing the default Orchestration Persistence database settings and configuring settings for new persistence databases.
- Adding new persistence databases.
- Changing data source name (DSN) settings.
- Performing a controlled shutdown of XLANG schedules.
- Restarting XLANG schedules.
Managing XLANG Scheduler and Other COM+ Applications
The default XLANG Scheduler application and Orchestration Persistence database are created during the installation of BizTalk Server 2000. If all your security and application processes are exactly the same, the default XLANG Scheduler application could host all of your XLANG schedules. Since this business scenario is unlikely, you will probably need to create new COM+ applications to host XLANG schedules or you might need to modify the default XLANG Scheduler application. How and when you create new COM+ applications depends on security issues and application processes. For example, you might want to isolate applications that run specific schedule instances. To do this, you need to create a COM+ application for each application that you want to isolate. Or, if you have specific security requirements for some applications or XLANG schedules, you will need to create a COM+ application for those XLANG schedules.
Each new COM+ application that you create has an XLANG tab in the properties dialog box for that COM+ application. On the XLANG tab, you can enable the new COM+ application to host instances of the XLANG Scheduler Engine. The specific COM+ application in which a new XLANG schedule runs is determined by the moniker syntax used to activate an instance of an XLANG schedule.
Changing the Application Identity
When you create a COM+ application, it is recommended that you change the application identity from an interactive user account to a service account. With an interactive user account, if a user is not logged on, the application will not run. However, if you change the interactive account to a service account, a specific user does not have to be logged on all the time, thus compromising security. A service account is an account with specific properties that allow the account to act as part of the operating system. Therefore, a specific user, or any user at all, does not have to be logged on for the application to process messages.
Managing Orchestration Persistence Database Settings
You could use the default Orchestration Persistence database to store all dehydrated XLANG schedules. However, this configuration would cause the persistence database to grow in size quickly. It is recommended that you create new persistence databases as appropriate for your business needs and processes. If you have many XLANG schedules that dehydrate often, you will need more persistence databases than if you have a few XLANG schedules that dehydrate infrequently.
In addition, if you associate a COM+ application with a new or existing persistence database, you must change the data source name (DSN) for that COM+ application. The DSN connects the COM+ application to the correct persistence database. If you change the persistence database, you must change the DSN for the COM+ application.
Shutting Down and Restarting XLANG Applications
If you need to bring a BizTalk Server that hosts BizTalk Orchestration Services offline, for example for maintenance purposes, you must perform a controlled shutdown of all XLANG applications so that data associated with XLANG schedules is not lost. A controlled shutdown saves the state for running XLANG schedules to the appropriate persistence database. If you perform a controlled shutdown on the default XLANG Scheduler application, all XLANG schedules are gracefully shut down and the XLANG schedule instance data is preserved. If you perform a controlled shutdown on a COM+ application that you created after installation, only the XLANG schedules associated with that COM+ application are gracefully shut down and preserved. All other XLANG schedules remain running until you shut down the COM+ application(s) with which they are associated.
To restart the XLANG schedules, you must restart all the schedules at the same time in the default XLANG Scheduler application. You cannot restart applications that are associated with a specific COM+ application.
Caution If you want to perform a controlled shutdown, do not right-click a COM+ application and choose Shut down. Additionally, do not use the Shut down item on the Action menu. These procedures perform an uncontrolled shutdown. If you perform an uncontrolled shutdown, one of the following might occur:
- If running XLANG schedules are fully transactional, executing transactions might abort.
- If running XLANG schedules are not fully transactional, data that is in process in the schedule is lost.
- If an XLANG schedule has not been persisted, there will be data loss and the XLANG schedule will not automatically restart.
Instead, go to BizTalk Server 2000 Help and follow the "Shut down all XLANG applications" procedure.
Do not shut down Windows without performing a controlled shutdown of all XLANG applications.
BizTalk Server 2000 supports the following transport services:
- Message Queuing
- Application integration components (AICs)
The type of transport that is used depends on the business process and the type of data that is exchanged. For example, the File transport service is often used with internal applications or with legacy systems. Message queuing is used to exchange messages and documents between BizTalk Orchestration Services and BizTalk Messaging Services. HTTP is often used to exchange documents with trading partners.
Each transport service requires special considerations to keep the system running smoothly. This topic discusses some of the issues you might encounter with some of the transport services.
When managing your BizTalk Server deployment, here are some things to keep in mind about some of the transport services.
HTTP and HTTPS
- Proxy servers and firewalls. If you do not properly configure TCP ports or if you use nonstandard ports, BizTalk Server might have problems connecting to the HTTP server. In both cases, BizTalk Server will not specify that the improperly configured TCP ports or the nonstandard ports are the issue. However, an "unable to connect" error will appear in the Event Log.
- User name and password changes. HTTPS can be configured to require a user to log on. However, if the user name and password change, BizTalk Server might be unable to access the Active Server Pages (ASP). In this case, the failure shows up as a random HTTP error.
For more information about configuring user names and passwords with HTTPS, see "Advanced Configuration of Channel Properties" later in this paper.
- Secure Sockets Layer port. Determine if the server is using the standard Secure Sockets Layer (SSL) port. If you do not use the standard SSL port, port 443, you must know what port should be used and modify the HTTP URL accordingly.
- Client certificates. If you decide to implement client certificates, ensure that you determine if the issuer of the client certificate is a trusted Certificate Authority (CA). You might encounter situations where an HTTP client receives a certificate from a valid issuing Certificate Authority, but the HTTP server might not have knowledge of the Certificate Authority. In this situation, the HTTP server might not accept the client certificate when the client attempts a connection with the HTTP server. If you or your trading partners require client certificate authentication over HTTP, you must agree upon the Certificate Authority. For example, if you send a client certificate to a trading partner, you must also send them a link to where they can download the Certificate Authority's certificate.
Likewise, all your trading partners must inform you who their Certificate Authority is. Additionally, they must provide you with a link to their Certificate Authority's certificate.
Because transactional receives are limited to local computers and BizTalk Server does not forward messages, you can configure the Message Queuing server to forward messages. For more information about Message Queuing, go to the MSDN Online Library Web site (msdn.microsoft.com/library/default.asp) and search for "Message Queuing."
Note Transactional message queues are recommended, but not required. However, it is recommended that you use transactional message queues to ensure that no data is lost when documents are submitted from a message queue to BizTalk Server.
A common issue that you might encounter when using SMTP as a transport service is the recognition of the e-mail address to which the application is sending an interchange or document. For example, the SMTP address might not be known or the server that houses the address might not be known. In these situations, verify that the e-mail address is correct.
When BizTalk Server sends an interchange or document to a trading partner or internal application using SMTP as a transport service, it does not send the mail directly to the Internet or intranet. Instead, BizTalk Server uses an SMTP server to forward the mail message to its final destination. If the SMTP server is offline, the interchange or document will not be delivered. Administrators must check the SMTP server to verify that it is running and routing e-mail correctly.
Some SMTP servers require a From address before they forward an e-mail message. In this situation, the messaging port must be configured with the correct return e-mail alias to accommodate the return SMTP address.
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 2000 and when you might need to configure and/or adjust those settings.
Tracking Settings for a Server Group
When BizTalk Server 2000 is installed, or when you add a new server group, the following tracking options for a server group are enabled by default:
- Enable document tracking
- Log incoming interchange
- Log outgoing interchange
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:
- Store complete copies of incoming and outgoing document instances.
- Track specific fields.
- Track custom fields.
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 in size. If the Tracking database gets too large and if you do not regularly maintain it, the performance of BizTalk Server 2000 will be negatively impacted.
Tracking XLANG Schedule Action Events
Messages processed by an XLANG schedule can be exchanged between BizTalk Messaging Services and BizTalk Orchestration Services. The ability to track the action events related to these messages is not automatically enabled. If tracking XLANG schedule events was not configured as part of your BizTalk Server deployment, you can enable the sample application, WorkFlowAuditClient.exe, to track action events related to messages processed by XLANG schedules. You must complete the following three steps to enable this feature:
- Register the sample dynamic-link library (DLL) file, WorkFlowAudit.dll.
You can find this sample file in the \Program Files\Microsoft BizTalk Server\SDK\XLANG Samples\WorkFlowAudit\bin folder.
- Run the WorkFlowAuditClient.exe application to activate WorkFlowAudit.dll.
You can find this sample application in the \Program Files\Microsoft BizTalk Server\SDK\XLANG Samples\WorkFlowAuditClient folder.
For additional information, you can view the documentation (Readme.txt) found in the \Program Files\Microsoft BizTalk Server\SDK\XLANG Samples\WorkFlowAudit\Docs folder.
- Click the Start button in the WorkFlowAuditClient application to initiate the logging of action events related to an XLANG schedule in the Tracking database.
If you need to change the tracking settings configured with your deployment of BizTalk Server, this section discusses some of the implications involved:
- Tracking settings. Administrative issues include determining when you need to track metadata for interchanges and documents, whole copies of documents, specific fields, and custom fields.
- Balancing tracking settings. Administrative issues include adjusting the settings in BizTalk Server Administration, BizTalk Messaging Manager, or the BizTalk Messaging Configuration object model.
- When to turn off tracking settings. Administrative issues include determining if and when you need to turn off tracking settings.
- Tracking action events related to messages processed by XLANG schedules. Administrative issues include starting the application that enables the Tracking database to store action events related to messages processed by XLANG schedules.
- Tracking database schema overview. Administrative issues include accessing the Tracking database if you need to present data stored in the Tracking database in a different format—for example, when using a reporting tool such as Crystal Reports.
Types of Tracking Settings
If your business needs require that you keep a copy of interchanges in their original format for nonrepudiation and commerce law concerns, make sure that the tracking settings for each server group are enabled. If you want to create an audit trail for internal purposes, or if you want easy access to data on a per-document basis, configure tracking settings in channels and/or document definitions using the BizTalk Messaging Configuration object model or BizTalk Messaging Manager.
Note If you use a preprocessor, be sure to provide a mechanism to preserve the interchange document before it is preprocessed. Interchanges and documents are not stored in the Tracking database until they are submitted to BizTalk Server for processing. Preprocessing occurs before an interchange or document is submitted to BizTalk Server. Therefore the interchange or document is not stored in the Tracking database before it is preprocessed.
Balancing Tracking Settings
You can configure tracking settings for a server group and in channels and/or document definitions. However, enabling all these tracking settings will cause your Tracking database to grow quickly in size. In addition to affecting the performance of BizTalk Server, you will store redundant data.
When to Turn Off Tracking Settings
There are two common situations in which you might need to turn off tracking settings for a server group and/or in a channel and/or document definition. They are:
- You plan to receive interchanges or documents that are larger than the equivalent of 20 MB of Unicode XML.
- You have absolutely no need to track interchanges and documents processed by BizTalk Server.
If you plan to receive interchanges or documents in XML Unicode format that are larger than 20 MB, it is advisable to turn off tracking settings for the server group that will receive the interchange. If you plan to receive ANSI flat-file interchanges that are larger than 7 to 10 MB in size, it is advisable to turn off tracking settings for the server group that will receive the interchange.
Similarly, if you plan to receive document instances in XML Unicode format that are greater than 20 MB, it is advisable to turn off document logging settings in BizTalk Messaging Manager. Or, if you plan to receive ANSI flat files that are larger than 7 to 10 MB, it is advisable to turn off document logging settings in BizTalk Messaging Manager.
If you have absolutely no need to track interchanges and documents that you send and receive, you can turn off all tracking settings. However, you must understand the implications of doing this. First, if tracking settings for a server group are disabled, tracking settings configured in channels and/or document definitions are also disabled. Second, no interchanges or documents are tracked in the Tracking database. This means that once a document leaves the Shared Queue, there is no way to trace it. If you need to trace an interchange or document for troubleshooting purposes, your task will be more difficult. Therefore, you must be very careful about disabling tracking settings for a server group(s).
Tracking Action Events Related to Messages Processed by XLANG Schedules
If you completed the three steps necessary to track action events related to messages processed by XLANG schedules, but no action events appear in the BizTalk Document Tracking user interface, the WorkFlowAuditClient application might have been stopped. Records are logged in the dta_wf_EventData and dta_wf_WorkFlowEvent tables only if the WorkFlowAuditClient application is started. To start the WorkFlowAuditClient application, you must complete the three steps listed in the topic "Tracking XLANG Schedule Action Events" earlier in this paper. If the WorkFlowAuditClient application is stopped, no records are logged in the dta_wf_EventData and dta_wf_WorkFlowEvent tables.
Tracking Database Schema Overview
BizTalk Document Tracking is a stand-alone Web application included with BizTalk Server 2000 for the purpose of creating queries on the Tracking database to view interchange and document records. Most of the data that is stored in the Tracking database is available through BizTalk Document Tracking. However, it might be necessary for you to query the Tracking database directly. For example, you might want to create your own user interface or use Crystal Reports to create a custom report from the Tracking database.
In these situations, you will need to access the Tracking database tables directly. This section provides a general overview of the Tracking database schema. For more detailed information, in BizTalk Server 2000 Help, see "Understanding the Tracking Database Schema."
All servers in a server group share a single Tracking database. If tracking settings are enabled for the server group, the Tracking database stores metadata related to interchange and document activity in BizTalk Server. If tracking settings are enabled in a channel and/or document definition used by the server group, the Tracking database can also store:
- Whole copies of documents.
- Specific fields.
- Custom fields.
The Tracking database consists of three main tables and six secondary tables. The three main tables in the Tracking database are:
- dta_interchange_details. Contains one record for each document submitted to BizTalk Server.
- dta_outdoc_details. Contains one record for each document generated by BizTalk Server.
- dta_indoc_details. Contains one record for each interchange processed by BizTalk Server.
The secondary tables are:
- dta_group_details. Provides extensibility components (parser, serializer, and receipt correlator) for document formats that employ like-kind document groups (for example, X12 or EDIFACT) within an interchange.
- dta_interchange_data. Contains one row for every interchange submitted to or sent by BizTalk Server. This table also stores any response documents returned to the IInterchange::SubmitSync method.
- dta_document_data. Contains one record for every document submitted to or sent by BizTalk Server.
- dta_debugdoc_data. Contains one row for every inDoc or outDoc item that is configured (on the messaging channel object) to record its interim XML format.
- dta_routing_details. Functions as a mirror of messaging ports for the purpose of eliminating a cross-database dependency on the BizTalk Messaging Management database.
- dta_custom_field_names. Contains a row for each distinct capture-field node name and data type pair encountered by BizTalk Server.
- dta_MIME_data. Contains one row for every MIME-encoded interchange submitted to BizTalk Server.
The following illustration shows the overall database schema of the Tracking database. For clarity, only the table names are listed. The lines that connect the tables demonstrate how the tables are connected through foreign key fields and the relationship between the tables.
The following table explains what the different links between the tables represent.
|This link||Represents this relationship|
|None or one-to-many relationship|
|One-to-none or one-to-many relationship|
|One-to-none or one-to-one relationship|
Caution Do not change the code, such as stored procedures or triggers, in the Tracking database. Do not access the Tracking database directly. Do not directly call the stored procedures or add triggers. Making changes to the Tracking database in this way might cause BizTalk Server to function incorrectly, cause the loss of data, or corrupt the Tracking database.
Note If you need to access the Tracking database, for example to use a reporting tool such as Crystal Reports, access a replicated copy of the Tracking database.
There are thirteen additional tables that are a part of the Tracking database. These tables are not included in the illustration because they support the secondary tables or store binary large object data. The related tables are:
- dta_ack_status_values. Stores the receipt status values.
- dta_blobtype_values. Stores the binary large object types.
- dta_data_level_values. Stores the data level values used in BizTalk Server.
- dta_direction_values. Stores the direction of the interchange.
- dta_error_message. Stores the error messages used in BizTalk Document Tracking.
- dta_group_correlation_keys. Stores the group correlation keys.
- dta_interchange_correlation_keys. Stores the interchange correlation keys.
- dta_transport_type_values. Stores the transport type values.
- dta_ui_codepage_charset. Stores the system code pages for character encoded data.
- dta_ui_user_queries. Stores the advanced queries that individual users create and save.
- dta_validity_values. Stores the validity values.
- dta_wf_EventData. Contains one record for each property logged in relation to a monitored COM+ event fired by an XLANG schedule. Sets of multiple rows in this table share a common parent in the dta_wf_WorkFlowEvent table. Records are logged only if WorkFlowAudit.dll is activated. For more information about activating WorkFlowAudit.dll, see "Tracking XLANG Schedule Action Events" earlier in this paper.
- dta_wf_WorkFlowEvent. Contains one record for each monitored COM+ event fired by an XLANG schedule. Records are logged only if WorkFlowAudit.dll is activated. For more information about activating WorkFlowAudit.dll, see "Tracking XLANG Schedule Action Events" earlier in this paper.
After the initial installation of BizTalk Server, you might need to change the following security settings:
- Logon properties and local policies
- Service accounts
- Roles in the BizTalk Server Interchange Application
Logon Properties and Local Policies
Logon properties control a user's ability to access specific computers or data, such as a page on a Web site. If users provide the correct user name and password, they gain access to resources. If they do not provide the correct user name and password, they are denied access.
Local policies are based on the computer a user is logged on to and provide the second layer of security. The local policies on a computer control policies such as user rights assignment, audit policy, and passwords.
For more information about settings for logon properties and local policies, in BizTalk Server 2000 Help, see "BizTalk Server 2000 Setup and Configuration."
It is recommended that BizTalk Server 2000 be run under service accounts rather than interactive user accounts. With interactive user accounts, a user must be logged on for the application to run. For example, 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. First, if the user logs off, the application stops running. Second, if a malicious hacker obtains the user's user name and password, the hacker could do a lot of damage. Third, if an application is running on a computer while an administrator is logged on, the application runs under the administrator's identity and could make calls on behalf of the client using the administrator's rights. To prevent this, it is recommended that you create a service account and use the service account to run BizTalk Server.
For more information about settings for service accounts, in BizTalk Server 2000 Help, see "Create a service account."
Control of a User's Ability to Submit Documents
Controlling a user's ability 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:
- Authentication level
- Impersonation level
- Access permissions
- Launch permissions
- Configuration permissions
If your deployment of BizTalk Server includes using 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 created a service account, log on using the service account you created.
- Specify that you want the certificate associated with the computer and not with a specific user when you issue the certificate.
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 user's password changes and that user is associated with a certificate, you must update the following two applications:
- BizTalk Server Interchange Application
- BizTalk Messaging Service
For more information about certificates and BizTalk Server, in BizTalk Server 2000 Help, see "Certificates Overview." Or go to the MSDN Online Library Web site (msdn.microsoft.com) and search for "Certificate services and components."
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:
- HTTP and HTTPS
- Messaging Queuing
To associate a user name and password with a channel and messaging port combination, on the Advanced Configuration page of the Channel Wizard, click the Advanced button. 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.
Three tools are available to monitor and test the performance of BizTalk Messaging Services. They are:
- System Monitor. A part of the Performance tool provided with Microsoft Windows 2000. Use this tool to collect and review real-time data about memory, disk, processor, and so on.
- Windows 2000 Event Viewer. Included in BizTalk Server Administration. Use this tool to view BizTalk Server and XLANG Scheduler errors.
- XLANG Event Monitor. A tool provided with BizTalk Server 2000 that allows you to monitor XLANG schedule events and the progress of XLANG schedules.
This section describes each of these tools and provides an overview of how to use them to monitor your deployment of BizTalk Server 2000.
You can use System Monitor, a part of the Performance tool included with Windows 2000, to graphically display counter readings that you specify as they change over time. To access System Monitor, perform the following step:
- On the Start menu, point to Settings, click Control Panel, double-click Administrative Tools, and then double-click Performance.
System Monitor is an item in the Performance tool console. What you monitor and how depends on your specific deployment of BizTalk Server 2000. However, you want to choose counters that monitor objects relevant to your installation and that indicate how well a specific component is working and/or is affected. For example, you might choose the Disk read/writes/sec counter to monitor the Physical Disk object. The information that you collect regarding the Disk read/writes/sec counter gives you insight about how SQL Server and the Message Queuing and File transport services are performing.
For more information about specific counters to use to monitor BizTalk Messaging Services, in BizTalk Server 2000 Help, see "Evaluating the Performance of a Configuration."
Windows 2000 Event Viewer
Event Viewer is the second component of the monitoring plan. Use Event Viewer to assist you in troubleshooting server and document processing problems. You can find Event Viewer in BizTalk Server Administration.
You can configure Event Viewer to display all information about security, application, and system problems. Or you can configure Event Viewer to display only BizTalk Server application and XLANG Scheduler errors.
XLANG Event Monitor
When the XLANG Scheduler Engine executes XLANG schedules, it generates many types of events, showing the progress of the schedule instances. BizTalk Server 2000 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.
Three major tools are available to aid you in troubleshooting BizTalk Server 2000: Event Viewer, the Suspended queue, and XLANG Event Monitor.
Troubleshooting Using Windows 2000 Event Viewer
You can configure error handling in BizTalk Server 2000 at the server level through Event Viewer. Event Viewer creates a log that contains information about hardware, software, and system problems. From BizTalk Server Administration, you can customize the Event Viewer to show application and XLANG Scheduler errors that are specific to BizTalk Server 2000, which makes troubleshooting for BizTalk Server efficient.
Troubleshooting Using the Suspended Queue
The following options are available from the Suspended queue to aid you in the troubleshooting process:
- View Error Description. Enables system administrators to view error descriptions that indicate why the document was sent to the Suspended queue.
- View Interchange. Enables system administrators to view the contents of an interchange that has failed processing for a variety of reasons, including parsing errors or failed transmissions.
- View Document. Enables system administrators to view the contents of a document that has failed processing for a variety of reasons, including serialization errors or the inability to find a channel.
Once you have determined the reason BizTalk Server could not process the interchange or document, the following options are available in the Suspended queue to help you resolve the situation:
- Delete. Enables system administrators to completely remove an entry from the Suspended queue. This action is not recoverable. After a document has been deleted from the Suspended queue, you cannot retrieve it.
- Resubmit. Enables system administrators to resubmit most interchanges and documents to BizTalk Server for processing. You cannot resubmit or retransmit interchanges or documents that failed parsing. You must delete those interchanges and documents and submit them to BizTalk Server again from the original organization or application. Resubmit can also be used to retransmit documents in the Suspended queue. When an interchange or document is resubmitted, it is processed from the point of failure. When a document is retransmitted, it is processed as though it was submitted to BizTalk Server for the first time.
Troubleshooting Using XLANG Event Monitor
You can use XLANG Event Monitor to aid in troubleshooting BizTalk Server. XLANG Event Monitor can help you identify the following states of XLANG schedules:
- Successfully completed
- Completed with errors
You can also use XLANG Event Monitor to examine events that are published for an instance. Combine the event information with the XLANG schedule state information and the Event Viewer error messages to get a clearer picture of the issue you are troubleshooting.
Understanding the eight major areas of administration related to BizTalk Server and understanding the concepts behind how BizTalk Messaging Services and BizTalk Orchestration Services work can help system administrators manage and configure BizTalk Server to boost performance for their particular installations. Understanding these concepts also helps the system administrator troubleshoot more effectively.
"Orchestrating Business Processes with Microsoft BizTalk Server 2000."
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This Article is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
Copyright © 2001 Microsoft Corporation. All rights reserved.
Microsoft, BizTalk, and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.