Friday, August 20, 2010

Using Notepad after Schema Changes

Often I want to make changes to a schema that I'm using in BizTalk. Typically I will change a node name (or two), or I'll change the namespace.

That will break any maps that reference the schema, and I'll sometimes get error messages if I compile an orchestration that uses the schema. Even worse, if I have some xpath expression in an orchestration, I may not figure that out that it's broken until run time.

I end up using a simple text editor like notepad to edit the map file(s) and orchestration file(s) directly, so I won't have to track down all of the usages of the changed node (or namespace) in the schema. I can just use simple search and replace (although I do check each replace instance before I actually do it). I don't work much with other BizTalk people these days, so I don't know if my approach is common...

Tuesday, August 10, 2010

BizTalk Error "...is an invalid XPath expression..." when using Table Looping functoid

I was building a BizTalk map today that uses a Table Looping functoid. It's been a while since I have used that functoid, and I thought I had everything setup fairly well. I went to test the map, and here's an error that I saw. The names have been changed to protect the innocent:
C:\dev\Acme Development\BizTalk\Code\Acme.Customer\Acme.Customer.Maps\TestCases_FF_to_TestCase.btm: 
error btm1050: XSL transform error: Unable to write output instance to the following
. XSLT compile error at (55,45). See InnerException for details.
'userCSharp:ConvertToXsDateTime(string($var:))' is an invalid XPath expression.
userCSharp:ConvertToXsDateTime(string($var:))' has an invalid qualified name.

ConvertToXsDateTime() is a function that I put inside of a scripting functoid, and one of the Table Extractor functoids feeds into it.

The issue was that I forgot to drag the output of the Table Looping functoid directly to the node I want to repeat. The output of the Table Looping functoid tells the map how many of the destination node it should produce.

I figured this out by changing the output of the Table Extractor functoids to feed directly into the destination field (instead of into my Scripting functoid), and observing that running the test didn't produce any useful output.

I want to record this here in my blog, since I've seen this error before, and I likely will again.