|
Home > Archive > BizTalk Server Orchestration > May 2004 > "The FILE send adapter cannot open file..."
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
"The FILE send adapter cannot open file..."
|
|
| nasreen 2004-05-20, 5:43 pm |
| Hello,
The orchestration in my BizTalk project is exposed as a web service. The orchestration receives a request from a web service client, sends a response to that client, and ends by dropping of the same message that it sent as a response to the client to fold
er on the local drive.
When I test this scenario, the client is able to receive the message from the web service, however the orchestration fails to drop the message off into the local drive folder. Here is the message:
The FILE send adapter cannot open file D:\filedrop\send for writing
Question 1: Does this message correspond to anything else other than the correct permissions not being granted to the file send adapter? Since I have made this folder accessible for writing/modifying to everyone for testing purposes, but it doesn't seem t
o work.
Question 2: Which group/account should have the permissions for this folder? Is there a way to configure the FILE adapter itself to access this specific folder? If so, how?
| |
| Gilles [MSFT] 2004-05-20, 5:43 pm |
| Hello,
>The orchestration in my BizTalk project is exposed as a web service. The orchestration receives a request from a web service client, sends a
>response to that client, and ends by dropping of the same message that it sent as a response to the client to folder on the local drive.
>When I test this scenario, the client is able to receive the message from the web service, however the orchestration fails to drop the message off into
>the local drive folder. Here is the message:
>The FILE send adapter cannot open file D:\filedrop\send for writing
>Question 1: Does this message correspond to anything else other than the correct permissions not being granted to the file send adapter? Since I
>have made this folder accessible for writing/modifying to everyone for testing purposes, but it doesn't seem to work.
The message is usually fired when you do not have the permissions or when the given directory (aka D:\filedrop\send) does not exist.
You gave read/write, but make sure that the user that the adpater runs under can "traverse" this directory. I would suggest that you give full
control to this directory for the user running the adapter for a a minute, for testing purposes, just to rule out possible permissions problems.
Also, there is another possibility. How did you configure your FILE send location? You need to put a valid file name in "File Name".
You can use the %xxx% construct to build file names that are unique. Often, FILE adapters are configured with %MessageID%. So you should
really have a filename like D:\filedrop\send\%MessageID%.xml or something like it (refer to the BizTalk documentation for the avaialble "macros" -
the %xxx% constructs).
Last but not least, make sure the "Copy mode" is adequate. If you have a file here, you might want to overwrite or apend, or create new.
>Question 2: Which group/account should have the permissions for this folder? Is there a way to configure the FILE adapter itself to access this
>specific folder? If so, how?
When you deployed your orchestration, you performed two important tasks: you created the send location that will drop the files in D:\filedrop\send
and you also bound that receive location to an orchestration port. When you bound the receive location, you had to choose a host. This host runs
under a specific user. This user must have the appropriate rights to save files. So locate the host you are using and use the MMC to figure out
under which user the host is running.
Thanks.
-Gilles.
| |
| nasreen 2004-05-20, 5:43 pm |
| Thanks Gilles, the invalid file name did turn out to be the reason. For some reason, once I deployed and binded the orchestration, the location for send got changed to a 'default' one that BizTalk chooses everytime I redeploy and rebind.
|
|
|
|
|