BizTalk Server 2006: Using .NET Classes for Orchestration Message Types
BizTalk allows serialisable .NET classes to be used as message types in BizTalk orchestrations. You can use tools such as XSD.exe to generate XML-Serialisable classes, or use the BinaryFormatter, or your own custom formatter, to perform serialisation and de-serialisation.
The may be benefits in some cases in using .NET classes as opposed to XSD types for BizTalk orchestration messages. Here are some potential reasons:-
- Allow orchestrations to directly process any message content type, including non-XML. Converting non-XML content to XML is a more common approach (supported, for example, by the FlatFile Disassembler) but custom classes are the only viable approach in some situations.
- 'Smart' messages. You can build message-specific business logic into your message types. You would typically do this as an alternative to handing off your orchestration code to external ‘helper’ code. This approach is more object-orientated and structured. There are lots of potential uses, including efficient message validation, cleansing, enrichment, transformation etc. Of course, this overlaps with what you might do with maps, functoids etc., and there are some obvious pros and cons here. Maps may be more maintainable and easier to change, but may be less efficient and, in some cases, harder to code.
- Easier message construction. If you are constructing messages in an orchestration, they can sometimes be easier to build than using XML. You can implement Factory design patterns on your .NET classes for this purpose.
- Easier to handle in the Rules Engine. It is fundamentally easier, and generally more efficient, to assert .NET objects as facts instead of XML documents in the Microsoft BRE. For orchestrations that make heavy use of the BRE, this can be beneficial.
- With help, messages can be easier and more efficient to enumerate. If your orchestration does a lot of looping through message content, then you can fairly easily build dehydration-safe enumeration into your classes (just call .MoveNext() in the 'while' condition of your loop). However, note the following:-
a) You generally have to enumerate variables rather than messages - i.e., first assign your message to a variable of the same .NET type. This is because, assuming you are using XML-serialisable classes for your message types, BizTalk will use the XML Serialiser to serialise the orchestration messages, but will use the BinaryFormatter to serialise your orchestration variables. Unless you are willing to add additional elements/attributes to your XML schema in order to support the serialisation of enumeration state, you will want BizTalk to use the BinaryFormatter to serialise all the state for your .NET-based messages.
b) It is easy to implement dehydration-safe enumeration. It is easy to implement thread-safe enumeration. It is rather harder to implement both together! However, it can be done. Microsoft-supplied .NET enumerators are not thread safe. There are situations in BizTalk orchestration where thread safe enumeration can be very useful, although you can generally avoid this with care.
c) If you find that your orchestration is doing a lot of enumeration over messages/objects with loops inside loops, and loops that span parent and child orchestrations, and especially if you are doing row-by-row validation and/or generating new message content within these loops, this may indicate that your logic would be better off implemented in a forward-chaining rules engine. This is a big subject, and if you are not familiar with forward-chaining engines such as the Microsoft BRE, then clearly it may be difficult to make this call. However, you should be aware of your options.
If you use XSD.exe (or some equivalent) and partial classes to create XML-serialisable .NET classes, you will find that there is fairly smooth two-way compatibility between the worlds of XSD and .NET orchestration message types. You often may need both XSD schemas and.NET classes for the same message type, and so may need to use custom pipelines to configure the XMLDisassember to select the XSD schema class.
If you want to pass an XML-serialisable .NET message through a Transform, you will need to assign it to an equivalent XSD-based orchestration message first.
There appears to be a 'bug' in the current version of Visual Studio 2005 which sometimes prevents the redeployment of BizTalk projects after a recompile of non-BizTalk code contained in the same solution. Visual Studio displays a spurious compile-time error claiming that an attempt is being made to use a non-Xml serialisable message type on an orchestration port. If you simply close and re-start Visual Studio, you can compile and re-deploy your BizTalk application. The problem appears to be preventable by placing all non-BizTalk code in a different solution. It does not appear to be related to the use of partial classes, and is not due to the common mistakes made when creating Xml serialisable classes (e.g., the lack of a default constructor). Because of this problem, it is probably better to always Receive and Send messages in orchestrations using an XSD-based message type, and then assign messages internally to a corresponding .NET message or variable for processing. This was the only practical approach in the original release of BTS 2004. In that case, there was a bug (fixed in SP1) which mean that subscriptions were not created correctly by orchestration Receive ports when using XML-serialisable .NET classes.
Source: BizTalk Server 2006: Using .NET Classes for Orchestration Message Types
