BizTalk Health Monitor - Using Older Versions of BizTalk

BizTalk 2013 R2 was just released not long ago.  One of the new tools that comes with BizTalk 2013 R2 is the BizTalk Health Monitor:

To review:
http://blogs.msdn.com/b/biztalkhealthmonitor/archive/2014/06/26/overview-of-biztalk-health-monitor-bhm.aspx

And http://blogs.technet.com/b/jpierauc/archive/2014/06/26/quot-biztalk-health-monitor-quot-now-available-in-biztalk-2013-r2.aspx

And  http://blog.jeroenmaes.eu/2014/06/biztalk-health-monitor-new-feature-in-biztalk-2013-r2/

To install:
http://blog.jeroenmaes.eu/2014/06/enable-biztalk-health-monitor-biztalk-2013-r2/

In a nutshell, the BHM incorporates:

• Integration of the MessageBox Viewer tool
• Performance analysis thanks to integrated PerfMon
• Easy SQL Job Status monitoring
• Automatic Archiving of Health reports

Finally, some consolidation of common BizTalk tools (and a few other things as well)…

If you look at the second link from above, you will notice the following:

“Note that BHM will work also with previous versions of BizTalk targeting any versions of BizTalk groups since BizTalk 2004 ;-) “

Cool…  So of course I had to try it against my BizTalk 2010 instance (using the last link for install instructions).  And... it works!

I downloaded the BizTalk 2013 R2 iso file via MSDN.

Update:  The BHM is now available as a separate download.  See http://blogs.msdn.com/b/biztalkhealthmonitor.

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.