|
Home > Archive > BizTalk Server General > April 2006 > Determine Receiving Party
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 Receiving Party
|
|
|
| Hello,
My question is regarding best practices for determining a receiving
party/business partner.
My problem is the following:
I receive an xml file with no indication of what partner it comes from.
The only way for me to know this is to look at the location that the
file comes from. Based on that location, I then have to fill in some
fields in the xml file.
For example:
Location: "../partners/partner1" would go into xml fields as partner1ID
(different from the location folder)
Things that I have tried or ruled out:
1. I don't want to have to parse the receive location URI
2. I tried using BizTalk parties to receive the file, but figured out
that it would only make sense if I was going to use the party
information for routing later on
A perfect solution for me would be to be able to associate a party with
a receive location (possible) and then get the various party
"qualifier" values somehow...is that possible? Is that sensible?
Any suggestions are appreciated.
Thanks.
Ana
| |
| Scott Colestock 2006-04-18, 12:47 am |
| Have you considered using a receive pipeline to add context properties to
your message based on receive location? This would require parsing a uri,
as you mentioned, but it would isolate that work to something reusable and
well upstream of our orchestration, etc.
Scott Colestock
www.traceofthought.net
"AnaB" <anabanana.discussions@yahoo.com> wrote in message
news:1145283884.881293.207760@g10g2000cwb.googlegroups.com...
> Hello,
> My question is regarding best practices for determining a receiving
> party/business partner.
> My problem is the following:
> I receive an xml file with no indication of what partner it comes from.
> The only way for me to know this is to look at the location that the
> file comes from. Based on that location, I then have to fill in some
> fields in the xml file.
>
> For example:
> Location: "../partners/partner1" would go into xml fields as partner1ID
> (different from the location folder)
>
> Things that I have tried or ruled out:
> 1. I don't want to have to parse the receive location URI
> 2. I tried using BizTalk parties to receive the file, but figured out
> that it would only make sense if I was going to use the party
> information for routing later on
>
>
> A perfect solution for me would be to be able to associate a party with
> a receive location (possible) and then get the various party
> "qualifier" values somehow...is that possible? Is that sensible?
>
> Any suggestions are appreciated.
> Thanks.
> Ana
>
| |
|
| Hello, Scott,
Thanks for your suggestion.
I basically don't want to implement anything that will put constrains
of the naming of the locations or that would prevent me from changing
them later on.
What other options do I have? Do I have other options? 
Ana
| |
| Scott Colestock 2006-04-18, 12:47 am |
| Well, at the end of the day, if the document coming in does not identify who
the sender is (either in the content, header, or via signature of some
sort), then you need to rely on details inherent to the transport it arrived
on (i.e. out of band to the message itself) or receive location/port that
picked it up.
You don't need to constrain how you name receive locations in biztalk
necessarily (is that your concern?) but you do need to come up with some
mechanism that extracts the information you need. By putting the
implementation of this logic into a pipeline component, you can be assured
that you can change that logic in response to new requirements (like a
different URI scheme, etc.)
Scott Colestock
www.traceofthought.net
"AnaB" <anabanana.discussions@yahoo.com> wrote in message
news:1145298771.275555.165200@e56g2000cwe.googlegroups.com...
> Hello, Scott,
> Thanks for your suggestion.
> I basically don't want to implement anything that will put constrains
> of the naming of the locations or that would prevent me from changing
> them later on.
> What other options do I have? Do I have other options?
> Ana
>
|
|
|
|
|