Image

One of the key features in BizTalk Server 2009 is the support for mobile RFID devices running Windows CE Professional 5 (or greater). This support includes a platform for creating applications that run on the CE Professional devices, and out-of-the-box functionality for integrating such devices into your overall application scenario. In this chapter, you will take a quick tour of the various pieces in BizTalk RFID Mobile, and also create your first mobile application that uses this new functionality.

In addition to support for mobile devices, BizTalk Server 2009 also introduces enhanced standards support for Low Level Reader Protocol (LLRP) and Tag Data Translation (TDT). BizTalk Server 2009 uses LLRP to implement communication between mobile devices and the server component, as well as establishing connectivity to LLRP-enabled RFID devices. TDT streamlines the use of global tag data–mapping standards, such as SGTIN, providing various methods and utilities for encoding and decoding tag information.

ImageNote In the rest of this chapter, when we refer to BizTalk RFID Server, Desktop, or just BizTalk RFID, we are referring to the platform that runs on the desktop and server operating systems (i.e., the same version of BizTalk RFID that is covered elsewhere in the book). When we refer to BizTalk RFID Mobile, we are talking specifically about the components that run on the mobile device. To distinguish between the mobile device and its RFID module, whenever we use the word “device” in this chapter, we are talking about the entire device, and when we say “RFID module” or “RF module,” we are referring just to the RFID functionality. Phew, with that out of the way, let us dive in!

BizTalk RFID Mobile consists of the following pieces:

DSPI Mobile: This provides a framework for developing device-agnostic applications, in the same fashion as the “server” DSPI implementation. While there are a few minor differences to account for developing on a mobile platform, developers will be able to leverage their existing skill set as the foundation for developing mobile applications.

Application libraries: Analogous to the synchronous commands provided by the server platform, RFID Mobile provides a rich set of classes for performing tasks such as discovering RFID modules, executing tag operations, and configuring settings and properties.

Remote management agent: This is an agent hosted inside of your mobile RFID application that communicates with a BizTalk RFID server using LLRP. This allows the device to be managed and configured from an RFID Manager console. In conjunction with an application, such as Systems Center Operations Manager, this allows both fixed and mobile RFID devices and applications to be managed from a central console.

Store-and-forward agent: This is an agent hosted inside of your mobile RFID application that provides a seamless way to flow events from a mobile application into an RFID process running on a BizTalk RFID server, even when faced with intermittent connectivity.

BizTalk RFID Mobile Architecture

The overall architecture of BizTalk RFID Mobile is consistent with BizTalk RFID Desktop, with a few important differences. Figure 7-1 shows what the architecture picture looks like at the 10,000-foot level. You can contrast that to Figure 2-1 in Chapter 2 for the desktop version of BizTalk RFID.

Image

Figure 7-1. BizTalk RFID Mobile architecture

The first thing to observe is that the entire BizTalk RFID Mobile platform runs in the same address space as your application, or in-proc. There are no Windows services that are hosting your code or the providers, or hidden remote communication that is happening on behalf of your application. Generally, this choice will lead to lower latency in communication between the module and the application, and will consume fewer resources than an out-of-process model. The downside of the in-proc model is reliability; an error in the provider can crash the entire application. As shown in Figure 7-1, the key components of BizTalk RFID Mobile are as follows:

Tag layer: The mobile platform is designed to support a wide variety of RFID frequencies and tag protocols, including LF, HF, and UHF (matching the functionality of the server platform). This provides the capability to connect to RF and bar code modules, both through direct connection (in case of embedded modules) and connectivity options such as Blue-tooth, serial, and Wi-Fi. One of the key features specific to the mobile stack is enhanced support for reading and working with bar codes.

Radio module layer: This is the specific implementation of the DSPI for the radio module, which has considerable overlap with the server version (over 90 percent of the API is identical). A provider author can share a significant amount of the command- and property-processing functionality between the server and mobile versions, assuming that the radio interface is similar.

Device abstraction layer: This is a layer hidden from most applications; it provides the necessary glue between the application-facing device connection APIs and the underlying device-specific providers. Rather than a separate asynchronous message stream (i.e., RFID process), the mobile stack provides a method of receiving asynchronous notifications directly in an application through a .NET event handler (note that this functionality is dependent on the specific provider—not all devices will support this).

DeviceConnection APIs: These are the core APIs that every BizTalk RFID Mobile application author will use to access the RF functionality. Again, there is considerable commonality between the desktop and server versions of this API.

