Last time I gave an overview of some potential different approaches to achieving a dynamic HTTP GET using BizTalk.
In this post I'll talk about the first one of those, using the BizTalk HTTP Receive Adapter.
As you probably know, BizTalk includes an HTTP Receive Adapter, which is designed for the scenario where you point it at an HTTP URL, and the Adapter polls that location looking for files that match some criteria on a periodic basis. The idea of this (similar to other Receive Adapters) is that when a file matches, BizTalk pulls that file in through the Receive Location configured with the Adapter (using HTTP GET), and it can then be used by the BizTalk messaging and/or orchestration engines.
There are two main problems with using this Adapter for our scenario.
Firstly, the intended use for the HTTP Receive Adapter is when you know in advance what the URL you're going to be polling is, and can configure it "statically". In our case, we don't know this URL until we're processing our "source" message in our orchestration instance. And although you can dynamically set transport properties for Send Ports, it's not possible to do the same for Receive Ports / Locations.
You could do something tricky like dynamically creating Receive Ports / Locations, and indeed that's something I've considered in the past (but with the FTP Adapter) when you have the scenario of files that you want to receive from a fixed location, but whose file name changes each day. You can certainly achieve this using the classes in the BizTalk Explorer Object Model... The problem though is that the Explorer OM is only supported in a 32-bit process, and ideally we don't want to constrain ourselves in that way.
The second problem with this approach is that the HTTP Receive Adapter is a Receive Adapter, so it's mainly of use when you want to use it to poll a location, find a file that matches, receive the file into BizTalk, and activate an orchestration instance based on the file having been received. In our case though, we're already in an orchestration instance... so how do we trigger the Receive Adapter to start polling for a file, and even once it's been received by BizTalk, how can it be receieved by our "source" orchestration instance and / or by another dedicated orchestration that is somehow tied to our "source" instance.
Again, there are certainly ways that you can achieve this:
(a) Using dynamically created Receive Ports / Locations, and having the "source" orchestration Listen to the BizTalk MessageBox for a message that matches the file you're waiting for;
(b) Having a separate orchestration that "dumbly" receives the file (asynchronously) and then sends a "trigger" message that the "source" orchestration Listens for;
(c) If the "source" orchestration really doesn't care whether the file is received or not before continuing, it can send a message to the MessageBox that triggers a separate orchestration that asynchronously retrieves the file and performs any processing required.
I guess the main take-away from these two problems is that neither of them are exactly "easy" to overcome, and can potentially make the solution much more complicated (and less scalable) than is ideal.
Surely there must be a better alternative?