This document provides information about Service Pack 2 (SP2) for Microsoft BizTalk Server 2000. SP2 applies to all editions of BizTalk Server 2000. BizTalk Server Service Packs are cumulative. SP2 includes all fixes from previously released Service Packs, and can be applied to an original installation of BizTalk Server or to one where SP1a was previously applied. To install SP1a, go to the BizTalk Server 2000 Service Pack 1a download page.
For more information about the specific fixes for SP2, see the following Microsoft Knowledge Base article:
INFO: List of Bugs Fixed in BizTalk Server 2000 SP2 (Q318625)
Important
Note
Service Pack installation instructions
All computers in a BizTalk Server group must run the same version of BizTalk Server
Additional installation instructions for maintaining the Tracking database
Additional installation instructions for maintaining the Orchestration Persistence database
This section provides an overview of the updates and changes that are included in this Microsoft BizTalk Server 2000 Service Pack. Because BizTalk Server Service Packs are cumulative, SP2 includes all fixes from previously released Service Packs.
Changes and updates introduced in SP2 include, but are not limited to, the following:
Changes and updates carried forward from previous Service Packs include, but are not limited to, the following:
The following topics are covered in this section:
BizTalk Server 2000 SP2 can be installed from the Microsoft Web site. BizTalk Server 2000 SP2 is not available on CD.
Caution
The following topics are covered in this section:
To use SP2 in BizTalk Server group scenarios, all computers in a BizTalk Server group must run the same version of BizTalk Server. After you apply SP2 on all computers, you will need to apply CleanQueuesPatch.sql to the Shared Queue database. For more information, see All computers in a BizTalk Server group must run the same version of BizTalk Server.
Or
If you have Microsoft SQL Server 2000 installed, on the Query menu, click Change Database.
After you apply SP2 on all computers, you will need to apply ControlNumbers.sql to the BizTalk Messaging Management database. ControlNumbers.sql fixes the stored procedure for retrieving electronic data interchange (EDI) control numbers associated with a port. If you install SP2 without running this file, outbound EDI will not work. However, if you installed and ran this file with SP1a, the following procedure is not necessary.
Or
If you have Microsoft SQL Server 2000 installed, on the Query menu, click Change Database and continue to step 4.
To verify that BizTalk Server 2000 SP2 has been installed, view the file properties for any of the DLLs (except setupex.dll) in the BizTalk Server 2000 installation directory.
There are two uninstall packages available with this Service Pack.
Caution
To uninstall SP2 in BizTalk Server group scenarios, you must complete the following steps:
Note
Microsoft Windows 2000 Service Pack 2 (SP2) officially supports BizTalk Server 2000 SP2. You can run BizTalk Server 2000 SP2 on Microsoft Windows 2000 SP1, but it is highly recommended to upgrade to Microsoft Windows SP2 as it resolves former BizTalk Server 2000 operational issues.
The following software is recommended, but not required, for running BizTalk Server 2000 SP2:
This topic lists the folders with files that have changed:
Notes
To use SP2 in BizTalk Server group scenarios, you must complete the following steps:
Important
Included in SP2 are utilities that maintain the Tracking database. When you install SP2, the appropriate files are copied to the \Program Files\Microsoft BizTalk Server\Setup folder. However, additional setup is required to activate the utilities. If you want to use these utilities, you must follow the instructions in this section.
If you do not track interchanges and documents in your BizTalk Server installation, or if you do not want to use the SQL scripts included in this BizTalk Server Service Pack to archive and purge your Tracking database, you can skip this section.
To install the utilities to maintain the Tracking database, you must complete the following steps:
Important
Notes
Perform the following steps on the server that you want to host the archive Tracking database.
Or
If you have Microsoft SQL Server 2000 installed, on the Query menu, click Change Database.
Note
Perform the following steps on the SQL Server that hosts the Tracking database.
Or
If you have SQL Server 2000 installed, on the Query menu, click Change Database.
Note
The following example is a sample SQL statement for configuring a linked server. In this example, a remote database server called "Seattle2" is a linked server on the local SQL Server:
EXEC sp_addlinkedserver N'Seattle2', N'SQL Server'
The following example is a sample SQL statement to create a mapping between the system administrator (sa) login on the local and remote linked SQL Servers. This sample assumes that the remote sa login password is "abc123."
EXEC sp_addlinkedsrvlogin '<Name of remote SQL Server>', 'FALSE', 'sa', 'sa', 'abc123'
Important
Note
Perform the following steps on the SQL Server that hosts the Tracking database. This should be the same server that you configured in the previous procedure.
The script creates a stored procedure named dta_purge_old_records. The script creates a SQL Server Agent job named "Archive and Purge BizTalk Tracking database: <Name of your Tracking database>." By default, the SQL Server Agent job is not enabled.
The following are some examples for configuring the input parameters passed to the dta_purge_old_records stored procedure. For more information about the syntax and arguments in this stored procedure, see Tracking database purging and archiving stored procedure usage.
USE InterchangeDTA
EXEC dta_purge_old_records 1, 24, 1,0
USE InterchangeDTA
EXEC dta_purge_old_records 2, 1000, 0, 1, N'<Name of a SQL Server>', N'<Name of the archive Tracking database>'
The changes are saved and the SQL Server Agent job is enabled.
Note
Included in SP2 are utilities that maintain the Orchestration Persistence database. When you install the Service Pack, the appropriate files are copied to the \Program Files\Microsoft BizTalk Server\Setup folder. If you want to use these utilities, you must perform the following procedure.
If you do not want to use the SQL script included in this BizTalk Server Service Pack to purge your Orchestration Persistence database, you can skip this section.
Note
Or
If you have SQL Server 2000 installed, on the Query menu, click Change Database.
Note
This topic describes documentation issues relevant to this Service Pack. It provides information on new functionality introduced by the Service Pack as well as corrections to the documentation in BizTalk Server 2000 Help.
The following topics are covered in this section:
This section contains important updates about BizTalk Administration.
The following topics are covered in this section:
Introduced in SP1
When you install this Service Pack, stored procedures are copied to the \Program Files\Microsoft BizTalk Server\Setup folder. This section describes the usage for the stored procedures to delete records from the Orchestration Persistence database.
Note
The sp_CleanDoneInstances stored procedure deletes all completed or stopped XLANG schedule instances, as shown in the following:
sp_CleanDoneInstances @CompletedBefore='<GMT date and time>'
The following is an example for using this stored procedure:
exec sp_CleanDoneInstances @CompletedBefore='2000-10-25 19:34:49.000'
In this example:
The sp_CleanDoneModuleInstances stored procedure deletes all completed or stopped XLANG schedule instances of a particular type of schedule, as shown in the following:
sp_CleanDoneModuleInstances @ModuleGUID='<globally unique identifier>', @CompletedBefore='<GMT date and time>'
The following is an example for using this stored procedure:
exec sp_CleanDoneModuleInstances @CompletedBefore='2000-10-25 19:34:49.000',
@ModuleGUID='4C5842DA-40E5-40B8-AF03-BC5DD4B7E037'
In this example:
ModuleID is a unique reference to a specific type of XLANG schedule. You can use the @ModuleGUID parameter to filter on the type of XLANG schedule. The @CompletedBefore parameter filters for XLANG schedule instances that ended before a specific time and the @ModuleGUID parameter filters for XLANG schedules that are of a certain type. You can use XLANG Monitor to determine the ModuleID for an XLANG schedule. The ModuleID is one of the properties in the events for ScheduleStart, ScheduleDone, ContextEnter, ContextLeave, TransactionBegin, and TransactionEnd. You can use also the public interface to XLANG schedule instances, IWFWorkflowInstance::ModuleId Property, to obtain the ModuleID.
The sp_CleanInstance stored procedure deletes a completed or stopped XLANG schedule and all child instances of that schedule, as shown in the following:
sp_CleanInstance @InstanceID='{<globally unique identifier>}'
This deletion operation is transactional. In this stored procedure, @InstanceID is the globally unique identifier (GUID) that is the instance identifier of the root XLANG schedule. BizTalk Server 2000 uses this stored procedure. You are not required to call this stored procedure directly. Instead, you should follow the instructions for purging the XLANG database.
Introduced in SP1
After you install SP2, you can publish BizTalk Server 2000 in Microsoft Active Directory to determine the availability of BizTalk Server 2000 in a distributed environment. For example, you might need to know which computers are running BizTalk Server 2000. You can determine this by publishing BizTalk Server 2000 in Active Directory.
For example: At the command prompt, type cd \Program Files\Microsoft BizTalk Server\Setup and press ENTER.
Note
Introduced in SP1
When you remove BizTalk Server 2000 from a computer, its registration is not automatically removed from Active Directory. You need to remove the registration of that computer so that only those computers still running BizTalk Server 2000 are properly identified when you query Active Directory.
For example: At the command prompt, type cd \Program Files\Microsoft BizTalk Server\Setup and press ENTER.
Introduced in SP1
If you install this Service Pack, BizTalk Server 2000 will stop processing an interchange or document and roll back the Shared Queue database under the following circumstances:
The transaction is rolled back even if BizTalk Server 2000 stopped processing after the interchange or document was transmitted. When the Shared Queue database is available again, the label is removed for all documents that are marked as "in process." This means that the documents are processed again instead of being placed in the Suspended queue.
If you use transactional message queues or reliable messaging, the delivery of your interchange or document is guaranteed to be just once. If you use non-transactional transmissions, then BizTalk Server 2000 might send the same document twice under the circumstances described in this topic.
Note
Introduced in SP1
When you specify the location for a message queue, you can use any name format that is valid. The following list provides examples of valid name formats for message queues:
Notes
This section contains important updates about BizTalk Editor.
The following topics are covered in this section:
Introduced in SP1
A new custom date/time data type is available in BizTalk Editor. This date/time data type enables you to send date and time information in the following format: HHMMSSDD. For more information about this time format, see A supported time format for X12.
For more information about how to open a document specification, see "Open Specifications" in BizTalk Server 2000 Help.
A warning message appears.
The new custom date/time data type is applied.
Important
Notes
The X12 parser and serializer read the custom date/time data type from left to right and will not return an error if the date and time sent are less than eight characters. For example, the following date and time data is valid:
Introduced in SP1
In BizTalk Editor, there is a new property available for the Custom Data Type for numbers. It is Custom Maximum Length. This property enables you to use periods, dashes, and so forth in your numbers field.
Specifically, this property allows you to control length validation for the native (non-XML) representation of data for cases where normalization to/from XML (i.e. parsing or serialization) affects the length of the data, and the length of the native data is the critical validation facet (i.e. length of the data as XML is not important because XML is just an interim format, for example, when processing flat file to flat file).
For more information about how to open a document specification, in BizTalk Server 2000 Help, see "Open Specifications."
where x is a number between 0 and 9
A warning message appears.
The new Custom Maximum Length field appears.
Introduced in SP1
In the BizTalk Editor, the supported time format for the X12 syntax (indicated when Standard is set to X12 on the Reference tab for the root node of the schema) is HHMMSSDD, where:
If you want to express time up to the tenths or hundredths of a second, use the custom date/time data type described in Applying Custom Date/Time format in BizTalk Editor.
Using the HHMMSSDD format, data that satisfies the input range restrictions listed previously can be four, six, seven, or eight digits in length. In other words, specifying HHMMSSDD for a time format means that instance data must match HHMM, HHMMSS, HHMMSSD, or HHMMSSDD. Although the HHMMSSD format is unavailable in the list of options for custom date/type data types, you can specify this format by selecting HHMMSSDD and setting the Maximum Length property on the Declaration tab to 7.
If you use the HHMMSSss format or any of its variations, the X12 parser and serializer are unable to parse the data correctly and you will receive a validation error. The error will appear either in the Tools Warning window when you validate the specification or in the Event Log during run time. HHMMSSss is not an approved X12 format for time fields; X12 uses HHMMSSDD only.
All time fields using the HHMMSSDD custom format will be treated as strings because XML does not support decimal seconds or hundredths of seconds.
Introduced in SP1
In BizTalk Server 2000 Help, note the following correction to the text in the tables of the "Set parse properties" section. In the "Standard: Custom Structure Property: Delimited" subsection, in the Parse Tab: Root Node or Record Properties table, the Value column for the Append New Line row should appear as follows:
Select one of the following options:
In the "Standard: Custom Structure Property: Positional" subsection, in the Parse Tab: Root Node Properties or Record Properties table, the Value column for the Append Newline row should appear as follows:
Select one of the following options:
Introduced in SP1a
A restriction to the kinds of instance structure permutation supported by the X12 parser is that there cannot be generational skips in Hierarchy Level (HL) segments.
This is a restriction whereby any HL segment/loop must be exactly one level deeper from the root than its parent HL segment/loop, if it has a parent HL. For example, HL/NM1/HL is not supported. In other words, a given sequence of 'x' nested HLs must span exactly 'x' generations of depth in the tree.
This section contains important updates about BizTalk Mapper.
The following topic is covered in this section:
Introduced in SP1a
In BizTalk Server 2000, when you create a link from an optional field in the source schema to a field in the destination schema, BizTalk Mapper might generate Extensible Stylesheet Language Transformations (XSLT) that will create a blank destination field. This happens if the source field does not appear in the instance document (because it is optional).
This BizTalk Server 2000 Service Pack corrects the problem. With BizTalk Server 2000 SP2, if the linked field is optional in the source schema, BizTalk Server generates an <xsl:if> clause to check for the existence of the source field before it creates the destination field. This ensures that the destination field is not created if the source field is absent in the source instance. When the source instance contains the field, the destination field is created as expected.
This section contains important updates about BizTalk Messaging Services.
The following topics are covered in this section:
Introduced in SP1
The default value for the Simple Mail Transfer Protocol (SMTP) Subject is <document_name>-<Tracking_ID>. This enables you to route documents based on the document definition name.
To change the default value for the SMTP Subject, perform the following steps:
The change is saved.
Note
Introduced in SP1
To configure the proxy user name and password for the HTTP and Hypertext Transfer Protocol Secure (HTTPS) transport services, perform the following steps:
The Channel Properties Wizard opens.
Introduced in SP1
Two keys, called src_filename and src_filepath, have been added to the run-time dictionary to provide the file name when a document is delivered. The server populates these keys when a File receive function or a Submit call with a file name has occurred. The file name is available throughout the life of a document. If an application integration component (AIC) requires these properties, they can be extracted from the dictionary. These keys will also be exposed as wildcard parameters, %src_filename% and %src_filepath%, similarly to %document_name% and %tracking_id%.
Notes
For example:
If the file name submitted is c:\temp\myfile.txt
, the wildcard parameters will be set up as follows:
%src_filepath% = "c:\temp" (no trailing backward slash)
%src_filename% = "myfile.txt"
To reconstruct the original file name, the wildcard parameters must appear as follows:
%src_filepath%\%src_filename%
A backward slash must separate the two fields. For more information, see the following note.
For example, if you have a source file located at C:\SourceFile, using the wildcards %src_filepath% = "c:"
and %src_filename%
= "SourceFile"
will move this file to c:\WINNT\System32\SourceFile or c:\SourceFile, depending on the current directory in the process.
This section contains important updates about deployment issues in BizTalk Server 2000.
The following topic is covered in this section:
Introduced in SP1
Several modifications have been made to the BizTalk Server Configuration Assistant tool since the release of BizTalk Server 2000. Additional information on these modifications can be found in the following Microsoft Knowledge Base article:
Q297445 INFO: List of Bugs Fixed in BizTalk Server 2000 Service Pack 1 (Q297445)
BizTalk Server Configuration Assistant is a tool that enables you to:
BizTalk Server Configuration Assistant relies on the BizTalk Messaging Configuration object model. For BizTalk Server Configuration Assistant to function correctly, the following files must be in the same directory as BizTalk Server Configuration Assistant:
Note
if (strDocsAppName <> strMapsAppName) then
On Error Resume Next
CreateApplicationFolder strLocalServer, strMapsAppName
Err.Clear
On Error GoTo errorExit
end if
For more information about BizTalk Server Configuration Assistant, see the readme file located in the \Program Files\Microsoft BizTalk Server\SDK\Messaging Samples\BTConfigAssistant folder.
This section contains important updates about document tracking.
The following topic is covered in this section:
Introduced in SP1
The following section describes the syntax and arguments in the Tracking database SQL scripts.
Syntax
The following code is the syntax used in the dta_purge_old_records stored procedure:
[ @nPurgeType = ] nPurgeType,
[ @nPurgeValue = ] nPurgeValue,
[ @nCompletedInterchangesOnly = ] nCompletedInterchangesOnly,
[ @nArchiveFlag = ] nArchiveFlag
[ , [ @nvcArchiveDBServer = ] N'nvcArchiveDBServer' ]
[ , [ @nvcArchiveDBName = ] N'nvcArchiveDBName' ]
Arguments
This topic describes the arguments used in the syntax.
[ @nPurgeType = ] nPurgeType
The [ @nPurgeType = ] nPurgeType argument is an integer value that indicates whether to select the interchanges for deleting by timestamp or by row count. If nPurgeType is 1, then records are deleted by timestamp. If nPurgeType is 2, then records are deleted by row count.
[ @nPurgeValue = ] nPurgeValue
The [ @nPurgeValue = ] nPurgeValue argument is an integer value. The meaning of this argument depends on the value of nPurgeType.
If the value of nPurgeType is 1, then nPurgeValue represents the number of hours to subtract from CURRENT_TIMESTAMP to determine how to archive interchanges older than a certain date and time. For example, if you specify 96 as nPurgeValue, then you archive interchanges that are older than 96 hours (four days).
If the value of nPurgeType is 2, then nPurgeValue represents the number of interchanges to be left in the database after records are archived and deleted from the database. For example, specifying 25,000 results in archiving all interchanges below the top 25,000 rows.
[ @nCompletedInterchangesOnly = ] nCompletedInterchangesOnly
The [ @nCompletedInterchangesOnly = ] nCompletedInterchangesOnly argument is an integer value that configures whether or not interchanges that require additional processing are deleted from the database. For example, some interchanges or documents might be waiting for an acknowledgement or might have to be resubmitted.
If you configure nCompletedInterchangesOnly to equal 0, then the purge job deletes interchanges and documents whether or not they still require additional processing. Setting this argument to 0 results in faster completion of the purge job because there is less filtering.
If you configure nCompletedInterchangesOnly to equal 1, then the purge job does not delete interchanges and documents that require additional processing. Setting this argument to 1 results in slower completion of the purge job because there is more filtering.
[ @nArchiveFlag = ] nArchiveFlag
The [ @nArchiveFlag = ] nArchiveFlag argument is an integer value that indicates whether the stored procedure archives interchange and document records before deleting them. If the value of nArchiveFlag is 0, then the stored procedure does not archive any interchange or document records. If the value of nArchiveFlag is 1, then the stored procedure archives the interchange and document records before they are deleted from the database.
[ @nvcArchiveDBServer = ] nvcArchiveDBServer
The [ @nvcArchiveDBServer = ] nvcArchiveDBServer argument is an optional argument. Configure this argument if you configure nArchiveFlag to equal 1. This argument is an nvarchar(128) data type and it specifies the name of the database server where the stored procedure archives the interchange and document records.
[ @nvcArchiveDBName = ] nvcArchiveDBName
The [ @nvcArchiveDBName = ] nvcArchiveDBName argument is an optional argument. Configure this argument if you configure nArchiveFlag to equal 1. This argument is an nvarchar(128) data type and it specifies the name of the database where the stored procedure archives the interchange and document records.
This section contains important information about dependent software and technologies.
The following topics are covered in this section:
Introduced in SP1
The following table lists keyboard shortcuts in BizTalk Server 2000.
User interface | Press | To |
BizTalk Editor | SHIFT++ (With the NUMLOCK key enabled, press the + key on the number pad while pressing the SHIFT key.) | Add a new custom annotation when the focus is on the namespace data sheet in the right pane. |
BizTalk Editor | TAB key | Access the buttons in the upper right corner of the New Document Specification dialog box. |
BizTalk Editor | SHIFT+F10 | Open the context menu for highlighted items. |
BizTalk Editor | CTRL+SHIFT+R | Insert a new record into a document specification. |
BizTalk Editor | CTRL+SHIFT+F | Insert a new field into a document specification. |
BizTalk Mapper | Arrow keys | Move the focus in the Grid Preview window. |
BizTalk Mapper | SHIFT+F10 | Open the context menu for highlighted items. |
BizTalk Mapper | TAB key | Access the buttons in the upper right corner of the Select Source Specification Type dialog box. |
The following table lists the operations for which there are no keyboard shortcuts. To perform the operations, you must use MouseKeys.
User interface | Operation |
BizTalk Editor | Move, drag-and-drop, copy nodes |
BizTalk Mapper | Move, select functoids, drag-and-drop functoids, linking |
Introduced in SP1
You must download and run an updated XSLT style sheet to convert an XDR schema into an XSD schema.
Note
Introduced in SP1a
The UNOX syntax identifier in EDIFACT is defined as a code extension technique to cover other non-single-byte characters. However, some countries and regions had already defined their own standards before the UNOX syntax was created. For example, in Korea, the standard called KEDIFACT marks data by KECA instead of UNO*. The EDIFACT data received by BizTalk Server 2000 has a modified header such that it is UNOA, however, the double-byte character set (DBCS) characters still remain. UNOA consists of uppercase ASCII characters only, and does not convert the DBCS characters correctly.
To resolve this issue, the EDIFACT parser and serializer have been updated. If the header is in UNOA characters, then the EDIFACT parser and serializer accept a registry key to define a codepage, other than the default codepage, that converts the data. A registry value, called EDIFACTUNOACodepage, has been added to the set of values that BizTalk Server 2000 defines. This registry value has a default of 0, and, if set to 0, uses BizTalk Server 2000 behavior. If this registry value is set to some other value, that value is the codepage value used to convert the resultant KEDIFACT data.
The codepage change is global. All EDIFACT data passing through that BizTalk Server 2000 processes data according to the EDIFACTUNOACodepage codepage.
Introduced in SP1
If you have installed Microsoft Data Access Components (MDAC) 2.5 and have configured an SMTP messaging port to have Multipurpose Internet Mail Extensions (MIME) encoding, when DBCS data is sent through that port, the data will return corrupt. (MDAC 2.5 comes with all Windows 2000 Service Pack versions.)
To avoid this issue, you can install MDAC 2.6 in one of the following ways:
At this time, no fix is available that works on both MDAC 2.5 and MDAC 2.6.
Introduced in SP1
It is highly recommended that you use the Microsoft XML Parser (MSXML) version 3.0 with Service Pack 2 (SP2) with your installation of BizTalk Server 2000. In addition, it is recommended that you use MSXML in Side-by-Side Mode. MSXML 3.0 SP2 installs in Replace Mode by default.
If you configure MSXML to operate in Replace Mode by installing XMLINST.exe, you might experience problems with BizTalk Server. For example, you might not be able to open BizTalk Editor or BizTalk Mapper. If you configure MSXML to operate in Replace Mode by using XMLINST.EXE or by changing registry keys, your installation of BizTalk Server will not be supported.
The following procedure describes how you can configure MSXML using XMLINST.EXE to operate in Side-by-Side Mode, if you currently have it configured to operate in Replace Mode.
For more information about using XMLINST.exe, see the following article in the Microsoft Knowledge Base, "PRB: Application Errors Occur After You Run Xmlinst.exe on Production Servers" (Q278636).
Important
Introduced in SP1a
This Service Pack provides Visio 2002 compatibility with BizTalk Server 2000. However, if you are using a language other than English in Visio 2002, some characters may not display properly in BizTalk Orchestration Designer. To correct this issue, specify that Microsoft Visio 2002 must always use the system default font.