Monthly Archives: May 2012

Debug Tracing in BizTalk Orchestrations and Custom C# Components

It’s not immediately obvious how you can debug code in BizTalk orchestrations, custom pipelines, custom fuctoids etc. After investigating a couple of options I found the easiest way is to use a tool called Debugview which is a simple executable (no installation required) supplied by Microsoft for free.

  1. Download the executable and install it on the desktop or somewhere else thats easy to get to
  2. In an orchestration enter the following code in either a Message Assignment or Expression shape with whatever you want to
    System.Diagnostics.Trace.WriteLine(System.String.Format("Message content is - {0}",msgMyEmployees.OuterXml));
    
  3. Or in c# you can write the same code in your custom functoid or custom pipeline
  4. Deploy / GAC / Restart host instances as usual then kick off DbgView.exe .
  5. Ensure Capture Win32 Capture Global Win32 are all checked under the capture menu
  6. Click on Capture (the magnifying glass)
  7. Run your test case through BizTalk and the output will be printed to the window. Nice and easy.

Where to Store BizTalk Environment Variables

Something that wasn’t immediate obvious when I began developing BizTalk applications was where to store my environment variables such as database URLs and web service URLs for custom functoids, passwords for authentication with other systems etc. 

SSO Storage. Having tried all the options below, my recommendation is to put them in the SSO storage by creating a custom library and custom functoid to make them easily accessible from maps and orchestrations. It may seem like hard work but it isn’t as bad as it looks and is definitely worht the effort.

First of all download the SSO snapin from Microsoft (seems odd this isn’t bundled with BizTalk) and set up your applications and variale key pairs. Note you will need to be in the BizTalk SSO Administrators AD group.

Then create a new library in your CommonArtifacts solution which will allow you to access SSO variables very easily. Use the SSOClient in the download from Microsoft as a guide for doing this. At the same time it is worth creating a custom fucnctoid which uses this new library so configuration viariables are also easily accessible from maps.

There is a great tutorial from Richard Seroter which explains how to do this in more detail.

BizTalk Configuration File. In my i initial applications I put environment variables in D:\Program Files\Microsoft BizTalk Server 2010\BTSNTSvc.exe.config (BTSNTSvc64.exe.config for 64bit installations) under the appsettings tag. I would access them by simply entering the following code into my orchestration and maps.

public string GetConfigString()
{
string connString=System.Configuration.ConfigurationSettings.AppSettings.Get("MyDatabaseConnectString").ToString();
return connString;
}

It became clear fairly quickly however that there were major drawbacks to this approach

  • You had to restart the host instances for any changes to take effect
  • Everything was unencrypted
  • You had to change a separate dev.config file for the changes to work in the BizTalk test map tool in Visual Studio

A custom Database Table is another option for handling environment variables and may occasionally be suitable for storing setings. But of course the URL to theis database will need to be stored somewhere anyway and variables are not encrypted by default.

The Business Rules Engine should be used when complex rules which are likely to change are required to drive mappings and workflow. I’m still not a huge fan of the BRE but perhaps I am just not using it in the way it is intended just yet.

BizTalk Project Structure Guidelines

When I first started developing in BizTalk 2010 I couldn’t find any definitive articles about how best to organise my solutions and projects in visual studio. I started with one solution for an individual project with individual projects containing all the artifacts for a specific area. I soon got into trouble with dependencies throwing errors on deployment and the end result was generally a bit of a mess.

Here are my recommendations on how to organise a BizTalk solution in Visual Studio.

Separate your solution with individual projects for each type of BizTalk artifact as follows.

  • Schemas
  • Transforms
  • Orchestrations
  • Pipelines
  • Components (c# project for any custom objects)

Create your first project as <CompanyName>.<FunctionalArea>.Schemas and the solution as <CompanyName>.<FunctionalArea>. for example “MyCompany.Sales.Schemas”. This solution should contain all artifacts with interfaces either publishing from your sales system into the BizTalk message box or subscribing to messages in the BizTalk message box.

Also create another solution called <CompanyName>.CommonArtifacts with projects containing the canonical form for each schema. e.g. <CompanyName>.CommonArtifacts.Schemas.Customer might contain the Customer.xsd which would then be referenced by all the other solutions which subscribed to this message type. The advantage of having a separate project for each canonical form is that you create less dependencies so if one schema changes then you don’t have to update so many other solutions and can deploy the new schema in isolation.

When you create your new project, the first thing you will want to do is set up your default namespace. My recommendation is that you keep it simple, e.g. <CompanyName>.BizTalk.<FunctionalArea>.<BTArtifactType>. e.g. MyCompany.BizTalk.Sales.Schemas. Also set your project name in the deployment options, usually the same as the Solution name you chose. You will also need to generate a key.

An advantage of using this structure is that it provides a standardised order for all your frameworks and also enables you to deploy .dll individually should you need to, for example if there is only a minor change to a map and you don’t want to have to redeploy everything. It also makes your solution compatible with the excellent BizTalk deployment framework available on Codeplex.