YABB!
Yet Another BizTalk Blog

True Stories of the XSD Editor

An encounter with validation errors for a schema instance requires a strange (but not surprising) refresh of sorts...

Neuron ESB vs. Microsoft ESB Guidance: A Quick Comparison

At the SOA and BPM Conference in Redmond last week Neudesic had a booth that discussed their Neuron ESB product. At the same time, Marty Wasznicky was wrapping up the final release of the ESB Guidance for BizTalk, accompanied by several presentations discussing what it was, how it works, etc.. It should be noted that Neudesic consultants (along with other Microsoft partners) helped build the ESB Guidance effort with Marty.

So what's the difference?

The key fundamental difference is that the Neuron ESB plugs into, but does not reside within, BizTalk Server. For those that haven't yet made the plunge into purchasing BizTalk licenses but looking to reap the benefits of SOA, this could be a great start.

Other than that, however, they provide strikingly similar functionality. The Neuron platform is .NET-based and leverages WCF, SQL Server, MSMQ and WMI. The two packages provide pretty similar functionality: intelligent routing, mediation, SLA awareness, monitoring, endpoint management and, of course, EAI and integration. Here's a snippet out of their documentation:

Neudesic Neuron ESB

For a deeper technical dive, I suggest getting contacting Neudesic or a Microsoft partner for more info.

(Disclaimer: I am not a Neudesic employee)

Best Little XPath Reference

I recently found myself in a bind trying to get a useful XPath function for the xpath() function (BizTalk developers, you know what I'm talking about) that would help me logically identify the existence of an element in a schema instance (otherwise known as an Xml document). The documentation (or at least my hard-copy version does?) states:

"For more information on the xpath function, see third-party documentation on the XML Path Language (XPath)."

So, I fired up my favorite search engine and did a quick search for some quick & dirty documentation. Lo and behold, I found what I was looking for on a site called refcards.com had one that works quite nicely. Not a big fan of the site overall - all links go to Google, which seems to pay them more than give you any meaningful information - but otherwise, the reference PDF provided makes for great hard-copy to paper your cubicle with. I was back to logic testing for empty Xml nodes in no time!

More on what I was building another time.

Error X2289 - A Port Binding Error

I ran into this error while undergoing a renaming effort in a project of mine, and in my haste I could not understand what this error meant, or why I was getting it. Specifically, it looked like this (incriminating names relegated to %n notation):

D:\ BTPROJECTS\ <ProjectFolder>\ <BizTalkServiceName>\ <OrchestrationName>.odx(471,49): error X2289: '%1': must be a port in service '%2' of polarity 'uses' and with porttype '%3'.

Whenever I start building a BizTalk project, I have a habit of renaming things. A lot. I constantly look for ways to improve the naming conventions of every artifact that makes up a BizTalk project in order for everything to make sense to whoever might look at it next. My philosophy: if the inevitable BizTalk novice comes to pick up where I left off in a project, and they can intuitively 'see' my intent through a well-organized, well-named project layout, it means less questions are asked, and subsequently, more work is done - and that I've laid a good foundation for them to build upon. But I digress...

Long story short - I have a port set up in my orchestration as a partner direct bound port, so it's binding to itself. When I renamed my port, the binding information did not update, so the binding configuration was invalid and caused this error.

To fix, simply go to your port configuration and select the 'correct' (or newly-renamed) port. This error should easily disappear.

For more information about partner direct bound ports (and an excellent collection of blog postings on port bindings in general), please visit Ken Lam's excellent blog site here.