How to capture the SFTP adapter input file details in to the Schema.
Example: If I get the file formats like .xml,.dat,.txt in a remote location .then how to captute the details like File Name,File Size,File Mask,Time Stamp in to a Xml schema.
You will have to implement a call to an external C# assembly, that queries that remote file (using .NET IO library functions) and returns those details, from your BizTalk orchestration.
"Google skills are more important than your coding skills."
Hi, If you use an Orchestration then you have all these fields in the Context of the Message.
From the Context you can create a custom XML with the fields you need.
Regards,NISHIL MCT,MCTS | Freelance BizTalk Consultant.biztalkconnect.blogspot.com
Thank u so much for your help.Can you people please explain briefly that is step by step about this.
Hi Danial and Nishil,
My actual requirement is as follows:
· A: Processing begins with the adapter’s schedule being triggered or for one of the adapters configured for manual processing being triggered through the ESB Web Portal.
· B: Once the file has been successfully received by the adapter, the file will be extracted in the adapter and placed in an internal file location. The file will not be processed through to the BizTalk MessageBox database. If no file is received. If there is more than one file that matched the file mask configured in the adapter, the adapter will continue to process the files in to the internal file location until no more files are found.
· C: No matter how many files are found (none, one or many) the adapter will create a control message based on a defined format (see later in document). This control message will be forwarded in to the BizTalk MessageBox for further processing.
· D: An orchestration will subscribed to this message and will process it once received from the MessageBox. The orchestration will be created with standard exception handling routines. The orchestration will be mainly responsible for calling Business Rules that will determine the destination for the original file. Business Rules will also be assessed to determine if mail notifications are need to be sent, and to whom. If emails are required, standard BizTalk maps will be executed to transform the control message in to human readable emails and forwarded to the logical port. The orchestration will also be responsible for dispatching the main control message in to several single control messages, one for each file that has been placed in to the temporary location and requires moving in to the target directory.
· E: Business rules determining the target location of the original file, email notification rules and email recipient information will be stored in the BizTalk Rules Engine.
· F: When an email message has been generated using maps within the Orchestration, a dynamic SMTP will subscribe to the message and use the fields within the message to determine the recipients. It will then forward to the message to a Boxer SMTP server for onward processing. The configuration of the SMTP is not in the scope of this document.
· G: The control message will also be mapped to a message that can be stored in the control database. This database is a custom created database used for logging the activity of all file handlers. The control message will be sent to the control database logical port in the orchestration. A physical WCF SQL port will subscribe to this message and ensure the appropriate insert stored procedure is executed in the database to ensure the log message is saved correctly.
· H: The file adapter will subscribe to the control message. At this point there should be one control message for each file.
· I: A custom pipeline component will retrieve the file from the temporary file location and allow the dynamic file adapter to move the file in to the final target directory.
J: The file should be now residing in the target location.
Can u people plese help me in this more briefly.
If you are using the BizTalk Sftp Adapter from Codeplex, the message context properties like File Size and DateTime are not promoted by default. You will have to customize the source code of that adapter library, in order to expose those properties and use them in an orchestration, for instance.
See the following link to a discussion that explains how you can customize the source code to achieve what you want:
Hope this helps,
Daniel - I too am struggling with how to determine a specific file name within a BizTalk 2009 Orchestration. The following command generates an error:
Command: FileName = msgIN(Blogical.Shared.Adapters.Sftp.Schemas.remotefile);
The Error: Inner exception: There is no value associated with the property 'Blogical.Shared.Adapters.Sftp.Schemas.remotefile' in the message.
Why does this not work? It seems to me like I am missing something to allow the BizTalk Receive Port to connect to the bLogical adaptor. Your link in the message that I replied to appears to be way too complex for what should be a simple solution. Any thoughts?
Thanx in advance!!
Do you find any solution for this problem???.If yes let me know.
Any luck on this ? i have similar requirement
Can any one tell on how to set outgoing file name with out using orchestation
You can do that in the File Transport Properties window when configuring your physical send port in the Administration console. You can also use macros like %MessageID% in the File Name field to make the naming convention more dynamic.
Pardhu - sorry to take so long to get back to you - I was on vacation.
The temporary solution that I found to work for me was to use the BizTalk FTP (NOT SFTP) adaptor on the Receive port and the SFTP adaptor on the Send port. This allows me to examine the file name to determine which client directory to deliver the file to. This solution only works because our BizTalk 2009 server is internal within our firewall thus FTP communications within the firewall are acceptable - for now. The company that I work for has determined that only SFTP communications will be allowed both internally as well as externally by the end of the year, so I will once again be facing this issue come fourth quarter. Hopefully an easier method for determining various receive file attributes will be devised by then ......