Last week a customer reported that they are suspecting that FILE adapter has written the same message twice to a file share. They provided me the event log from the time of issue.
I asked them the few questions and got the following responses.
Question: Is there any particular scenario (like large file size) or this issue is happening all the time?
Answer: It happened twice in 2 years or so. No specific behaviour observed around file size.
Question: The file share is a UNC share or NAS share or local path of the server?
Answer: It’s a UNC share.
Question: Can we look into the message flow to confirm it the message is sent twice using the FILE adapter?
Answer: In this case, the message is received at SendPort at 3:00 PM. The SendPort completed at 4:30 PM, after a host restart. These are the port start and end times as seen in the MessageFlow. Also message is pretty small – we don’t expect to see such a long time.
REASON
After going through the event logs and doing some RND I came to the following points.
1. Event log shows lots of network connectivity error.
Unable to communicate with MessageBox BizTalkMsgBoxDb on SQL Instance BTSSERVER1. Error Code: 0xc0c01b45. Possible reasons include:
- The MessageBox is unavailable.
- The network link from this machine to the MessageBox is down.
- The DTC Configuration on either this local machine or the machine hosting this MessageBox is incorrect.
2. When dealing with file data writes across WAN/LAN, sometimes the return transport ACK does not make it through so even though the file did get through, BizTalk File Adapter did not get the ACK and thus goes in for Retry. So here in this case due to the network issue though the file got written completely in first time only but ACK could not come back to the BizTalk File Adapter and hence the File adapter sent the file again.
SOULTION
On the FILE Adpater dialog, General tab.
Enable the option “Use temporary file while writing“.
It defines whether to write the output file to a temporary file first and then rename the file once the write operation has completed. If this option is enabled then the temporary file will be created with the extension BTS-WIP.
Valid values are:
True (-1) The File adapter creates a temporary file when writing to the target folder.
False (0) The File adapter does not create a temporary file when writing to the target folder.
We also have “Rename files while reading” option available in File Receive Adapter. When renaming is enabled, the file receive adapter appends the extension .BTS-WIP to the file.
The receive adapter then reads the messages from the renamed file in the receive location and submits it to the server. After the receive adapter reads the message and successfully submits it, the receive adapter deletes the renamed file from the file system or network share.
If a message has been read but failed processing in the pipeline, the receive adapter places the message in the MessageBox database suspended queue, and deletes the renamed file from the network share.
Note that renaming files has no impact on performance and improves scalability so that one server does not handle all received messages.
Also its strongly advisable to use transactional adapters (ex- MSMQ) for critical data transfer like financial data.
For further information about transations in BizTalk, you can refer my next post.
