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.
- 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...
- HTTP
- Use a solicit-response send port
- Use bogus HTTP page that simply echoes the content back.
<% @ webhandler language="C#" class="LoopbackHandler" %>
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();
}
}
}
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.
- 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.
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.