none
Publish Flatfile Adapter as WCF RRS feed

  • Question

  • Hi,

    we like to publish some ReceiveLocations via WCF to handle different file formats like flatfile and excel.
    The goal is to read the files in an .NET application and send them to Biztalk for further processing.
    Is this the right approach to send the files via WCF? And how could I send them? Via stream? Which encoding do i have to use?
    Are there any turorials in the web how to accomplish this?


    Thanks for your help and regards

    Stefan
    Friday, September 19, 2008 8:04 AM

Answers

  • Ok, so your scenario is to have a 2-way Receive Location in BTS. 

    In such a situation, using the file adapter for submitting the message and then having BTS send a response back to your application via WCF might not be that great, since your application will have to listen on some endpoint in order for BTS to let you know what happened. What happens if multiple instances of your application are running - they'll all try listening to the same endpoint? 
    Having a WCF Receive Location would solve your problem, since the 2-way receive is then synchronous. Though you'll need to host the Receive location in IIS if using WCF-HTTP; then in BTS you'll need to extract the file data from within the SOAP message, etc. If the file isn't that large, you could just send it as a byte[]. Or, you could just send the filename as a string, and in a custom pipeline component, extract the string and read the actual file from disk, and send that message out to BTS.

    Given a single file which the user has uploaded, without doing any heavy processing on it, is there a way to uniquely identify the file? If so, what you could do is (an asynchronous solution) -
    (a) get the file from the user (via the upload dialog)
    (b) get and ID or something from the file, which uniquely identifies the file
    (c) dump the file into a folder (FOLDER1) where there is a file receive location waiting to pick it up and submit it to BTS
    (d) In the BTS orchestration, you already have the flat file parser helping you in processing the file. Figure out the ID which makes the file unique (same ID as in step (b) above).
    (e) After processing the file (either success or failure), write out the file to another folder FOLDER2, with either the filename containing the ID, or place the ID within the data in the file, which your .NET application can understand.
    (f) Your .NET application can use the FileSystemWatcher component on FOLDER2 to read the responses as BTS finishes processing.
    As long as you don't need to give the response back to the user (who uploaded the file) synchronously, the advantage of this approach is that you can get by with very little code - the only code you'd have to write is file manipulation stuff
    Friday, September 19, 2008 4:08 PM

All replies

  • Can you clarify your scenario a little more? When you say "read the files in a .NET application and send them to BTS for further processing" - where is your .NET application going to read the files from? In what format (xml/flat file/etc)? Is it going to do any processing at all, or just read it from somewhere and send it to BTS?

     

    What value do you see WCF adding here? Why not just dump the files into a folder, and have a file port (file receive location) read the files from there and submit it to BTS?

     

    Friday, September 19, 2008 1:58 PM
  • Hi ,

    the Application is a Web Application. The Files get there via upload dialog.
    Then they should get imported from the biztalk server.

    The only value of WCF is to get a response to the user what happens to his data.
    But this will also be possible if we dump the files into a folder and maybe let the BTS send a feedback to the application via WCF. Would this be the better approach?

    Regards
    Stefan
    Friday, September 19, 2008 3:47 PM
  • Ok, so your scenario is to have a 2-way Receive Location in BTS. 

    In such a situation, using the file adapter for submitting the message and then having BTS send a response back to your application via WCF might not be that great, since your application will have to listen on some endpoint in order for BTS to let you know what happened. What happens if multiple instances of your application are running - they'll all try listening to the same endpoint? 
    Having a WCF Receive Location would solve your problem, since the 2-way receive is then synchronous. Though you'll need to host the Receive location in IIS if using WCF-HTTP; then in BTS you'll need to extract the file data from within the SOAP message, etc. If the file isn't that large, you could just send it as a byte[]. Or, you could just send the filename as a string, and in a custom pipeline component, extract the string and read the actual file from disk, and send that message out to BTS.

    Given a single file which the user has uploaded, without doing any heavy processing on it, is there a way to uniquely identify the file? If so, what you could do is (an asynchronous solution) -
    (a) get the file from the user (via the upload dialog)
    (b) get and ID or something from the file, which uniquely identifies the file
    (c) dump the file into a folder (FOLDER1) where there is a file receive location waiting to pick it up and submit it to BTS
    (d) In the BTS orchestration, you already have the flat file parser helping you in processing the file. Figure out the ID which makes the file unique (same ID as in step (b) above).
    (e) After processing the file (either success or failure), write out the file to another folder FOLDER2, with either the filename containing the ID, or place the ID within the data in the file, which your .NET application can understand.
    (f) Your .NET application can use the FileSystemWatcher component on FOLDER2 to read the responses as BTS finishes processing.
    As long as you don't need to give the response back to the user (who uploaded the file) synchronously, the advantage of this approach is that you can get by with very little code - the only code you'd have to write is file manipulation stuff
    Friday, September 19, 2008 4:08 PM
  • I vote for the 2 way WCF receive location.  WCF would be a very clean solution IMHO.  You can use the WCF service publishing wizard to publish a schema and select the schema type as Microsoft.BizTalk.XLANGs.BaseTypes.Any.  The published WSDL will contain an XML <any> node for the SOAP envelope body, and when you generate a proxy on the client side the parameter type will be Object.  Since the proxy takes an Object, you should be able to give it the file as a byte[] or a string.  You will need to play around with this and try different techniques to find the best approach.

    The WCF service publishing wizard creates an IIS virtual directory and a BizTalk WCF receive location for you.  You can bind the receive location directly to an orchestration, or you can use direct binding via filter expressions to route the file where it needs to go in BizTalk.
    Saturday, September 20, 2008 8:16 PM