BizTalk 2010: Deploying and Undeploying EDI Parties with the BizTalk Deployment Framework

By jpsmit
April 19, 2013
1

I’m a big fan of the BizTalk deployment framework, because it makes deployment so easy, repeatable and reliable because it automates a lot of manual actions.

In my current project I’m working with EDI, so I also have to work with parties and agreements. Of course I wanted to embed this in the deployment framework.

Deploying is pretty easy, because the party and agreement information is part of the binding.

But if an application with party and agreement information already has been deployed, how do you undeploy this? Especially because you cannot delete an application if the party information still is there. If you try to do this, you’ll run into this cryptic error:

 

It is trying to say you cannot delete the application as long as the party information is present…..

After some research I found out how to automate this and I decided to dedicate a blog post to it. Also because other people had the same question, see http://biztalkdeployment.codeplex.com/discussions/256406 and http://biztalkdeployment.codeplex.com/discussions/275140.

Fortunately there is a tool in the SDK capable of deleting parties, which can be found at this location in the BizTalk install folder:

C:Program Files (x86)Microsoft BizTalk Server 2010SDKSamplesAdminExplorerOMDeleteParty

Like almost any admin tool it is utilizing the BizTalk Explorer object model (ExplorerOM) to do the trick. You won’t find the exe there. It is an uncompiled project and that gives you the opportunity to adjust the implementation to your needs. This is necessary because the tool needs to access the BizTalkMgmtDB and assumes it is installed on the server running the tool. On a production environment this often isn’t the case and since this tool is part of deploy/undeploy it will run on the BizTalk server. Another improvement I made is to let the tool undeploy multiple parties in one call, something the out-of-the box implementation also isn’t capable of.

So after the mentioned changes, my code looks like this and I can build the solution to create the DeleteParty.exe tool.

using System;

using System.Windows.Forms;

using Microsoft.BizTalk.ExplorerOM;

 

namespace Microsoft.Samples.BizTalk.ExplorerOM.DeleteParty

{

/// <summary>

/// DeletePartyClass is the wapper class for the Main function.

/// </summary>

class DeletePartyClass

{

/// <summary>

/// The main entry point for the application.

/// The only argument should be the name of the party to delete.

/// </summary>

[STAThread]

static void Main(string[] args)

{

// Handle the command-line arguments and switches

if (args.Length != 2)

{

PrintUsage();

return;

}

if ((“/?” == args[0]) || (“-?” == args[0]))

{

PrintUsage();

return;

}

 

// Create the root object and set the connection string

BtsCatalogExplorer catalog = new BtsCatalogExplorer();

catalog.ConnectionString = string.Format(“SERVER={0};DATABASE={1};Integrated Security=SSPI”, args[0], “BizTalkMgmtDB”);

 

try

{

// Split the party information, we might need to remove multiple

string[] parties = args[1].Split(‘,’);

 

foreach (string pty in parties)

{

// Get the requested party from the collection

Party party = catalog.Parties[pty];

if (null == party)

{

Console.WriteLine(“Party named “ + pty + ” was not found.”);

continue;

}

 

Console.WriteLine(“Deleting party: “ + party.Name);

 

// Remove the party

catalog.RemoveParty(party);

 

// commit the changes

catalog.SaveChanges();

 

Console.WriteLine(“Party deleted.”);

}

}

catch (ConstraintException ce)

{

// Any changes need to be reverted

// when there is an error

catalog.DiscardChanges();

 

// Since this is a common configuration exception

// we don’t need a stack trace

Console.WriteLine(ce.Message);

}

catch (Exception e)

{

// Any changes need to be reverted

// when there is an error

catalog.DiscardChanges();

 

Console.WriteLine(e.ToString());

}

}

 

static private void PrintUsage()

{

Console.WriteLine(“Usage:”);

Console.WriteLine();

Console.WriteLine(“DeleteParty.exe <BizTalkDbServer> <PartyName>”);

Console.WriteLine();

Console.WriteLine(” Where: “);

Console.WriteLine(” <BizTalkDbServer> = The name of the SQL Server where the BizTalk databases are installed.”);

Console.WriteLine(” Example: localhost”);

Console.WriteLine(” <Party Name> = The name of the Party(s) to delete. To delete more than one use , to separate (no space between parties!)”);

Console.WriteLine(” Example: MyBusinessParty1,MyBusinessParty2″);

Console.WriteLine();

}

}

}

Next step is adding the DeleteParty.exe to your solution, so it will be copied to the deployment folder. First add the tool to your solution folder where the other deployment framework files are located. Then add the lines below to your BTDFPROJ file so it will be copied and executed as part of the undeployment.

<!–

 

 

 

 

  <AdditionalFiles Include=DeleteParty.exe>

    <

 

 

LocationPath>.</LocationPath>

  </

 

 

AdditionalFiles>

</

 

 

ItemGroup>

 

 

 

 

 

 

 

Make sure the DeleteParty SDK tool is also deployed, otherwise we cannot undeploy the app anymore because of the stuck party information –>

<

 

 

ItemGroup> <!– Custom undeploy to first delete the party information before being able to remove the application –>

 <Target Name=CustomUnDeployTarget>

<Exec Command=..DeleteParty.exe $(DeleteParty_BizTalkDbServer) $(DeleteParty_PartyName) ContinueOnError=False />

</Target>

 

As you can see, I’ve added two variables (‘DeleteParty_BizTalkDbServer’ and ‘DeletePart_PartyName’) to the command line to be able to run this on various environments. For example the ‘BizTalkDbServer’ won’t be the same on all environments. Add the section below somewhere between the other ‘ItemGroups’ in the BTDFPROJ file, so the variables will be read from the settings file and be available in the script.

<ItemGroup>

<!– We are asking the Deployment Framework to create MSBuild properties from the values

in our environment settings file that are named here.

With this request, we can use these values later on in the script

–>

<PropsFromEnvSettings Include=DeleteParty_BizTalkDbServer;DeleteParty_PartyName />

</ItemGroup>

 

The ‘DeleteParty_BizTalkDbServer’ and ‘DeleteParty_PartyName’ are regular settings you have to put in the SettingsFileGenerator.xml settings file.

Now when you run the deployment script, the DeleteParty tool is run as part of the undeploy.

Didago IT Consultancy

 

 

Comments: 1

  1. Ronald Lokers says:

    Great article, and still applicable to BizTalk 2013R2. Exactly what I was looking for!

Leave a Reply

Your email address will not be published. Required fields are marked *