Promoting values from destination schema of map on receive port

by eliasen 10. June 2009 23:30

Hi all

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:

Distinguished fields
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 fields.

Promoted Properties
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.

Envelopes
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.

Conclusion
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.

--
eliasen

Tags:

Comments (7) -

Thiago
6/11/2009 8:39:14 PM #

Eliasen,

This is so timely it's unreal. I was just investigating what happens to promoted properties on messages after the map runs. Saved me a couple of hours!

Regards,
Thiago Almeida

Reply

Jan Eliasen
Jan Eliasen
6/12/2009 7:14:57 PM #

Well... I aim to please Smile

Reply

Richard
Richard
6/12/2009 7:49:27 PM #

Great job summarizing this.

Reply

Jan Eliasen
Jan Eliasen
6/12/2009 8:14:58 PM #

Thanks, Richard.

Reply

Kiran
Kiran
5/28/2010 7:09:52 PM #

You are saying the XML disassembler get called twice..Once when the incoming message flows thru the pipeline and then again after the   mapping  is done ? ..I also think ..I have this envelope schema problem as described below..

Incoming File I am grouping using a custom XSLT

In the Receive Port  I am doing this
                  Incoming File  -------CustomXSLT  at REcieve port ---- > Into a grouped XML (which is envelope schema)
I thought  it will never  try to execute the  de-batching based on envelope because the Map gets executed after the dissembler..Looks like if the output of the map is an envelope dissaembler springs into action again and try to debatch it based on the envelope  but as per ur explanation it fails because its not looping ...

Reply

Kiran
Kiran
5/28/2010 7:10:55 PM #

Reply

Jan Eliasen
Jan Eliasen
5/30/2010 9:17:58 PM #

Hi Kiran.

Yes, that will definately fail. You can get around it by not marking the schema for the grouped XML as an envelope.

--
eliasen

Reply

Add comment

  Country flag

biuquote
  • Comment
  • Preview
Loading

About the author

Jan Eliasen is 37 years old, divorced and has 2 sons, Andreas (July 2004) and Emil (July 2006).

Jan has a masters degree in computer science and is currently employed at Logica Denmark as an IT architect.

Jan is a 6 times Microsoft MVP in BizTalk Server (not currently an MVP) and proud co-author of the BizTalk 2010 Unleashed book.

BizTalk Server 2010 Unleashed


Buy from Amazon

Microsoft MVP


6 times: July 2004, July 2008, July 2009, July 2010, July 2011, and July 2012. Not currently an MVP.

MCTS

Image to show

Month List

Page List