ImageNote Since all the APIs are in-proc with the application, the BizTalk RFID Mobile APIs are defined in the following three DLLs: Microsoft.Rfid.SpiSdk.dll, Microsoft.Rfid.Util.dll, and Microsoft. Rfid.Design.dll; and one additional DLL: Microsoft.Rfid.ObjectModelExtensions.dll. There is no “ManagementWebServiceProxies” DLL, since there is no web service call between your application and the platform.

Installing BizTalk RFID Mobile

Installing BizTalk RFID Mobile is a fairly reasonable task, but has certain prerequisites:

Please refer to the product documentation for both of these prerequisite applications for installation instructions.

Developing applications for BizTalk RFID Mobile requires Visual Studio 2008 (or Visual Studio 2005) with the Smart Client development feature (which is not available in the Express edition) and the Windows Mobile 5 SDK (available from www.microsoft.com).

After installing the .NET Compact Framework and SQL Server Compact files on the mobile device, the BizTalk RFID Mobile bits may be installed. The BizTalk RFID Mobile installer will install a set of CAB files and DLLs to the Microsoft BizTalk RFIDSDKMobile directory under Program Files. Note that the sample applications are not installed automatically, and need to be accessed from the installation directory.

The installation instructions for the BizTalk RFID Mobile CAB files are included in the Installing BizTalk RFID Mobile.htm document included with the installation package. This document also includes step-by-step instructions for installing the prerequisite applications. The basics of installing the necessary CAB files on a mobile device are as follows:

  1. On your computer, in the folder containing the BizTalk RFID Mobile installation files, browse to the folder %RFIDInstallDir%SDKMobilev1.1inwce500armv4i.
  2. Copy the appropriate installation CAB file to your mobile device, depending on whether it is running Windows Mobile or Windows CE.

    On a computer with Microsoft Sync Center installed (Windows Vista or Windows Server 2008), you should be able to browse the mobile device’s file system by clicking Start Image Computer, and the mobile device icon.

    1. For a Windows Mobile device, copy the file biztalkrfidmobile.enu.wm.armv4i.cab.
    2. For a Windows CE 5.0 device, copy the file biztalkrfidmobile.enu.wce5.armv4i.cab.
  3. Locate the CAB file on your mobile device and tap the file to start the installation process.

When the installation is finished, you should see a BizTalkRfidMobile directory under the Program Files directory, which contains the tools and the default location for the configuration store. You will also see a directory called Logs underneath that. In that directory, you will find the log file for your application, with a format very close to what is produced by the desktop version.

ImageNote The store-and-forward functionality uses the LLRP provider, which has a dependency on having port 5084 available on the BizTalk RFID server host. Ensure that the firewall port is open, either through the MMC administration console, or by executing a netsh command such as netsh advfirewall firewall add rule name="LLRP_Service" dir=in action=allow protocol=TCP localport=5084.

Creating a BizTalk RFID Mobile Application

In this section, we will write our first RFID Mobile application, for the following scenario. Assume that you are going to track high-value assets in your enterprise, such as laptops. Assume that the laptops already have a bar code tag on them, and the goal is to increase the automatic visibility for such an asset by fixing an RFID tag on the laptop.

Given the kind of sensitive information that resides on most laptops (e.g., official or personal information), this kind of track-and-trace application is actually a very legitimate and popular use case for high-value asset tracking. In this section, we are going to write a small .NET Compact Framework Windows Forms application that reads a bar code and the tag ID from an RFID tag, and then writes the same value back to an RFID tag using the standard BizTalk RFID Mobile device simulator.

The first step is to install the DSPI provider for your device on the handheld reader. Exercise 7-1 demonstrates how to do this using the RFID Manager application that is part of BizTalk RFID Mobile with the default BizTalk RFID Mobile device simulator. Exercise 7-2 builds on this foundation to develop a basic BizTalk RFID Mobile application.

ImageNote If you have an RFID-enabled Windows Mobile device supported by BizTalk RFID Mobile, you may use the vendor’s mobile DSPI provider (and physical RFID reader) instead of the simulator.

Exercise 7-1. Installing a Device Provider

This exercise demonstrates how to get the sample DSPI provider installed on the handheld reader, and how to browse the properties of the mobile reader simulator. This exercise will use the Windows Mobile 5.0 Professional emulator and the MyFirstCEProvider sample provider that is part of BizTalk RFID Mobile.

Note that as with the server experience, any task or feature in a provided management application is available through the .NET APIs (this allows applications to include any of the required management or configuration functionality, and not require the use of a separate application).

  1. Run the RFID Manager application, which was installed on the device during BizTalk RFID Mobile installation. It may be found in the Program FilesBizTalkRfidMobile directory (the name of the executable file is ManagementApp). Figure 7-2 shows you what the initial screen looks like.
    Image

    Figure 7-2. The mobile version of RFID Manager

  2. Click Add to browse for provider DLLs. Click the Browse button to bring up the file selection dialog. The MyFirstCEProvider DLL should be visible in the dialog, as shown in Figure 7-3. Click the MyFirstCEProvider file.
    Image

    Figure 7-3. Selecting the MyFirstCEProvider file

  3. The default provider name, MyFirstCEProvider, will be filled in automatically, as shown in Figure 7-4. Click OK to close the file selection dialog and automatically start the provider.
    Image

    Figure 7-4. Confirming the provider name

    ImageNote Under Windows Mobile, by default, you can only browse for files under the My Documents root.

  4. Click OK to close the “Provider started and registered” dialog.
  5. As MyFirstCEProvider implements device discovery, the simulated device will be automatically detected. Click the Devices tab to view the list of available devices, and then click MyCEDevice, as shown in Figure 7-5.
    Image

    Figure 7-5. Selecting the simulated reader

  6. Click Menu and then Properties to bring up the configuration page for the device, as shown in Figure 7-6.
    Image

    Figure 7-6. Properties of the simulated reader

  7. Click the Advanced tab to view the device and source properties. Just as for fixed RFID readers, mobile readers can have properties bound to the device or any sources on the device. Typical sources on a mobile device include RFID (the primary RFID device) and Barcode. Click the drop-down box to expose the list of sources, as shown in Figure 7-7.
    Image

    Figure 7-7. Sources of the simulated reader

Exercise 7-2. Creating a Simple BizTalk RFID Mobile Application

In this exercise, you will write an application that uses the RF module (and indirectly the provider) installed in Exercise 7-1. The goal is to create a simple application for reading tags using the mobile platform.

  1. Start Visual Studio, click File Image New Project, and then select the Smart Device category from under the Visual C# node (as shown in Figure 7-8). Select the Smart Device Project type, and then select an appropriate location (such as C: emp) and name the project HelloMobileRfid. Click OK to open the Add New Smart Device Project dialog.
  2. From the Add New Smart Device Project dialog, select Windows Mobile 5.0 Pocket PC SDK and .NET Compact Framework Version 3.5, as shown in Figure 7-9.
    Image

    Figure 7-8. Creating a Smart Device project

    Image

    Figure 7-9. Selecting the Smart Device project type

  3. Click the Device Application project type, and then click OK.
  4. The next step will be to add the BizTalk RFID Mobile libraries to the application. Open the Add References dialog and browse to the Microsoft BizTalk RFIDSDKMobilev1.1in directory. Select the following assemblies, and click OK to add them to the project:
    1. Microsoft.Rfid.Design.dll
    2. Microsoft.Rfid.Llrp.dll
    3. Microsoft.Rfid.ObjectModelExtensions.dll
    4. Microsoft.Rfid.SpiSdk.dll
    5. Microsoft.Rfid.Util.dll

    ImageNote The names of the mobile DLLs are the same as those for the desktop version of BizTalk RFID. Be sure to link with the correct version for your application (i.e., not the DLLs in the BizTalk RFIDin directory).

  5. Add some basic graphical elements to the form, as shown in Figure 7-10:
    1. Select the Form1 form and change the Text property to Read Tag.
    2. Select the Form1 form and change the MinimizeBox property to False.
    3. Drag a button onto the form, name it btnOpen, and give it a Text property of Open RF.
    4. Drag a button onto the form, name it btnClose, and give it a Text property of Close RF.
    5. Drag a button onto the form, name it btnRead, and give it a Text property of Read Tag.
    6. Drag a text box onto the form and name it tbTag.
    Image

    Figure 7-10. The Read Tag main form

  6. Double-click the Open RF button in the designer to create a Click event handler in Form1.cs. Fill in the Click event handler as shown in Listing 7-1. Note that this code only works because you have previously registered the provider and device in Exercise 7-1.

    Listing 7-1. Using the ProcessManagerProxy to Obtain a List of Registered RFID Processes

    // Shared DeviceConnection object – used to communicate with RFID module
    private DeviceConnection connection;

    private void btnOpen_Click(object sender, EventArgs e)
    {
        // Create a device manager proxy to obtain the device list
        DeviceManagerProxy proxy = new DeviceManagerProxy();

        // Obtain the name of the first (usually the only) device
        string deviceName = proxy.GetAllDevices()[0].Name;

        // Establish a connection to that device
        connection = new DeviceConnection(deviceName);
        connection.Open();
    }
  7. Add the using statements shown in Listing 7-2 to the top of the Form1.cs file.

    Listing 7-2. Adding the Required using Statements

    using Microsoft.SensorServices.Rfid.Management;
    using System.IO.SensorServices.Rfid.Client;

    Listing 7-3. The Close RF Button Event Handler

    private void btnClose_Click(object sender, EventArgs e)
    {
        // If an active connection exists, close it
        if (connection != null)
        {
            connection.Close();
            connection = null;
        }
    }
  8. From the Form1 designer, double-click the Read RF button to create a Click event handler. Fill in the event handler as shown in Listing 7-4.

    Listing 7-4. The Read RF Button Event Handler

    private void btnRead_Click(object sender, EventArgs e)
    {
        // Confirm the connection is available
        if (connection != null &&
            connection.ConnectionState == ClientConnectionState.Open)
        {
            // Read tags through the synchronous GetTags function and display
            // in the text box
            foreach (TagReadEvent tre in connection.GetTags(TagDataSelector.All))
            {
               string hex = HexUtilities.HexEncode(tre.GetId());
               tbTag.Text = hex;
               tbTag.Refresh();
        }
      }
    }

    ImageNote The concepts from Chapter 6, including device connections, synchronous commands, and the TagReadEvent object, are exactly the same on the mobile and server platforms.

  9. The application is now ready to deploy to the device or emulator. For this exercise, the application will be deployed to the Windows Mobile 5 device simulator (which was installed with the Windows Mobile 5 SDK). From the drop-down box underneath the File menu, as shown in Figure 7-11, select the USA Windows Mobile 5.0 Pocket PC R2 Emulator option.
    Image

    Figure 7-11. Selecting the deployment device in Visual Studio

  10. In order to ensure that the appropriate libraries are accessible, the next step will be to deploy this application into the BizTalkMobile directory on the mobile device. From Solution Explorer, right-click the HelloMobileRfid project and click Properties. Click the Devices tab to bring up the Deployment Options page.
  11. Click the … button next to the “Output file folder” option to bring up the Output File Folder dialog, as shown in Figure 7-12. Change the subdirectory to BizTalkRfidMobile, and click OK.
    Image

    Figure 7-12. Changing the output directory

  12. Click Debug Image Start without Debugging to deploy the application to the emulator. This may bring up the Deploy dialog, as shown in Figure 7-13. If so, select the USA Windows Mobile 5.0 Pocket PC R2 Emulator, and click Deploy.
    Image

    Figure 7-13. Selecting the deployment target in Visual Studio

  13. After the emulator starts up and the application is deployed and launched, test out your first mobile RFID application. Click the Open RF button and then the Read Tag button. A simple tag ID should appear in the text box, as shown in Figure 7-14.
    Image

    Figure 7-14. Reading your first tag with BizTalk RFID Mobile

In the following sections, we are going to look at some of the features that are unique to the BizTalk RFID Mobile platform that make it easy for you to build mobile applications.

Asynchronous Event Notification

If your application requires you to receive events continuously from an RFID reader, instead of “on demand,” you can use the new NotificationEvent .NET event on the DeviceConnection object (provided this feature is supported by the mobile provider and RFID hardware). Using the NotificationEvent provides asynchronous notification functionality similar to an RFID process in the BizTalk RFID server world.

The code fragment in Listing 7-5 shows you a small example of how to do this.

Listing 7-5. Using the NotificationEvent in the DeviceConnection Object

static void HandleTagReadEvent(object sender, NotificationEventArgs args)
{
 TagReadEvent tre = args.Notification.Event as TagReadEvent;
 if (tre != null)
 {
  string hex = HexUtilities.HexEncode(tre.GetId());
 MessageBox.Show("Read tag " + hex);
 }
}

You can hook the NotificationEvent up to the DeviceConnection class as follows:

connection.NotificationEvent += HandleTagReadEvent;

and when you are done, you should unregister your callback as follows:

connection.NotificationEvent -= HandleTagReadEvent;

Note that the C# delegate simply provides a channel for receiving events as the underlying RF module raises them. For the module to actually start reading (and raising asynchronous events), typically you have to do one of two things:

  • Set the Source:ContinuousRead property on the device connection to True. Setting this tells the RF module to continuously poll for tags.
  • Use triggers to control the read operation. The use of triggers is covered in the next section.

ImageCaution Polling for tags is usually a very power-intensive operation; if you are going to use continuous read, you should have a way to enable and disable it, either by user input, triggers, or timers from your application. If you don’t have these controls, you can quickly drain the battery on the device. In addition to this, if a Windows Mobile device enters its hibernation or power-saving state with an active RFID connection, the connection state may not automatically reset.

Using Triggers to Control Asynchronous Notifications

Most handheld RFID and bar code scanners come with triggers, or simple pull-release mechanisms for the operator to interact with the application on the device. In a warehouse or plant floor environment, triggers tend to be used heavily for user input, as compared to other methods such as typing with the keyboard or tapping with the stylus on the screen.

Since the most common operations in an RFID application will involve enabling RF to read tags and then turning it off, BizTalk RFID has some pretty nifty functionality to enable this set of scenarios with very few lines of code (provided the device and RFID module support triggers—it’s an optional feature in the DSPI).

connection.SetProperty(StandardDevicePropertyGroups.Notification,
                                        NotificationPropertyGroup.OnTriggerPull,
                                 TriggerAction.ScanRfid);

The permissible values for trigger action include whether you want to scan RFID tags, bar code tags, both, or none.

BizTalk RFID Mobile also recommends that the device expose trigger events as keypress events, so if you want to use the trigger for some other part of the application, you should use the ScanNone option and handle the keypress event in the application.

Combining the trigger with the notification event delegate gives you a very convenient way to get asynchronous event notification, with the RF module actually coming on exactly when the user presses the trigger, so it is power efficient and works with a minimal amount of code on your part. If your handheld device supports triggers, this is the best way to read tags from a device.

Scanning Bar Codes from Your BizTalk RFID Mobile Application

BizTalk RFID Mobile preserves the concept of a source in the same way that the desktop platform does. You should check with your hardware provider for details on the number of sources. Typically, there should be two sources on a handheld, supporting both RFID and bar code scanning, and the bar code scanner source should be disabled by default (since the platform assumes that RFID is the primary scenario for BizTalk RFID Mobile).

If you need to access the bar code scanner engine, enable the bar code source, and then set the OnTriggerPull property to the appropriate value. Once you do that, bar code events will also be delivered up through the same notification event mechanism. The code snippet in Listing 7-6 illustrates how you would enable bar code functionality (assuming the source on your device is called “Barcode”).

Listing 7-6. Enabling Bar Code Functionality

void EnableBarcodeScan(DeviceConnection connection)
{
    // Enable the Barcode reader (source) by setting its Enabled property to True
    connection.SetProperty("Barcode",
        StandardDevicePropertyGroups.Source,
        SourcePropertyGroup.Enabled, true, null);

    // Set the asynchronous notifications to raise events from the "Barcode" source
   // not the RFID source
connection.SetProperty(StandardDevicePropertyGroups.Notification,
        NotificationPropertyGroup.OnTriggerPull,
        TriggerAction.ScanBarcode);

    // Capture asynchronous notifications from the device in the HandleTagReadEvent
    // method
    connection.NotificationEvent += HandleTagReadEvent;
}

Within your event handler, you can check if the event is from the bar code scanner by using the TagType property. If it is a bar code scan, the additional properties shown in Listing 7-7 are available to decode the bar code symbology and the human-readable text for the bar code.

Listing 7-7. Handling Bar Code Events

static void ProcessBarcodeScan(TagReadEvent tre)
{
    // Determine if the TagReadEvent is a bar code
    bool isBarcodeScan = tre.Type == TagType.Barcode;
    if (isBarcodeScan) {
        // Obtain the bar code binary ID
        byte[] binaryId = tre.GetId();

        // Obtain the data label from the bar code (i.e. the data)
        string textualBarcode = (string)
            tre.VendorSpecificData[BarcodeConstants.ScanDataLabel];

        // Obtain the encoding type of the bar code
        string symbology = (string)
            tre.VendorSpecificData[BarcodeConstants.ScanDataType];

        // Display the information to the user
        MessageBox.Show("Read barcode scan " + textualBarcode +
           "with symbology " + symbology);
   }
}

ImageNote Check whether your hardware provider vendor supports decoding bar code scans and the supported symbologies.

Integration with BizTalk RFID Server

BizTalk RFID Mobile was designed from the beginning to be tightly integrated with BizTalk RFID Server. It includes a component called the RfidServerConnector, which can be used to send events from the mobile device to BizTalk RFID. The API for using the RfidServerConnector is very straightforward, but you should understand how it works from a troubleshooting perspective.

The RfidServerConnector is a stand-alone agent that can take a tag read event from any application and post it to BizTalk RFID. Since connectivity between the device and the server could be intermittent, especially if you are using Wi-Fi or Bluetooth to establish the connection, the component supports an out-of-the-box notion of store-and-forward. If the connection is up, the event is sent immediately. If the attempt to send the event fails, the event is persisted to local storage and sent whenever the connection is reestablished.

By default, the RfidServerConnector will retry the connection every 60 seconds. However, this value is configurable in your application. Depending on the amount of RFID data that will be ready and the time between pushing the tag events to a central store, it may be a best practice to store the local SqlCe database on a storage card.

using (RfidServerConnector connector = new RfidServerConnector(defaultActiveSyncIp,
defaultPort))
{
    connector.Initialize();
    connector.Post(new RfidEventBase[] {tre});
}

Under the covers, the platform does a fair bit of work to implement the connector. It actually establishes a transport connection that uses LLRP to transmit the events over to the BizTalk RFID server, which must have the LLRP provider running. Here are the prerequisites for using the store-and-forward feature:

  • You must have the BizTalk RFID standards pack installed on the desktop machine, with port 5084 allowed through the firewall.
  • The LLRP provider must be running.
  • The device must be discovered and configured.
  • You must have an RFID process that is interested in events from the mobile device.

Remote Management Support

In the previous section, you saw how BizTalk RFID Server could receive events from the mobile device. That is actually just one half of the story. The other half is remote manageability. Yes, you can manage the RF functionality on your mobile device, using the familiar desktop RFID Manager. There are two ways to enable remote manageability; one is through the RfidServerConnector API described previously, and the other is through the RFID Manager application that is on the handheld device.

The default autoconfiguration IP for ActiveSync (or Windows Mobile Device Center) connections is 169.254.1.2, as shown in Figure 7-15 (a snapshot of the Manage tab in the RFID Manger mobile application). If you are not using ActiveSync (e.g., Wi-Fi), ensure that you have provided the correct IP address for the server.

ImageNote This remote management still requires some interaction from your handheld user—either the RFID Manager application on the handheld device must be running or some application must be using an initialized RfidServerConnector.

Image

Figure 7-15. Enabling remote management with RFID Manager (mobile)

Once the remote managemement functionality is enabled, you can browse properties, change settings, and apply them. The best reasons to do this are to enforce a standard set of property profiles on all your mobile readers (using the device template feature), and to centrally track changes to property settings.

The device management feature implicitly manages the first RF module on the device. This is controllable through the HKLMSoftwareMicrosoftRfidAgentModuleName registry setting on the device. Each source on the RF module is exposed as a source in RFID Manager, with the name Antenna_<source number>. Using this, you can change common properties such as power level, if the provider supports it.

ImageTip If you look at the Custom tab for the device from the desktop RFID Manager, you will see a number of LLRP properties. These are really intended for LLRP devices, and are not truly applicable to mobile devices. Scroll past them, and near the end you will see a category called RFID Mobile, which contains the custom settings that are valid for BizTalk RFID Mobile devices.

Storing Events Locally in a SQL Server CE Database

Just like the desktop version of BizTalk RFID has out-of-the-box support for storing events in a SQL Server database, BizTalk RFID Mobile has out-of-the-box support for storing events in a SQL Server Compact Edition (SQL Server CE) database. It has support for the standard TagRead and TagList events, including the vendor extensions on the TagReadEvent object. The core class for storing events is NotificationStorage.

By default, the object creates a SQL Server CE database called sink.mdf at the root directory of your device. You can customize the location using the connection string property. The following code fragment shows you how to post an event to the SQL Server CE database:

using (NotificationStorage storage = new NotificationStorage())
{
 storage.Post(tagReadEvent);
}

Tag Data Encoding and Translation

One of the new standards conformance features in BizTalk RFID Mobile is the TDT API. This includes a set of classes and helper utilities for translating between the serialized binary tag representation and the various standard encoding schemes, such as GTIN, GID, SSCC, SGLN, and so on. There exist two flavors of the encodings, one for 64-bit tags and another for 96-bit tags.

ImageNote The TDT API is an implementation of the EPCglobal Tag Data Standard (TDS) version 1.1, revision 1.27 of the spec.

You can use the classes to translate binary quantities to the specific encoding formats, and back to strings. Listing 7-8 outlines how to convert a raw value into an EPC.

Listing 7-8. Converting a Raw Value into an EPC

static void Translate(byte[] rawValue)
{
 IdentityEncoding decodedValue;
 if (IdentityEncoding.TryParse(rawValue, out decodedValue))
 {
  EpcEncoding epc = decodedValue as EpcEncoding;
  if (epc != null)
  {
   string uriEncodedString = epc.ToString();
  }
 }
}

The preceding TryParse pattern lets you translate values where you don’t know ahead of time if the tag is going to follow a particular encoding scheme or not. There are four important use cases for the TDT library:

Cross-enterprise scenario: If the tags in your scenario are going to be placed in one company and read in another company, as is the case in most global supply chain visibility scenarios, using a standard serialization makes your solution more open and interoperable. A corollary to this scenario is, if there are tags from other scenarios and companies floating around in your environment, being able to identify “your” tags in an easy and straightforward manner is valuable.

Pallet-case-item tagging and filtering: If you are going to tag items at multiple levels of granularity, and different scenarios require you to focus on different groups of tags, using the EPC encoding with its Filter property is both convenient and performant. In many cases, the Filter property can be expressed at the air protocol level or on the reader, thus reducing the event processing load on your application server.

Hierarchical item representation: If your products have a set of common attributes, you can model them using the ItemClass construct in the TDS.

Self-describing tags: This is an interesting scenario with some benefits, but also the potential for overuse. If you think of the classical way to use RFID tags, they represent an opaque identifier, or a license plate (think GUID in Microsoft terminology). Any interpretation would require a local database lookup of some kind before processing. With TDT, you can parse the information contained in the tags to potentially extract some business context directly without doing a database lookup. This could be extremely useful in the mobile context, where it would be impractical to have a database of RFID tags for product classes, for example. However, if you encode too much information in the tag, you run the risk of an inflexible solution, where changes to the information that you encode require rewriting a large number of tags, some of which may have figuratively, and literally, left the building.

Conclusion

In this chapter, we took a tour of the BizTalk RFID Mobile platform. We started with the overall architecture and installation, followed by a simple mobile application for reading tags. Finally, we looked at some of the new services that make it easier to write applications that need to interoperate between the mobile and desktop platforms. The key concepts to remember are as follows:

  • BizTalk RFID Mobile extends the reach of the BizTalk platform’s RFID capability to a wide range of Windows Mobile devices.
  • The mobile API is virtually identical to the server API, allowing developers to quickly ramp up on developing mobile RFID applications.
  • The mobile API includes support for automatically storing and forwarding RFID events into a server-side RFID process.
  • The TDT library can be leveraged both on the mobile and server platforms for managing tag data formatting in a standard format, such as SGTIN.

Building on the foundation of developing server-side applications (both synchronous and asynchronous), the next step will explore integrating the flow of RFID data with back-end business applications and systems.

CASE STUDY: MANAGING BURIED UTILITIES THROUGH MOBILE RFID

Industry: Utilities.

Overview: A firm that works with damage prevention and asset management has integrated mobile RFID into its infrastructure to enable the rapid location of buried utilities. In one scenario, RFID transmitters are embedded on buried pipelines at specific intervals. Information about the pipeline, including content (oil/gas/other), make (plastic/concrete/other), and metadata (such as date of placement) is added to the chip that is embedded. Once the pipeline has been buried, a mobile device can be used to locate the buried utilities and retrieve information.

Results: Rather than relying on the current methods of manually tracing utilities (using above-surface technologies), this approach ensures accurate locating of buried utilities. If successful, the company projects that damages resulting from poor utility management will be drastically reduced. Mobile RFID ensures accuracy and maintainability of data that does not exist in the utility industry today.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset