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.