Pluralsight and I are excited to announce another new BizTalk Server 2006 R2 course – one specifically geared toward RFID! Check it out here – http://www.pluralsight.com/courses/AppliedBizTalkRfid.aspx no public offerings schedule yet – but there should be one RSN.
So I had to fire up my XP laptop today because my new Rode Podcaster microphone (which is otherwise is totally awesome) won’t start on Vista despite getting a usbaudio.sys hotfix from MS Support (which was a suprisingly painless experience).
Anyway – cleaning out my old harddrive I found this picture:
This is a picture of the BAM portal. What I was doing was using BAM to give me some rough performance metrics between two version of an orchestration. In the “XmlDocument” version of the orchestration I was reading in a 9MB Xml file into BizTalk. In the orchestration I was passing the document to a .NET component as “XmlDocument” and reading the whole document. This is the typical example code you’ll find for reading BizTalk messages from .NET code.
In the “XmlReader” version of the orchestration – I was passing the message as XLANGMessage. This is the underlying datatype that the Orchestration compiler uses to represent a message. Only when you pass it to a .NET component as XmlDocument do they actually convert it to an XmlDocument (even if your message type on your orchestration is System.Xml.XmlDocument btw). Inside of the method my code looked something like this:
public static XmlDocument FromMsg(XLANGMessage old)
//get at the data
XmlDocument ret = new XmlDocument();
XmlReader reader = (XmlReader)old.RetrieveAs(typeof(XmlReader));
//construct new message from old
object msgid = old.GetPropertyValue(typeof(BTS.MessageID));
By calling RetrieveAs and passing typeof(XmlReader) I avoid loading the BizTalk message into a DOM – and can read the message using standard XmlReader techniques.
As you can see from the BAM metrics (which is not an absolutely high performance timing mechanism – but in this case should be close enough) the XmlDocument version took about 3xs as long as the XmlReader version. So rule of thumb – if you care about performance – use XmlReader with XLANGMessage – not XmlDocument for your .NET methods from an Orchestration.
Unfortunately the XLANGs compiler won’t allow us to return XmlReader as the return value – so for constructing we are still stuck with the DOM.
Just an update – see this post for more updated information about using XLANGMessage.
As my new friend Sam mentioned on his blog, we’ve been hanging out yesterday and today exploring Windows Workflow. Just had lunch as this excellent place – http://philadelphia.menupages.com/restaurantdetails.asp?areaid=0&restaurantid=30368&neighborhoodid=0&cuisineid=58&home=Y.
If you are in the neighborhood – let Sam know – I’m sure he’d love to take you there to get the free-range colard greens and chicken.
If you going to Philly Code Camp tomorrow – make sure to stop by his talk – http://www.phillydotnet.org/Default.aspx?tabid=589
A few people have asked me about what courses I am teaching in the near future.
Coming up in June – I’ll be teaching Pluralsight’s Applied BizTalk Server 2006 in Dallas – http://www.pluralsight.com/courses/appliedbiztalkserver2006.aspx
In July – I’ll be teaching the R2 version of the same course in Los Angeles – http://www.pluralsight.com/courses/appliedbiztalkserver2006.aspx. Come and we’ll have a big party – the course starts on my birthday!
So if you are interesting in how to integrate WCF and WF today (yes all the cool new WCF/WF stuff in Orcas is really cool – but still some number of months away) – please come to my pre-con at TechED US – https://www.msteched.com/public/precons.aspx#PRCN15 I’ll be doing it with my good friend Richard Blewett – which should be a good combination of technical learning and fun.