Re: FTP %SourceFileName%
- From: "Tom" <fishingrod45@xxxxxxxxxxx>
- Date: 29 Jan 2007 10:56:19 -0800
Hi,
I have been reading this thread with great interest as we are having a
similar issue, as I posted on January 25th. We too are receiving a
file on a file receive port, then converting it and transmitting on an
FTP adapter send port. The issue only comes when trying to implement
the temporary folder option, which according to the documentation is a
slam dunk and is accomplished by suppling a folder in the Temporary
Folder box of the FTP Transport Properties window. We have supplied
that folder name. Our files transmit to the temporary folder, but the
move from temporary to the delivery folder always fails.
the Error text looks like this:
Description: A message sent to adapter "FTP" on send port
"spExtract_FlatFile_Header" with URI "ftp://122.122.222.55:21/folder/
Hdr.txt" is suspended. Error details: A failure occurred when moving
the file from the spooling folder to the destination folder. Please
verify the destination folder has the correct permissions.
MessageId: {5368F6FB-BE41-4BAD-8DDD-69ED2E7E2846} InstanceID:
{215E626E-EFD7-41C1-9DB8-CE069C3E741F}
Are we missing a patch for the FTP Adapter?
If the temporary folder option is removed, file transmission to this
folder is successful, "ftp://122.122.222.55:21/folder/Hdr.txt".
If the temporary folder option is removed, and the file is transmitted
to the folder that was previously designated as the temporary folder
(whew), file transmission is successful.
We want to use the temporary folder option but need your help to
diagnose.
Thank you,
Tom
On Jan 29, 7:50 am, PeterW <n...@xxxxxxxxxxxxx> wrote:
Hi WenJun
This morning I did what I said I was going to.
I changed the code in the orchestration to be like
outMsg(FTP.ReceivedFileName)=inMsg(FILE.ReceivedFileName)
Then recompiled, redeployed, started ports etc.
Dropped message into file receive location and lo and behold it appeared
properly in the FTP Collect folder.
The permissions thing was a red herring as I suspected. So my problem has
gone away.
I am stiil musing over the fact that the exception thrown was
BTSAdapterException and not DeliveryFailureException.
Also the fact that if you receive messages via an ftp port and send to a
file port, code
like the following works:
outMsg(FILE.ReceivedFileName)=inMsg(FILE.ReceivedFileName)
whereas when the direction is reversed, it must be
outMsg(FTP.ReceivedFileName)=inMsg(FILE.ReceivedFileName)
I raised the permissions issue with one of our administrators and he
confirmed that ftp permissions in this particular situation are cascaded down
the tree, so that was eliminated as an issue.
Thanks for your help.
cheers
--
PeterW
""WenJun Zhang[msft]"" wrote:
Hi Peter,
Glad to hear from you again.
First of all, have you checked the permission of destination FTP directory
and ensure that the user account specified on the FTP send port has correct
permission to write it?
It's a normal behavior that the file will be written into the temp folder
with a temporary filename(guid) first before moved to the destination
folder with the actual name. The behavior is clearly described in the
following blog thead:
BizTalk Server 2004: FTP guaranteed delivery
http://geekswithblogs.net/cyoung/archive/2004/08/10/9524.aspx
So I suspect it's still a permission error. Please double-check the folder
right or manually FTP some files to it to test.
I look forward to your findings or results.
Thanks and have a great weekend.
Sincerely,
WenJun Zhang
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to:
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.asp...
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at:
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.- Hide quoted text -- Show quoted text -
.
- Follow-Ups:
- Re: FTP %SourceFileName%
- From: Tom
- Re: FTP %SourceFileName%
- References:
- RE: FTP %SourceFileName%
- From: "WenJun Zhang[msft]"
- RE: FTP %SourceFileName%
- From: PeterW
- RE: FTP %SourceFileName%
- Prev by Date: RE: FTP %SourceFileName%
- Next by Date: Re: FTP %SourceFileName%
- Previous by thread: RE: FTP %SourceFileName%
- Next by thread: Re: FTP %SourceFileName%
- Index(es):
Relevant Pages
|