Does anyone have any thoughts on what (if any) performance impacts there may
 be of performing mapping operations within an orchestration rather than in 
the send and receive ports that serve the orchestrations.  I have the option
 to do either (however I do
need to have the orchestration to perform other business processes).  Since 
I must already have the orchestration, is there any performance advantage of
 mapping within the ports (or indeed vice-versa) performance disadvantages? 
 I guess I want to know wh
ether these transformations (orchestration mapping vs port mapping) differ i
n the guts of BTS2004.

Thanks - Jenny

[ Post a follow-up to this message ]

While there are actually some performance related reasons to put your maps
in the receive and sendports, there are much better business reasons for
doing it outside of your schedule. We tend to refer to mapping in receive
and send ports as document normalization. In the case of receive ports, you
are normalizing the documents from the format of your customers into an
internal standard format. On the outbound side, you are converting out of
your normalized format and into the specific format of your trading partner
or internal application. If you embed the map in the schedule and the
partner changes the format, not only do you have to rebuild the map, you
have to rebuild the schedule to use the new version of the map. Also, what
happens when you add a new partner with a new format. That is a new map and
if you have embedded the map in a schedule, it means a new schedule. This
is exactly why we added support for multiple maps (one per source message
type) on the receive port so that you could create a single location for
all of your partners and easily handle normalize into your internal
standard formats. Putting these types of maps in schedules would be a bad
idea. There are times when it makes sense to use a map in a schedule. When
you need to generate a new message in the schedule and use the modified
(mapped) contents of an existing message as the base. When you want to map
multiple parts of a message into one outbound message (this type of mapping
cannot be done in a receive / send port). THere are performance gains which
come from doing mappings in receive ports sometimes, but they are mostly
around how many persisted messages your scenario generates and it is a bit
complicated to explain. The actual mapping technology is the same. To keep
your internal business logic from getting tightly couple with the document
formats of your trading partners, you should do your document normalization
(mapping) in the send and receive ports.

HTH
Lee

This posting is provided "AS IS" with no warranties, and confers no rights.

EBusiness Server Team
--------------------[vbcol=seagreen] 
may be of performing mapping operations within an orchestration rather than
in the send and receive ports that serve the orchestrations.  I have the
option to do either (however I do need to have the orchestration to perform
other business processes).  Since I must already have the orchestration, is
there any performance advantage of mapping within the ports (or indeed
vice-versa) performance disadvantages?  I guess I want to know whether
these transformations (orchestration mapping vs port mapping) differ in the
guts of BTS2004.[vbcol=seagreen] 

[ Post a follow-up to this message ]

Lee,

This is, by far, one of the best explanations I've ever seen regarding
BizTalk Server 2004 ports and mapping. This "guidance" is exactly the type
of "best practices" information that BTS2004 developers are looking for,
especially those of us that are migrating from BTS2002.

Please contact Scott Woodgate (MSFT) and have him post this to his BizTalk
blog for everyone to see (or your own blog if you have one).

Jeff Lynch
"A BizTalk Enthusiast"


"Lee Graber [MSFT]" <leegr@microsoft.com> wrote in message
news:18yphfXXEHA.2408@cpmsftngxa10.phx.gbl...
> While there are actually some performance related reasons to put your maps
> in the receive and sendports, there are much better business reasons for
> doing it outside of your schedule. We tend to refer to mapping in receive
> and send ports as document normalization. In the case of receive ports,
you
> are normalizing the documents from the format of your customers into an
> internal standard format. On the outbound side, you are converting out of
> your normalized format and into the specific format of your trading
partner
> or internal application. If you embed the map in the schedule and the
> partner changes the format, not only do you have to rebuild the map, you
> have to rebuild the schedule to use the new version of the map. Also, what
> happens when you add a new partner with a new format. That is a new map
and
> if you have embedded the map in a schedule, it means a new schedule. This
> is exactly why we added support for multiple maps (one per source message
> type) on the receive port so that you could create a single location for
> all of your partners and easily handle normalize into your internal
> standard formats. Putting these types of maps in schedules would be a bad
> idea. There are times when it makes sense to use a map in a schedule. When
> you need to generate a new message in the schedule and use the modified
> (mapped) contents of an existing message as the base. When you want to map
> multiple parts of a message into one outbound message (this type of
mapping
> cannot be done in a receive / send port). THere are performance gains
which
> come from doing mappings in receive ports sometimes, but they are mostly
> around how many persisted messages your scenario generates and it is a bit
> complicated to explain. The actual mapping technology is the same. To keep
> your internal business logic from getting tightly couple with the document
> formats of your trading partners, you should do your document
normalization
> (mapping) in the send and receive ports.
>
> HTH
> Lee
>
> This posting is provided "AS IS" with no warranties, and confers no
rights.
>
> EBusiness Server Team
> -------------------- 
> may be of performing mapping operations within an orchestration rather
than
> in the send and receive ports that serve the orchestrations.  I have the
> option to do either (however I do need to have the orchestration to
perform
> other business processes).  Since I must already have the orchestration,
is
> there any performance advantage of mapping within the ports (or indeed
> vice-versa) performance disadvantages?  I guess I want to know whether
> these transformations (orchestration mapping vs port mapping) differ in
the
> guts of BTS2004. 
>

[ Post a follow-up to this message ]

I will get this up on my blog shortly. Scott is a good friend of mine, but
I have been encouraged to have my own blog. You can find it under
BizTalk_Core_Engine. It is just started so nothing usefull up yet, but
stuff will be coming shortly from myself and a few other core engine
developers. Hope it helps.

Lee

This posting is provided "AS IS" with no warranties, and confers no rights.

EBusiness Server Team
--------------------[vbcol=seagreen] 
<18yphfXXEHA.2408@cpmsftngxa10.phx.gbl>[vbcol=seagreen] 
cpmsftngxa06.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!tk2msftngp13
.phx.gbl[vbcol=seagreen] 
maps[vbcol=seagreen] 
receive[vbcol=seagreen] 
of[vbcol=seagreen] 
what[vbcol=seagreen] 
This[vbcol=seagreen] 
message[vbcol=seagreen] 
bad[vbcol=seagreen] 
When[vbcol=seagreen] 
map[vbcol=seagreen] 
bit[vbcol=seagreen] 
keep[vbcol=seagreen] 
document[vbcol=seagreen] 
ports[vbcol=seagreen] 
there[vbcol=seagreen] 

[ Post a follow-up to this message ]