|
Home > Archive > BizTalk Server General > August 2004 > Send Port Order of Operations - Document Mapping Error 2
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 |
Send Port Order of Operations - Document Mapping Error 2
|
|
| Ben Goeltz 2004-08-18, 5:52 pm |
| This is a follow-up post to my previous post listed below.
I've done a little additional research on this issue, and have tried
adding a second receive port/location and send port which picks up the
document after it has passed through the orchestration. This receive
port/location and send port pair simply moves the message to a new
folder location, with the receive location using the XMLTransmit
pipeline, and the send port applying the same map that I have
configured on the send port which is tied to the orchestration. When
I add this step into the scenario, the message is successfully mapped.
This leads me to believe that although the message is the same when
it passes through the two send ports, the BTS message properties are
not the same (as the map is correctly applied during the second send
port, but not the first).
What BTS message property does BizTalk use to match up a map in the
map collection on a send port with the message being transmitted? I
thought it would be BTS.MessageType, but given that this property is
correctly set in the message, I'm not sure. Alternatively, is there
some promotion of BTS message properties that needs to happen for the
send port map to be successfully applied?
Original Message
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~
I have a scenario where I have an orchestration (used as a convoy to
implement FIFO) which handles multiple message types inbound and
outbound. I have created a message within the orchestration which has
a type of System.Xml.XmlDocument, which allows mutliple different
message types to be handled by the same orchestration both inbound and
outbound through the same logical ports. This seems to work well, as
I can debug the orchestration, and see that although the orchestration
message object is just a generic XmlDocument, the actual underlying
message has the correct properties (specifically, BTS.MessageType is
set to the correct BizTalk schema). I can also verify this through
HAT.
The issue arises when the message is sent from the orchestration's
logical send port to the physical send port. Within this physical
send port, I have configured multiple maps to be applied (so that each
different message type is mapped appropriately). Given that the
messages that are being passed to the physical send port have the
correct BTS.MessageType property associated with them, I assumed the
mapping would be applied correctly (i.e. the send port would be able
to interrogate the messages BTS.MessageType property, match it up with
the correct map in the maps collection of the send port, and apply
that map). Unfortunately, it appears that this is not the case.
I think what's happening is that by sending the message out of the
orchestration as a generic XmlDocument, the send port is not able to
successfully interrogate the BTS.Message property . This may be
because the message has not yet passed through the XMLTransmit
pipeline, which I believe promotes the message's properties.
What is the order of operations on a send port (i.e. does mapping
happen before the pipeline)? If the mapping does occur before the
pipeline, is there any way to allow the send port to interrogate the
message properties if an orchestration is sending it an XmlDocument
(as opposed to a message with a specific schema type)?
| |
| Ben Goeltz 2004-08-25, 5:54 pm |
| I found a work-around for my issue:
The issue was that the message coming out of the orchestration did not
have it's properties promoted (specifically, BTS.MessageType), and
therefore the send port could not apply the correct map to the
message. What I did to solve this was to create a correlation set
within my orchestration based on the BTS.MessageType property. I
initialize this correlation set on the orchestration send port, which
automatically promotes the correlation set property (BTS.MessageType,
in this case). With that property promoted, the send port was able to
apply the correct map.
bengoeltz@hotmail.com (Ben Goeltz) wrote in message news:<1282aa77.0408180807.994385b@posting.google.com>...
> This is a follow-up post to my previous post listed below.
>
> I've done a little additional research on this issue, and have tried
> adding a second receive port/location and send port which picks up the
> document after it has passed through the orchestration. This receive
> port/location and send port pair simply moves the message to a new
> folder location, with the receive location using the XMLTransmit
> pipeline, and the send port applying the same map that I have
> configured on the send port which is tied to the orchestration. When
> I add this step into the scenario, the message is successfully mapped.
> This leads me to believe that although the message is the same when
> it passes through the two send ports, the BTS message properties are
> not the same (as the map is correctly applied during the second send
> port, but not the first).
>
> What BTS message property does BizTalk use to match up a map in the
> map collection on a send port with the message being transmitted? I
> thought it would be BTS.MessageType, but given that this property is
> correctly set in the message, I'm not sure. Alternatively, is there
> some promotion of BTS message properties that needs to happen for the
> send port map to be successfully applied?
>
>
> Original Message
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~
>
> I have a scenario where I have an orchestration (used as a convoy to
> implement FIFO) which handles multiple message types inbound and
> outbound. I have created a message within the orchestration which has
> a type of System.Xml.XmlDocument, which allows mutliple different
> message types to be handled by the same orchestration both inbound and
> outbound through the same logical ports. This seems to work well, as
> I can debug the orchestration, and see that although the orchestration
> message object is just a generic XmlDocument, the actual underlying
> message has the correct properties (specifically, BTS.MessageType is
> set to the correct BizTalk schema). I can also verify this through
> HAT.
>
> The issue arises when the message is sent from the orchestration's
> logical send port to the physical send port. Within this physical
> send port, I have configured multiple maps to be applied (so that each
> different message type is mapped appropriately). Given that the
> messages that are being passed to the physical send port have the
> correct BTS.MessageType property associated with them, I assumed the
> mapping would be applied correctly (i.e. the send port would be able
> to interrogate the messages BTS.MessageType property, match it up with
> the correct map in the maps collection of the send port, and apply
> that map). Unfortunately, it appears that this is not the case.
>
> I think what's happening is that by sending the message out of the
> orchestration as a generic XmlDocument, the send port is not able to
> successfully interrogate the BTS.Message property . This may be
> because the message has not yet passed through the XMLTransmit
> pipeline, which I believe promotes the message's properties.
>
> What is the order of operations on a send port (i.e. does mapping
> happen before the pipeline)? If the mapping does occur before the
> pipeline, is there any way to allow the send port to interrogate the
> message properties if an orchestration is sending it an XmlDocument
> (as opposed to a message with a specific schema type)?
|
|
|
|
|