Developing custom tools for BizTalk

by | Dec 14, 2009 | BizTalk Community Blogs via Syndication

For the last four months I’ve been developing a benchmarking tool for BizTalk which is going to be released soon. However, I thought I’d share some of the pain you might run into while developing custom tooling for BizTalk.

The problem lies with communicating with BizTalk, where you’re pretty much left with two options; Microsoft.BizTalk.ExplorerOM (EOM) or WMI. First of all, each option is suitable for different purposes. If you want to manage ports and applications, ExplorerOM would be your best bet, where as if you’d like to manage hosts, host instances or handlers, WMI would be your only option.

The problem I ran into, is that neither one of these works if you are not running this from a BizTalk Server, which in some cases is not preferred.

The problem occurs where the user tries to start a port from the custom application and therefore needs to commit using the SaveChanges operation (EOM). In the worst scenario, the user is running the app from a server/desktop where BizTalk is not installed. BizTalk and SQL are installed on separate boxes.

Using EOM won’t work as it throws an “Object reference not set to an instance of an object” exception (see code below). This is because EOM require BizTalk to be installed on the same box, even though it doesn’t necessarily need to be part of the group you’re trying to connect to.   

 

static void Main(string[] args)
{
    Console.WriteLine("Server name?");
    string server = Console.ReadLine();

    BtsCatalogExplorer explorer = new BtsCatalogExplorer();
    explorer.ConnectionString = new SqlConnectionStringBuilder()
    {
        DataSource = server,
        InitialCatalog = "BizTalkMgmtDb",
        IntegratedSecurity = true
    }.ConnectionString;

    Console.WriteLine("Connected..."); // This works!

    try
    {
        explorer.SaveChanges(); // This fails!
        Console.WriteLine("SaveChanges were executed without exceptions.");
    }
    catch (Exception ex)
    {
        Console.WriteLine("An error occurd...");
        Console.WriteLine(ex.Message);
    }
    Console.WriteLine("\nPress any key to close...");
    Console.ReadKey();
}

 

Using WMI won’t work because of the  “double-hop authentication issue”, where credentials will be lost on the second jump (to SQL). This will result in a “Anonymous user does not have access blah blah blah” – SQL exception. http://www.microsoft.com/technet/scriptcenter/resources/wmifaq.mspx#EXLAC

I’d really like to see the product team to ship BizTalk with a Management Application, exposing services for the most common tasks.

The Microsoft Application Platform in association with Technet: Connecting business applications, partners and devices

by | Dec 13, 2009 | BizTalk Community Blogs via Syndication

Just wanted to put the word out about the following event at TVP in Febuary. Looks like the content includes a few companies who have spoke previously at SBUG events so it should be interesting to see how these projects have evolved.

To get more details please refer to:

http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032436355&Culture=en-GB

Checking if BizTalk binding file is up-to date during deployment

Checking if BizTalk binding file is up-to date during deployment

by | Dec 11, 2009 | BizTalk Community Blogs via Syndication

As all of you know the number one time consuming task in BizTalk is deployment. How many times have you worked your way through the steps below (and even more interesting – how much time have you spent on them …)

  • Build

  • Create application

  • Deploy schemas

  • Deploy transformations

  • Deploy orchestration

  • Deploy components

  • Deploy pipelines

  • Deploy web services

  • Create the external databases

  • Change config settings

  • GAC libraries

  • Apply bindings on applications

  • Bounce the host instances

  • Send test messages

  • Etc, etc …

Not only is this time consuming it’s also drop dead boring and therefore also very prone – small mistakes that takes ages to find and fix.

The good news is however that the steps are quite easy to script. We use a combination of a couple of different open-source MsBuild libraries (like this and this) and have created our own little build framework. There is however the BizTalk Deployment Framework by Scott Colescott and Thomas F. Abraham that looks great and is very similar to what we have (ok, ok, it’s a bit more polished …).

Binding files problem

Keeping the binding files in a source control system is of course a super-important part of the whole build concept. If something goes wrong and you need to roll back, or even rebuild the whole solution, having the right version of the binding file is critical.

A problem is however that if someone has done changes to the configuration via the administration console and missed to export these binding to source control we’ll deploy an old version of the binding when redeploying. This can be a huge problem when for example addresses etc have changed on ports and we redeploy old configurations.

What!? If fixed that configuration issue in production last week and now it back …

So how can we reassure that the binding file is up-to-date when deploying?

One solution is to do and export of the current binding file and compare that to one we’re about to deploy in a “pre-deploy”-step using a custom MsBuild target.

Custom build task

