Just lost a couple of hours I will never get back…

I am in the process of upgrading one of our RFID applications to 2010 beta. The upgrade went through without a hitch and I found myself the proud owner (or at least caretaker) of a brand-spanking new BizTalk RFID Server 2010.

(No visible differences to BizTalk RFID Server 2009 – except for the icon)

I then proceeded to upgrade my Visual Studio 2008 projects to VS 2010. WOW!!! Build succeeded first time…I am on a roll baby!

So I imported my Process into RFID Manager and fired her up…

The WCF service was not responding. So I open up IIS Manager (my VM is Windows Server 2008 so I’m running IIS 7) and try to browse to the hosting.svc under my RFID process VD and I get a http 401.3 error. Where do I start to hunt this down. I have installed .NET Framework 4.0, VS 2010, BizTalk RFID Server 2010 (plus Silverlight 4, Windows Azure platform AppFabric 1.0, … ).

So I check:

• Application pool identities are correct – Tick
• Application pool framework version – v4.0 Classic mode
• Authentication set to Anonymous – Tick
• Anonymous user set to application pool identity - Tick
• NTFS permissions on the VD - Tick
• Test Pass-through authentication – Green Lights
• IISRESET (last desperate attempts of a beaten Sco)

Still no go. I get on the “bat-phone” to Ninja Mick and explain what's happening. He just laughs…”What! Another 401 error. That’s about the sixth this week”. He points me off to a KB article about disabling the loopback check (I am using host headers on my RFID Services site). Still no go but it hinted at the problem…host headers.

Back into RFID Manager and look at the Advanced Server Properties

Even though these settings are technically correct and BizTalk RFID Server creates the provider and process services without error, I needed to set the Host IP address to the host header name I am using. This appears to have changed between either BizTalk RFID Server 2009 > 2010 or a change to IIS, Windows Update, .NET 4.0 … your guess is as good as mine?

After setting this to the host header name all worked fine and I’m back to sending my tag read events into BizTalk RFID Server 2010

This week the Breeze RFID Team will be show casing an innovative RFID Document Management solution at CeBit. We have teamed up with Magellan Technologies to develop a hardcopy (paper) document workflow solution built on the Microsoft SharePoint platform. The solution allows printed documents to participate in document management workflow in the same way as traditional electronic documents.

Our partners, Magellan, have some very cool RFID gear on show including their RFID Document Tray Reader and their RFID Bookshelf Reader that we use in the demo.

So if you're at the show, pop in and say hi to the team.

When developing applications, at some point in the dev cycle we want to know how the system will perform under load. In BizTalk RFID land it is no different. In fact, in BizTalk RFID implementations we often deal with devices capable of raising hundreds of reads every second. So how do we go about testing these?

I'm a big fan of using physical devices during development rather than device emulation, but when it comes to load testing we need to present hundreds of tags to the reader and no matter what I try I just can't get the work experience kid to act fast enough! But instead of using a emulated device, what if we could raise tag read events programmatically and have our RFID Process consume them? Surely then we could get enough events to constitute a decent load test.

So how do we go about pushing tag read events through our RFID process in code?

We do this using the BizTalk RFID management API's, namely the ProcessManagerProxy. In just a few lines of code we can connect to the RFID process we want to test and "submit" a tag read event to the event pipeline. To get up and running with this you will need to add the following references to your project: (all can be found in %RFIDINSTALLDIR%\bin)

• Microsoft.Rfid.Design.dll
• Microsoft.Rfid.ManagementWebServiceProxies.dll
• Microsoft.Rfid.SpiSdk.dll
• Microsoft.Rfid.Util.dll

Then, in three lines of code you can create your tag read event, connect to your process, and submit your event for processing;

            // Create the tag read event
to submit
            TagReadEvent tag = newTagReadEvent( HexUtilities.HexDecode(strTagID), TagType.EpcClass1Gen2, HexUtilities.HexDecode(strTagData),
strTagSource, DateTime.Now, null, null ); //
Connect to the local RFID serverProcessManagerProxy proxy
= newProcessManagerProxy("localhost"); //
Submit event to the event pipeline proxy.AddEventToProcessPipeline( strRfidProcessName,
tag, strLogicalDeviceName); 

And that's it.

For my needs, I created a quick Win forms app that retrieved a list of registered tag id's from a SQL DB and submitted them to my RFID process at configured intervals:

I added a few variables to adjust the interval between tag read events, the number of events to submit each interval, and the number of duplicates to send for each tag id. These variables (used when looping through the set of tag id's) combine to give me a good approximation to a real, high volume environment.

Firing up good old perfmon and adding the RFID:Process counters, I ran through a number of test configurations to make sure my RFID process performs well under high load. (Note: the RFID process you are monitoring must be running before you can add the counters). Of most interest is the Tags In Queue counter. This tells me when my process is not performing well and tags are being queued up waiting to be processed (not good in real-time processing systems). We want this to be flat-lined most of the time.

Another good idea is to use the SQL Sink EH component while testing. After running your tests you can simply and easily calculate event processing latency by executing the following T-SQL query against the tagevents table in the RfidSink DB.

            SELECT
            
              AVG
            (DATEDIFF(ms,
sinktime, tagtime)) FROM tagevents;

A while back, Mickposted about a great article on MSDN around performance and capacity planning for BizTalk RFID. Some goodness in that article so check it out as well.