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.

I have been an advocate of VMware Server (v1.0) having used it for the past three or so years now as my virtual development platform. The performance, networking, and user experience have all been good enough. I have accumulated a decent library of platforms, server products, developer tools, and client environments that I can call upon whenever needed. I especially liked the USB support which came in handy when working with RFID devices.

Recently I got around to installing the latest version (v2.0 beta) ...oh dear .

Ok, it was only beta but it lost all the attributes that I mentioned as good points above. Performance was noticeably poorer (perhaps beta related), the revamped networking might be ok after a training course, and most importantly the user experience was totally shite. VMware moved away from the remote console being a Rich UI application (that had its faults but got the job done well enough) to a browser-based console. Why? I thought the industry has have moved on from this already .

So, I have finally conceded to (and coped a few ha-ha's from colleagues) to move my virtualisation platform over to Windows Server 2008 Hyper-V. No small job as I will have to convert (rebuild) all my VM's. In the meantime, I am running Virtual Server 2005 R2 on the laptop to "ease" myself into the new platform.

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

BizTalk RFID ships with the Business Rules Framework (commonly called the Business Rules Engine or BRE). BRE is a rules execution engine that allows you to dynamically create, publish, deploy, and execute policies without having to stop and restart running business processes. There is actually much, much more to BRE than my one sentence overview, but that is not what this post is all about.

In BizTalk RFID land, we can call our business policies within RFID Processes using the OOTB RuleEnginePolicyExecutor component. We can use business rules to filter and enrich RFID tag event data. Having created the policy, we add and configure an instance of the RuleEnginePolicyExecutor component to our RFID process. We configure the component to specify any database and/or xml facts to pass to the executing policy.

A good friend to business rule developers working with BizTalk RFID processes is the RfidRuleEngineContext class. It contains a number of properties and methods that make working with tag read event data very easy. An instance of this class is always passed to the executing policy by the RuleEnginePolicyExecutor component.

Ok, so there is some context for the post...

The Problem:

The other day, I had a BRE policy that, amongst other things, was updating SQL tables in some rule actions. I was calling the BRE policy from a BizTalk RFID process and all was working fine, until I noticed the database changes were not being made. I checked the process log file and verified the SQL update rule actions were firing...but the database facts were not being updated. Why?

Tip: Troubleshooting BRE policy execution within a RFID process is made easy by setting the process log level to Verbose. This writes all BRE tracking info to the process log file.

In BizTalk Orchestrations, when we update database facts in rule actions, we had to manually commit the changes on the SQL Data Connection (using an expression shape, not the call rules shape).

The Solution:

In BizTalk RFID we can use the RfidRuleEngineContext.UpdateDataConnections method to commit all changes on the SQL data connection(s) used during policy execution (the database fact we configured at design time). Keep in mind the message handling reliability setting (sometimes called the Tag Processing Mode) of your RFID process. If you have set message handling reliability to Transactional, BizTalk RFID will create a transaction scope over all event handlers in the process. That is, if any event handler fails, the transaction is aborted.

Mick's Tip: Include enlist=false; in your connection string when configuring the RuleEnginePolicyExecutor if you do not want your SQL data connection to participate in the transaction.

The Business Rules Engine is a powerful tool in your BizTalk RFID toolbox. If you have never used it before, check out the Walkthroughs for Creating and Using Policies in RFID Processes in the online help. There is also a great sample in the SDK as well.

If you are receiving this error when validating your RFID process and don't know why, or you have never seen this error before, read on as it just might save you some pain...

RFID Processes - 101

RFID Processes consist of device bindings and component bindings. The device bindings link physical RFID devices to logical devices. Component bindings define the event handlers that perform the processing. Conceptually, an RFID process looks something like this:

Source: Microsoft BizTalk RFID Online Help

When PhysicalDevice1 raises an event, it is sent via LogicalDevice1 to EventHandler1 for processing. EventHandler1 processes the event and passes the event data to EventHandler2. Event handlers can also terminate the event processing and not pass the event on. (but lets leave that for another post)

When we put together RFID Processes that consist of multiple event handlers, we need to ensure that each event handler in the process can accept the event(s) passed from the previous one.

Back to the Problem

BizTalk RFID will throw "The process has a component that is not reachable..." error when it determines that an event handler in the process can not receive an event.

This can happen in two ways:

1. The device binding is not set and the event can not reach the first event handler.
2. An event handler can not pass an event(s) to the next event handler in the pipeline.

And it is this last case that can cause the pain.

A Common Scenario

You have a RFID process with two event handlers. The OOTB SqlServerSink event handler (EH1) and a custom event handler (EH2). BizTalk RFID throws the above error when you try to save. Why?..

In this case the first event handler, SqlServerSink, is not designed to pass on events. It's event handler method has no output parameter. (check out the method signatures PostEventToSink and PostEventsToSink in online help) Event processing will always stop at the SqlServerSink component.

The solution: Move the custom event handler (EH2) ahead of the SqlServerSink (EH1) event handler to pass validation.

An Actual Scenario (that resulted in much loss of sleep)

I had a RFID process that used the OOTB event handler RuleEnginePolicyExecutor to call BRE policies from the process. The next event handler in the pipeline was my custom component that I had used in many processes before with no issue. The output type of the RuleEnginePolicyExecutor event handler method(s) is RfidEventBase[]. The event handler method on my custom component only accepted RfidEventBase as an input parameter. That is, the RuleEnginePolicyExecutor component was passing my custom component an array of events and I only supported a single event in my event handler.

The solution: Create another event handler method that accepts RfidEventBase[] as the input parameter. I iterated through the array calling my original event handler method. Now my component supports both scenarios.

Troubleshooting

So when you receive this error, examine the message to identify the component at fault. Check the event handler method signatures of this and the previous component. What you are looking for:

1. The previous event handler passes on the event (i.e. has an output parameter)
2. The event handler at fault can accept the event (i.e. has an input parameter type that matches the event type sent)

As event handlers can have more than one event handler method, ensure that the event handler at fault has an event handler method with the right input type for each of the output types of the previous component. This becomes quite complex when we consider pipelines mat contain multiple logical sources as well.

Tip: The Custom Event Handler Project Template that shipped with the SDK Samples only implements event handlers that accept TagReadEvent and TagListEvent input types. You will need to implement another event handler that accepts RfidEventBase[] as an input type to use your component with the RuleEnginePolicyExecutor component.

For those early adopters who grabbed the DLP Design RFID Reader/Writer and launched into the wonderful world of BizTalk RFID in Beta 2, there may be a rude shock when you install the RTM...the device provider fails to install.

Ok, so don't panic. Here are the re-built DLP Design DSPI provider assemblies.

If you want to explore BizTalk RFID a little deeper then follow the steps below to re-build the DSPI provider from source.

If you haven't already, download the source for the DSPI provider. Mick Badran kindly linked to them in a blog post not so long ago. Unpack the compressed file and open the solution in VS 2005.

Take a look at the project references

Refresh the references to Microsoft.Rfid.SpiSdk and Microsoft.Rfid.Util assemblies found in the BizTalk RFID bin folder (C:\Program Files\Microsoft BizTalk RFID\bin for a typical install)

Build the project...Before you build, take a look at the project Build Events (Right-click DlpDesignDSPI project and select Properties). The build event uses the RfidClientConsole.exe command line tool to register and copy the DSPI assemblies to the Providers bin folder. Go explore the RfidClientConsole command line tool a bit more closely as you will cross paths with it frequently in BizTalk RFID land.

Ok...now Build the project.

In RFID Manager, the device provider should be installed and in the Registered state.

To those who are using the device simulator in BizTalk RFID, I fully recommend getting a physical RFID device, like the Dlp Design Kits we got. Actually swiping tags across the reader and seeing the HD led go nuts is a much better experience than clicking a button that's labeled "Pretend you swiped a tag"

Now you are back up and running. Enjoy!