Custom build task in MsBuild are easy, a good explanation of how to write one can be found here. The custom task below does the following.

  1. Require a path to the binding file being deployed.

  2. Require a path to the old deployed binding file to compare against.

  3. Using a regular expression to strip out the time stamp in the files as this is the time the file was exported and that will otherwise differ between the files.

  4. Compare the content of the files and return a boolean saying if they are equal or not.

     public class CompareBindingFiles : Task
 {
     string _bindingFileToInstallPath;
     string _bindingFileDeployedPath;
     bool _value = false; 

     [Required]
     public string BindingFileToInstallPath
     {
         get { return _bindingFileToInstallPath; }
         set { _bindingFileToInstallPath = value; }
     } 

     [Required]
     public string BindingFileDeployedPath
     {
         get { return _bindingFileDeployedPath; }
         set { _bindingFileDeployedPath = value; }
     } 

     [Output]
     public bool Value
     {
         get { return _value; }
         set { _value = value; } 

     } 

     public override bool Execute()
     {
         _value = GetStrippedXmlContent(_bindingFileDeployedPath).Equals(GetStrippedXmlContent(_bindingFileToInstallPath));
         return true; //successful
     } 

     private string GetStrippedXmlContent(string path)
     {
         StreamReader reader = new StreamReader(path);
         string content = reader.ReadToEnd();
         Regex pattern = new Regex("<Timestamp>.*</Timestamp>");
         return pattern.Replace(content, string.Empty);
     } 

 }

Using the build task in MsBuild

After compiling the task above when have to reference the dll in element like below.

<UsingTask AssemblyFile="My.Shared.MSBuildTasks.dll" TaskName="My.Shared.MSBuildTasks.CompareBindingFiles"/>

We can then do the following in out build script!

<!--
    This target will export the current binding file, save as a temporary biding file and use a custom target to compare the exported file against the one we’re about to deploy.
    A boolean value will be returned as IsValidBindingFile telling us if they are equal of not.
-->
<Target Name="IsValidBindingFile" Condition="$(ApplicationExists)=='True'">
    <Message Text="Comparing binding file to the one deployed"/> 

    <Exec Command='BTSTask ExportBindings /ApplicationName:$(ApplicationName) "/Destination:Temp_$(BindingFile)"'/> 

    <CompareBindingFiles BindingFileToInstallPath="$(BindingFile)"
                         BindingFileDeployedPath="Temp_$(BindingFile)">
        <Output TaskParameter="Value" PropertyName="IsValidBindingFile" />
    </CompareBindingFiles> 

    <Message Text="Binding files is equal: $(IsValidBindingFile)" /> 

</Target>

<!--
    This pre-build step runs only if the application exists from before. If so it will check if the binding file we try to deploy is equal to one deployed. If not this step will break the build.
-->
<Target Name="PreBuild" Condition="$(ApplicationExists)=='True'" DependsOnTargets="ApplicationExists;IsValidBindingFile">
    <!--We'll break the build if the deployed binding files doesn't match the one being deployed-->
    <Error Condition="$(IsValidBindingFile) == 'False'" Text="Binding files is not equal to deployed" /> 

<!--All other pre-build steps goes here-->

</Target>

So we now break the build if the binding file being deployed aren’t up-to-date!

This is far from rocket science but can potentially save you from making some stupid mistakes.

BizTalk Server 2009 R2 Technology Adoption Program (TAP) Enrollment

by | Dec 9, 2009 | BizTalk Community Blogs via Syndication

The BizTalk 2009 R2 Technology Adoption Program (TAP) is now open for enrollment.

The goal of the TAP is to get critical feedback on feature capabilities and product quality that will be used to determine when BizTalk Server 2009 R2 is ready to ship. 

The TAP Benefits

Customers that join the TAP get access to a range of resources and benefits to help make this happen as follows:

Program Management

  • Assigned Microsoft program manager from the product team
  • Weekly conference calls with participants’ project teams

Product Training

  • Provide early access to product documentation and training resources
  • Invitation to attend monthly webcasts from the product team on specific areas of the product
  • Issue Escalation and Resolution
  • Highest level of Technical Support dedicated to supporting your production environment
  • Ability to request and receive quick fixes to approved builds for project blocking issues

Early Access to BizTalk Server 2009 R2 Builds

  • Key milestones and interim builds

The TAP Requirements

The Program is designed to bring together the Microsoft engineering team and customer’s project team to drive a BizTalk Server 2009 R2 project into production prior to general release of the product. 

We are interested in working with organizations who want to evaluate BizTalk Server 2009 R2 and commit to providing bug reports and feature feedback.

Product Use and Deployment

  • Participants must have a project that is related to a specific business need and has appropriate senior level support and funding. This project will rely on BizTalk Server 2009 R2
  • Participants who are selected into the “production deployment” pool will commit to going into production within 45 days prior to product release date
  • Participants must have schedule flexibility

Project Team and Readiness

  • Assign Project Manager and suitable project staff as necessary
  • Team will participate in weekly conference calls with an assigned Microsoft Project Manager
  • Team will log product bugs and verify bug fixes

Documentation Requirements

Participants must accept and sign the following agreements that will be provided if the nomination is accepted:

  • Master TAP Agreement
  • Agree to Program Description
  • Supplemental  End User License Agreement
  • Non Disclosure Agreement

How to Submit a Nomination

If your organization is interested in joining the TAP, please use the link below to complete the nomination form, you will need to be signed in with a valid Windows Live ID to see the form.  You will be contacted by the Microsoft TAP program team within 2 weeks of your submission.

https://connect.microsoft.com/BizTalk/Downloads/DownloadDetails.aspx?DownloadID=22333

Questions

If you have any questions about the BizTalk Server 2009 R2 TAP program, please don’t hesitate to email us at: [email protected]

Technorati Tags: BizTalk,TAP,BizTalk Server 2009 R2