BizTalk Message Based Routing: why is my file not transfered to the location of the Send Port
Inspired by some tweets I had with Sam Vanhoutte (@SamVanhoutte), Mikael Sand (@MikaelSand) and Dean Robertson (@DeanRobertson), I decided to write down a number of our experiences of what can go wrong, or what you could forget, in case of a simple message based routing scenario.
So 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.
1. 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.
2. 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.
3. 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.
4. 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).
5. 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 picked up by the Receive Location. So make sure your file names are shortes than 256 characters.
6. 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.
7. 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.
8. 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.
9. 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.
10. The name of the Receive Port in the filter of the Send Port is surrounded with quotes
Quotes are not needed, so remove them.
11. 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.
12. 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.
13. 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.
14. 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.
15. 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 went wrong while delivering the message to the Primary Transport.
16. 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.
17. Tricked by Windows Explorer
You think you are dropping a .XML file, and the file mask 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.
Thanks to Mikael Sand for supplying a number of possible problems. Some of the problems are derived from this article.
