Stacking Maps in BizTalk Server

Scenario: I have a need to process two transformations back-to-back.  For example, I have Schema1, Schema2, and Schema3, and I have two maps:

  • Schema1 -> Schema2
  • Schema2 -> Schema3

Schema1 is our canonical schema, meaning this is the schema we always use to "publish" to the MessageBox database.  Consider this diagram in which we receive a message and publish the update to two line-of-business (LOB) applications:

Message Flow 1

Notice what's missing?  There is no Schema1 -> Schema3 map.

In the real-life scenario that inspired this test, the maps are very complicated and it would be too much of an undertaking (currently) to invent a new map for transforming Schema1 directly to Schema3.  So how do we apply multiple maps in a row using BizTalk?

For this example, I've built out three schemas and two maps, as outlined above.  Here are the schemas:


Complicated, I know! =)

First, the easy approach: Orchestration.

BizTalk Orchestration

This works, however the message in the real-life scenario is over 600MB.  BizTalk Server, by default, will swap to disk for transforms performed in an orchestration when the message is over 1MB in size (see the note about TransformThreshold in this article).  We can increase this threshold if needed, but 600MB is a bit excessive, I think.

Once orchestration was ruled out, my first thought was to do something in a pipeline component; however, I wanted to see if I could do this without code.

So how about this: I set up a WCF-based NetTCP receive location (and BizTalk sets up its own service host -- how nice) and a corresponding NetTCP send port.  (In retrospect NetNamedPipes might have been better?  Not sure, but this still worked.)  On the way out of the send port, we transform to Schema2, which is published back to the MessageBox by the receive port.  Finally, our LOB2 send port applies the second map on its way out.

Message Flow 2

Yeah, yeah... it's clumsy... it's kind of a hack... but it was fun.

Seriously, however, if anyone has a different approach, I'm all ears. =)  Eventually the "correct" solution will be to create a map which transforms Schema1 directly to Schema3.

Sample code:


Technorati Tags:

Comments (9)
  1. Juan Suero says:

    only thing with that is you break up the transactionality … one of the things that Biztalk has is transactionality from the port to the message box.  what happens if your send port chokes on the message.  

    another hack could be using the SOAP adapter (he he)

    you can have a XMLReceive dump it to the message box..

    a solicit response send port with SOAP adapter would listen.  the SOAP adapter would be configured to use a webservice proxy from some assembly lets say assembly "X".

     inside assembly "X" you can inherit a class from the interface that gets implemented when you generate a proxy from a ASMX webservice.

    i know you can receive XMLElement from the Adapter.

    You can try to receive a Stream maybe more efficient i havent tried it.

    Take this stream or XMLelement and pass it right back to the SOAP Adapter.

    Use XMLReceive and XMLSend pipelines on the solicit response port

    put your MapAtoMapB as an outbound map

    put your MapBtoMapC as an inbound map

  2. Chris Romp says:

    There’s also the Transformation Web Service as a part of the ESB Guidance.  It could be called twice in sequence before (or after) completing other actions.

    Mostly I was curious to see if I could make it work. 🙂

  3. Ben Cline says:

    Couldn’t you just tie a send port with an outbound map to the same location as a receive port with an inbound map to do the 2 map thing? Then you could stack it even more if you had another send port filter to match the namespace of the 2nd output schema.

  4. Chris Romp says:

    Isn’t that what I’ve done?  The send port is pointing to a receive port on the same BizTalk machine.

    It’s not a particularly elegant solution, but it seems to work.

  5. Fabio says:

    Maybe this is stupid, but… How did you configure the two NetTCP Ports? What URI did you use?


  6. Chris Romp says:

    The receive location is just a WCF-NetTCP binding with a net.tcp://localhost… URI.  Then I pointed a send port with the same binding to that URI.

  7. Daniel says:

    Hi Chris,

      I just found another way to chain two maps together without another orchestration: put map 1 in the Inbound Maps tab of your Receive port, and put map 2 in the Outbound Maps tab of the Send port. Also don’t forget to set the BTS.ReceivePortName property to the name of your Receive port in the Filters tab of your Send port.


  8. Chris Romp says:

    Richard Seroter has written a much better approach using itineraries in the ESB Toolkit for BizTalk Server:

  9. Atam says:

    Hi, what software did you use to make the diagrams? thanks

Comments are closed.

Skip to main content