(Part 1) – Motorola XR450 and BizTalk RFID: Hands On

Continuing the (much delayed) postings on putting together basic end to end systems with RFID readers and BizTalk RFID, I’m going to delve into how to configure and deploy Motorola’s XR450 RFID reader.  As usual, the primary steps covered are:

Clearing SDRAM ... Complete
}}}BootStrap of XR400 V 4.01.0000
Copyright 1999-2005, Symbol Technologies
Copying Monitor image to RAM ...
|
Run Monitor_0 ....}}}Flash Info: wMfgId=0x89, wDevId=0x891C
Flash Info: flashDeviceSize=0x2000000, blockSize=0x20000, bootBlockSize=0x8000
Done: P30 Flash Unlocked
Check BootData to Update system ......
Do nothing for recovery.
Copying CE image to RAM ...
|
Booting Windows CE ...

ARC
        ****** Symbol XR450 RFID Reader Serial Console ******
Please enter user name:

Current Configuration:
        Serial Number: C80507AF82805945   MAC Address: 00:A0:F8:C2:02:D5
         1 -- DHCP               : ON
         * -- IP Address         : 172.27.166.75
         3 -- BSP Port           : 3000
         * -- Network Mask       : 255.255.255.0
         * -- Gateway            : 172.27.166.1
         * -- DNS Host           : 157.54.14.146
         7 -- Web Server Mode    : HTTP
         8 -- HTTP Port             : 80
         9 -- Shell Type         : Telnet
        10 -- File Transfer Mode : FTP
        11 -- Watchdog           : Enabled
        12 -- Trusted Hosts Only : OFF
        13 -- Commit Change
        14 -- Discard Change
        15 -- Exit
        16 -- Reboot
        17 -- Show system log
        18 -- Trace system log   : OFF
        19 -- TCP Timeout (mins) : 0
        20 -- BSP Mode           : Unsecured
        21 -- HTTPS Port                    : 443
        22 -- BSP User Auth      : OFF
* These are current system values and cannot be changed while DHCP is ON
Select the menu number to change the item value:

An alternate method of querying the visible tags is by browsing to the URL http://[ip address of device]/cgi-bin/dataProxy?oper=queryTags:

Updating the Device Firmware

Updating the device firmware on the XR series readers can be a little tricky the first time, due to the need to set up a FTP server to host the firmware update files.  However, once that server is in place and functional, performing the updates becomes a fairly trivial process.

Installing a FTP Server (Windows Server 2003)

The FTP server functionality included in IIS is the easiest method for enabling native firmware updates.  To install IIS with the FTP server extensions:

• Click on Start, Control Panel, Add/Remove Programs to bring up the Add or Remove Programs dialog.
• Click on Add/Remove Windows Components.
• From the Windows Components Wizard, click on Application Server, then click the Details button (IIS will already have been installed as part of the BizTalk RFID installation). 
• From the Application Server dialog, click Internet Information Services (IIS), then click the Details button.
• From the Internet Information Services (IIS) dialog, ensure that the File Transfer Protocol (FTP) Service is checked, then click OK until you return to the Windows Components Wizard dialog.
• Click Next to update the computer’s configuration, then Finish to close the wizard.

Configuring the FTP Server (Windows Server 2003)

Once the FTP Server has been installed, we need to create an FTP site with the appropriate security settings and firmware files.  For the purposes of this article, we’ll use the default FTP site that’s created when the FTP service is installed.

• From the IIS Manager, right-click Default FTP Site (under FTP Sites), then click on Properties.
• From the Default FTP Site Properties dialog, click on the Security Accounts tab.  Ensure that Allow anonymous connections is checked.  Note: to configure the service with user accounts for extra security, refer to http://msdn.microsoft.com/en-us/library/6ws081sa.aspx.
• Click on the Home Directory tab.  This should display the FTP site directory as being C:\inetpub\ftproot.  We’ll add the appropriate Motorola firmware update files under this directory.
• Create the directory C:\inetpub\ftproot\Moto.
• Download one of the XR Software releases from the Motorola web site for the XR450, such as version 3.3.10.  Download and unzip this package into the directory c:\inetpub\ftproot\Moto\3.3.10\.  This directory should resemble the image below.

• To create a firewall exclusion for the FTP service, execute the following firewall rule (opens port 21)

netsh firewall add portopening TCP 21 "FTP Server"

Testing the FTP Server

From a different machine on the network (NOT the FTP Server itself!), connect to the FTP server to ensure that the Motorola firmware update files can be accessed.  The easiest way to do this is via Internet Explorer, using the ftp URL syntax.  From the Internet Explorer address bar enter the URI ftp://[IP address of server]/Moto/3.3.10/.  If you have configured everything properly, you should see a directory listing similar to:

Performing the Update

• From the reader’s web management console, click on Maintenance, then Version to bring up the Version Control panel.
• In the FTP server text box type in the full FTP URL to the firmware files (i.e. ftp://[ip address]/Moto/3.3.10/
• For the username enter Anonymous.
• For the password enter ftp@.
• Click on Start Update to start the firmware update.

The reader will then start the process of retrieving and installing the firmware update, which you may observe from the web console.  This process usually takes about 5 minutes, so go grab a coffee or either suitably caffeinated beverage.

(Part 2) – Impinj Speedway and BizTalk RFID: Hands On

Building on the steps in the previous post, we’ll use BizTalk RFID to connect to the Impinj Speedway. This post assumes that you've gone through the steps in part 1.

Connectivity and configuration with Biztalk RFID

Now the part we've all been waiting for - firing up Biztalk RFID, and using it in conjunction with the Impinj reader to do cool stuff.  As the Speedway supports LLRP (low-level reader protocol, a standard for communication between RFID readers and middleware such as BizTalk RFID), no additional provider is required – BizTalk RFID 2009 ships an LLRP provider out of the box (note; if you’re using BizTalk RFID 2006 R2, you’ll need to download and install the Standards Pack).

Adding the Reader

• From the RFID Manager, right click the Devices node, and click on New Device.
• From the Add Device Wizard (Introduction)  dialog, ensure that the Add single device radio button is selected, and click Next.
• From the Add Device Wizard (Provider) dialog, click on LLRP in the list of available providers and click Next.
• From the Add Device Wizard (Connection) dialog, type the IP address of the device into the Name or IP address textbox, and type in 5084as the value for the Port.  Note that the standard port for LLRP is 5084.  Click Next.
• From the Add Device Wizard (Add Device to a Group) dialog, select any device group (or the root device group) and click Next.
• From the Add Device Wizard (Authentication) dialog, type in root for the username, and impinj for the password (the default factory values).  Click Next to start connecting to the device.  This will take several seconds, so don't get too impatient.

Checking for Tag Reads

• Place a tag in the read field of the antenna (in this case, somewhere close any of the connected antennae).
• From the RFID Manager, click the Devices node. 
• Right click on the new device you have just added, and click View Tags.

Almost there!  Now that we are successfully communicating with the Speedway reader and receiving tag notifications, we need to bind the device into an RFID process to persist tag events into a database, and then build a report.

Building a BizTalk RFID process and capturing tag reads

Now for the fun part - capturing the stream of information from the Speedway reader, and making it consumable by a user.  In this section, I'll create a basic RFID process using the SqlSink event handler.

Creating a Biztalk RFID Process

The first step in capturing the information from the RFID reader will be to define an RFID process, bind in that reader, and use an event handler to route information to a SQL database.

• From the RFID Manager, right click the Processes node, and click on New Process.
• From the New Process Dialog
  • Type in SampleProcess as the Process name.
  • Select Reliable as the Tag processing mode.
  • Leave the description blank.
  • Ensure the Start Bind Wizard box is checked.
  • Click OK.

• From the Bind Wizard (Welcome to the Bind Wizard) dialog, click Next.
• From the Bind Wizard (Bind Process to Logical Devices) dialog, we'll create a logical device.  Logical devices are used to create associations between event sources (like devices and antenna) and logical or physical constructs (like portals or doorways).  In this case, our system will pretend that the Speedway is located at a loading dock, door A.
• Click New.
• From the Logical Device Name dialog, type in Dock Door A and click OK.
• Back in the Bind Wizard (Bind Process to Logical Devices) dialog, click on the checkbox for Dock Door A.  If you don't click on the checkbox, the option to bind physical devices to the logical device will not be available.
• In the Bind Wizard (Configure logical device - Dock Door A)  dialog, expand the Speedway entry to expose the list of sources (4, for the four antenna supported by the Speedway). 
• Click on the checkbox next to the Speedway reader to bind all events from the device to this logical device.  Note that this also creates "soft links" to all antenna of the reader.
• Click Next.

• From the Bind Wizard (Configure Components) dialog, click New Component.
• Click on the SqlServerSink component, then click Add.

• Type in SqlSink as the Instance name and click OK.

• Click Close to finish adding components.
• Click Next.
• Ensure that the Start the process when I click Finish box is checked, then click Finish.
• From the RFID Manager, you should be able to see the process running.
• Right click on the process name and click View Tags.  By default the page is on a Manual refresh, so click the Refresh button.  If you don't see any tags in the window, it's time to troubleshoot!  Happily, troubleshooting is covered in the next installment of this series.

• Now that we've confirmed tags can be read in the process, the last step before building out a reporting interface will to confirm that the event handler (the SqlSink) is processing the tags correctly.  Start up the SQL Server Management Studio, and connect to the RFIDSINK database.
• From the list of tables in the RFIDSINK database, dump the contents of the dbo.TagEvents table.  The tag reads should now be visible in the database.

Summary

In this posting, we walked through using BizTalk RFID to communicate with the Impinj Speedway and flow tag information into a database. 

(Part 1) – Impinj Speedway and BizTalk RFID: Hands On

As the next (much delayed) post in a hands-on series, I’m going to walk through the process of creating an end to end solution with BizTalk RFID and the Impinj Speedway reader.  The primary steps covered are:

PowerShell and BizTalk RFID (1) - Providers and Server Configuration

Been on the road pretty much non-stop since January, so I haven't had the opportunity to post as much as I'd like.  However, it looks like the next couple of months will be a little more reasonable in terms of the travel schedule, so I should be able to clear out a bit of the backlog of strange and interesting posts about RFID, BizTalk Server, and other bits of Microsoft technology.

I've always been a scripting guy, going back almost 15 years to being a pretty hard core UNIX sysadmin.  Cut my teeth on perl4, and every manner of shell scripting under the sun (as well as some that should never have seen the light of day).  Although I no longer have much (any) claim to vi wizardry (I'll keep my Visual Studio thank you very much) one of the aspects of the *NIX environment that I'd always missed was a rich scripting and automation interface.  With the release of PowerShell, the Windows platform has an amazing scripting environment that combines much of the magic of other scripting hosts, as well as some truly unique features leveraging the .NET platform.

