Determine which receive location a message is received on.

[Phil]

I have multiple receive locations for a receive port. Is there away of
determine which receive location the message was received on? Where I
received the message from determines where I send the message. Thanks!

[Tomas Restrepo (MVP)]

Hi Phil,

Post by Phil
I have multiple receive locations for a receive port. Is there away of
determine which receive location the message was received on? Where I
received the message from determines where I send the message. Thanks!

I don't think that any one property really specifies the receive location.
At best, you can get the URI of the original message, via the
BTS.InboundTransportLocation, but that doesn't necessarily have to match the
URI of a specific receive location (because some, such as the File adapter,
use wildcards).

I believe that you might be better served here by putting each receive
location in their own receive port, and then using direct binding in your
orchestration's initial receive shape so that it subscribes to messages
coming off any of your receive ports. This is easier because you can then
indeed use the BTS.ReceivePortName property to do your routing if you like.

If each location/port represents a particular business partner/entity that
sent you a message, it might be worthwhile to look into using RoleLinks and
the Party Resolution facilities in BizTalk to help out with the routing, it
might make things easier on you.

[Greg Forsythe]

The BTS.InboundTransportLocation will always be the same as the URI of the
receive location.
The URI is used by the adapter to identify the Receive Location

The real issue is this URI will change depending on the deployment. Your
dev, test. production servers will probably have different URIs.
So hardcoding the URI in an orchestration or on a send port filter will
cause a lot of pain.

One option is to use Microsoft.Biztalk.ExplorerOM to retrieve the
ReceiveLocation name using the BTS.InboundTransportLocation.
As long as the ReceiveLocation name is always the same on all deployments
then this would be less maintenance.

Greg

Post by Tomas Restrepo (MVP)
Hi Phil,

Post by Phil
I have multiple receive locations for a receive port. Is there away of
determine which receive location the message was received on? Where I
received the message from determines where I send the message. Thanks!

I don't think that any one property really specifies the receive location.
At best, you can get the URI of the original message, via the
BTS.InboundTransportLocation, but that doesn't necessarily have to match
the URI of a specific receive location (because some, such as the File
adapter, use wildcards).
I believe that you might be better served here by putting each receive
location in their own receive port, and then using direct binding in your
orchestration's initial receive shape so that it subscribes to messages
coming off any of your receive ports. This is easier because you can then
indeed use the BTS.ReceivePortName property to do your routing if you like.
If each location/port represents a particular business partner/entity that
sent you a message, it might be worthwhile to look into using RoleLinks
and the Party Resolution facilities in BizTalk to help out with the
routing, it might make things easier on you.
--
Tomas Restrepo
http://www.winterdom.com/

[Tomas Restrepo (MVP)]

Hi Greg,

Post by Greg Forsythe
The BTS.InboundTransportLocation will always be the same as the URI of the
receive location.
The URI is used by the adapter to identify the Receive Location

duh!, thanks for correcting me, you're right, of course.

Post by Greg Forsythe
The real issue is this URI will change depending on the deployment. Your
dev, test. production servers will probably have different URIs.
So hardcoding the URI in an orchestration or on a send port filter will
cause a lot of pain.

So true.

Post by Greg Forsythe
One option is to use Microsoft.Biztalk.ExplorerOM to retrieve the
ReceiveLocation name using the BTS.InboundTransportLocation.
As long as the ReceiveLocation name is always the same on all deployments
then this would be less maintenance.

Am I the only one that feels this would be too much work (not too mention
that opening and closing ExplorerOM objects is rather expensive)?

[Greg Forsythe]

Tomas,

Yes the ExplorerOM option would not be great from a performance point of
view. using a management interface for a runtime process is not ideal

The multiple receive ports with a direct bound orchestration would be the
easiest and quickest to set up - no custom code.

The role link option is relatively difficult to set up the first time, but
once this is done you have a reusable routing infrastructure for other
projects.

Greg

Post by Tomas Restrepo (MVP)
Hi Greg,

Post by Greg Forsythe
The BTS.InboundTransportLocation will always be the same as the URI of
the receive location.
The URI is used by the adapter to identify the Receive Location

duh!, thanks for correcting me, you're right, of course.

Post by Greg Forsythe
The real issue is this URI will change depending on the deployment. Your
dev, test. production servers will probably have different URIs.
So hardcoding the URI in an orchestration or on a send port filter will
cause a lot of pain.

So true.

Post by Greg Forsythe
One option is to use Microsoft.Biztalk.ExplorerOM to retrieve the
ReceiveLocation name using the BTS.InboundTransportLocation.
As long as the ReceiveLocation name is always the same on all deployments
then this would be less maintenance.

Am I the only one that feels this would be too much work (not too mention
that opening and closing ExplorerOM objects is rather expensive)?
--
Tomas Restrepo
http://www.winterdom.com/

[Phil]

Thanks to everyone for their response. Being relative new to Biztalk – I am
trying what appears to be the easy solution first. Tomas, can you explain
how to tie two receive ports to a receive shape. I tried using the filter
expression in the receive shape, using TBS.ReceivePortName for both my
receive ports. Any suggestions would be greatly appreciated!

Post by Tomas Restrepo (MVP)
Hi Phil,

Post by Phil
I have multiple receive locations for a receive port. Is there away of
determine which receive location the message was received on? Where I
received the message from determines where I send the message. Thanks!

I don't think that any one property really specifies the receive location.
At best, you can get the URI of the original message, via the
BTS.InboundTransportLocation, but that doesn't necessarily have to match the
URI of a specific receive location (because some, such as the File adapter,
use wildcards).
I believe that you might be better served here by putting each receive
location in their own receive port, and then using direct binding in your
orchestration's initial receive shape so that it subscribes to messages
coming off any of your receive ports. This is easier because you can then
indeed use the BTS.ReceivePortName property to do your routing if you like.
If each location/port represents a particular business partner/entity that
sent you a message, it might be worthwhile to look into using RoleLinks and
the Party Resolution facilities in BizTalk to help out with the routing, it
might make things easier on you.
--
Tomas Restrepo
http://www.winterdom.com/

[Tomas Restrepo (MVP)]

Hi Phil,

Thanks to everyone for their response. Being relative new to Biztalk - I
am
trying what appears to be the easy solution first. Tomas, can you explain
how to tie two receive ports to a receive shape. I tried using the filter
expression in the receive shape, using TBS.ReceivePortName for both my
receive ports.

You are on the right track. The trick here is that

a) you need to first define your logical receive port in your orchestration
as direct bound (instead of bind later/now)
b) Use filters in your receive shape (as you are doing now). You probably
don't want to bind based only on the receive port name (as that will pretty
much do the same as if you were using normal binding), but instead bind on
something more interesting. For example, biztalk will by default get you
binding based on the MessageType. That might be enough for you. Or, you
could bind based on the value of a custom property you're promoting on the
receive pipeline (either because the disassembler promotes it, or because
you have a custom pipeline component that does it).


Once that is done, it's just a matter of deploying, creating the ports, and
then enlisting and starting everything.

I recommend you start by taking a look at Charles Young's excellent article
on direct binding, it will clear a lot of things up:
http://geekswithblogs.net/cyoung/articles/19546.aspx

["Paul Brinkley-Rogers" $]

Phil,

Assuming you are using orchestration (versus straight messaging), you could
create an assembly, install it in the GAC, add a reference to it in your BTS
project, and call it from an Expression shape to resolve the receive
location. You would only really need one static method in a class. Be sure
to add a reference to Microsoft.BizTalk.ExplorerOM.dll.
Example:


using Microsoft.BizTalk.ExplorerOM;
namespace Phil
{
public class OrchestrationHelpers
{
public static string ResolveReceiveLocationName(string
inboundTransportLocation, string receivePortName)
{
BtsCatalogExplorer bts = new BtsCatalogExplorer();
bts.ConnectionString =
"SERVER=localhost;DATABASE=BizTalkMgmtDb;Trusted_Connection=True;Network
Library=DBMSSOCN;"
foreach (ReceiveLocation location in
bts.ReceivePorts[receivePortName].ReceiveLocations)
{
if (location.Address == inboundTransportLocation) return location.Name;
}
return null;
}
}
}

In your Expression shape within your orchestration, assuming a message
called "MyMessage" and a string variable "receiveLocationName":

receiveLocationName =
Phil.OrchestrationHelpers.ResolveReceiveLocationName(MyMessage(BTS.InboundTransportLocation),
MyMessage(BTS.ReceivePortName));
HTH,
Paul Brinkley-Rogers

Post by Phil
I have multiple receive locations for a receive port. Is there away of
determine which receive location the message was received on? Where I
received the message from determines where I send the message. Thanks!