During my preparation for my Tech Ed talk on BizTalk Server port binding options, I wanted to write a PowerShell script to help me manage the transitions from one demo to another. For the most part, I was looking for a way to quickly enable / disable receive locations and start / unenlist send ports and orchestrations. All of this is available in WMI, but I wanted to make some reusable functions in PowerShell so I didn't have to drop into WMI each time I wanted to do it. I wanted a simple function I could call like so:
EnableReceiveLocation("MYRL")
It turns out that creating these functions in a script file is relatively easy. One issue I ran into, however, is that transitions for send ports and orchestrations are not as straight forward as they are in the UI. In the UI if a port is unenlisted, I can simply start it. Under the covers, however, the admin tool is actually enlisting and then starting. So, in code, I have to call the operations to both enlist and start. Or, if the port is already enlisted, but not started, then in a function called StartSendPort, I have to just start it. So there is some checking of the current status rather than just blindly wrapping WMI calls. You'll need to check the docs in some situations to get the enum values. I used the hard coded values in my case.
function StartSendPort{
param([string]$portName)
$sp = Get-WmiObject MSBTS_SendPort -n root\MicrosoftBizTalkServer -filter "Name='$portName'"
if($sp -ne $null)
{
if($sp.Status -eq 1 -or $sp.Status -eq 2)
{
if($sp.Status -eq 1)
{
$null = $sp.Enlist()
}
$null = $sp.Start()
Write-Host "Started send port: " + $portName -fore Green
}
else
{
Write-Host "Send port " + $portName + " is already started." -fore Yellow
}
}
else
{
Write-Host "Send port not found" -fore Red
}
}
Where things got a little more challenging was when I wanted to start working with applications. Applications provide a nice way to manage a group of ports by allowing start/stop functionality; unfortunately, the application is not surfaced through WMI. Never fear however, b/c PowerShell is built on top of .NET. All I needed to do was create an instance of the BtsCatalogExplorer class and then I was on my way to managing the applications. But first, I had to load the assembly that included that class. I chose to do that using the path, but strong names works very well too. Then I used the New-Object cmdlet to create an instance and navigate to the application.
[System.Reflection.Assembly]::LoadFrom("C:\Program Files\Microsoft BizTalk Server 2006\Developer Tools\Microsoft.BizTalk.ExplorerOM.dll")
function StopBTSApplication
{
param([string]$appName)
$exp = New-Object Microsoft.BizTalk.ExplorerOM.BtsCatalogExplorer
$exp.ConnectionString = Get-BTSConnectionString
$app = $exp.Applications[$appName]
if($app -eq $null)
{
Write-Host "Application " $appName " not found" -fore Red
}
else
{
if($app.Status -ne 2)
{
#full stop of application
$null = $app.Stop(63)
$null = $exp.SaveChanges()
Write-Host "Stopped application: " $appName
}
}
}
And, because I was trying not to hard code too much, I create the connection string using WMI to get the group settings.
function Get-BTSConnectionString
{
$group = Get-WmiObject MSBTS_GroupSetting -n root\MicrosoftBizTalkServer
$dbName = $group.MgmtDBName
$server = $group.MgmtDBServerName
[System.String]::Concat("server=", $server, ";database=", $dbName, ";Integrated Security=SSPI")
}
Notice that I simply execute the Concat to get the connection string, and because this results in a new string, that value is returned to the pipeline and available to be set in a variable or used in a cmdlet.
I'm loving the stuff I can do with PowerShell and feel like I'm just scratching the surface. Hope this helps someone else get a jumpstart as well. I've attached the PowerShell file with my functions included.
Attachment: BizTalk_PowerShell.ps1.txt
Posted
Jun 26 2008, 10:29 PM
by
matt-milner