Introduction

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.

Scenario

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.

The Receive Location listens to the wrong folder or contains a typo

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.

The Receive Location is not enabled

If the Receive Location is not enabled, it won't poll the configured folder, so you must enable the Receive Location.

Mismatch of the file mask on 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.

Tricked by Windows Explorer

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.

A Service Window or Start/Stop Date prevents the Receive Location to poll for incoming messages

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.

BizTalk is not authorized to access the file location of the Receive Location

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 encountered in the Receive Location

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.

Files have the System or Read-only attribute

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.

Empty (zero byte) files

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.

The Host Instance which runs the Receive Location is not started

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.

The filter on the Send Port contains the wrong Receive Port or contains a typo

Correct this by copying the name from the Receive Port and paste it in the filter of the Send Port.

The name of the Receive Port in the filter of the Send Port is surrounded with quotes

Quotes are not needed, so remove them.

The Send Port is not enlisted and started

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.

The Host Instance which runs the Send Port is not started

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.

BizTalk is not authorized to access the file location from the Send Port

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.

The File Send Adapter cannot write to the file specified because it has the Read-only or System attribute

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 Read-only attribute.

The Send Port uses the Backup Transport (if configured)

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.