Sunday, July 29, 2007

BizTalk RFID: notes

After finally getting around to setting up VMWare Workstation with a BizTalk 2006 R2 Beta2 + BizTalk RFID, I did several experiences with the Phigets RFID reader and the Phidgets DSPI.

Two notes about the setup of the DSPI: first, do it manually, following the instructions. The setup script has an error in the names of the dll files (is uses the name "phidgets" instead of the correct name of the dll, "*phidget*"). Second, if you have an error when starting the provider, check this page in the Msdn forums. The setup guide for the Phidgets RFID quickly guides you through a complete configuration of the provider, device, and business process, so I highly recommend you follow it.

One important limitation of the Phidgets DSPI is that it doesn't support the elimination of repeated reads. Just to give you an example of why this is a limitation, if you hover the Rfid tag for about half a second over the reader, you get 10-20 tag reads. I have my doubts as to wether this elimination should happen at the provider level (DSPI)... it seems to me it should be done in the generic RFID Infrastructure. Apparently other DSPIs have the same limitation, but there's a way around it: either use specific features of the device (non applicable in the case of the Phidgets reader), or an event handler associated to the business process you define (check the DupElim sample in the BizTalk 2006 R2 Beta2 samples).

Something that I found unintuitive when setting up BizTalk RFID is that this package (much like BizTalk Services) is not part of BizTalk Server itself. Or rather, what I mean is: you won't get "tag read" messages directly into the Message Box, like you could assume you'd get. Rather, you associate some kind of "sink" to an application/business process you configure in the RFID management console (typically, the out-of-the-box SqlSink that just drops the reads in a SQL Server database), and then use BizTalk Server to consume events from that sink. An alternative way of getting tag reads is to use an orchestration to consume the RFID webservice (check the ConsumeRFIDWS sample). This does make BizTalk RFID into a generic "RFID server", but the BizTalk in the name is misleading. One further note about this is that you do get, out of the box, the capability to use the Business Rule Engine as a way of validating your tag reads (check the BRESample).

Microsoft's forum for BizTalk RFID is here, and I highly recommend it if you have problems, I found a solution there for all the difficulties I had.


On to a different subject, Microsoft has recently updated the Roadmap for BizTalk Server, with the interesting part being the "Beyond Biztalk Server R2" section. It seems that the "Solution Designer" that left us open eyed when it was shown in a Channel9 video two years ago is really not going to happen.

Tuesday, July 17, 2007


LoadGen is a Microsoft tool that can be used to generate test inputs to BizTalk solutions. The two features I really like about it are Message Creators, which allow you to generate different messages in each run (for example, different request id's, guid's, etc. in every generated file/message), and the Load Generators/Transports, which allow you to generate files, Http or Soap requests, Msmq messages, etc. A third architectural component are Throttlers, which allow you to regulate the rate at which documents are generated.

Load generation is just the first part of the problem when testing a BizTalk solution, however. You must have a way to measure how your solution is holding on, and for this a typical approach is using Performance Counters.

The download includes several samples, however most of these omit the configuration of Message Creators, which took me some time to get working. One thing to remember is that you can/should include the configuration of the Message Creator inside a Section block, at its end.

Here are some other quick tips:

  • LoadGen writes (verbosely) to the Event Log. Check it to find out if something is wrong with your configuration, for example.
  • In the documentation for Message Creators ("Dynamic Message Creation"), the MessageCreator/Field/InitialValue Xml element contains a simple replacement string: if the source file contains IDField_0, this will be replaced by the value generated by the configured MessageCreator. The documentation talks about this being a "field name", which is not totally clear.
  • The MessageCreator/TemplateFilePath element should point to the configuration for the Message Creator, and not to the Template for document generation. It's a bit mis-named.
  • If you have a Section for generating files, with a Message Creator within it, you have two references to the template file for your documents: in the Message Creator configuration file, the element MessageCreator/@SourceFilePath, and in the Section you have Section/SrcFilePath. This can get a bit confusing.

In my tests, I wanted to generate values with specific formats, so I decided to write an additional Message Creator. What I found out was that it was way quicker to disassemble the out-of-the-box CustomMC assembly and extend it than write one from scratch. Not exacly recommended and probably not supported/allowed, but... quick. I used Reflector.Net and the File Disassembler add-in.

LoadGen is a nice tool, but it's only the beggining of your work. Now, what I would really like to see is something like this being used in conjunction with BizUnit :-).

Just another suggestion: Scott Colestock did a session at last year's SOA conference I recommend, on this testing topic: «Applying Maximum Sustainable Throughput to a Management/Operations Strategy». Slides are here.

Monday, July 16, 2007

Take a Look at These...

I'm not about to start a series of "daily links" post, but here are recent links I find relevant:

Happy reading!

Wednesday, July 11, 2007

Gadgets in Javascript? I changed my mind

When I first heard that Vista Sidebar Gadgets where to be developed using Javascript, I thought Microsoft was making a mistake, and that Javascript+Html+Css was the wrong platform for these developments.

Since then, I've tried several gadgets, and tweaked two of them: first the Show Me Life Flickr gadget and yesterday the Scraper gadget. What I found is that the technologies involved are really convenient, and development turned out to be really quick. The Scraper gadget sample doesn't work anymore (I think the site where it scrapes info from is down), but I quickly changed it to get financial quotes from my bank's pages, add auto-update timers, use a better layout, and be configurable. All in a couple of hours.

Being a simple development, I did the code editing in Notepad2, but I think for more advanced gadgets (a few months back I tweaked Microsoft's Outlook Upcoming Appointments to get my own custom to-do list, and Outlook's object model is significantly more complex, which made this much more complicated) a more sofisticated development+test environment is probably a good idea.

You'll have to excuse me for not sharing the code, but I don't want the bank to block the scraping. :-)