Ok, so these aren’t entirely compiler hints, but interesting nonetheless:
1. Re-Ordering of Catch Clauses
The compiler will throw the following warning if you catch specific exceptions after a general exception block:
Orchestraion.odx(653,17): warning X4001: automatically re-ordering catch clauses from specific to general
I’m surprised that this doesn’t throw an error as including a General catch block as the first ‘catch’ is bad practice: the first catch clause that specifies the exception type is considered a match and a general catch clause is considered a match for any exception type – if you have a General catch block as the first block, this will catch all exceptions, irrespective of type, possibly giving unexpected results.
2. Number of Correlation Properties in a Convoy Set
So this one isn’t a compiler warning (but maybe it should) – the maximum number of properties used in a Correlation Type for a Convoy is limited to three! When you try and enlist an orchestration that employs a Convoy pattern where there are more than three properties in the correlation, you will receive a warning:
The maximum number of convoy set properties has been exceeded. A convoy set can only contain up to 3 properties.
3. The Xml Disassembler will not Promote Properties in Debatched Messages
This one was a bit of a show-stopper for me earlier this week. Suppose you have an envelope schema that is used to debatch messages and you need to promote properties fromthe debatched schemas into the context of those individual messages – it would appear that properties will not be promoted into the debatched messages. Yikes!
I need to do some more investigation on this, but I’m presuming its something to do with the same XML disassembler issues Charles Young wrote about back in October 2004!
Update #1: I’ve just read this article on MSDN and two points have jumped out at me (my emphasis):
The disassembler component parses each document within the envelope. For each document, the BizTalk message object is created with its own context where all the properties promoted from the envelope and from the document itself get copied.
and:
The XML Disassembler only processes data in the body part of the message. Thus, only properties from body part can be promoted.
Again, I need to check this out, but what I think I’m reading here is that if the document schema and property promotions on that document schema are defined in the envelope schema (bear with me here….) and the document schema itself is referenced from the envelope schema, we should get promoted properties! I’ll try this out tomorrow….
Update #2: Ok, so this is possible and as usual, the god to all things BizTalk – Mr Richard Seroter – blogged about it two and a bit years ago! I’m normally just a year behind you Richard, but this is just embarassing ;-)
Nick Heppleston's BizTalk Blog 