Thursday, April 26, 2007

I built an XPath expression to extract the contents of an XML element.  I tested this XPath in a utility I created that executes the expression, and writes the results to the file system.  The XPath expression worked perfectly, and returned the contents of the XML element.  Here's a quick and dirty example ...

My XML file:

<ns0:Example xmlns:ns0="http://example/">
 <ns0:Contents>1169861</ns0:Contents>
</ns0:Example>

And my XPath expression:

/*[local-name()='Example' and namespace-uri()='http://example/']/*[local-name()='Contents' and namespace-uri()='http://example/']/text()

(Don't forget the "/text()" at the end, or you'll get the entire element!)

And, using my utility, I get the following (expected!) output:

1169861

However, when run in BizTalk 2006, I got that ever-so-annoyingly-generic error message:

Object reference not set to an instance of an object.

I confirmed that this error occured when I set my orchestration's local numeric variable equal to the the following expression in my BizTalk orchestration:

xPathExpression = "/*[local-name()='Example' and namespace-uri()='http://example/']/*[local-name()='Contents' and namespace-uri()='http://example/']/text()";

contents = xpath(msgExample, xPathExpression);

What gives?  The XPath expression works perfectly in my utility, but it doesn't in a BizTalk orchestration?  So, I decided see if I could find any help on Google.  No joke, I searched for "biztalk xpath gotcha" and found Aaron Saikovski's blog detailing this problem.  His note indicated that, in BizTalk 2004, you had to wrap your XPath expressing with string()!  It's that simple.  So, changing my XPath to the following ...

xPathExpression = "string(/*[local-name()='Example' and namespace-uri()='http://example/']/*[local-name()='Contents' and namespace-uri()='http://example/']/text())";

... saved the day!

What a fun quirk!  Thanks Aaron!

Posted on 04/26/2007 # Comments [0] Trackback
 Wednesday, April 18, 2007

So, I was having fun building some Orchestrations and Pipelines in BizTalk 2006, when all of a sudden I started getting some awful errors when I went to deploy from Visual Studio 2005.  Here are the errors I received:

Object reference not set to an instance of an object.
 
at Microsoft.BizTalk.Deployment.BizTalkAssembly.GetConnectedPorts(BtsCatalogExplorer explorer, String pipelineFullyQualifiedName)
   at Microsoft.BizTalk.Deployment.BizTalkAssembly.RemovePortsUsingPipelines()
   at Microsoft.BizTalk.Deployment.BizTalkAssembly.RemovePipelines()
   at Microsoft.BizTalk.Deployment.BizTalkAssembly.Remove()
   at Microsoft.BizTalk.Deployment.BizTalkAssembly.RemoveNamedModule(String server, String database, String assemblyName, String assemblyVersion, String assemblyCulture, String assemblyPublicKeyToken, ApplicationLog log)
 
Unspecified exception: "Object reference not set to an instance of an object."

Failed to add resource(s). Change requests failed for some resources. BizTalkAssemblyResourceManager failed to complete end type change request. Object reference not set to an instance of an object. 

All I did was update a pipeline that was used by an Orchestration!  I tried all kinds of things to get this to work: restarted host instances, restarted the Enterprise Single Sign-On service, performed a full stop on all my applications, and even deleted all my project assemblies from the GAC.  Nothing worked except for rebooting.

That is, nothing worked until I decided to actually delete the pipeline from BizTalk application.   Once I manually deleted the pipeline, my deployments started working again.

Very strange behavior!

If anyone can explain to me why BizTalk behaves this way, I would greatly appreciate it.

Posted on 04/18/2007 # Comments [1] Trackback
 Thursday, April 05, 2007

I have started hosting this blog in a new location.  Unfortunately there were some routing issues, and I think the blog was down for about two or three hours.  Those problem has been corrected, and it shouldn't happen again (who would have guessed that the network adapter was defaulted to turn off when not being used).

Hey!  I'm a software developer, not a systems guru!

Posted on 04/06/2007 # Comments [0] Trackback
 Tuesday, April 03, 2007

It's often nice, while working with BizTalk (or any other MS product, for that matter) to have UDL files available to allow you to quickly setup your connections to various databases.  A UDL file is essentially a file that saves connection information, making it available for future use.

To create a UDL file, follow these steps:

  1. Open a folder (or use the desktop) and create a new text file (right-click --> New --> Text Document).
  2. Rename the extension from ".txt" to ".udl".  Ignore the warning message.
  3. Double-click the new UDL file.
  4. Configure your database connection settings.

  5. Once you've been able to successfully test your connection, click the OK button.

That's it!  It's that simple!  Now your UDL file is available for future use.

Best of luck!

Posted on 04/04/2007 # Comments [4] Trackback