File Adapter: files not being picked up
Hi.
I'm having a problem with the file adapter not picking up files from a shared folder.
The files we need to copy and move are placed in a shared folder on a server by our document production system.
I have set up two receive ports with one receive location each (using only PassThruReceive pipelines): one that listens for *.xml using the UNC path to the folder in question and one listening for *.pdf.
There are three different send ports subscribing to the messages coming in through these two receive ports.
Having set up the application, I tested it by placing some files in the shared folder in question, and it worked just fine. However when our document production system places files in the folder BizTalk does not pick them up! There are no error messages in the event log or in BizTalk. The files are just not being picked up.
If I move the files manually to another subfolder on the share and move them back nothing hapends either. But: if I manually move them to another partition or to another server and then move them back to the sahred folder, BizTalk DO pick them up! It's all very strange.
Have anyone come across annything like this before?
I suspect it's caused by a combination of how the source system places the files in the folder and how the Windows filesystem events are being used from the file adapter in BizTalk. The inner workings of the file adapter (i.e. how it interacts with the Windows filesystem) is something I haven't found that much documentation about, so if anyone have some knowledge about this please reply.
Answers
Possibly a file permissions problem.
Have you checked the file permissions on the files when they are first placed in the folder by the source system?
All Replies
Possibly a file permissions problem.
Have you checked the file permissions on the files when they are first placed in the folder by the source system?
Specifically around permissions, check the share's setting for "delete subfolders and files" rights (http://seroter.wordpress.com/2007/06/18/biztalk-production-application-deployment-issues-encountered/).
Are you sure the document production system is outputting the files with the correct extensions? Please make sure that the extensions are being shown in Folder Options. It is possible to have a file called File1.pdf.txt when in the Windows explorer it looks like File1.pdf but in reality it has a different extension. This is is one tricky issue with the FILE adapter that can be very confusing until you show file extensions.
Thanks,
It was a file permission problem.
Turns out that the permissions on the files are different than those on the share and folder, so now I'm trying to figure out how the file permissions are being set...
Shouldn't there have been an error in the event log when BizTalk can't access the folder and/or file that the receive location is configured to pick up?
If the file adapter cannot access the folder because of an access violation then you will get an error in the event log.
If you have access to the directory, then the adapter will get a directory list based on the file mask. I suspect the file subsystem is omitting the files from the directroy list if the user does not have access to those files. So the adapter does not know there are files to process and does not report an error.
If the file adapter cannot access the folder because of an access violation then you will get an error in the event log.
If you have access to the directory, then the adapter will get a directory list based on the file mask. I suspect the file subsystem is omitting the files from the directroy list if the user does not have access to those files. So the adapter does not know there are files to process and does not report an error.
I encountered the exact same problem. I had the necessary file access permissions for the Biztalk App user but the receive location just wouldn't pick up the file (no errors logged) until I gave the BTS App user 'Write permission' and 'Change permission' access to the directory. It's basically wanting a full access. Beats me why that would fix the issue.
