Wandering in the land of .NET
Flat file parsing in BTS2006 is pretty nice in general - you get a very specific error back in the error log if your incoming file is in the wrong format for the schema (or, put a more likely way, if you have buggered up creating the schema). However, this vague error stumped us for a little while: There was a failure executing the receive pipeline: "Orders.ContoFFPipeline.Con... Orders.ContoFFPipeline, Version=1.0.0.0, Culture=neutral, PublicKeyToken=d5d6f7acdeb8... Source: "Flat file disassembler" ......
Here's a braindump that I did for people with 2004 experience who are moving across to 2006. It's just a very quick run through some of the new bits and pieces to look out for. It's not complete, but it might be handy as the 50,000 ft view. It's also written with a dev audience in mind and is not necessarily the view of my employer either! (Is that enough caveats?). New Features Functionally very smilar to 2k4 - nothing like the shift in experience from 2k2 to 2k4. It's a "tidying up/more functionality" ......
Today's tip is brought to you via the BizTalk 2006 Deep Dive training course that I'm on, run by Alan Smith of the Bloggers' Guide to BizTalk fame.. In BizTalk 2004, if you wanted to create an empty output element in your target document via the mapper, you had a couple of options. You could either use a string concat functoid with one empty input parameter, or use a value mapper with 'true' and an empty string as its inputs. Bit tacky really, and in the case of a string concat also a bit slow as ......
The Solidsoft blogging community continues to grow! My colleague Richard Case has just started his blog. I know recently he's been doing some cool stuff with NAnt tasks for BizTalk deployment that have a lot of synergy with Scott Colestock's work and luckily don't overlap it too much, so check out his blog...
Ever wanted to quickly and easily try out different XPath expressions on your documents?
Just click this link!
A couple of blog entries that I wanted to highlight, but I've been a bit late blogging on (blame short-sharp-"just do this project before Christmas would you?" type work). First, I'm sure you've all seen it by now, but Scott Colestock is continuing his barnstorming work on BizTalk deployment with NAnt. Check it out. BAT files are so 1980's ;-) If you're not doing something similar in your deployments (either through your own work, or using Scott's) then you are really missing a trick. Also, a big ......
A few days ago, I blogged about splitting documents. It seems that there's a bug in BizTalk that means this approach won't work. The typical pattern when defining an envelope schema is to define your repeating node as one schema, and xs:import it to your envelope schema (for details, see Jan Tielen's excellent blog entry). Unfortunately, if you create a map that maps to your envelope schema (for example in my case because the envelope schema is also the canonical batched data format), then that map ......
An interesting scenario came up this afternoon. I receive a bunch of different documents containing address changes, which I map to my canonical "address changes" format in the receive port. I then want to split my canonical document using an envelope so that each address change record is out on its own. As far as I can see, to do this I'm going to have to write the canonicalised document out to disk, then read it back in from disk and split it in the corresponding receive pipeline. This feels awfully ......
The full list isn't up in ScottW's blog yet, but the MSDN BPI Home page lists these folks as winners: 1st: Paul Somers of London, England; BizTalk Server Management Tool entry2nd: Jesus Rodriguez; BizTalk Server UDDI Publishing Wizard3rd: Scott Colestock of Champlin, Minnesota4th: Pallavi Narayanaswamy of Bangalore, India5th: Darrin Weber of Allentown, Pennsylvania Good to see a fellow Brit at the top of the list ......
I've held off posting on the WSDL-first approach so far because I've been waiting for the tools to arrive to make my gripes go away. Well, I'm still waiting... and waiting... In the BizTalk world, we already have a Service Oriented mindset. We communicate in terms of schema-defined documents; we offer up services not APIs. We want to be interoperable with as many people as possible. I don't care whether you're using Java, .NET or ARM assembler - if you can send me a soap message, I'll talk to you. ......
Full BizTalk Server Archive