Today was the 2nd and last day of the training/conference on BizTalk RFID (See here for Day 0, 1, 2, 3).

Module 7 - Business Rules

Now we're starting to get somewhere interesting, business rules. However, before I could start the module, I needed to redo some previous steps as my VM was reset to a clean state over night. Thankfully, as like other classes I've been to, solution files are provided for each module, so I started more or less from module 6.

One step of my rebuild process I wanted to point out was importing a process. In Module 5 and 6 we were working with a process called Parking Event, so I went to import this process in the BizTalk RFID manager. The import process asks for a XML file which specifies the configuration for the process. Now this was imported successfully, but when I went to validate I got a FileNotFound exception, and as I expected, the import process does not import/move the necessary binary files.

Under the BizTalk RFID folder, is a Processes folder which has a folder for each process configured. The import process created a ParkingEntry folder (C:\Program Files\Microsoft BizTalk RFID\Processes\Parking Entry) and other required files, but the bin folder was empty. All I had to do was copy my binary files (.dll's) from the solutions folder to the bin folder, and the validation succeeded.

I am very grateful for module 2 (see day 3) in which we walked thru the folder structure of BizTalk RFID, as it made fixing this error very easy. Now I will return you to our regularly scheduled Module 7.

Due to some missing instructions in the Student Manual, we were instructed to use the Business Rules deployment wizard to import a policy file which defined the rules themselves. The rules are pretty simple for this exercise and this is more about BizTalk RFID as a whole then how to manage BizTalk rules, worthy of it's own multi-day class.

We also imported the Microsoft.Rfid.OobComponets assembly which contains several static classes with useful utility functions. For this exercise, we make use of the RfidRuleEngineContext class. I would recommend you review the MSDN documentation to familiarize yourself with the methods and properties exposed.

My SQL server somehow got completely messed up, and I needed to take a break and fix it before proceeding. I have posted a separate post on what happened and how I fixed it.

During the lecture portion of this module, Mick showed a simple example of invoking the BizTalk rules engine directly from a .Net Application. You could easily expand upon this idea to expose the BizTalk rules engine as a WCF service available to your entire enterprise (service bus). Given the fact that the rules engine comes with the branch edition of BizTalk which retails for $1800, this could very easily speed the adoption of the BizTalk rules engine.

This raises an interesting decision, BizTalk rules or WF Rules. Previously I have been looking primarily at the WF rules engine. I feel that it was a little easier to use, and since it's freely including with .Net 3.0, it seems to have more community support.

Module 8 - WCF Services

Module 8 involves sending tag data from BizTalk RFID to a Windows Forms application via a WCF web service. To start off, we create a new custom event handler which invokes the WCF service.  At this point I really started to understand the power behind the process and event handler model that BizTalk RFID is built on. The WCF event handler uses a standard WCF service proxy to invoke the service, and is setup to use the TagReadEvent as the sole parameter to the method call.

This is an important design decision to point out. Instead of creating a new data contract, you use the TagReadEvent which "everyone" should know how to use. A question I have is, what other objects are setup for use as DataContracts, and are there any predefined ServiceContracts defined for exposing services?

The TagReadEvent object is passed to the Windows Forms Application, and a new key is added to VendorSpecificData and is returned to the caller. The caller, if you remember, is our custom event handler, which returns the modified TagReadEvent which in turn, makes that object available in downstream event handlers.

Again, I have come to realize some of the potential available in BizTalk RFID. However, after spending the past 2 hours working on this module, I have come to the conclusion that BizTalk RFID is as finicky as BizTalk proper, and requires some serious debugging skills. The problem, 'IN' versus 'IN         '. Somewhere I was getting extra spaces (probably from the database and the way we are reading) which was causing havoc with my rules, or rather in how I expected the rules to evaluate. I went back to one of the previous labs and modified the assembly which handled looking up data from our simulated LOB database to trim strings.

One other note, it looks like if you replace files in bin, or modify the web.config file, the process will automatically restart, and log the reason and a stack trace to shutdowns.log.

The good news is that there is some decent troubleshooting facilities available using the built in logging mechanism. This was how I was at least able to see where my problem was. Log files for processes are stored in the Process Folder, and are named [ProcessName].log.

Module 9 - BAM

Someday I will sit down and figure out what BAM is all about, but it wasn't today. Class was pretty much cut short due to people flying out today instead of tomorrow.

Miscellaneous Notes

• Enriching Data: This is a term used to define a process by which you take the raw tag id and add additional data from your LOB database for example. This information was usually added to the VendorSpecificData property bag which is a property of TagReadEvent and was covered in Module 6.
• Device Simulator: c:\Program Files\Microsoft BizTalk RFID\Samples\Device Service Provider\Contoso\ContosoEndToEnd\ContosoDeviceSimulator
• There is other stuff in the Samples folder so check it out.