If you've never been exposed to PowerShell before, I highly recommend checking out the following:

When deploying and managing (troubleshooting!) BizTalk RFID installations, there is often the need to automate certain tasks.  BizTalk RFID ships with a command line utility (rfidclientconsole.exe), but this isn't well suited to adhoc tasks and quick scripting, as it relies heavily on the use of parameter passing via complicated XML files.  Happily, PowerShell is very well suited to wrapping up .NET API's and making them consumable with rich parameters and aggregation.

The intent is to publish a series of blog posts on using PowerShell and RFID, and gradually build up a library of cmdlets that can be used to administer BizTalk RFID installations.

Source Code Package here.

Providers and Server Configuration Cmdlets

In this first post we'll pick off some low-hanging fruit - the ability to get information about providers and server configuration, then create some code to perform a basic sysadmin task - changing the log level of a provider or process component programatically.  Following the usual PowerShell naming conventions, we will create the following cmdlets (mimicking functionality of the rfidclientconsole application, only with a rich parameter experience):

Creating PowerShell Cmdlets

To get started on creating PowerShell cmdlets, read the following excellent blog posts:

• David Aiken's Creating a Windows PowerShell CmdLet using the Visual Studio Windows PowerShell Templates
• Mike Stall's Debugging PowerShell cmdlets in the VS IDE

The samples in the rest of this post will use the PowerShell templates and debugging techniques from these posts.  To get started:

1. Install David's project wizard from http://channel9.msdn.com/Photos/ZippedFiles/256835_PSTemplates.zip. 
2. Create a new Windows PowerShell project called BizTalkRFID.PowerShell.  Make sure that the project is set to use .NET 3.5.
3. Configure the project for auto-registering and debugging the cmdlet as per Mike Stall's post.

NOTE: If you are running on a 64-bit system, you need to GAC the output assembly with both the 32-bit and 64-bit versions of installutil.exe.  Do that with a post-build event command lineof:

c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\installutil.exe $(TargetDir)$(TargetFileName) 
c:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\installutil.exe $(TargetDir)$(TargetFileName)

Get-RfidProviderStatus

We'll start with a fairly simple cmdlet - retrieving the status of a set of providers, leveraging the GetProviderStatus() API call.  The cmdlet should be able to take in the name (or names of a set) of a provider as well as a target server.  The signature of the cmdlet will be:

Get-RfidProviderStatus [Provider Names] [-Server servername]

1. Start off by adding a new Cmdlet to the project, under Add, New Item, Windows PowerShell, Windows PowerShell Cmdlet.  Name it GetRfidProviderStatusCmdlet.cs.

2. Add the following references to the project, from the C:\Program Files\Microsoft Biztalk RFID\bin\ directory.

Microsoft.Rfid.Client.dll
Microsoft.Rfid.Design.dll
Microsoft.Rfid.ManagementWebServices.dll
Microsoft.Rfid.SpiSdk.dll

3. Add the following using statements to the top of the class file:

using Microsoft.SensorServices.Rfid.Runtime;
using Microsoft.SensorServices.Rfid.Management;

