|
Home > Archive > BizTalk Server General > March 2006 > Determine which receive location a message is received on.
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Determine which receive location a message is received on.
|
|
|
| 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\) 2006-03-17, 5:52 pm |
| Hi 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
tomasr@mvps.org
http://www.winterdom.com/
| |
| Paul Brinkley-Rogers 2006-03-17, 5:52 pm |
| 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
"Phil" <Phil@discussions.microsoft.com> wrote in message
news:52F791B6-5014-4868-BB68-11736AF7EC6F@microsoft.com...
>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!
| |
| Greg Forsythe 2006-03-17, 5:52 pm |
| 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
"Tomas Restrepo (MVP)" <tomasr@mvps.org> wrote in message
news:uREuVzfSGHA.4952@TK2MSFTNGP09.phx.gbl...
> Hi Phil,
>
>
> 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
> tomasr@mvps.org
> http://www.winterdom.com/
>
| |
| Tomas Restrepo \(MVP\) 2006-03-17, 5:52 pm |
| Hi Greg,
> 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.
> 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.
> 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
tomasr@mvps.org
http://www.winterdom.com/
| |
| Greg Forsythe 2006-03-18, 3:18 am |
| 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
"Tomas Restrepo (MVP)" <tomasr@mvps.org> wrote in message
news:eJi7UfhSGHA.736@TK2MSFTNGP12.phx.gbl...
> Hi Greg,
>
>
> duh!, thanks for correcting me, you're right, of course.
>
>
> So true.
>
>
> 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
> tomasr@mvps.org
> http://www.winterdom.com/
>
| |
|
| 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!
"Tomas Restrepo (MVP)" wrote:
> Hi Phil,
>
>
> 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
> tomasr@mvps.org
> http://www.winterdom.com/
>
>
>
| |
| Tomas Restrepo \(MVP\) 2006-03-21, 3:10 am |
| 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
--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/
|
|
|
|
|