I guess I should be flattered

I guess I should be flattered

That some spammer thought my wiki pages where hit enough to warrant modifying them
on a daily basis with links to various “odd” sites 😉

Thanks to Craig I’ve
upgraded to FlexWiki 2.0 and now those pages
are locked down – I apologize if you’ve visited them and they haven’t been right, 
should be ok from now on.

My
Workflow Sample Page

My
BizTalk Sample Page

 



Check out my BizTalk
R2 Training
.

Code Samples from todays webcast

Code Samples from todays webcast

For those of you who attended my webcast today on workflow communications, the demo code is attached to this post. It includes the base activities used for communication activities (more on these in a later post) and it provides simple example of local communications and web services. The two-way communication activity and sample is also included. 

If you are interested in the webcast check here in the next day to two for the OnDemand link.

 

Enjoy!

 

 

 

PowerShell for BizTalk Server

PowerShell for BizTalk Server

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

Understanding RosettaNet Message Flow in BizTalk Server 2006

Understanding RosettaNet Message Flow in BizTalk Server 2006

If a picture is worth a thousand words, then these two diagrams (courtesy & copyright Microsoft) are worth millions! At least they are to anyone desperate to understand how the BizTalk Accelerator for RosettaNet (BTARN 3.5) really works.

Initiator Message Flow

Don’t let the complexity of this diagram scare you. The message flow for an outbound RNIF (or PIDX) message consists of four key areas.

  1. The SQL Server BTARN Databases where all “lob” messages (such as a P21 – PIDX Invoice) and any attachments are stored BEFORE the outbound RNIF message flow actually begins, and the SQL Receive Location used to process the message content and attachments into the MessageBox.

    Note: If you’re not sending attachments you may elect not to use SQL for this and can substitute FILE receive locations. The SDK contains sample code and a pretty good explanation of how this may work.

  2. The Initiator Private Process orchestration where the actual messages and attachments are “prepared” (usually transformed into XML) for further processing by the initiator public process.
  3. The Initiator Public Process orchestration where the outbound message is actually formatted to meet the RNIF standard. This includes adding the required RNIF headers and other such tasks. Consider this a “Black Box” since you can’t change how this works without invalidating the RosettaNet certification.
  4. The HTTP/HTTPS Send Ports and the RNIFSend.aspx web application that are CRITICAL to the correct processing of the outbound messages. This is where the real work is done to validate the messages, create the correct MIME headers and add the required RNIF DOCTYPE declarations.

    Just a side note. If you’re really interested in how this all works, you can look at the source code for this web application using Lutz Roeder’s Reflector. I think you’ll be amazed at how much Regex is used to “craft” these RNIF messages.

Responder Message Flow

The message flow for an inbound RNIF message (whether it’s a new message or an asynchronous response to a message you’ve already sent) consists of three key areas.

  1. The RNIFReceive.aspx web application which processes the inbound message, validates it and then removes all the RNIF specific headers and DOCTYPE declarations. This then passes the message along to the HTTP/HTTPS Receive Port and Pipeline which handles the non-repudiation, decodes the message, parses the message and resolves which Party it came from.
  2. The Responder Public Process receive the RNIF message from the MessageBox and extracts the content and attachments and sends them to the responder private process for further processing. Just like the initiator public process, the Responder Public Process should be considered a “Black Box” and left unchanged.
  3. The Responder Private Process then routes the inbound messages and any attachments to the SQL Server BTARN Databases where it can be further processed and sent to some “lob” back-end system.

There are a few other details involved in the message flow (signals) depending upon whether your transmission is synchronous or asynchronous, but the basics are fairly straight-forward. The best thing is that this workflow is almost entirely “configured” using the BTARN Management Console and is “message agnostic”, meaning that you can use any standard RNIF, CIDX or PIDX “PIP” (Partner Interface Process) that you and your trading partner both support.

Best of all, it’s included in the price of BizTalk Server 2006 R2!

Currently listening to Carrie Underwood’s Carnival Ride

Controlling BizTalk Orchestrations with PowerShell

Controlling BizTalk Orchestrations with PowerShell

Here’s a sample PowerShell script/functions to start/stop BizTalk orchestrations.
This is an extended version of the Stop-Orchestration VBScript included in the BizTalk
2006 SDK, which I hope someone finds useful :-).

The script can be used to start or stop either a specific orchestration or a group
of orchestrations defined in a BizTalk assembly. For example, to stop and unenlist
all orchestrations in a given assembly, you could use this:

stop-orch -assembly 'MyProject.BizTalk,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=50b7b2906e3f8aa5'
-unenlist

Here’s the code for the script:

$script:bound = 2

$script:started = 4

$script:controlRecvLoc = 2

$script:controlInst = 2

function script:get-assemblyfilter([string]$assembly)
{

   # The BizTalk WMI provider uses separate properties
for each


   # part of the assembly name, so break it up to
make it easier to handle


   $parts = $assembly.Split((',', '='))

   $filter = "AssemblyName='$($parts[0])'"

   if ( $parts.Count
-gt 1 ) {

      for ( $i=1; $i -lt $parts.Count; $i += 2 )
{

         $filter = "$filter
and Assembly$($parts[$i].trim())='$($parts[$i+1])'"


      }

   }

   return $filter

}

function script:find-orch([string]$name, [string]$assembly)
{

   # We want to be able to find orchestrations by

   # name and/or assembly. That way we can control

   # all orchestrations in a single assembly in one
call


   $filter = ""

   if ( ![String]::IsNullOrEmpty($name)
) {

      $filter = "Name='$name'"

      if ( ![String]::IsNullOrEmpty($assembly)
) {

         $filter = "$filter
and $(get-assemblyfilter $assembly)"


      }

   } else {

      $filter = $(get-assemblyfilter $assembly)

   }

   get-wmiobject MSBTS_Orchestration `

      -namespace 'root\MicrosoftBizTalkServer' `

      -filter $filter

}

function start-orch([string]$name, [string]$assembly)
{

   $orch = (find-orch $name $assembly)

   $orch | ?{ $_.OrchestrationStatus
-eq $bound } |
%{

      write-host "Enlisting
$($_.Name)..."


      [void]$_.Enlist()

   }

   $orch | ?{ $_.OrchestrationStatus
-ne $started }
| %{

      write-host "Starting
$($_.Name)..."


      [void]$_.Start($controlRecvLoc, $controlInst)

   }

}

function stop-orch([string]$name, [string]$assembly, [switch]$unenlist = $false)
{

   $orch = (find-orch $name $assembly)

   $orch | ?{ $_.OrchestrationStatus
-eq $started }
| %{

      write-host "Stopping
$($_.Name)..."


      [void]$_.Stop($controlRecvLoc, $controlInst)

      if ( $unenlist )
{

         [void]$_.Unenlist()

      }

   }

}