4. Change the class Cmdlet attribute to reflect the desired name of the cmdlet.  Note that since this cmdlet does not have any impact on the system (i.e. doesn't change anything), we can set the SupportsShouldProcess value to false.

[Cmdlet(VerbsCommon.Get, "RfidProviderStatus", SupportsShouldProcess = false)]
    public class GetRfidProviderCmdlet : Cmdlet
    

4. Define the parameters, as per the following code.  This will define two parameters, ProviderName (an array of strings to represent the provider name), and Server (a single string to represent the target BizTalk RFID server).

   1:  [Parameter(Position = 0,

   2:      Mandatory = false,

   3:      ValueFromPipelineByPropertyName = true,

   4:      HelpMessage = "The name (or names) of the target providers")]

   5:  [ValidateNotNullOrEmpty]

   6:  [Alias("name")]

   7:  public string[] ProviderName

   8:  {

   9:      get;

  10:      set; 

  11:  }

  12:   

  13:  [Parameter(Position = 1,

  14:      Mandatory = false,

  15:      ValueFromPipelineByPropertyName = true,

  16:      HelpMessage = "The name (or names) of the target BizTalk RFID server")]

  17:  [ValidateNotNullOrEmpty]

  18:  public string Server

  19:  {

  20:      get;

  21:      set;

  22:  }

5. Override the BeginProcessing method to create initialization code which will create the ProviderManagerProxy object pointing to the appropriate server.

   1:  private ProviderManagerProxy provProxy;

   2:   

   3:  protected override void BeginProcessing()

   4:  {

   5:      if (String.IsNullOrEmpty(this.Server))

   6:          provProxy = new ProviderManagerProxy();

   7:      else

   8:          provProxy = new ProviderManagerProxy(this.Server);

   9:  }

6. Now the meat of the whole cmdlet development exercise - actually reaching out to the BizTalk RFID server and retrieving the provider status information.  Create an override for the ProcessRecord method, as per:

   1:  protected override void ProcessRecord()

   2:  {

   3:      try

   4:      {

   5:          if (ProviderName == null || ProviderName.Length == 0)

   6:              WriteVerbose("Retrieving status for all providers");

   7:          else

   8:              WriteVerbose("Retrieving status for providers " + String.Join(",", ProviderName));

   9:          

  10:          ProviderStatus[] provStatus = provProxy.GetProviderStatus(ProviderName);

  11:          WriteObject(provStatus, true);

  12:      }

  13:      catch (RfidClientException ex0)

  14:      {

  15:          ApplicationException ex_app = new ApplicationException(ex0.RemoteErrorMessage, ex0);

  16:          WriteError(new ErrorRecord(ex_app, ex0.RemoteErrorCode, ErrorCategory.InvalidOperation, ProviderName));

  17:      }

  18:      catch (Exception ex1)

  19:      {

  20:          ThrowTerminatingError(new ErrorRecord(ex1, "", ErrorCategory.InvalidResult, ProviderName));

  21:      }

  22:  }        

This entire method boils down to two lines (10 and 11) - the rest is diagnostics and error handling.  Note that we have to catch the RfidClientException and wrap the RemoteErrorMessage, otherwise the only feedback to the user is "Remote method failed" - an instance of absolutely correct and singularly useless feedback.

7. Now that the cmdlet has been created (sans documentation - we'll get to that in a minute), it's time to see the fruits of our labours.  This cmdlet is executed against a base install of BizTalk RFID 2009 with the LLRP provider registered.  Press F5 to start a debuggable instance of PowerShell, and dump out the basic provider information:

PS C:\files\BizTalkRFID.PowerShell\bin\Debug> Get-RfidProviderStatus


Name           : LLRP
ProviderFaults : {}
LastFaultType  : None
LastFaultTime  : 1/1/0001 12:00:00 AM
ProviderState  : Registered

Exciting stuff, eh? :).  The real "wow" factor here isn't being able to dump out this basic list - could do that with rfidclientconsole.  The exciting part is now this information can leverage all of the power and utility of PowerShell scripting to do things, build reports, drive automation, etc.  Expanding the idea a bit:

PS C:\Files> Get-RfidProviderStatus | format-table Name,ProviderState -autosize

Name ProviderState
---- -------------
LLRP    Registered

Creating a simple table of available and registered providers.

   1:  PS C:\Files> Get-RfidProviderStatus | where-object { $_.ProviderState -eq 'Regis

   2:  tered' }

   3:   

   4:   

   5:  Name           : LLRP

   6:  ProviderFaults : {}

   7:  LastFaultType  : None

   8:  LastFaultTime  : 1/1/0001 12:00:00 AM

   9:  ProviderState  : Registered

Now we're starting to do fun things - with this command we filtered out registered provider names.  Further on in this series when we create cmdlets such as Start-RfidProvider, we could write simple scripts that automatically started all Registered providers with something as simple as

Get-RfidProviderStatus | ? {$_.ProviderState -eq 'Registered' } | Select-Object Name | Start-RfidProvider

Get-RfidProviderMetadata

The next cmdlet will be retrieving the metadata from a provider, or set of providers.  This cmdlet is nearly identical to the previous, the only difference being the cmdlet name, Cmdlet() attribute definition, and implementation of ProcessRecord.

   1:    [Cmdlet(VerbsCommon.Get, "RfidProviderMetadata", SupportsShouldProcess = false)]

   2:      public class MyCmdlet1 : Cmdlet

   3:      {

   4:  ...

   5:   

   6:  protected override void ProcessRecord()

   7:  {

   8:      foreach (string name in ProviderName)

   9:      {                

  10:          try

  11:          {

  12:              WriteVerbose("Retrieving provider metadata..");

  13:              ProviderMetadata meta = provProxy.GetProviderMetadata(name);

  14:              WriteObject(meta);

  15:          }

  16:          catch (RfidClientException ex0)

  17:          {

  18:              ApplicationException ex_app = new ApplicationException(ex0.RemoteErrorMessage, ex0);

  19:              WriteError(new ErrorRecord(ex_app, ex0.RemoteErrorCode, ErrorCategory.InvalidOperation, name));

  20:          }

  21:          catch (Exception ex1)

  22:          {

  23:              ThrowTerminatingError(new ErrorRecord(ex1, "", ErrorCategory.InvalidResult, name));

  24:          }

  25:      }

  26:  }

Compile and run the updated project. From the PowerShell window you should now be able to execute the Get-RfidProviderMetadata cmdlet, as per:

ug> Get-RfidProviderMetadata LLRP -verbose
VERBOSE: Retrieving provider metadata..


ProviderInformation            : <providerInformation><id>Microsoft BizTalk RFI
                                 D LLRP Provider</id><description>Provider for
                                 LLRP devices</description><version>3.7.0.0</ve
                                 rsion></providerInformation>
ProviderCapabilities           : {The provider supports TCP/IP transport., The
                                 provider supports raising a defunct event., Th
                                 e provider supports device discovery., The pro
                                 vider supports triggering of device discovery.
                                 }
ProviderPropertyMetadata       : {[Connection:Port], [General:LLRP Version], [M
                                 anagement:LLRP Message timeout], [Management:T
                                 CP KeepAlive Time]...}
VendorExtensionsEntityMetadata : {[HoppingEvent:DSPI management event], [Reader
                                 ExceptionEvent:DSPI management event], [RFSurv
                                 eyEvent:DSPI management event], [ConnectionAtt
                                 emptEvent:DSPI management event]...}
DevicePropertyMetadata         : {[LLRP General Capabilities:Antenna Sensitivit
                                 y Maximum Index], [LLRP General Capabilities:A
                                 ntenna Sensitivity Minimum Index], [LLRP Gener
                                 al Capabilities:Can Set Antenna Properties], [
                                 LLRP General Capabilities:Has UTC Clock Capabi
                                 lity]...}

Not very exciting, either.  Or is it?  Remember that PowerShell uses the default formater defined by the underlying .NET type - in this case output as XML.  Those aren't text strings, but fully fledged objects that can be manipulated.  Like this:

PS C:\Files> $meta = Get-RfidProviderMetadata LLRP
PS C:\Files> $meta.ProviderCapabilities


Value              : 4
Description        : The provider supports TCP/IP transport.
IsDiscoveryRelated : False
IsEventRelated     : False
IsTransportRelated : True

Value              : 3
Description        : The provider supports raising a defunct event.
IsDiscoveryRelated : False
IsEventRelated     : True
IsTransportRelated : False

Value              : 1
Description        : The provider supports device discovery.
IsDiscoveryRelated : True
IsEventRelated     : False
IsTransportRelated : False

Value              : 2
Description        : The provider supports triggering of device discovery.
IsDiscoveryRelated : True
IsEventRelated     : False
IsTransportRelated : False

Displaying the list of capabilities for the LLRP provider.

PS C:\Files> $meta.DevicePropertyMetadata.Keys | sort GroupName

GroupName                               PropertyName
---------                               ------------
General                                 Regulatory region
General                                 Name
General                                 Firmware version
General                                 Vendor...

Listing out the provider properties (full list truncated for space reasons).

PS C:\Files> $meta.DevicePropertyMetadata.Keys | sort GroupName | format-table -autosize | select-object -first 10

GroupName                               PropertyName
---------                               ------------
General                                 Regulatory region
General                                 Name
General                                 Firmware version
General                                 Vendor
LLRP Access Report Spec                 Trigger
LLRP Antenna Configuration              Receiver Sensitivity Index
LLRP Antenna Configuration              Transmit Power Index
LLRP Antenna Configuration              Hop Table Id

Listing the first 10 provider properties, sorted by GroupName, with automatic sizing in the table formatting.

Get-RfidProviderProperties

Now to dig a little deeper into provider properties.  The GetProviderProperties() method of the ProviderManagerProxy() returns the non-default (i.e. changed) values from the provider.  The GetProviderMetadata() returns the metadata for said properties, including the defaults.  Useful information, but in two separate buckets.  Let's write a cmdlet that returns a unified view of the properties using a custom PSObject (i.e. leveraging PowerShell's awesome adaptive type system).

1. This cmdlet is nearly identical to the previous, the only difference being the cmdlet name, Cmdlet() attribute definition, and implementation of ProcessRecord.  The definition of the class and Cmdlet attribute is:

   1:   [Cmdlet(VerbsCommon.Get, "RfidProviderProperty", SupportsShouldProcess = true)]

   2:      public class GetRfidProviderPropertiesCmdlet : Cmdlet

   3:      {

2. The implementation of ProcessRecord is a little trickier, and requires some explanation.

   1:  protected override void ProcessRecord()

   2:  {

   3:      foreach (string name in ProviderName)

   4:      {

   5:          try

   6:          {

   7:              WriteVerbose("Retrieving provider metadata..");

   8:              ProviderMetadata meta = provProxy.GetProviderMetadata(name);

   9:   

  10:              WriteVerbose("Retrieving provider properties..");

  11:              PropertyProfile prof = provProxy.GetProperties(name);

  12:   

  13:              foreach (PropertyKey k in meta.ProviderPropertyMetadata.Keys)

  14:              {

  15:                  PSObject obj = new PSObject(meta.ProviderPropertyMetadata[k]);

  16:                  obj.Properties.Add(new PSNoteProperty("Group", k.GroupName));

  17:                  obj.Properties.Add(new PSNoteProperty("Name", k.PropertyName));

  18:                  // Modified value

  19:                  if (prof.Keys.Contains(k))

  20:                  {

  21:                      PSNoteProperty n = new PSNoteProperty("Value", prof[k]);

  22:                      obj.Properties.Add(n);

  23:   

  24:                      PSNoteProperty o = new PSNoteProperty("Default", false);

  25:                      obj.Properties.Add(o);

  26:                  }

  27:                  // Default value

  28:                  else

  29:                  {

  30:                      PSNoteProperty n = new PSNoteProperty("Value", 

  31:                          meta.ProviderPropertyMetadata[k].DefaultValue);

  32:                      obj.Properties.Add(n);

  33:   

  34:                      PSNoteProperty o = new PSNoteProperty("Default", true);

  35:                      obj.Properties.Add(o);

  36:                  }                        

  37:                  WriteObject(obj);

  38:              }

  39:          }

  40:          catch (RfidClientException ex0)

  41:          {

  42:              ApplicationException ex_app = new ApplicationException(ex0.RemoteErrorMessage, ex0);

  43:              WriteError(new ErrorRecord(ex_app, ex0.RemoteErrorCode, ErrorCategory.InvalidOperation, name));

  44:          }

  45:          catch (Exception ex1)

  46:          {

  47:              ThrowTerminatingError(new ErrorRecord(ex1, "", ErrorCategory.InvalidResult, name));

  48:          }

  49:      }

  50:  }

Line 3 - Since we can receive multiple provider names, we'll iterate over each.

Line 7-11: In order to aggregate the property information, we need to retrieve both the metadata and property profile.

Line 13: As the metadata has the "master" list of all properties, we use this as the baseline for enumeration.

Line 15-17: Here is the PowerShell magic.  We're going to create a PowerShell object (PSObject) that wraps the native metadata object, and decorate it with some note properties.  In this case the GroupName and the property name.

Line 19-25: If the property profile contains the value, then it's a non-default value.  We add two note properties, one with the modified value, the other with a flag indicating its non-default status.

Line 30-35: If the property profile does not contain the value, then it's a default value, which we grab from the metadata.  We add two note properties, one with the modified value, the other with a flag indicating its default status.

Line 40-47: The usual error handling.

With this simple bit of code we can now do some interesting automation (well, for now we can play with data - once the Set-RfidProviderProperty cmdlets are written in future posts we can have more fun).

ug> Get-RfidProviderProperty LLRP | format-table

Group   Name      Value Default IsInitO Type    Descrip LowerRa HigherR ValueEx
                                    nly         tion        nge    ange pressio
                                                                        n
-----   ----      ----- ------- ------- ----    ------- ------- ------- -------
Conn... Port       5084    True    True Syst... Prov...       1   65535
General LLRP...   1.0.1    True   False Syst... Indi... ...+308 ...+308
Mana... LLRP...   45000    True   False Syst... Time...   10000 ...3647
Mana... TCP ...   60000    True   False Syst... Time...   30000 ...3647
Conn... Devi...      60    True    True Syst... Inte...       1 ...3647
Disc... Matc...      10    True   False Syst... Indi...       1 ...3647

Retrieving all of the provider properties and their current values.

ug> Get-RfidProviderProperty Contoso | format-table Name,Value,Default -autosize

Name             Value                                  Default
----             -----                                  -------
Init_NonEditable Rfid                                      True
Name             Contoso                                   True
Description      Sample Microsoft BizTalk RFID Provider    True
DevelopedBy      Microsoft BizTalk RFID Team               True
Year Developed   2006                                      True
Integer_Editable 100                                       True
bool_Editable    True                                      True
DiscoveryPort    9876                                      True
HostDS           False                                     True
XML              False                                     True

Having a look at the Contoso provider's properties.

PS C:\files\projects\Microsoft.Rfid.PowerShell\Microsoft.Rfid.PowerShell\bin\Debug> Get-RfidProviderProperty Contoso | ? {$_.Type.FullName -eq 'System.String' } | format-table Name,Value -autosize

Name             Value
----             -----
Init_NonEditable Rfid
Name             Contoso
Description      Sample Microsoft BizTalk RFID Provider
DevelopedBy      Microsoft BizTalk RFID Team

Get a list of all of the string type properties.

Set-RfidLoggingLevel

Most of this article was written while trying to create this one cmdlet, for automating log level configuration.  This can be a somewhat non-intuitive exercise (or at least it was for me :), so a quick walkthrough of the steps involved may be useful.  The log level appears on the Initialization Parameters of the Properties page of a provider in the RFID Manager.  This may lead one to assume that the logging level is a property of the provider.  One would be flat out wrong :)

The logging level is an aspect of the RFID Server Configuration.  Let's use the rfidclientconsole to dump the server configuration and have a look:

   1:  C:\>rfidclientconsole GetServerConfiguration test.xml

   2:  C:\>type test.xml

   3:   

   4:  <?xml version="1.0" encoding="utf-16"?>

   5:  <RfidServerConfiguration xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.datacontract.org/2004/07/Microsoft.SensorServices.Rfid.Management">

   6:      <clusterNetworkName i:nil="true" />

   7:      <rfidServerBootstrapConfiguration>

   8:          <eventLoggingPolicyForExceptions>

   9:              <logNonRfidServerExceptions>true</logNonRfidServerExceptions>

  10:              <minimumExceptionSeverityForLogging>Fatal</minimumExceptionSeverityForLogging>

  11:          </eventLoggingPolicyForExceptions>

  12:          <log>

  13:              <component>

  14:                  <ComponentLogLevelType>

  15:                      <level>Info</level>

  16:                      <name>MSBizTalkRFID</name>

  17:                  </ComponentLogLevelType>

  18:                  <ComponentLogLevelType>

  19:                      <level>Info</level>

  20:                      <name>ProcessManager</name>

  21:                  </ComponentLogLevelType>

  22:                  <ComponentLogLevelType>

  23:                      <level>Info</level>

  24:                      <name>DeviceManager</name>

  25:                  </ComponentLogLevelType>

  26:                  <ComponentLogLevelType>

  27:                      <level>Info</level>

  28:                      <name>Device</name>

  29:                  </ComponentLogLevelType>

  30:                  <ComponentLogLevelType>

  31:                      <level>Info</level>

  32:                      <name>FixedTimerQ</name>

  33:                  </ComponentLogLevelType>

  34:                  <ComponentLogLevelType>

  35:                      <level>Info</level>

  36:                      <name>Common</name>

  37:                  </ComponentLogLevelType>

  38:                  <ComponentLogLevelType>

  39:                      <level>Info</level>

  40:                      <name>SecurityManager</name>

  41:                  </ComponentLogLevelType>

  42:                  <ComponentLogLevelType>

  43:                      <level>Info</level>

  44:                      <name>ProviderManager</name>

  45:                  </ComponentLogLevelType>

  46:                  <ComponentLogLevelType>

  47:                      <level>Info</level>

  48:                      <name>ComponentManager</name>

  49:                  </ComponentLogLevelType>

  50:                  <ComponentLogLevelType>

  51:                      <level>Info</level>

  52:                      <name>ConnectorServices</name>

  53:                  </ComponentLogLevelType>

  54:                  <ComponentLogLevelType>

  55:                      <level>Info</level>

  56:                      <name>RfidWebService</name>

  57:                  </ComponentLogLevelType>

  58:                  <ComponentLogLevelType>

  59:                      <level>Error</level>

  60:                      <name>Tracking</name>

  61:                  </ComponentLogLevelType>

  62:              </component>

  63:              <dateTimeFormat i:nil="true" />

  64:              <defaultLogLevel>Info</defaultLogLevel>

  65:              <logFile>logs\RfidServices.log</logFile>

  66:          </log>

  67:          <rfidStore>

  68:              <connectionString>Persist Security Info=False;database=RFIDSTORE;Integrated Security=SSPI; server=MASIMMS-DESKTOP</connectionString>

  69:          </rfidStore>

  70:          <wsConfiguration>

  71:              <wSPort>0</wSPort>

  72:              <wSPortSpecified>false</wSPortSpecified>

  73:          </wsConfiguration>

  74:      </rfidServerBootstrapConfiguration>

  75:      <rfidServerRuntimeConfiguration>

  76:          <deviceManagerConfiguration>

  77:              <autoApplyNonPersistentProperties>true</autoApplyNonPersistentProperties>

  78:              <deviceCommandResponseTimeoutMilliseconds>180000</deviceCommandResponseTimeoutMilliseconds>

  79:              <deviceConnectionCheckTimeMilliseconds>60000</deviceConnectionCheckTimeMilliseconds>

  80:              <deviceConnectionFailedThreshold>10</deviceConnectionFailedThreshold>

  81:              <deviceConnectionRetryTimeMilliseconds>60000</deviceConnectionRetryTimeMilliseconds>

  82:              <maxTagPrintedEvent>50</maxTagPrintedEvent>

  83:              <stampNotificationEventWithID>false</stampNotificationEventWithID>

  84:          </deviceManagerConfiguration>

  85:          <exposeStackTrace>false</exposeStackTrace>

  86:          <hostingConfiguration>

  87:              <iisHost>localhost</iisHost>

  88:              <iisPort>80</iisPort>

  89:              <iisTimeOutSeconds>60</iisTimeOutSeconds>

  90:              <iisWebsiteId>1</iisWebsiteId>

  91:          </hostingConfiguration>

  92:          <logConfiguration>

  93:              <currentBackupIndex>0</currentBackupIndex>

  94:              <fileCheckFrequency>25</fileCheckFrequency>

  95:              <fileCount>2</fileCount>

  96:              <fileSize>10</fileSize>

  97:              <maxAllowedDuplicates>3</maxAllowedDuplicates>

  98:              <spamControlTimePeriodInMinutes>10</spamControlTimePeriodInMinutes>

  99:          </logConfiguration>

 100:          <processManagerConfiguration />

 101:          <providerManagerConfiguration>

 102:              <delegateThreadTimeoutMilliseconds>60000</delegateThreadTimeoutMilliseconds>

 103:              <providerSideBySideLoadAllowed>false</providerSideBySideLoadAllowed>

 104:          </providerManagerConfiguration>

 105:          <wSConfiguration>

 106:              <shouldAuditSuccess>false</shouldAuditSuccess>

 107:          </wSConfiguration>

 108:      </rfidServerRuntimeConfiguration>

 109:  </RfidServerConfiguration>

Wow.  That's a lot of stuff.  The interesting items are the logging components.  These define the individual logging level for each component in the system, both internal system components and the "user" components such as providers and processes. 

Note that the LLRP provider does NOT appear in this list.  This is due to the INHERIT LOG LEVEL checkbox being set in the RFID Manager.  If a user component is set to inherit a logging setting, it will not have an entry in the RFID Server Configuration data set.  This comes into play in our implementation of the Set-RfidLoggingLevel command.

The ServerManagerProxy exposes a very chunky interface, meaning that we have to retrieve the RFID server configuration, make changes to that configuration, then dump the configuration back in order to effect any changes.

1. This cmdlet is nearly identical to the previous, the only difference being the cmdlet name, Cmdlet() attribute definition, and implementation of ProcessRecord.  The definition of the class and Cmdlet attribute is:

   1:   [Cmdlet(VerbsCommon.Set, "RfidLogLevel", SupportsShouldProcess = true)]

   2:      public class SetRfidLogLevelCmdlet : Cmdlet

   3:      {

2. The parameter set is a little different, consisting of the Log Level, followed by the component names with an optional Server parameter.

   1:  [Parameter(Position = 0,

   2:      Mandatory = true,

   3:      ValueFromPipelineByPropertyName = true,

   4:      HelpMessage = "Logging Level")]

   5:  [ValidateNotNullOrEmpty]

   6:  public ConfigLogLevel Level

   7:  {

   8:      get;

   9:      set; 

  10:  }

  11:   

  12:  [Parameter(Position = 1,

  13:  Mandatory = true,

  14:  ValueFromPipelineByPropertyName = true,

  15:  HelpMessage = "The name (or names) of the target components (providers and processes")]

  16:  [ValidateNotNullOrEmpty]

  17:  [Alias("name")]

  18:  public string[] ComponentName

  19:  {

  20:      get;

  21:      set;

  22:  }

  23:   

  24:  [Parameter(Position = 2,

  25:      Mandatory = false,

  26:      ValueFromPipelineByPropertyName = true,

  27:      HelpMessage = "The name of the target BizTalk RFID server")]

  28:  [ValidateNotNullOrEmpty]

  29:  public string Server

  30:  {

  31:      get;

  32:      set;

  33:  }

3. The initialization code is also a little different.  In order to perform parameter validation we need to have the list of user components (providers and processes), and will thus need the proxy objects to access these in addition to the ServerManagerProxy.

   1:  private ServerManagerProxy srvProxy;

   2:  private ProviderManagerProxy provProxy;

   3:  private ProcessManagerProxy procProxy;

   4:   

   5:  protected override void BeginProcessing()

   6:  {

   7:      if (String.IsNullOrEmpty(this.Server))

   8:      {

   9:          srvProxy = new ServerManagerProxy();

  10:          provProxy = new ProviderManagerProxy();

  11:          procProxy = new ProcessManagerProxy();

  12:      }

  13:      else

  14:      {

  15:          srvProxy = new ServerManagerProxy(this.Server);

  16:          provProxy = new ProviderManagerProxy(this.Server);

  17:          procProxy = new ProcessManagerProxy(this.Server);

  18:      }

  19:  }

4. Now the good stuff.  Actually implementing the changes. 

   1:  protected override void ProcessRecord()

   2:  {

   3:      try

   4:      {

   5:          // Get the server configuration, which contains the logging level information in the

   6:          // bootstrap (i.e. startup) settings

   7:          WriteVerbose("Retrieving server configuration");

   8:          RfidServerConfiguration config = srvProxy.GetServerConfiguration();

   9:   

  10:          // Get the list of provider and process names - these are the only valid components

  11:          WriteVerbose("Retrieving provider list");

  12:          ProviderStatus[] provStatus = provProxy.GetProviderStatus(null);

  13:          List<string> providerNames = new List<string>();

  14:          foreach (ProviderStatus s in provStatus)

  15:              providerNames.Add(s.Name);

  16:   

  17:          WriteVerbose("Retrieving process list");

  18:          List<string> procNames = new List<string>(procProxy.GetAllProcesses());

  19:          

  20:          // Perform parameter validation on the list of input components

  21:          List<string> validComponents = new List<string>();

  22:          foreach (string name in this.ComponentName)

  23:          {

  24:              if (procNames.Contains(name) || providerNames.Contains(name))

  25:              {

  26:                  WriteVerbose("Component " + name + " is a valid logging component");

  27:                  validComponents.Add(name);

  28:              }

  29:              else

  30:              {

  31:                  WriteWarning("Component " + name + " is not a process or provider name");

  32:              }

  33:          }

  34:   

  35:          foreach (ComponentLogLevelType n in config.RfidServerBootstrapConfiguration.log.component)

  36:          {

  37:              if (validComponents.Contains(n.name))

  38:              {

  39:                  WriteVerbose("Changing log level of component " + n.name + " to " + Level.ToString());

  40:                  n.level = this.Level;

  41:                  validComponents.Remove(n.name);

  42:              }

  43:          }

  44:   

  45:          // Check for "default" logging levels

  46:          List<ComponentLogLevelType> vals = new List<ComponentLogLevelType>(

  47:                  config.RfidServerBootstrapConfiguration.log.component);

  48:              

  49:          foreach (string name in validComponents)

  50:          {

  51:              WriteVerbose("Setting log level of component " + name + " to non-default value " + Level.ToString());

  52:              ComponentLogLevelType t = new ComponentLogLevelType();

  53:              t.name = name;

  54:              t.level = Level;

  55:              vals.Add(t);

  56:          }

  57:          config.RfidServerBootstrapConfiguration.log.component = vals.ToArray();

  58:   

  59:          WriteVerbose("Updating Server..");

  60:          srvProxy.SetServerConfiguration(config);

  61:          

  62:      }

  63:      catch (RfidClientException ex0)

  64:      {

  65:          ApplicationException ex_app = new ApplicationException(ex0.RemoteErrorMessage, ex0);

  66:          ThrowTerminatingError(new ErrorRecord(ex_app, ex0.RemoteErrorCode, ErrorCategory.InvalidOperation, this.Server));

  67:      }

  68:  }

  69:  }

adfasdfasdf

All of this code (well, it's not a huge amount), but we get a very straightforward logging configuration experience:

ug> Set-RfidLogLevel Verbose LLRP -verbose
VERBOSE: Retrieving server configuration
VERBOSE: Retrieving provider list
VERBOSE: Retrieving process list
VERBOSE: Component LLRP is a valid logging component
VERBOSE: Changing log level of component LLRP to Verbose
VERBOSE: Updating Server..

Once we have the opportunity to implement more of the Get-Rfid* cmdlets, this method can be used to do some interesting things.  However, since we already have a way to retrieve a list of the provider names:

ug> Get-RfidProviderStatus | select-object Name | Set-RfidLogLevel Verbose -verbose
VERBOSE: Retrieving server configuration
VERBOSE: Retrieving provider list
VERBOSE: Retrieving process list
VERBOSE: Component LLRP is a valid logging component
VERBOSE: Changing log level of component LLRP to Verbose
VERBOSE: Updating Server..
VERBOSE: Retrieving server configuration
VERBOSE: Retrieving provider list
VERBOSE: Retrieving process list
VERBOSE: Component Contoso is a valid logging component
VERBOSE: Changing log level of component Contoso to Verbose
VERBOSE: Updating Server..

PowerShell script to set all of the Provider log levels to Verbose.

Note: because of the use of ProcessRecord the log levels are being changed sequentially.  A more efficient way of doing it would be to aggregate the component names in ProcessRecord and actually update the server in EndProcessing.

Pro RFID with BizTalk Server 2009 - Hot Off the Presses

After a marathon writing binge over the past few months, the first book on BizTalk RFID has been published by Apress.  Written by myself, Ram Venkatesh (former Lead Architect on BizTalk RFID, now CEO of S3 Edge), and Mark Beckner (prominent writer and consultant on BizTalk Server and EDI) it's packed full of BizTalk RFID goodness.  Available now for order!

Read Chapter 1, or have a look through the table of contents:

• Foreword
• About the Authors
• About the Technical Reviewer
• Acknowledgments
• Introduction
• CHAPTER 1 RFID Background Primer
• Tracking Stuff: Eyeballs and Lasers
• Introducing Radio Frequency Identification
• Navigating the Technology Matrix
• What’s in a Tag?
• Active vs. Passive
• Passive Readers in Action
• Active RFID Technology
• Tag Memory: Reading and Writing
• Printers and Applicators
• Cutting Through the Hype
• The Science of the Feasible vs. the Art of the Possible
• The Myth of the RFID Solution
• Electronic Product Code Class 1 Generation 2
• Closed-Loop vs. Open-Loop Systems
• Applying RFID
• Conclusion
• CHAPTER 2 BizTalk RFID Architecture and Installation
• The BizTalk RFID Process Architecture
• The Physical Layer
• The Device Layer
• The Device Provider Layer
• Application-Level Services
• LOB and Back-End Connectivity
• The BizTalk RFID Device Model
• Identity
• Endpoint
• Connection Initiation
• Authentication
• Discovery
• Knobs
• Management
• Sources
• The BizTalk RFID Device Model for Applications
• The Device Model Assumed by DeviceConnection
• The Device Security Model
• The Concurrency Model for the DeviceConnection Class
• The RFID Business Process Device Model
• Installing BizTalk RFID
• Conclusion
• CHAPTER 3 The RFID “Hello World” Application
• Overview
• Using the Device Simulator
• Configuring Settings
• Configuring Notifications
• Creating a Device in BizTalk RFID
• Creating a Process
• Conclusion
• CHAPTER 4 Using RFID Manager
• Overview of RFID Manager
• Permissions
• Connecting to Servers
• Managing Server Properties
• RFID Manager Server Dashboard
• Managing Providers
• Managing Device Groups
• Managing Devices
• Importing and Exporting Devices
• Device Configuration
• Managing Device States
• Managing Processes
• Understanding Logical and Physical Devices
• Managing Components
• Conclusion
• CHAPTER 5 Asynchronous Event Processing in BizTalk RFID
• What Is a BizTalk RFID Process?
• Hands-On Exercises
• Event Processing Application Model
• Initialization
• Design-Time Support
• The Actual Event Handler Methods
• Tear-Down and Cleanup
• Deployment and Undeployment
• Strong Typing
• Error Handling
• Binding and Deployment
• Executing RFID Processes
• RFID Process Runtime Architecture
• Activation and Hosting
• BizTalk RFID Hosting Model for Windows Server
• Transactionality
• Conclusion
• CHAPTER 6 Command Processing
• Connecting BizTalk RFID to Your Application
• Processes
• Devices
• Device Management
• Implementing Synchronous Calls from .NET Applications
• Implementing Device Callbacks
• Managing Device Connections
• Standard Commands
• Vendor Commands
• Common Tasks
• Simulating Tag Reads
• Conclusion
• CHAPTER 7 BizTalk RFID Mobile
• BizTalk RFID Mobile Architecture
• Installing BizTalk RFID Mobile
• Creating a BizTalk RFID Mobile Application
• Asynchronous Event Notification
• Using Triggers to Control Asynchronous Notifications
• Scanning RFID Barcodes from your BizTalk RFID Mobile Application
• Integration with BizTalk RFID Server
• Remote Management Support
• Storing Events Locally in a SQL Server CE Database
• Tag Data Encoding and Translation
• Conclusion
• CHAPTER 8 Integrating with BizTalk Server
• Publishing Events to BizTalk Server
• Publishing to BizTalk Server Using MSMQ
• Publishing to BizTalk Server Using SqlServerSink
• Extending the Flexibility of Event Retrieval
• Calling the BizTalk BRE
• Logging Using the BRE
• Calling a BizTalk RFID Web Service Proxy from an Orchestration
• Conclusion
• CHAPTER 9 Direct Communication with Enterprise Applications
• Integrating with SQL Server Reporting Services
• Querying the BizTalk RFID Databases
• Writing the SQL Server Reporting Services Reports
• Connecting to BizTalk RFID via Remote Machines
• Integrating with SharePoint 2007
• Developing the SharePoint Web Part Foundation
• Extending the Web Part to Use the RFID Web Service Proxies
• Extending the Web Part to Use a Custom Web Service
• Conclusion
• CHAPTER 10 Diagnostics and Troubleshooting
• Setting the Stage: Tools and Techniques
• Introducing PowerShell
• Tailing a Log File
• Peeking Inside a BizTalk RFID Application
• BizTalk RFID Server Log Files
• Provider Log Files
• Process Log Files (Event Handlers)
• WMI for RFID
• Troubleshooting BizTalk RFID
• RFID Devices
• Tags and Objects
• Communication
• Service and Providers
• Logical Devices and Process Binding
• Event Handlers
• Sinks and External Applications
• Conclusion
• CHAPTER 11 Enterprise Planning and Deployment
• From Development to Production
• Staging RFID Device Definitions and Device Properties
• Planning for Disaster Recovery
• BizTalk RFID Footprint
• Enabling Cold Standby
• Running BizTalk RFID Under Microsoft Cluster Service
• Enterprise Deployment
• Servicing RFID Device Providers
• Servicing RFID Processes
• Changing Device Bindings for a Process
• Distributing and Upgrading Business Rules
• Enterprise Monitoring
• RFID Management Pack for BizTalk RFID
• Device Versioning
• BizTalk RFID Service Discovery Through Active Directory
• Conclusion
• CHAPTER 12 BizTalk RFID Recipes
• 12.1. Transport Protocols Within Event Handlers
• 12.2. RFID Data, XML, and SQL Server
  12.3. Debugging Tips
  12.4. Integration with BizTalk EDI Functionality
  12.5. Creating an XSD Based on BizTalk RFID XML
  

(Part 2) - Hands on with Biztalk RFID and the Alien 9650

Building on the previous post, the next thing we'll do is use Biztalk RFID to connect to the Alien 9650.  This post assumes that you've gone through the steps in part 1.

Connectivity and configuration with Biztalk RFID

Now the part we've all been waiting for - firing up Biztalk RFID, and using it in conjunction with the Alien reader to do cool stuff.  This process (at least the first time) involves obtaining and installing the provider, configuring the appropriate firewall access on the host machine, and then adding the reader itself.

Obtaining and Installing the Provider

The provider is available from the partner site (another reason I recommend getting a partner login as soon as possible :).  In the partner site, under Technical Information -> Software, look for the Microsoft BizTalk RFID Provider for ALR-9900, 9800, 8800, 9650 link.  This leads to a zip package containing an installer.  Download the package and execute the installer.   This will install the provider DLL under Program Files at \Alien RFID\Alien RFID Provider. 

Note: the installer does not register the provider, so we'll need to take care of that in the next step.

To register the provider (remember that multiple versions of the same provider can be simultaneously registered - great feature :):

• Start the RFID Manager, and click on the Device Providers node.  We'll go ahead and add the Alien which I downloaded from the partner site in the last step.

• Right click on Device Providers, and click on New Provider.  
• From the Add Provider dialog window type in Alien as the name.
• Click on Browse, and navigate to the Alien RFID Provider directory (under \Program Files\Alien RFID) and select the AlienRfidProvider.dll file.
• Click Register to load the provider into Biztalk RFID.

As of the time I wrote this article, the Alien provider has a minor bug when running on Windows Vista with IPv6 enabled related to the Local Host property.  This property is used by the provider to auto-configure the device's notification host.  The notification host is the destination to which the reader sends asynchronous events, such as "I saw tags", or "my input port changed".  If the provider does not have the correct value for this asynchronous events will never be received - i.e. RFID Processes in Biztalk RFID will never receive tags.

To fix the problem get rid of the IPv6 "fluff" around the local address.  In the example the default host string is fe80::200:5efe:10.0.0.1%12.  Change that to 10.0.0.1 (the IPv4 address buried in the middle).  A quick review of the other configuration properties (which don't need to be changed for default scenarios, but good to be familiar with none the less) is listed in the next section.

• Ensure the Start the provider box is checked, then click OK to start the provider.

Snapshot of Vendor Properties

Configuring Firewall Ports

As noted in the previous section certain inbound ports need to be opened in the firewall to enable asynchronous notification and discovery functionality.  The default ports 3988, 7797, 7798, and 7799 may be opened by executing the commands below.

For Windows XP / Server 2003:

netsh firewall add portopening TCP 3988 “Alien Discovery”

netsh firewall add portopening TCP 7797 “Alien Notification”

netsh firewall add portopening TCP 7798 “Alien IO”

netsh firewall add portopening TCP 7799 “Alien Streaming”

For Windows Vista / Server 2008:

netsh advfirewall firewall add rule name=”AlienDiscovery” dir=in action=allow protocol=TCP localport=3988

netsh advfirewall firewall add rule name=”AlienNotification” dir=in action=allow protocol=TCP localport=7797

netsh advfirewall firewall add rule name=”AlienIO” dir=in action=allow protocol=TCP localport=7798

netsh advfirewall firewall add rule name=”AlienStreaming” dir=in action=allow protocol=TCP localport=7799

Adding the Reader

Seems like a lot of work just to connect to a reader and a get a few tags, doesn't it?  I went into a lot more detail for the prerequisites than was perhaps strictly necessary - however, knowing why certain things are done is crucial when you have to perform troubleshooting.  Not to mention the number of times that diagnostics have ended with staring at the end of an unplugged cable has taught me to start with the basics (power, connectivity, firmware, tags) before building up.  To add the reader:

• From the RFID Manager, right click the Devices node, and click on New Device.
• From the Add Device Wizard (Introduction)  dialog, ensure that the Add single device radio button is selected, and click Next.
• From the Add Device Wizard (Provider) dialog, click on Alien in the list of available providers and click Next.

• From the Add Device Wizard (Connection) dialog, type the IP address of the device into the Name or IP address textbox, and type in 23 as the value for the Port.  Note that the Alien provider uses port 23 for connecting, not the web interface on port 80.  Click Next.
• From the Add Device Wizard (Add Device to a Group) dialog, select any device group (or the root device group) and click Next.
• From the Add Device Wizard (Authentication) dialog, type in alien for the username, and password for the password (the default factory values).  Click Next to start connecting to the device.  This will take several seconds, so don't get too impatient.

If you cannot connect to the device, and upon clicking View Error you receive the Error 24 Invalid Format error your notification host value is set incorrectly at a provider level.  Go back to the provider properties and fix that value.

• From the Add Device Wizard (Properties) dialog, click Next to advance the final step without modifying any of the base device description properties, unless of course you really want to.
• From the Add Device Wizard (Completion) dialog, click Finish to finish the process of adding the device.

Checking for Tag Reads

• Place a tag in the read field of the antenna (in this case, somewhere close to the built-in antenna).
• From the RFID Manager, click the Devices node. 
• Right click on the new device you have just added, and click View Tags.

Almost there!  Now that we are successfully communicating with the Alien reader and receiving tag notifications, we need to bind the device into an RFID process to persist tag events into a database, and then build a report.

Building a BizTalk RFID process and capturing tag reads

Now for the fun part - capturing the stream of information from the Alien reader, and making it consumable by a user.  In this section, I'll create a basic RFID process using the SqlSink event handler, extend the table schema to associate tags with assets and generate a basic ASP.NET report from that database table.

Creating a Biztalk RFID Process

The first step in capturing the information from the RFID reader will be to define an RFID process, bind in that reader, and use an event handler to route information to a SQL database.

• From the RFID Manager, right click the Processes node, and click on New Process.
• From the New Process Dialog
  • Type in SampleProcess as the Process name.
  • Select Reliable as the Tag processing mode.
  • Leave the description blank.
  • Ensure the Start Bind Wizard box is checked.
  • Click OK.

• From the Bind Wizard (Welcome to the Bind Wizard) dialog, click Next.
• From the Bind Wizard (Bind Process to Logical Devices) dialog, we'll create a logical device.  Logical devices are used to create associations between event sources (like devices and antenna) and logical or physical constructs (like portals or doorways).  In this case, our system will pretend that the ALR-9650 is located at a loading dock, door A.
• Click New.
• From the Logical Device Name dialog, type in Dock Door A and click OK.
• Back in the Bind Wizard (Bind Process to Logical Devices) dialog, click on the checkbox for Dock Door A.  If you don't click on the checkbox, the option to bind physical devices to the logical device will not be available.

• In the Bind Wizard (Configure logical device - Dock Door A)  dialog, expand the Alien RFID Reader entry to expose the list of sources (2, for the two antenna supported by the ALR-9650).  Click on the checkbox next to the Alien RFID Reader to bind all events from the device to this logical device.  Note that this also creates "soft links" to both antenna of the reader.
• Click Next.

• From the Bind Wizard (Configure Components) dialog, click New Component.
• Click on the SqlServerSink component, then click Add.

• Type in SqlSink as the Instance name and click OK.

• Click Close to finish adding components.
• Click Next.
• Ensure that the Start the process when I click Finish box is checked, then click Finish.
• From the RFID Manager, you should be able to see the process running.
• Right click on the process name and click View Tags.  By default the page is on a Manual refresh, so click the Refresh button.  If you don't see any tags in the window, it's time to troubleshoot!  Happily, troubleshooting is covered in the next installment of this series.

• Now that we've confirmed tags can be read in the process, the last step before building out a reporting interface will to confirm that the event handler (the SqlSink) is processing the tags correctly.  Start up the SQL Server Management Studio, and connect to the RFIDSINK database.
• From the list of tables in the RFIDSINK database, dump the contents of the dbo.TagEvents table.  The tag reads should now be visible in the database.

Summary

In this posting, we walked through using BizTalk RFID to communicate with the ALR-9650 and flow tag information into a database.  In the next posting we'll cover troubleshooting the most common problems and build out a basic reporting interface using ASP.NET.

(Part 1) - Hands on: Building an End to End Solution with Biztalk RFID and the Alien 9650

As the first post in a hands-on focused series on building out solutions with Biztalk RFID, I'm going to walk through the process of creating an end to end solution with Biztalk RFID and the Alien 9650 RFID reader.  Future posts in this series will cover the Motorola XR450, Impinj Speedway, and others.  The primary steps covered are:

• Installing the necessary software bits
• Setting up the reader (from the shipping box to the network)
• Performing native firmware updates
• Connectivity and configuration with Biztalk RFID
• Building a basic business logic and reporting interface

Installing the necessary software bits

The first step will be to ensure that you have all of the necessary (and few optional :) software bits installed on your workstation.  The baseline components are:

• SQL Server 2005 (any edition, including express), including Service Pack 2 - trial
• Visual Studio (preferably 2008) - trial
• Biztalk RFID - trial

Trial editions for each of the base software are available from the links above.  Note that the next release of Biztalk Server (Biztalk Server 2009) will officially support SQL Server 2008 and Visual Studio 2008, but since Visual Studio 2008 can target the base 2.0 .NET Framework it works with Biztalk Server 2006 R2 (caveat; use at your own risk - it will not be officially supported until the next release, so if something goes wrong, you're on your own :).

The installation instructions for each are included with the trials, but a Quick Start Guide for Biztalk RFID is available.  Remember to install / enable MSMQ, and install WSE 3.0 (required for the complete installation option of Biztalk RFID).

Note: Vista User Access Control (UAC) does some strange things in conjunction with Biztalk RFID.  For development purposes only, it may streamline things to disable UAC.  As this has security implications, do this at your own risk.

Setting up the reader (from the shipping box to the network)

Every RFID reader is a little different in terms of power, network and antenna, so being familiar with the specifics of the readers you employ in your solutions is vitally important.  While Biztalk RFID does an excellent job of abstracting away many of the software and management related details, all the software in the world won't help if you can't turn the reader on! :)

From the Alien web site:

ALR-9650 Complete, Easy, Single-Antenna RFID Solution
The ALR-9650 is the ideal solution for single and two-antenna applications. The reader electronics and a high-quality, circularly polarized antenna reside in a single package, eliminating external antenna cables, resulting in the simplest and least expensive installation. A second antenna port enables 2-antenna applications.

Some of the key, unique features of this device are:

• The device supports Power-Over-Ethernet to reduce cabling requirements.  One of the practical aspects of this is the provided power adapter, which can be a little tricky to plug in the first time (more about that below).
• Built-in antenna - excellent for applications with constrained space requirements.

The box includes:

• The ALR-9650 (pictured above)
• CD-ROM (documentation and software)
• Crossover Ethernet cable (for connecting PC directly to the RFID reader)
• Standard Ethernet cable, PoE rated (for connecting the reader to a hub or the enclosed power supply)
• PoE converter brick (provides a PoE connection without a full-up PoE infrastructure)
• RS232 serial cable

Ensure that you have all of the pieces that you're supposed to have - including the serial cable!  You will also need an additional Ethernet cable to connect the reader to a hub.

Installing the Software and Documentation

Before going crazy plugging things in, take the time to install the software and documentation from the provided CD-ROM.  The key documents will be located under

Alien RFID -> DocZone -> ALR_9650

in the form of the Hardware Setup Guide and the Quick Installation Guide.  I know nobody reads documentation, but if you take one single piece of advice in this whole article - READ THE HARDWARE SETUP GUIDE!!!  Rant over :). 

Connecting the Serial Connection

When setting up a reader for the first time, or performing low-level debugging a serial connection is invaluable.  If your PC or laptop does not have a built-in serial port, I would highly recommend purchasing a USB-to-serial adapter such as this one.   Note that most big-box retailers or computer stores will carry a similar product in stock.  In addition to the physical connection, you'll need a terminal adapter program.  Note that since Hyperterminal is not a part of Windows Vista, you likely don't have a built-in one available.  I like a number of different (freeware) products, such as TeraTerm Pro.  After downloading and installing Tera Term Pro, start the application.

Select the appropriate COM port (if using a USB-to-serial converter see the manufacturer documentation for details), and click OK.  Built-in COM ports are usually COM1.  Click on Setup, then Serial port to configure the serial port settings.

The serial communication settings for the Alien ALR-9650 are 115200 8N1 (or, 115200 baud rate, 8 bit data, none parity, 1 bit stop, none flow control).

Powering the Reader

The fundamental aspect of using any electronic device - that wonderful stuff we call power.  While the ALR-9650 supports the standard Alien power adapter (the ALX-616-2 AC/DC brick), the power supply enclosed with the reader is a PoE Power Sourcing Equipment (PSE) module that "jumpstarts" power onto a standard Ethernet line.  As per page 18, figure 10, we'll use the enclosed PoE power supply in conjunction with the reader.

1. Plug one end of the enclosed Ethernet cable into the LAN port on the ALR-9650.
2. Plug the other end of the enclosed Ethernet cable into the J1 DATA & PWR port on the PSE module.
3. Plug one end of another Ethernet cable into the J2 DATA port on the PSE module.
4. Plug the other end of the Ethernet cable into a network hub.
5. If we were using an additional antenna with this reader, we would plug it into the auxiliary antenna port at this time.  Since we're not for this purposes of this walk-through, moving on..
6. Take the enclosed AC power cord and plug one end into the wall socket, the other end into the PSE module.  At this point, the green POWER LED on the reader should illuminate.
   1. Note: if you're not sure which end is which on the AC power cord, please step away from the computer.

Note: the ALR-9650 is a mono-static reader.  This means that a single antenna is used for both transmit and receive.  As such, the reader needs only a single antenna to operate.

When the reader is starting up, it will print a stream of information to the serial port (which was the whole point of doing that first :).  The key information we'll be looking for during boot-up is the network settings, which will look like:

Network Settings:
   MAC Address : 00:1B:5F:00:0E:E1
   Hostname    : alien-000EE1
   IP Address  : 10.10.10.125
   Netmask     : 255.255.254.0
   Gateway     : 10.10.10.1
   DHCP        : 1
   DHCP Time46
   TimeServer  : 132.163.4.103
   TimeZone    : -8
   CommandPort : 23

The key information is the IP address - this will tell you if the device has successfully captured a DHCP lease from the network.

Note: Alien readers support a very useful and handy discovery feature, that is also supported by Biztalk RFID.  The intent of this article is to demonstrate techniques that can be used to connect to readers in edge cases (such as the reader being on a separate broadcast domain from the host PC or server).

Using the Serial Interface

The Alien readers all support a rich serial/telnet interface that allows configuration of virtually all aspects of the device.  While all of these features are accessible through Biztalk RFID, it's vital in troubleshooting scenarios to be able to isolate portions of the system (from the power supply on up), which is why I'm talking about them in this article.  All of the Alien commands are documented in their Reader Interface Guide, but a couple of useful commands are shown below.

Alien>ipaddress?
IPAddress = 157.56.25.21

Alien>dhcp?
DHCP = ON

Alien>

In this case we use the ipaddress? and dhcp? commands to query the specific IP address and dhcp configuration for the reader.

Scanning Tags

I always recommend checking for tag scans with the lowest number of moving parts (i.e. if tag reads aren't showing up in a report there are many potential sources of failure - tag, antenna, reader, network, middleware, database and the report itself).  Since the ALR-9650 has a built in antenna, and only requires a single antenna to implement a read point, this is relatively simple out of the box.  Wave a valid EPC Class 1 Gen 2 tag over the reader, then execute the t? command on the reader.

Alien>t
30 14 35 D8 C0 10 D4 80 00 00 00 03, 0, 2008/12/04 12:59:20.691, 2, 3000

If a valid tag(s) is in the antenna read field, it should show up on the display.  Provided this is directly out of the box, there shouldn't be any misconfigured configuration properties to handle the basic case.  However, in the case where the reader has been in service, it's usually a good idea to revert to the "stock" settings.  The easiest way to perform this operation from the console is factorysettings.

Alien>factorysettings
All settings reset to factory defaults.

Peforming Native Firmware Updates

Occasionally it may be necessary to perform firmware updates using the vendor native interface.  A specific example of this is a reader which has a version of firmware which is not supported by the vendor's Biztalk RFID provider (usually in the case of older firmware versions).  If Biztalk RFID can't connect to the reader, it's not in a good position to perform firmware updates :). Firmware updates are available from the Alien web site, but you first need to register as a partner here.  There's a manual approval process involved, so it's good to register as a partner as soon as you order your Alien equipment (though approval usually only takes a day or two).

Once you've accessed the partner site, browse to Technical Information -> Firmware.  There's usually one primary "active" firmware version available that works across all of the Alien readers, in the form of a .zip package.  After downloading the current firmware package, unzip it to a local directory.  In this section we'll use the native web server interface to perform a firmware upgrade (rather than an external application such as Biztalk RFID or the Alien Gateway software).

Log into the device's web management interface by navigating to the device's IP address.  The task selection list should look similar to the one in the picture below.

Click on Upload Firmware.  As this is the first operation that requires authentication to the device, you'll need to log in.  The default username and password for all Alien devices is username alien and password password.  Click on the Browse button and select the appropriate fw aef file.  Click Upload File to update the firmware image.

The progress of the upload process can be viewed from the serial console (yet another reason to know how to use the serial console :).

Primus Posting

Coming into my fourth week here at Microsoft as a Field Program Manager in the Customer Experience group within CSD has been quite the experience.  My role centers around working with customers, partners and the Microsoft field teams to enable the adoption of Biztalk RFID. 

My goal is to use this as a medium to spread the word on all of the exciting things happening both within the partner community and around Microsoft related to RFID, and to share tips and tricks for delivering Biztalk RFID based solutions.