Microsoft BizTalk RFID with KalyanaJ

BizTalk RFID Setup: Troubleshooting

kalyanaj — Mon, 12 Jan 2009 04:06:06 GMT

We have recently heard one of our customers run into the following issue during BizTalk RFID installation:

-------

Error 1957. Failed to set permissions for user domain\account on the RFIDSTORE database on SQL Server FOO. One reason for this could be that we couldn't establish a connection to the SQL database. Please make sure you are using a domain account for the RFID Service account if you specified a remote SQL Server. See logs for more details.

-------

In this particular scenario, what was happening was that the account with which Setup was running was the same as the one specified for the RFID Service account credentials. While this may not be a very common scenario (as typically Setup is done by an account in the local administrators group and the default for the RFID Service account is .\RfidSvcAcc), I do see the possibility of somebody requiring this kind of a configuration. However, BizTalk RFID Setup doesn't currently support such a configuration, so I would strongly recommend ensuring during Setup that these two accounts are different.

BizTalk RFID Forums

kalyanaj — Fri, 19 Dec 2008 05:36:29 GMT

The BizTalk RFID MSDN forums has moved to the following new location: http://social.msdn.microsoft.com/Forums/en-US/biztalkrfid/threads/

This supports improved filtering/tagging, improved posting experience (dynamic posting, thread preview, real time updates), Live alerts and RSS support.

Do check out the new forums, and fire away your questions/feedback!

BizTalk RFID Mobile is here!

kalyanaj — Thu, 11 Dec 2008 05:20:29 GMT

I am very excited about the launch of BizTalk RFID Mobile and BizTalk RFID Standards Pack this month!

BizTalk RFID Mobile is the RFID platform for Windows CE/Mobile: our goal is to make it as easy as possible to build a rich RFID/barcode enabled mobile application. In addition to enabling the human workflow scenarios on the mobile device, it also provides store-and-forward capabilities to publish data to a BizTalk RFID Server. You can find the comprehensive details about the platform here. Of course, you will need the corresponding device providers for the mobile device, and you can find those links here. If you have any feedback, please do post on the BizTalk RFID MSDN forums.

BizTalk RFID Standards Pack includes a SDK for Tag Data Translation, a standards based discovery library, and a standards-based LLRP device provider which makes it easy to connect to any device that supports LLRP. The Standards Pack also enables the connectivity between BizTalk RFID Server and BizTalk RFID Mobile (for store-and-forward as well as for remote management of the mobile device from server).

Here are some links to the documentation/evaluation editions of BizTalk RFID Mobile and BizTalk RFID Standards Pack:

BizTalk RFID Standards Pack:

Installation Guides and Readme

Downloadable Documentation

MSDN Documentation

Trial Software

Code Samples

BizTalk RFID Mobile:

Installation Guides and Readme

Downloadable Documentation

MSDN Documentation

Trial Software

Code Samples

TechEd IT Pro 2008: BizTalk RFID Tech Talk

kalyanaj — Sun, 07 Sep 2008 16:47:00 GMT

The BizTalk RFID Tech Talk that Sudhir and I did at TechEd 2008 IT Pro has now been published to TechEd Online.

Tech Talk Video: Developing RFID-Enabled Applications with BizTalk RFID

In this session we discuss how RFID-enabled applications can be developed using BizTalk RFID Server and BizTalk RFID Mobile. We talk about simulated envionment, available for folks to develop without physical equipment. With J. Kalyana Sundaram and Sudhir Hasbe.

Downloads:

BizTalk RFID at Tech.Ed 2008 IT Pro

kalyanaj — Fri, 08 Aug 2008 11:31:08 GMT

I participated, as a co-speaker, in the TechEd IT Pro conference at Orlando during June this year. Our team had a few sessions here:

1) Deep Dive Into BizTalk RFID: This was a one hour interactive theater style presentation. Here, we started with a general overview of the BizTalk RFID, and then explained the concepts in BizTalk RFID using a shipping/receiving scenario. We used a fixed RFID reader and did a complete end to end demo on how a RFID business process could be set up that can get events from this device and store them into a SQL Server database. The attendees were really excited by the fact that events could go all the way to SQL database without writing even a single line of code. During the demo, we also added the Contoso provider (the simulated provider that ships with BizTalk RFID) and simulated five Contoso devices and showed them how they can use this to do their application development even if they don’t have a physical device. We also did some chalk talk on the general concepts.

2) Building rich RFID enabled applications for Windows CE/Mobile devices using "BizTalk RFID Mobile": This was a 75 minute breakout session. Here we spoke about the evolving mobile scenarios and form factors and the need for a mobile platform. We also went into the features and architecture of the platform. We had tagged some real products and demonstrated a picklist scenario on a mobile RFID reader running BizTalk RFID Mobile Beta and the corresponding device provider. We also did a RFID application development demo using the Windows Mobile emulators and attendees were able to appreciate how they can use this to do application development and testing without requiring to have a physical mobile reader.

There was lot of excitement about how simple it was to connect to a radio module, get notified about events, and post events to a server.

3) Tech Talk on BizTalk RFID: This was a 20 minute interview style video recording. Here, Sudhir and I talked about three main topics:

a) Application development with BizTalk RFID:

Event Handler development
Design vs. Deployment,
Integration with BRE/BizTalk Server, and
Mobile application development using BizTalk RFID Mobile.

b) Manageability: how RFID Manager, Client Console can be used to manage BizTalk RFID, and how System Center Operations Manager (SCOM) can also help in managing RFID devices.

c) How can a RFID application developer get started using emulators, Contoso provider / Contoso device simulator / MyFirstCEProvider etc.

This video will soon be posted to http://www.microsoft.com/teched.

Our booth:

We had a booth for BizTalk RFID in the SOA theme. Cathexis Innovations had an event management solution that they ran in the booth: for every attendee to the booth, we registered them and printed out a RFID tag for them using BizTalk RFID. This was affixed on their badges, and attendees could come back and get this scanned (in order to increase their chances of winning a Zune) using BizTalk RFID Mobile.

Device Security

kalyanaj — Fri, 08 Aug 2008 10:15:30 GMT

I had briefly touched upon Device Security in one of my earlier posts: in particular, the privileges needed for using the DeviceConnection methods. In this post, I will elaborate more on the same:

1) If you are performing a DeviceConnection operation that can potentially change the device (such as DeviceConnection.SetProperty()), the caller should have administrative privileges on the device. Having administrative privilege on a device means that at least one of the following should be true:

a) The caller is a member of the builtin administrators group on the server (OR)
b) The caller's account is a member of the device's custom administrator list (To view/modify this using RFID Manager, right click on a device -> Security). Note that in addition to being in the custom administrators list of the device, this account also should be added to the RFID_USER group on the server machine.

2) If you are performing a DeviceConnection operation that cannot change the state of the device (such as DeviceConnection.GetProperty()) or DeviceConnection.PrintTag()), the caller does not require administrative privileges. Any account in the RFID_USER group on the server machine should be able to perform such operations.

Here's the full list of DeviceConnection methods and the information on whether it requires administrative privileges:

Method Name in DeviceConnection	Admin privilege required
SetReadFilter	Yes
GetReadFilter	No
GetDiagnostics	No
GetCurrentPropertyProfile	No
GetDefaultPropertyProfile	No
ApplyPropertyProfile	Yes
GetProperty	No
SetProperty	Yes
ExecuteVendorDefinedCommand	Yes
GetTagData	No
GetPartialTagData	No
GetTagMetadata	No
GetTags	No
KillTag	No
LockTag	No
LockPartialTagData	No
UnlockTag	No
UnlockPartialTagData	No
PrintTag	No
WriteTagId	No
WriteTagData	No
WritePartialTagData	No
AddPrintTemplate	Yes
RemovePrintTemplate	Yes
GetAllPrintTemplates	No
GetAllPrintTemplateNames	No
GetCurrentPrintTemplateName	No
SetCurrentPrintTemplateName	Yes
GetPrintTemplate	No
GetStandardizedPrintTemplate	No
GetPrintTemplatePreview	No
GetPrintLabelPreview	No
GetSources	No
GetDeviceCapabilities	No

Note: If you are using DeviceManagreProxy.ExecuteCommandForConnection(), the same security model described above applies exactly to it as well. However, I would strongly recommend using DeviceConnection for such operations instead of DeviceManagerProxy. (DeviceConnection internally goes through DeviceManagerProxy).

Management Events in BizTalk RFID

kalyanaj — Thu, 17 Apr 2008 07:22:00 GMT

Sorry about the long hiatus - things have been pretty hectic in the last few months. Planning to catch up on all the missed blogging in the coming few weeks (things will always be hectic, so why wait any longer :)) !! If you have any specific topics in mind that you want the BizTalk RFID team to blog about, please send me a note.

Today, there was an interesting question from one of our IHV partners about the management events hierarchy, so that brings us to this post:

BizTalk RFID supports the concept of management events. A management event is an asynchronous event that can originate from a device or the device provider or even from the BizTalk RFID Service to notify the occurence of a specific condition.

Examples of management events:

1) An event "BizTalk RFID Service discovered a new device" (DeviceDiscoveryEvent) raised by BizTalk RFID Service. This is an example of an informational event.

2) An event "The source <foo> of Device <bar> is currently down" (SourceDownEvent) raised by the device provider. This is an example of a warning/error event.

For event handlers / apps / management consoles:

So, how can one subscribe to these events? BizTalk RFID Service exposes them to the outside world in two ways:

1) BizTalk RFID Service fires the management event as a WMI event. This applies to the events that originated from the device/provider and also the events that originated from the Service itself. The "RFID Tray" application that ships with BizTalk RFID (you can find it in the shortcuts in the programs menu) is an example of a "WMI consumer" application that subscribes to such events and displays them in its UI.

2) BizTalk RFID Service sends the management event to the RFID Process pipeline (i.e. notifies interested processes). This applies only to events that originated from the device/provider and not for events originating from the service. For e.g. if you have process P1 that was bound to device "D1" and if there is a BatteryLowEvent from this device, it will be sent to P1's process pipeline.

So, you can see that the above kind of events can be useful for a RFID administrator or an Event Handler writer to know about these conditions and take appropriate action when required. If you have MOM, you can use the MOM Pack as well.

There are a whole bunch of standard management events defined by BizTalk RFID - you can see the full list of derived classes from the base class documentation at http://msdn2.microsoft.com/en-us/library/microsoft.sensorservices.rfid.management.managementevent.aspx

For Provider Writers:

If you look at the hierarchy of the management events defined in the DSPI, there is a class ManagementEvent from which there are three derived classes:

        i) DeviceManagementEvent
       ii) ProviderManagementEvent
      iii) ServerManagementEvent

All the derived classes from DeviceManagementEvent (http://msdn2.microsoft.com/en-us/library/bb656891.aspx) and all the derived classes from ProviderManagementEvent fall in the domain of the provider; for e.g. the SourceDownEvent derives from DeviceManagementEvent and you should strongly consider supporting this in your provider/device. Anything which derives from ServerManagementEvent falls in the domain of BizTalk RFID Service (i.e. service will raise such events).

Also, please make sure your device capabilities is in sync with the management events that you support in your provider. For e.g. if you support SourceDownEvent, include that in your device capabilities.

Simulating multiple devices using Contoso device simulator...

kalyanaj — Thu, 04 Oct 2007 14:09:00 GMT

One recent question I got on BizTalk RFID was: "Is it possible to try it out with multiple simulated devices?"

The good news is "Yes, it is amazingly easy to do this" using the Contoso Provider / Device Simulator. Let's say you have added the Contoso Provider in BizTalk RFID using RFID Manager.

1. Go to %RFIDINSTALLDIR%\Samples\Device Service Provider\Contoso\ContosoEndToEnd\ContosoDeviceSimulator

2. Open ContosoSimulatorConfig.xml

3. Add additional sections here: add one section for each additional device that you want to simulate. Note that each section should have a unique name, unique device name, and unique port number. You need to change only the port information and can use the same IP address.

For e.g.

section name="DeviceInformation_2">

<entry name="DeviceName">ContosoTestDevice2</entry>

<entry name="ConnectionType">TCPIP</entry>

<entry name="ProviderId">Contoso</entry>

<entry name="NotificationDataFile">ContosoNotificationConfig.xml</entry>

<entry name="DeviceTranslatorAssemblyPath">Microsoft.Rfid.Test.ContosoDeviceTranslator.dll</entry>

</section>

4) Run “runContosoSimulator.cmd”.

Now, you can use the Add Device Wizard to add these simulated devices and connect to them.

DeviceConnection revisited...

kalyanaj — Fri, 21 Sep 2007 21:54:00 GMT

One client connection vs. multiple client connections:

We saw an overview of the DeviceConnection class (Microsoft.Rfid.Client) in an earlier post and how it can be used for configuration and operations on a device. Now, consider the scenario where there is a client application which has opened a connection to a particular device and is doing some configuration on it (say for e.g. SetProperty). If another client application wants to open a connection to the same device to configure/operate it, DeviceConnection.Open() doesn't allow it because having more than one application configuring/operating on the device at the same time could affect the state of the device and could potentially take the device to an undefined state. Hence, when the second client application tries to do a deviceConnection.Open(), it would get an exception such as:

"Cannot open a connection to device <devicename> because another client has already connected to the device. Retry the operation later"

That said, there is an override if your application is really sure of what it is doing and has the required administrative privileges: DeviceConnection.OpenAdministrationConnection(). You can use this if you are sure that you are not stepping on some other client that is connected to the device.

Device Security:

What privileges are needed for using the DeviceConnection methods? Any operation that can potentially affect/change the state of the device requires the caller to have administrative privileges on the device. Having administrative privilege on a device means that atleast one of the following should be true:

1) The caller is a member of the builtin administrators group (OR)
2) The caller is a member of the device's custom administrator list (To view/modify this using RFID Manager, right click on a device -> Security)

So, using DeviceConnection.OpenAdministrationConnection() or DeviceConnection.SetProperty() or DeviceConnection.ApplyPropertyProfile() are considered "state changing operations" and hence would require one of the above two privileges. Using DeviceConnection.Open() or DeviceConnection.GetProperty() or DeviceConnection.PrintTag() are not considered to change state and hence don't require the above privileges - just being a member of the RFID_USER group (a Windows group created by BizTalk RFID during its installation) is enough to do such operations. Note that tag related operations (GetTags(), PrintTag() etc.) fall into the latter category. By default, devices in BizTalk RFID inherit security options from the parent device group.

Using DeviceConnection from an event handler:

If you have an event handler running as part of a RFID process, you may want to use DeviceConnection to do operations such as getting/setting the I/O port value on a device. This scenario is considered to be very similar to any other standalone client application using DeviceConnection. Let's say you want to do a state changing device operation from an event handler such as DeviceConnection.SetProperty(). If you see an exception such as the one below, it means the context in which the event handler is running doesn't have the required privileges to do the operation:

System.IO.SensorServices.Rfid.Client.DeviceManagerException: Insufficient permissions to perform the requested operation on device entity <device name>.

at System.IO.SensorServices.Rfid.Client.DeviceConnection.ExecuteCommand[TCommand](String deviceSourceName, TCommand cmd, VendorDefinedParameters parameters)
at System.IO.SensorServices.Rfid.Client.DeviceConnection.SetProperty(String sourceName, String groupName, String propertyName, Object value, VendorDefinedParameters parameters)

An event handler runs in the context of the "RFID Service Account (RSA)" on Windows XP / Windows Vista; it runs in the context of a "Worker Process Account (PSA") on a Windows Server 2003 computer. If this account is not part of the device's custom administrator list, it means that it does not have the privileges to do the operation. You can resolve this easily by adding PSA (on a Windows Server 2003 computer) or the RSA (on a Windows XP or Windows Vista computer) to the device's administrator list, using RFID Manager -> Right click on the device or device group -> Security -> Add.

To summarize, any client application or an event handler using the DeviceConnection.Open() or DeviceConnection.OpenAdministrationConnection() is considered to be a "synchronous client". There could be any number of running "RFID Processes" bound to a device and be receiving notifications from the device. Internally, BizTalk RFID maintains only a single connection to the device and closes this connection only when the final interested process or the client goes away. I will post more on the device connection management in a later post.

Auto-Apply of non-persistent properties...

kalyanaj — Mon, 17 Sep 2007 18:39:00 GMT

I briefly touched upon device properties (in my earlier post on device configuration and management) in the example of how to get the current device property profile. The "current property profile" of a device or source includes all the properties applicable to the device or source, including the standard properties (those that are defined by BizTalk RFID DSPI) as well as any additional custom properties of a specific device. Now, it may not be feasible for the provider or the device to persist the values of all of these properties, say for e.g. across a reboot of a device. To address such a scenario, BizTalk RFID provides support for a provider to specify the persistence status for a property (using the IsPersistent field in the device property metadata). Based on this information, BizTalk RFID automatically applies such properties every time after it establishes connection to a device.

For e.g., you may notice something similar in your RfidServices.log file:

Here's some background on how BizTalk RFID accomplishes this: every time there is a change in the value of one or more properties (for e.g. when you set a property or when you apply an entire property profile) BizTalk RFID creates a new version for the device in its version store to track the changes. After every successful connection to a device, it checks with the provider (using its device property metadata) if there are any properties that the provider is not persisting. If it finds such properties, it applies the values for these properties based on the latest values from its version store. Note that the same thing applies for the source/antenna properties as well...

By default, this behavior is enabled and shouldn't be modified. If you really need to turn this behavior off, you can do that by setting RFID Manager -> Devices -> Connection Parameters -> "Auto-apply Non-Persistent Properties" to false.

Device States in BizTalk RFID...

kalyanaj — Mon, 17 Sep 2007 16:11:00 GMT

In this post, I will talk about the various states of a device added in BizTalk RFID. Before I jump into that, want to quickly mention that you can use the "Contoso Provider" and the "Contoso Device Simulator" that come with BizTalk RFID (as part of the SDK component) to simulate a device. You can run the device simulator by changing directory to %RFIDINSTALLDIR%\Samples\Device Service Provider\Contoso\ContosoEndToEnd\ContosoDeviceSimulator and then launching runContosoSimulator.cmd. This will launch a device at 127.0.0.1 at port 6666 and you can add this device to BizTalk RFID.

Now, back to device states - the following is the overview of the various states (you can observe these using RFID Manager):

1) Open: BizTalk RFID Service (hereafter referred to as "the service") is connected to this device. This can happen in the following scenarios:
a) You have one or more running "RFID processes" that are "bound" to this device. (and/or)
b) You have a client application running that has opened a connection to this device.

2) Closed: The service is not currently connected to this device. Obviously, this means that there are no running processes or applications that are interested in this device.

3) Retrying: The service will retry connection to this device periodically as it couldn't connect successfully in an earlier attempt. This can happen in the following scenario:
a) There are one or more running "RFID processes" that are "bound" to this device, (AND)
b) The service couldn't connect to this device successfully in an earlier attempt.

How frequently does the service re-attempt a connection to such a device? In RFID Manager, if you right click on the Devices node on the left, and select "Connection Parameters", you can see a "Connection Retry Interval" parameter. This defaults to one minute, and can be tweaked appropriately to suit your needs.

How many times does the service re-attempt a connection to such a device before giving up? In the same "Connection Parameters" dialog, you can see a "Maximum retry attempts" parameter. This defaults to 10 attempts. Again, you can configure this parameter based on your environment.

You would also notice a parameter called "Connection Check Time" in the same dialog. For connected devices that are associated with a RFID process, the service has a mechanism to automatically verify periodically if the connection is still alive. The "Connection Check Time" parameter dictates how frequently the service should verify the validity of such connections. If the device is not found to be alive, the service automatically re-attempts a connection to this device. Note: I say "for a device associated with a RFID process" specifically because this automatic connection checking is not supported for a device connected through only a client application.

4) Disabled - Failed: We talked about the maximum number of retry attempts above. What happens when the service gives up? It takes the device to the "Failed" state. In this case, it might require the manual intervention of an administrator to fix the connectivity issue (for e.g. fix the IP address or fix a network problem). In most cases, the device has to be enabled manually before it can be used again. I say most cases because there is also a way in which BizTalk RFID can automatically bring back to life such a device: if it receives a discovery event for the same device from the provider, it will automatically enable the device. For e.g. there could be a mobile device which has gone out of scope and when it re-enters the system, the discovery event acts as a nice mechanism for automatically re-enabling such a device.

There is another scenario (probably less common compared to the above) where a device can get into the "Failed" state and that's when the provider corresponding to a device is "stopped" while a connection to the device is open. In such a case, the device is taken to the "failed" state. When the provider is started again, the service will automatically re-attempt a connection to the device if there is atleast one RFID process that is bound to this device. If there is no RFID process interested in the device, the device will transition to the "Closed" state. Note that in this case the manual action to transition the device out of the failed state is to just start the provider.

5) Disabled - UnConfigured: This is the default state of a newly discovered device. Enabling such a device typically involves providing the authentication information required to connect to this device (if any). An administrator has to manually enable such a device before it can be used.

6) Disabled - Name Conflict: This indicates that the "physical name" of a device is different from its "logical name" (the name with which it was added to BizTalk RFID). This can happen in the following scenario:

a) The physical device supports the NAME property and it is a writable property (AND)
b) When starting a RFID Process, the service finds that the physical name is not the same as the logical name.

An administrator has to manually enable such a device before it can be used. An easy way to fix this would be to rename the device and provide a new name so that the service can apply the same name to the physical name as well.

7) Disabled - Manually Disabled: You can also manually disable a device to temporarily put it out of use; this can be useful for any troubleshooting/maintenance activities on the device. An administrator has to manually enable such a device before it can be used

To manually enable a device from any of the above four disabled states, you can right-click on a device in the Devices node of RFID Manager, and click "Enable".

So, how do you track such state changes? For e.g. how can you detect quickly when you lose connection to a device and it goes to Retrying state? BizTalk RFID raises various management events, for e.g. DeviceConnectionAttemptFailedEvent when the service is not able to connect to a device. These are WMI based events and you can have your own WMI consumer client to listen to this events or use the "RFID Tray" application to view these events, or better still use MOM to manage such events. I will detail out the various device related management events in a future post...

Device Configuration and Operations...

kalyanaj — Sun, 16 Sep 2007 08:41:00 GMT

In my earlier post, I gave an overview of the various approaches in which you can add/register a device with BizTalk RFID. Now that you have the device added, I am sure you can't wait to configure it and start putting it to use. So, how do you use BizTalk RFID to configure it as well as do certain operations on it? I will explain both the RFID manager part of it as well using the Object Model to do this programmatically, in that order.

A. Configuration (using RFID Manager): This can involve setting properties on the device, for e.g. the Regulatory Region or the event mode. In RFID Manager, right-click on a device, and then select Properties. RFID Manager will first attempt connect to the device; if the device is online, it will retrieve the latest values for the properties from the device ("current property profile") and display the properties in the Properties Dialog. If RFID Manager is not able to connect to the device, it will display the last known version of the property values: in this case, you will notice that you will only be able to view the properties and not edit them. The device needs to be online to be able to edit the properties as well. What about the properties of a device's sources/antennae? You can view the important properties of the antennae in the Sources tab of the Device Properties dialog; to view the rest, you can go the Custom tab of this dialog and select a particular source to view its other properties.

B. Operations (using RFID Manager): RFID Manager provides support for certain common operations on a device: one example is to view tags from a device. You can right-click on a device, and then select View Tags. You will be able to configure the refresh interval as well. There are other such device operations as well that are supported from RFID Manager.

C. Configuration/Operations (Programmatic): Now, on to the programmatic part: most of the device configuration and operations can be represented as "Commands" in the BizTalk RFID Device Service Provider Interface (DSPI). For e.g. you have a GetCurrentPropertyProfileCommand to get the latest property profile from a device, or a SetPropertyCommand to set the value for a particular device property. Similarly, you have a "GetTagsCommand" or "PrintTagCommand" for various device operations. From the Object Model perspective, the execution of these commands are synchronous in nature. You need to open a connection to the device before you can execute a command on it. I will give you two approaches by which you can achieve this:

1. Using DeviceConnection (recommended):

The DeviceConnection class is the recommended approach when you want to do programmatic configuration/operations on a device.

for e.g. to get the current property profile, here's a rough idea of how you can use the DeviceConnection class (Note: exception handling not included in the below samples):

using (DeviceConnection deviceConnection = new DeviceConnection("localhost","ContosoTestDevice"))
{
deviceConnection.Open(); // open a connection to the device
PropertyProfile properties = deviceConnection.GetCurrentPropertyProfile();
}

for e.g. to kill a tag:

using (DeviceConnection deviceConnection = new DeviceConnection("localhost","ContosoTestDevice"))
{
    deviceConnection.Open();
    byte[] tagId = new byte[] {1, 2, 3, 4, 5, 6, 7, 8};
    deviceConnection.KillTag(tagId);
}

[You will have to add a reference to Microsoft.Rfid.Client.dll]

Overall, there are lot of other such methods in the DeviceConnection class for various configurations/operations on a device. The typical pattern for each operation/configuration method is that you will find a simpler overload for the most common usage, and you will find a more advanced usage if you want to specify more options (for e.g. if you want to perform the operation/configuration on a particular source of a device, there is an overload where you can specify the source name). You can use this class from a standalone application or from your own BizTalk RFID event handler that is part of a RFID business process.

2. Using DeviceManagerProxy:

The DeviceManagerProxy provides support for:

Opening a connection to a device : OpenConnection(),
Executing a command on the device/source : ExecuteCommandForConnection(),
Closing the connection to the device: CloseConnection()

In this, you will have to build a "Command" object and execute it - for e.g. to build a SetPropertyCommand to modify the location property,

PropertyKey locationKey = new PropertyKey(StandardDevicePropertyGroups.General, // General Group
GeneralPropertyGroup.Location); // Location Property
EntityProperty locationProperty = new EntityProperty(locationKey, "New Location");
SetPropertyCommand setPropertyCommand = new SetPropertyCommand(locationProperty);

DeviceConnection uses this model internally, and it is recommended to use the DeviceConnection model rather than using the DeviceManagerProxy directly.

Download the documentation!

kalyanaj — Fri, 14 Sep 2007 16:50:00 GMT

There is a convenient download link to download the Help file, Tutorials etc. for BizTalk RFID. The BizTalkRFID.chm file is the comprehensive help file that you can use for API reference as well as for other deployment operations. Check it out at: http://www.microsoft.com/downloads/details.aspx?FamilyID=22b2e8d9-8cda-44f8-8f4e-b372c7660989&DisplayLang=en.

-Kalyan

Adding/Registering a device with BizTalk RFID

kalyanaj — Fri, 14 Sep 2007 15:47:00 GMT

In this post, I will attempt to give an overview of the various methods in which you can add/register a device with BizTalk RFID. You can use "RFID Manager" (the MMC based management console which ships with BizTalk RFID) to check out most of these concepts. The following are the main ways in which a device can be registered with BizTalk RFID:

1. Device Discovery: If your device provider supports discovery, it can post a discovery message to BizTalk RFID. If BizTalk RFID determines that the discovery information corresponds to that of a new device, it will add this device to its list of devices and will set it to "Unconfigured" state. The newly added device will instantly appear in the Devices view in RFID Manager. The main thing to note here is that you need to "enable" the device before you can start using this device. Enabling such a device typically involves providing the authentication information required to connect to this device (if any). To do this, you can right-click on a device in the Devices node of RFID Manager, and click "Enable".

You can also use the "Trigger Discovery" functionality to manually trigger the above discovery process. To do this, you can right-click on a provider in the Providers node of RFID Manager, and click "Trigger Now".

2. Adding a device manually: You can use the Add Device Wizard in RFID Manager to add a device. You need to specify the following:

The name of the device provider: i.e. what provider should this new device use)
The connection information (i.e. how should BizTalk RFID connect to this device): For e.g. if you select TCP/IP, you need to specify the IP address and port number information of the device. In this list, you will see only those specific transport settings that are supported by your particular device provider. For e.g. if you don't see "Serial", it means your device provider doesn't support this particular transport setting.
The authentication information required to connect to the device (if applicable)
The DeviceGroup under which this device should be added (by default, it is "RootDeviceGroup" which is the root of the hierarchy)

Add Device Wizard will try to connect to the device based on the connection information you specified and will retrieve certain properties such as name, location and description. You can optionally change these values and complete the device addition. If RFID Manager is not able to connect based on the specified connection information, you still have the option of adding the device ("offline" mode). Unlike a device added through discovery, a device added in this way is by default in the "enabled" and usable state.

3. Bulk Addition of devices: Very similar to 2) above, but here you have the option of adding more than one device at the same time. In Add Device Wizard in RFID Manager, you can select the "Add Multiple Devices" option and you can specify a range of addresses. RFID Manager will attempt to connect to devices in this range and you also have the option to specify that devices found in this fashion be added automatically.

4. Your own client application: You can write your own client application which uses the BizTalk RFID Object Model to add a device. You can use DeviceManagerProxy.AddDevice() and specify the above details and choose whether you want to add the device in online mode or offline mode. You need to add references to "Microsoft.Rfid.Design.dll", "Microsoft.Rfid.SpiSdk.dll", "Microsoft.Rfid.ManagementWebServiceProxies.dll".

The following is the SAMPLE code for how this can be done (you need to have Contoso simulator running if you want to really see this in action):

using System;
using Microsoft.SensorServices.Rfid.Design;
using Microsoft.SensorServices.Rfid.Dspi;
using Microsoft.SensorServices.Rfid.Management;

namespace AddDeviceApp
{
    class Program
    {
         static void Main(string[] args)
         {
              TcpTransportSettings transportSettings = new TcpTransportSettings("127.0.0.1", 6666);
              ConnectionInformation connectionInformation = new ConnectionInformation("Contoso", transportSettings);
              UserDeviceInformation deviceInfo = new UserDeviceInformation(connectionInformation, null);

              // Build the device definition
              DeviceDefinition deviceDefinition = new DeviceDefinition(deviceInfo, "ContosoTestDevice", null);
              DeviceManagerProxy deviceManagerProxy = new DeviceManagerProxy();

              try
              {
                  deviceManagerProxy.AddDevice(deviceDefinition, DeviceGroupDefinition.RootDeviceGroupName, false);
                  Console.WriteLine("Device added successfully in online mode");
              }
              catch (RfidClientException rfidException)
              {
                     // hit exception while trying to add in online mode
                     Console.WriteLine("Online AddDevice encountered exception {0}", rfidException);
                     // process exception appropriately
              }

              Console.ReadLine();
        }
   }
}

Isn't this cool :)? You can explore the full power of the Object Model using Visual Studio Intellisense or by looking at the BizTalk RFID developer reference at http://msdn2.microsoft.com/en-us/library/bb769184.aspx.

That's it for now. If you have any specific topics that you would like to see, please do give me feedback and I will attempt to address it in future posts.

-Kalyan

BizTalk Server 2006 R2 RTM is here!

kalyanaj — Thu, 13 Sep 2007 09:27:00 GMT

BizTalk Server 2006 R2 final RTM version has been launched! This includes BizTalk RFID and I will be blogging more about the various features of RFID, particularly related to device management and RFID Manager.

http://www.microsoft.com/biztalk/technologies/rfid/default.mspx has more details. You can download an evaluation version from: http://www.microsoft.com/biztalk/default.mspx