So, the other day, a guy asked a question on the online forums, and another guy tried
helping out by stating, among other things, that the maps on receive ports are executed
before the receive pipeline. This isn’t true, and I posted a post, where I tried to
explain how things work. This ended up being slightly wrong, so I posted a correction,
but now it seems I need to post another correction… and I ended up writing this post
to explain how stuff works.
First of all, let me set one thing straight; When a message arrives on a receive location
it is first sent through the receive pipeline that is specified on the receive location.
This is needed before the map for several reasons, including converting the input
to XML and promoting the MessageType, so the receive port can choose the correct map
to execute. The receive pipeline also promotes all the distinguished fields and promoted
properties that are specified on the schema.
Now, after the map has finished executing, the transformation engine will look up
the schema for the output and it will instantiate the XMLDisassembler with this particular
schema, so the disassembler doesn’t have to find the correct schema itself. After
instantiating it, it will call it, so the XMLDisassembler will read the output from
the map and promote all distinguished fields and promoted properties to the context
of the message. Also, before doing the promotion, it will copy all the context from
the original message, so you get all the properties from the adapter and so on copied
to the destination message.
Now, there are a couple of issues to this, which most people don’t realize – mostly
because they will only affect you on very very rare occasions:
I found that if you have an input message with a field marked as a distinguished
field and then look at the context of the output from the map, then the output message
also has the distinguished field from the input message in its context which really
doesn't make sense, since you can't use it in any way. This has NO influence at runtime
and NO influence at design time, so you will go through your life not realizing it.
Also, usually we don’t set distinguished fields on the external schemas, because we
don’t want to change them and because we don’t want to use schemas exposed to trading
partners in our business processes, which is the only place we can use the distinguished
If you have promoted a field from both input and destination schema to the
same property, the value from input schema in the properties is overwritten by the
value from the destination schema after the map. For the same reasons as for the distinguished
fields, we rarely have promoted properties on the external schemas, and therefore
you probably will never have an issue with this.
IF the schema for the destination message is marked as an envelope, the message
will fail. This is because the disassembler will recognize the schema is an envelope
and it will then debatch the message into several messages. Only the first is returned
though, since the mapping engine which is calling the disassembler assumes this is
not an envelope and therefore will only call the GetNext method once, whereas normally
the GetNext emthod is called until it returns null. This first message is then looked
at, but in the properties for the disassembler, the transformation engine has all
ready set the only allowed schema, which was the envelope schema. So the disassembler
only has the envelope schema as a possible schema, and the instance that comes out
after debatching is not the output from the map anymore, meaning that it will fail
with the standard error message “Details:"Document type "http://MyNameSpace.com#Record"
does not match any of the given schemas."” As with the first to issues about
distinguished fields and promoted properties, this should practically never happen,
since you are most likely mapping the incoming message to some internal schema, for
which there is usually no reason to mark as an envelope.
So, basically, when a message arrives, the receive pipeline is executed,
then the map is executed and at the end, the XML disassembler is executed by the transformation
engine to get all promoted fields in the destination message promoted. There are a
couple of known issues with this, but they are either totally unimportant or very
unlikely to occur.
I hope this helps someone out there.