Reserved words in BizTalk Orchestrations - unexpected keyword

Some of you have come across the "unexpected keyword: " issue with the use of XML schemas within BizTalk, and it's fairly well posted:

• http://bencode.wordpress.com/2008/02/13/reserved-words-and-distinguished-fields/
• http://www.power-programming.co.uk/post/2009/03/05/BizTalk-Orchestration-error-unexpected-keyword-request.aspx
• http://brucetank.blogspot.com/2011/02/biztalk-xml-schema-invalid-type-name.html

This solves many things.  However, you may also find issues with parts that do not really relate to the schema itself.  See the below screenshot.

I have selected the actual xsd file within the Visual Studio Solution Explorer and took a look at the properties.  You may notice the the Namespace property of the file is BizTalk_Server_Project2.response.

This is a project-level value, as you won't see this value in the schema file itself.  So let us say we have a 'MySchemas' project and a 'MyOrchestrations' project within a BizTalk solution.  You reference the MySchemas to the MyOrchestrations.  When you compile the MySchemas, you will end up with a .NET class with the .NET namespace of the above.  You may likely now get an error when trying to build the MyOrchestrations.

Sandro Pereira eludes to the same issue in a slightly different way, but the root of the issue is the same - reserved words (whether .NET or XLANG or whatever the technology):

• https://sandroaspbiztalkblog.wordpress.com/2012/02/28/identifier-retrycount-does-not-exist-in-myprojectnamespace-are-you-missing-an-assembly/

As always, put some thought into ensuring you have unique naming conventions within your solution.

XML Schema Deep Dive

I came across this link (http://social.technet.microsoft.com/wiki/contents/articles/19692.biztalk-server-deep-dive-in-schema-design.aspx) which does a nice job of giving a deeper overview of XML schema capability and design.

Although this comes across as BizTalk-centric, my thoughts are that the overall information is W3C compliant. This means that Microsoft, in their own way (in this case, using BizTalk as the schema editor) which does try to conform to XML standards. This is a good thing, of course.  Any tool could be used, for that matter, such as Altova's XMLSpy, to develop XML schemas (.xsd file).

I've seen many developers load in an XML document and immediately using xPath to get information.  Depending on the scenario/environment, this may lead to issues that are difficult to debug, especially when working with complex (and sometimes slightly different) XML documents.  It's much better to bring in and XML document and use it as a 'type' via a schema, rather than treating it similar to a text file with 'some extra functionality'.

Also, another site (http://www.xfront.com/BestPracticesHomepage.html) which discusses some best practices...

The .NET way of changing a namespace within an XML Document

I'm on a project which receives messages and 'normalizes' the namespace of the XML message. You can do this easily in BizTalk by using the ESB pipeline components (ESB Add Namespace and ESB Remove Namespace).

If you aren't using BizTalk, you can do this in .NET as well, using the RemoveAttribute and SetAttribute methods. You may also wish to attempt the NamespaceURI.Replace method as well.

If you look closely at the documentation for the RemoveAttribute and SetAttribute link, at the bottom you will see

Therefore, changing xmlns attributes will have no affect until you save and reload the XmlDocument object.

Put a trace or watch in the Locals viewer and step through within Visual Studio debug mode. You will find out quickly that the xml document doesn't change if you try to modify the XmlDocument directly in code.

The way to accomplish this is by creating a placeholder XmlDocument variable, copy the contents of the original XmlDocument, and at then replace the namespace.  This can be done with a few lines of code:

PowerShell for BizTalk Administration: Suspended Message Counts

Continuing on with using PowerShell to help with BizTalk administration, I'd like to focus on suspended messages.

Sometimes, one of our internal departments expects a message to come in at a particular time. There are times, however, that the message was never sent to BizTalk for processing. Either way, the "I don't see an expected message, can you see if it failed?" routine is communicated our way. Keep in mind that we already have put mechanisms in place to notify if something failed... :)

At any rate, I've developed a quick PowerShell script to see if anything indeed has suspended. This one uses SQL, and it hooks into the BizTalk MessageBox Database; make sure permissions are set accordingly. This post is rather code agnostic, but the approach is to use PowerShell to be consistent with the other scripts which our group has put in place.

The query is a common, read-only script that you may have seen elsewhere:


The next step is to do the traditional SQL routine, create the SQL connection, open it, put it into a SQL adapter, and so on.


Now you have a list of all suspended messages in a typical .NET DataSet. From there we can slice and dice the information. I like sorting and grouping everything out, and PowerShell does a fantastic job of that.


The result is a list of unique BizTalk applications in your environment with a suspended message count for each application. If there aren't any suspended messages, obviously you won't have any rows in your DataSet, and you can notify your customers that everything is operating as expected in BizTalk. ;)

Interesting...

Google and Microsoft agree on something.

PowerShell for BizTalk Administration: Is this thing on? Part 3

In Part 2 I outlined getting the status of BizTalk artifacts (Recieve Locations, Send Ports, and Orchestrations) using PowerShell. All 3 of those use the same pattern. Validating the status of the Host Instances, however, can be done without using the Microsoft.BizTalk.ExplorerOM.

Looking at the Host Instances (not Hosts) at a high level, they are nothing more than a Windows Service on a server. So two ways to get information on a service via PowerShell is use use either the Win32_Process or Win32_Service objects using the PowerShell Get-WMIObject command. However, there is a unique WMI object specifically for BizTalk: MSBTS_HostInstance. I chose the last one for my script.  This does assume you have this class installed on the server you are making the call from.

Instantiating the object is a one-liner (no need to establish the SQL Server, as in the previous post).  At that point you can loop through each host instance and get the state of the Host Instances.

PowerShell for BizTalk Administration: Is this thing on? Part 2

In Part 1, the story is set up that we may need to get some information on BizTalk in a quick, detailed way.  We could certainly use the BizTalk Administration console, but I'd have to remote in to the server.  Our security model makes that a little difficult.

So the first thing I'd like to check are the Receive Locations and the Send Ports.  I want to create this in a script so I can run this at-will.  There are a few ways to do this: NotePad being the most basic, or we could download the PowerShell ISE.  But my favorite is SAPIEN PowerShell Studio.  I'm still trying to figure out why Microsoft hasn't tightly integrated this kind of functionality to Visual Studio.

So back to the scenario.  The object to use in both cases is the Microsoft.BizTalk.ExplorerOM.BtsCatalogExplorer:

You may notice the hard way that this object is a 32-bit only object.  So, if you are running in a 64-bit mode of PowerShell, your script won't run.  You will need to force 32-bit mode.  This can be done with the following:

The above two snippets are the basis of setting up both Receive Locations and Send Ports.  I'll first focus on the Send Ports.  The first thing is to instantiate an object using the BizTalk Explorer Object Model.  Once that's done, we'll need to connect to the proper BizTalk database.  After that's done, it's a simple loop to go through each Send Port:

Receive Locations are nested one level deeper than Send Ports, otherwise they are essentially the same process.

And (surprise, surprise) the Orchestration model is very similar as well.
And that's it.  Nothing incredibly complicated.  Obviously you'll want to code additional functionality (write out to a log file, for example) to tailor to your specific needs.  As a side note, a wonderful tool which helped me discover most BizTalk WMI objects is the PowerShell WMI Explorer.

Part 3 will cover Host Instances.