Basically this article contains a checklist, which can be used as a reminder in case your message based routing scenario does not work, like you expected.
Imagine you have a message based routing solution in its most simple form. Your Receive Location listens to a local folder and your Send Port is subscribed to the Receive Port from the Receive Location. The URI of the Send Port is another local folder.
Although this is a very simple solution, still there is enough that can prevent the messages from flowing from A to B. So people can use this article as a checklist to find out what they forgot or what they did wrong.
To be absolutely sure you have configured the correct folder, copy the path from the address bar in Windows Explorer and paste it at the URI field in the Receive Location.
If the Receive Location is not enabled, it won't poll the configured folder, so you must enable the Receive Location.
The file that you drop on the folder of the Receive Location does not match the file mask from the Receive Location. If you are dropping a .XML file while the Receive Location expects only *.TXT files, your .XML file won't be picked up by the Receive Location.
You think you are dropping a .XML file, and the file mask of the Receive Location expects .XML files, but still the file is not picked up. Perhaps you are tricked by Windows Explorer. Windows Explorer has an option to hide familiar extensions of files. So
if you have a file called order.xml.txt, Windows Explorer hides the .txt extension, perhaps giving you the idea that you are dealing with a .XML file, while in fact you are dealing with a .TXT file. In Windows Explorer turn off the option to hide familiar
extensions, making sure that you will always deal with the full file name.
On a Receive Location a Service Window can be configured. When a Service Window is set, the Receive Location will only process incoming messages during the configured timeframe. So be sure no Service window is active.
Furthermore you can also configure a Start/Stop Date. When a Start Date is configured (and enabled) which lies in the future, no processing will take place until that date. When a Stop Date is configured (and enabled) which lies in the past, no processing
will take place from that date on.
Make sure that the identity which is configured at the Host which runs the Receive Location, has enough permissions (read/write) on the folder of the Receive Location. Failing to do so, results in the Receive Location disabling itself (after some retries).
Files with names longer than 256 characters are ignored by BizTalk, so they will not become picked up by the Receive Location. So make sure your file names are shorter than 256 characters.
If (one or more of) the files at the Receive Location have the System or Read-only attribute, they will be ignored by BizTalk, so make sure that the files do not have the System or Read-only attribute.
If an empty (zero byte) file is picked up by the File Receive adapter, the file is deleted and a warning is written to the application log of the BizTalk server. The File Receive adapter deletes zero byte files by design.
Host Instances take care of the actual processing of your Receive Locations, Send Ports and Orchestrations. So if the Host Instance from the Receive Location is not started, no files will be picked up, although your Receive Location is enabled, so start
the designated Host Instance.
Correct this by copying the name from the Receive Port and paste it in the filter of the Send Port.
Quotes are not needed, so remove them.
If the Send Port is not enlisted, there is no active subscription for the Send Port. Further the Send Port must be started to send any files, coming from the Receive Port to the outgoing folder. So Enlist and Start the Send Port.
Host Instances take care of the actual processing of your Receive Locations, Send Ports and Orchestrations. So if the Host Instance from the Send Port is not started, the file will be picked up by the Receive Location, stay in the MessageBox, but won't be
delivered to the outgoing folder, so start the designated Host Instance.
Make sure that the identity which is configured at the Host which runs the Send Port, has enough permissions (read/write) on the folder of the Send Port. Failing to do so, will result in suspended messages.
If you want to append data to a file, but the file to which is written by the Send Port has the System or Read-only attribute, BizTalk won't be able to write to it, so make sure that the file on the Primary (or Backup) Location do not have the System or
In case anything went wrong while writing to the Primary Transport from the Send Port, BizTalk tries to write the message to the Backup Transport if it is configured. So if a message shows up on on the Backup Transport, apperently something went wrong while
delivering the message to the Primary Transport.
Mikael Sand for supplying a number of possible problems. Some of the problems are derived from
Read suggested related topics: