Geeks With Blogs

News View Michael Stephenson's profile on BizTalk Blog Doc View Michael Stephenson's profile on LinkedIn
Michael Stephenson keeping your feet on premise while your heads in the cloud

I think it would be useful if maps could be applied at Receive Location level.  I was working on a demo scenario the other day where I had an orchestration that was exposed to two different receive locations through a port.

The message formats coming in were different as well as the transport.  Inbound it was easy I could apply 2 maps to the port and map the different requests to a common schema for the orchestration to work with.

The problem came because it was a synchronous service and when the orchestration returns a common response there is no way to work out which outbound map should be applied as both maps would have the same source document.

If the map could be applied at receive location level then this problem would be resolved as each location in this scenario would be working with its specific message format.

I would imagine this isnt that uncommon a scenario.


Following feedback from Jason ive added this update to try and ensure I have explained this correctly as its a little awkward to describe.

As mentioned the process is synchronous request response.  The following diagram illustrates what happens on the inbound part of this process:

As you can see the both locations pass in different message formats which are processed and then mapped in the port (using a different map for each) to a common schema.  This common message is what hits the message box and is then processed by an orchestration.  The two different maps are applied because they each accept a different message input type and the map which should be used can easily be resolved.

The next diagram shows what happens on the response side of this:

As you can see when the common schema for the response message is returned to the message box from the orchestration and picked up by the port for processing the 2 maps which are used to map the response back to the sender specific response message will both have the same input schema.  This wont work as the map to use can not be resolved correctly.

As Jason mentioned you can work around this and infact what I did in my sample scenario was to implement a pipeline component which could execute BizTalk maps (ill discuss this in another article) this ment the mapping was in the pipeline rather than the port so the problem did not occur.

The point of this article is that the scenario here is potentially fairly common and while you can work around this problem the solution is a bit of a pain in the butt to implement so it would be nice if in future versions it was easier.

Posted on Sunday, May 4, 2008 4:36 PM BizTalk , BizTalk Wishlist | Back to top

Comments on this post: Another one for the BizTalk Wish List

# re: Another one for the BizTalk Wish List
Requesting Gravatar...
Why not make a pipeline for them and use a custom pipeline component for each, and each component promotes a property you set at deploy time which you could use later in the orchestration to determine which path it came from? You could probably also look at the stock transport properties, but that would couple you too tightly. Would that work for you or did I read the problem wrong?
Left by Jason Turnage on May 05, 2008 2:39 PM

# re: Another one for the BizTalk Wish List
Requesting Gravatar...
Hi Jason

Thanks for the feedback, ive applied an update just to try describe it a little better.

As you mention I did work around the problem, but it would be nice if in the next version of BizTalk we didnt have to

Left by Mike on May 05, 2008 3:46 PM

Your comment:
 (will show your gravatar)

Copyright © Michael Stephenson | Powered by: