Skip to main content

Potential Scenarios

Scenario 1: A BizTalk Server environment has been running perfectly fine for the last couple years and it may have processed tons of messages. Suddenly one day the BizTalk server refuses to start and in event log you will notice an error message: "Arithmetic overflow error converting expression to data type int." The problem occurs because BizTalk Server uses INT data type for some of its internal tables and INT data type has the upper limit of 2.147.483.647. Microsoft Customer Service and Support (CSS) has created a hotfix for this issue—KB article 972196: FIX: A BizTalk host instance stops and an Event ID 5410 is logged in the Application log in BizTalk Server 2006. With this hotfix, the data type has been changed from INT to BIGINT, and it will take a long while for a BIGINT to overflow.

Scenario 2: In BizTalk Administration, you query yesterday’s activity. For newer messages, the data is displayed. For example, you query for data from yesterday at 9 P.M., and data is returned. However, if you query for data from yesterday at 9 A.M., there is no data.

If you query Transaction Set Details, for some EDI messages, you might get an error: Invalid attempt to read when no data is present. For more information, see http://social.msdn.microsoft.com/Forums/en-US/biztalkediandas2/thread/fd0897dd-0e6b-471a-ba41-729d1dd08d13.

You’ve configured the DTA Purge and Archive SQL Agent job to maintain the BizTalkDTADb database. There are some key parameters in the job that affect this scenario:

  • nLiveHours (default of 0 hours)
  • nLiveDays (default of 1 day)
  • nHardDeleteDays (default value of 30 days)

nLiveDays is the number of days you want to preserve completed data. nHardDelete is the number of days to wait before deleting incomplete data. So with these default values, you would have the following in the BizTalkDTADb database:

  • No data older than 30 days
  • Only incomplete instances older than 1 day
  • Completed instances are deleted after 1 day

To address the query in BizTalk Administration, set nLiveDays to more than 1 day.

For more information, see How to Configure the DTA Purge and Archive Job.

Scenario 3: You upgraded a server running BizTalk Server 2006 to BizTalk Server 2006 R2 or BizTalk Server 2009. You send large messages and are concerned about the Large Message Threshold and Large Message Fragment Size values.

For BizTalk Server 2004, the Large Message Threshold default value is 100 KB (102400), and for BizTalk Server 2006 the default value is around 1 MB (1000000). When BizTalk Server 2004 is upgraded to BizTalk Server 2006, the Large Message Threshold is not changed to the new default until you click the Restore Defaults button in the BizTalk Administration group properties. If the message part exceeds the Large Message Threshold, the message part is split into fragments of the Large Message Fragment Size, which has a default value of 100 KB (102400). The Large Message Fragment Size can be configured up to around 1 MB (1000000). The Large Message Threshold and Large Message Fragment Size values are not synchronous.

For BizTalk Server 2006 R2 and BizTalk Server 2009, a change was made to Large Message Fragment Size. It is now synchronized with the Large Message Threshold value by the BizTalk run time. Therefore, if the Large Message Threshold is 2 MB (2097152), the Large Message Fragment Size will also be 2 MB (2097152). If the message part exceeds the Large Message Threshold, the message part is split into fragments of the Large Message Threshold size. The Large Message Threshold default value is around 1 MB (1000000). The Large Message Fragment Size value in BizTalk Administration can be ignored.

Therefore, with the default Threshold and Fragment Size values:

  • BizTalk Server 2004 and BizTalk Server 2006: A 6 MB message part would be fragmented into 60 fragments and written to the database under the context of a single distributed transaction.
  • BizTalk 2006 Server R2 and BizTalk Server 2009: A 6 MB message part would be fragmented into 6 fragments and written to the database under the context of a single distributed transaction.

In BizTalk Server 2004 and BizTalk Server 2006, modifying the Large Message Threshold can have a significant impact on performance. In BizTalk Server 2006 R2 and BizTalk Server 2009, the default values are probably sufficient. However, when using considerably larger message fragments, modifying the Large Message Threshold can improve performance.

For more information, see:

Scenario 4: BizTalk Server 2006 R2 comes with WCF adapters and can work with WCF extensions (custom bindings and custom behaviors). It does require users to define these WCF extensions in machine.config.  However, machine.config is ideally used to store configuration information that is required across all applications that are running on a particular computer. On the other hand, WCF custom behavior extensions may be required only by BizTalk Server and not by all the applications running on the computer. So, although storing the custom behavior extensions in machine.config serves the purpose, it is not the optimal location.  

BizTalk Server 2006 R2 SP1 can fulfill this requirement by providing an alternative location for defining WCF extensions. WCF extensions can now be imported in the Handler properties for WCF-Custom and WCF-CustomIsolated adapters. In the new design, the code now looks in two places to form a cumulative list of binding extensions: machine.config and the Handler properties.  The list of bindings displayed in the Bindings tab in the WCF-Custom and WCF-CustomIsolated configuration user interface is a combination of bindings in machine.config and the imported configuration of the Handler; the user can then choose a binding from this combined list. Another benefit of using Handler properties is that once the WCF extensions are imported, they can be used by any computer in the BizTalk group.

For details, see New Features in BizTalk Server 2006 R2 Service Pack 1.

Scenario 5: BizTalk Server 2006 R2 AS2 processing allows the outgoing AS2/MDN messages to be signed. The signing certificate is defined as part of the BizTalk Group properties. This dictates that all outgoing AS2/MDN messages can only be signed with the same certificate for the entire BizTalk group. However, there could be scenarios where the party that receives the messages wants the messages to be signed with a private certificate that the party provides, or the party might expect a different certificate to be used for signing outgoing messages.

Fortunately, this scenario of signing outgoing messages using different certificates is enabled if you have BizTalk Server 2006 R2 Service Pack1 installed. If a certificate is specified as part of the AS2 properties for a party, that certificate is used for signing outgoing AS2/MDN messages. If no certificate is defined for the party, the default certificate specified as part of the BizTalk Group properties is used.

For details on how to use this new functionality, see New Features in BizTalk Server 2006 R2 Service Pack 1.