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.

Ever seen some of those videos of mobile phones frying popcorn? Mick posted some a few days ago and my wife and I thought we could use a snack while we watched a movie last night.

We tried to "cook" a small number of popcorn kernels using two Sony Eriksson K610i's, a connected Bluetooth headset, and an old Motorola E386 (similar setup to that in the videos from Mick). The K610's have a SAR rating of 1.01 (as reported on the SAR Shield web site)

The result...we went hungry. And we did leave the calls open for a minute or two, stopped and started calls, even sent picture messages from one handset to the next. I don't think they emit nearly enough RF to pop the kernels. It takes the microwave (895W) a few minutes to do the job, we would have to have the phones (~0.7W) in talk/data mode for over a day to get close to that amount.

20 minutes wasted. Luckily we have one of those mobile plans were we get free calls between our phones.

That got me thinking....we need more power.

So I hooked up three UHF long range RFID antennas and placed some rather nervous looking kernels in the middle. At 2W each, it still would of taken around 5 hours to get some popcorn. These puppies can read tags at 10m (even through walls as I discovered) but excite a popcorn kernel, they can not...we need more power.

What I need is one of those "lasers"

Who wants steak!

While working on a BizTalk RFID project we (Mick, Rahul, and I) wanted to explore whether we could use Silverlight (SL) to display tag read events as they are captured. As usual in these scenarios, I started writing wonderfully creative cheque's my graphic design skills could not cash. Eventually I put together an acceptable looking SL page with a couple of animated user controls to represent the received tag read events and counters.

The trick was how do we notify the SL application of the tag read event. At first we went down the client polling route and that worked out fine, but we really wanted something akin to duplex communications in WCF. That is, we want the service to push data out to the client when the service receives the event.

At the time we were working with SL 2 Beta 1 and quickly realised two constraining factors

1. Silverlight only supports http based WCF bindings.
2. Security restrictions prevent the SL application from creating callback listeners.

Luckily for us Tech.Ed 2008 in the US was running and the team at Microsoft announced Beta 2 with support for a polling duplex communications model. After decoding the beta documentation , and some help from learned blogger's, we cracked that puppy and got a Silverlight 2 Beta 2 version working.

Here is a outline of the WCF bits of the Silverlight solution.

• Create a new "Silverlight" flavoured WCF service containing both a service contract and a client callback contract (a duplex service).
  
  
  
• Implement the SubscribeToEvents operation ensuring you set a reference to the client callback channel. This is how we send events back to the SL application.
  

  // Obtain a reference to the client callback
           channel _callback = OperationContext.Current.GetCallbackChannel<IDuplexServiceCallback>();

• Implement the client callback. In our case, when the WCF service receives a tag read event from BizTalk RFID, we create a new message instance containing the event data and invoke the client callback method NotifyEvent()
  

  // Construct NotifyEvent message Message
           message = Message.CreateMessage(MessageVersion.Soap11, "Silverlight/IDuplexService/NotifyEvent",
           xmlEventData); // Push event to client _callback.NotifyEvent(message);
  
  

• Create your own service host and custom binding that uses the PollingDuplexBindingElement located in the new System.ServiceModel.PollingDuplex assembly in the SL 2 Beta 2 SDK (the one in the ..\Libraries\Server\Evaluation folder).
  
• In the SL application we create a duplex polling receiver class (see the Silverlight documentation for details) and use the PollingDuplexHttpBinding class to create factory and channel objects to send a message to the service. We then start a message receive loop to listen for messages sent by the service.
  
• Received events are then routed to the SL Page class. In our SL Page class we create instances of user controls for each event received and update some running counters.

I did feel some pain around the WCF message formats (see point 3 above). At first I got the message action wrong, but no exceptions were thrown at all warning me of this...the SL application just sat there waiting for the callback. You have to make sure the message action here matches the callback operation exactly. That is, <ServiceContractNamespace>/<ServiceInterface>/<Operation>.

As this is just a POC, I'm sure it will completely change (more than once) as it matures into production ready code, but I thought I might share what we are doing around Silverlight, WCF, and BizTalk.

Also, Dan Wahlin has a great post detailing how to push data to a Silverlight application using WCF duplex services. Much of his work was used to understand how to put all these Silverlight and WCF pieces together. Thanks heaps Dan.

Recently I implemented a BizTalk web services interface that required the need to support SoapFault messages. I quickly fell into a common trap and received a compiler error:

error X2162: must receive before sending a fault message on an implemented port

(see Scott Colestock's post that nicely outlines his experience with the same issue)

As Scott describes, the solution involved using the succeeded() function to first test if a transaction scope had succeeded or not in order to send out my soap-fault correctly. I vaguely recalled this function but never used it in anger before. After having spent a hour or so I will never get back, I made a note-to-self to seek out and reacquaint myself with the other operators and functions available to use in expression shapes within an orchestration.

Here is the full list taken from the online documentation:

Since then, this little exercise has helped in a few occasions, particularly the need for the exists function when working with optional property schema fields.

I knew I should of read the manufacturers instructions

Today I was working on a BizTalk solution to intercept, transform, and relay emails sent from a LOB system. BizTalk polled a POP3 mailbox and my orchestration replaced the original plain/text email body with some fancy, template driven HTML content and sent it out a dynamic SMTP send port. Only the email body was to be modified, the rest of the email message was to replicate the original email message, including any attachments (that may or may not be present).

To aid in testing I wrote a simple .Net email client. (I got tired of composing a new email in Outlook every time I wanted to test the solution)

The solution worked well (and perhaps I may post about the details sometime later) accept for the fact the outbound message had lost the attachment filenames.

Note: The attachment on the outbound message has a filename of ATT00241.DAT

A helper class in my orchestration inspected the inbound message for attachments and added them to the new outbound message. Each message part (attachment) was assigned the MIME message part context properties of the same inbound message part. What I found was the MIME.FileName property was not being populated by the MIME decoder.

The MIME decoder in the POP3 adapter (when configured to apply MIME decoding) populates the following message part context properties when a MIME encoded message is received:

I checked the message source of the email I was sending (via my DIY email client) to check the MIME headers were present.

Appears OK right?...

content-type: application/octet-stream; name=SampleAttachment.zip
content-transfer-encoding: base64

Wrong

It turns out the MIME decoder is looking for the content-disposition header values

content-type: application/octet-stream; name=SampleAttachment.zip
content-transfer-encoding: base64
content-disposition: attachment; filename=SampleAttachment.zip

So some quick changes to the Breeze Simple Email Client ...

attach.ContentDisposition.DispositionType = System.Net.Mime.DispositionTypeNames.Attachment
attach.ContentDisposition.FileName = Path.GetFileName(attachmentFileName)

...and we were back to cooking with gas.

and now attachments on our outbound message retain their original filename...noysh!

And BTW, not all commercial email clients populate these MIME headers correctly either (or so a friend of a friend who's aunt once knew someone that was talking to a girlfriend at the supermarket said). Check out the message source of items in your inbox. You might be surprised.

Happy spamming er...umm...BizTalking