Can Biztalk run a console application?

Question

Howdy,

I am writing a C# console application that takes a binary file, rips it apart, analyzes it, and stores the data into a database.

We want to use BizTalk to orchestrate watching when a new binary file is placed in a directory and calling my application with the file name/names to be parsed.

Can BizTalk run a command line program?
Can it pass command line parameters to the program?
How would I report back to BizTalk that the last run was a success or a failure?

Thank you,
Keith

Answer 1

Biztalk is a server product so it will always be running in the background when you set it up in a production environment.

I'd suggest that if you're wanting to use BizTalk you set it up to watch the location where the file will be dropped, rip it apart, analyze it and then write out to the database all within a BizTalk workflow. Its exactly what it's been designed to do. The workflow could also contain notifications or you could just use BizTalk tracking to confirm if the operation has been successful. The only custom code you might need to write is a disassembler for your binary file to turn it into XML. This would be done as a receive pipeline component.

If that's all your doing though, BizTalk is a heck of an expensive option for just this. I suggest you write your own Windows service and use the FileSystemWatcher to intercept the fact that a file has been written and then do the processing in your C# code.

Answer 2

I would not recommend doing this but in theory you could run the exe using a shell command within an expression shape:

System.Diagnostics.Process.Start(@"C:\yourPath\yourExecutable.exe")

The System.Diagnostics namespace is available in BizTalk 2006, I don't think it is available in BizTalk 2004 (BizTalk 2004 had a very restricted subset of the System namespace available).

I'm not sure about getting return values back but you should certainly be able to provide parameters.

Some references on C# shell commands can be found here and here.

I personally think there are three better options available to you:

1. Don't use BizTalk.

   As Campbell suggests, use a windows service instead.

   Only use BizTalk for something like this if you want to leverage an already existing BizTalk framework (logging, reporting etc...) or if you have other tasks in a workflow that BizTalk is going to perform. (There are arguments for putting everything into one platform - if you use BizTalk for one thing, use if for everything, but that is a different conversation).

2. Refactor the logic of your shredder into a C# class library that both your Console application and BizTalk can call.

   Calling a class library from BizTalk is much easier to do cleanly and robustly that calling an executable would be.

   Simply reference your signed and GACed assembly from an orchestration (create it as an orchestration variable) and you can then call it directly from an expression shape.

   here is an article on this that covers the basics. It doesn't go into a lot of the ugly detail or offer discussion on best practices. Professional BizTalk Server 2006 is a good book for that.

3. As Campbell said, most of this can probably be done with pure BizTalk functionality.

I think perhaps a mix of options 2 and 3 would be best for what you want. Put the binary shredding logic you already have into a C# class library and call this from within a BizTalk orchestration that takes care of your file monitoring, error notification, tracking and integration with other processes.

Answer 3

BizTalk calling a C# application is kind of out if its box. We've had issues like this in the past and we have the console applications written or wrapped as a web service. This way, Biztalk picks up the file being dropped off and sends it to the app web service application. This falls under the 'swiss army knife' portion of how we use BizTalk. This is really underkill. However, BizTalk does provide things like tracking, BAM, queueing for farside failures, etc. We additionally have gotten into copying files to archive locations, reading result codes from web services and using the SMTP adapter to send notification of success or failure.

Hope this gives you some ideas. Best of luck!