Executing pipelines from inside an orchestration: Introducing the LOOPBACK adapter

by | Nov 9, 2004 | BizTalk Community Blogs via Syndication | 0 comments

Let’s go over some of the out-of-the-box options for executing a pipeline from inside your orchestration.

 

It struck my mind first that the MSMQT adapter IS in fact the messagebox.

 


  1. MSMQT

 


  • Set up a schedule with 1 MSMQT send port and 1 MSMQT receive port sharing the same MSMQT queue name (for example ‘ loopback’ would make a lot of sense)
  • Create a correlation type and set based on the my MSMQT label property.
  • Assign the MSMQT message-label to a newly created GUID inside your orchestration.

 

Try to do a send and a receive and you will see that your pipelines will be executed. As a test I could successfully parse a message from inside a schedule.

 

Another very simple option is using the HTTP adapter, credits go 100% to Scott Colestock. Scott used this as just a temporary approach to get past this problem, and then switched to the loopback adapter below…

 


  1. HTTP

 


  • Use a solicit-response send port 
  • Use bogus HTTP page that simply echoes the content back.

 


using System;
using System.Web;
using System.IO;

public class LoopbackHandler : IHttpHandler
{
   public bool IsReusable
   { get { return true; } }
  
   public void ProcessRequest(HttpContext context)
   {
      using(StreamReader sr = new StreamReader(context.Request.InputStream, true))
      {
         StreamWriter sw = new StreamWriter(context.Response.OutputStream, sr.CurrentEncoding );

         sw.Write(sr.ReadToEnd());

         sw.Flush();
         sw.Close();
      }
   }
}


  • Call it loopback.ashx for example, use IIS to host the page (for example http://localhost/loopback/loopback.ashx).

 

This can be easily explained because it requires no knowledge of correlation types and correlation sets, since you are using request/response ports the whole way. If simplicity is the main goal then this solution is probably superior to the MSMQT one.

 


  1. Custom LOOPBACK Adapter.

 

I also had another idea. Why not make your own loopback adapter by writing a bogus solicit-response adapter that returns a response BizTalk IBaseMessage that is a copy of the original request message. Recreate the original individual message-parts and copy of the request stream to the response stream. It’s very simple – download my sample loopback adapter here.

 


  • It’s a custom coded VB.NET non-batched but non-blocking (async) adapter that really doesn’t do anything.
  • Uses limited memory-footprint, streams to disk. 
  • To install use the MSI package. Don’t forget to add the adapter by using BizTalk administration…
  • It auto generates the transmit location URI (in fact it’s a GUID). I also added a Boolean property to specify whether you want the original message and part properties to be copied on to the response-message and parts.

 

Here are some of the benefits:

 


  • Trigger pipeline execution from inside your orchestration. Just define your outbound and inbound pipelines and they will be executed.
  • Send pipeline errors can be catched by adding a deliveryfailure-exception handler. Also adapter exceptions can be catched there, but since this adapter really doesn’t do anything this will be very rare (at least I hope so).
  • Receive pipeline errors can be catched by adding a general SOAP-exception handler.
  • Execute mappings from inside your orchestration by defining a map on the inbound and outbound port. When you use the later, mapping failures will be catched by the SOAP-exception handler.
  • It’s a black-hole adapter if you want. It can be used to ignore the processing of certain incoming messages. Make a send-port, name it ‘VANISH’ and subscribe to a given message-type or receive-port name for example.
  • It’s very useful for doing in-order processing. You can for example receive messages from MSMQT through a pass-through pipeline (which is recommended BTW) and process messages in-order from start-to-end while doing exception-handled parsing/validation/mapping by implementing a serial convoy.

 

Here’s a sample project that demonstrates some of the benefits.

 



Remarks:

 


  • The code can definitely be improved. It has been written very quickly in the scope of a POC. Alternatively you could make a better one using the adapter base classes and the wizard. In fact I’m hoping the community will see the benefit of this loopback adapter and someone else will make a better one. I’m not (yet, ha!) a streaming and multi-threading expert.
  • Apparently it is advised to return a read-only forwarding stream to the receive-pipeline. At least until SP1 arrives. I just used the VirtualStream class from the BizTalk Streaming assembly.
  • Do not forget, and as usual: there’s no warranty at all. I haven’t tested this very thoroughly yet so…use the adapter at your own risk.

Submit a Comment