Wednesday, March 19, 2008

FTP Gauranteed Delivery

The BizTalk Server FTP adapter offers a 'guaranteed delivery' feature, the details of which are not documented by Microsoft. The mechanism is very straightforward, however, and involves the use of a temporary folder. Files are staged by BizTalk in this folder before being moved to the destination folder. BizTalk supports this for both Send and Receive handlers. To use this feature, simply set the "Temporary Folder" property of the FTP adapter. For Send ports, this will be the name of an FTP folder on the server, rather than a local folder.
The main advantage of using this feature is that retries can be performed in the event of a transport failure, with multiple copies of the same file being sent to the temporary folder. However, at most, only one copy of the file will ever be moved to the destination folder or receive location. The use of staging eliminates the possibility (in theory) of the FTP server (Send port) or BizTalk (Receive port) receiving multiple copies of the same file. Another advantage is that you can ensure that a file is received in entirety, or not at all. FTP allows files to be partially transferred, and supports transfer recovery where a partially completed transfer can be re-started from the point of failure (FTP regets and reputs). While this is a great feature in some scenarios, it is potentially a killer in BizTalk, because it can lead to BizTalk believing it has received or sent a file, when in fact the file has only been partially transferred. The use of a temporary staging folder allows a file to be fully transported before being transferred to its destination folder or receive location. This is particularly useful when transporting large files or transporting files over un-reliable networks.
You do need to be very careful when using the feature on a receive port. You configure the temporary folder at the host level via the BTS Administrative console. If you have multiple servers in your BizTalk group, and run multiple instances of you host across those boxes, each instance will point to the same temporary folder. In this case, things go badly wrong. Unlike the File adapter, instances of the native FTP adapter do not lock or rename files in order to prevent other instances from processing the same input. Hence, bad things happen. It is possible to have multiple instances of the same message delivered to the MessageBox, even though you are using the 'guaranteed deliver' feature. In addition, when one instance of the adapter moves a file from the temporary folder, a second instance then fails when it tries to do the same thing, and cannot find the file. Always isolate your FTP adapter in a separate host, and always run just one instance for a receive handler. One idea might be to assign your FTP-receiving host to multiple servers, but only enable one of the host instances. You could then use WMI to automate a fail-over to another instance in the event of a failure.

Content owner:
http://geekswithblogs.net/cyoung/archive/2004/08/10/9524.aspx

Wednesday, March 12, 2008

Deadlock due to Body Tracking - BizTalk Server 2006

You receive a similar alert as this one
ISSUE:
Event Type: Error
Event Source: BizTalk Server 2006
Event Category: BizTalk Server 2006
Event ID: 6912Date: 19/12/2007
Time: 08:09:11
User: N/A
Computer: SOMESERVER
Description:The following stored procedure call failed: " { call [dbo].[bts_UpdateMsgbox_HostInstanceName]( ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}". SQL Server returned error string: "Transaction (Process ID 102) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.;Duplicate key was ignored.".

RESOLUTION:

Disable body tracking!!

Problem was due to problems in BizTalk 2006 when you have multiple tracking on the same message. E.g. Before and After without changing the message (Pass-through) and in multiple place like when sending to many send ports/send port groups and tracking in all of them or tracking pipelines and schemas as well. Only tracking the same message in one place solved the problem. This was not fixed due to too complex and not happening too often