Even though I’m not actively developing in BizTalk these days, I still have a need to go in and do some support on an existing system a couple of times a year. Of course it takes me a little bit to get back into the BizTalk frame of mind. Today, I had to make a couple of changes to an orchestration and deploy. Part of this process involved un-enlisting several receive locations while I made this change.

When I re-enlisted the receive locations and went to check for problems, I noticed that all of my messages where not being processed due to there be no subscription setup for them. I knew that my orchestration should be subscribed to these messages, and thankfully BizTalk creates a suspended message instance that lists the context of the message at the time of the routing failure. I immediately noticed that none of my promoted properties were in the context, which would explain the routing issue.

It took me a while to figure out how to fix this, but in the end I noticed that the receive pipeline on my receive locations looked incorrect. Checking a staging server, documentation, and an XML copy of the bindings I exported before the change, I confirmed my suspicion. It seems that during the the deployment process and the un-enlist and re-enlist, some of my receive locations reverted to the default pass thru receive pipeline. After changing them back the XML receive pipeline, things are all good.

For the first time in almost a year, I had to do some BizTalk development (actual BizTalk development, not the support tool I wrote about previously) to support our old system. We were making a change to one of our schemas, but need to send a message that conforms to the original schema version on one of our send ports. The easiest way I could think on how to accomplish this, would be to add a map on the send port that transforms the message from the new schema to the old schema. Seeing as I’m was a little rusty on my BizTalk dev skills, this took a little longer then expected.

First, the schema I was dealing with had an element comprised of child elements, whose Group Order Type property got changed to sequence. This resulted in errors such as “Element E1 has unexpected child element E2 in Schema, list of possible elements include E3”. It would be nice if the error message was a little more clear. I even ran the schema thru a web based XML validator I found and got the same error message, so that must an error message in the XML spec. I finally figured out what was going on by looking at a sample XML message created using the Generate Instance fucntion and saw that only 1 of my “required” elements was showing up. Changed the Group Order Type to sequence fixed my problem.

With my test message passing the schema validation, I moved on to creating the map. I created a new assembly to hold the map, as well as the destination schema type. I then referenced my existing assembly to get the source schema for my map. This was pretty straight forward, and I was able to build and deploy my updated and new assemblies to BizTalk. Trying to keep things simple I set up 1 receive port/location and 2 send ports along with some content based routing. On one send port, I applied my map, and the other I did not. After sending a test message thru, I saw that both my send ports produced a file, but neither were transformed as expected.

Turns out I forgot to set the receive pipeline to XMReceive…I know I’m a bit of a BizTalk newbie sometimes. You do not need to change the pipeline from pass-thru on the send port, just on the receive location. After correcting this, my message suspended out with the error: “Cannot locate document specification because multiple schemas matched the message type http://Fully.Qualified.Schema#RootNode.” This makes sense, as all I did was copy/paste my original schema to the new schema file to preserve the existing structure, and then modified the original file, adding my new elements. I also needed to modify the schema on the new version, indicating a new version (which we happen to include as part of the namespace).

At this point things started working as I had originally envisioned. BizTalk is not something I can quickly jump back into for some reason. There is a bit of ramp up time to get back into the swing of things. I should probably go find some more BizTalk stuff to fix while I’m in the right frame of mind.

This morning I was greeted with a proactive alarm email stating that we had over 100 messages in our BizTalk suspend queue. What an awesome way to start my Monday morning. Sure enough, the Biztalk admin tool showed the messages suspended out starting around midnight, which first made me think that maybe somebody made a change somewhere. If you couldn’t tell from the title, the error message in the Event Logs as well as the Admin tool was: “The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel” (this is on a HTTP send adapter by the way).

The first thing I did was attempt to browse to the destination URL in IE from the BizTalk server. Everything worked, no errors or warnings, but here is something intesting the cert was recently issued last week. Now why would it take a week to start seeing errors, unless it wasn’t installed until last night? Sure enough, heard from customer that maintains the destination server, and they updated their cert over the weekend. So why was BizTalk having problems, but IE wasn’t?

It appears, that BizTalk must do some sort of caching, either on the cert or the HTTP connection. I’m not exactly sure what it does, but after restarting the host process, everything work fine. All the messages were resumed without issue and we’ve had no more suspend out.

In part I, I talked about how I had a need for a way to managed suspended messages in BizTalk using something other then the BizTalk Administration tool. Using a combination of BizTalk dll’s I was able to query, read and suspend BizTalk messages. The need for a “web” based tool is one of accessibility to our BizTalk server from remote machines that are not directly connected to the DMZ zone that they reside in. I’ve also been wanting to create a tech support tool for myself to manage other aspects of our hosted solution, and this would fit in nicely with it.

Being a glutton for punishment, I decided to sacrifice my weekend and go for the more complex, but really cool sounding idea of a set of web services that interface with SilverLight 2. I choose SilverLight as I’ve been wanting to get my hands dirty with it for some time, and another member of the team was talking about doing the same, and what’s a little friendly competition? While I had a grand vision of what my tool would look like, which I will refer to as the Unified Administration Tool (UAT), I knew I wouldn’t be able to code everything in one weekend. I had to set some realistic goals and try to add only what was needed, while still allowing for future functionality to be “plugged-in”. The good thing was, since this was pretty much just for me, I didn’t have to worry about other peoples requirements ;)

The UAT is an n-tier application which will provide administrative functionality over our hosted solution that is distributed among several servers in different DMZ zones (as mentioned in Part I of the BizTalk Web Admin). In addition to dealing with the distributed nature of our servers, the tool must also account for the various environments, with one environment consisting of an instance of our solution deployed across one or more servers. Perhaps to put this more simply is that I wanted to be able to perform the same functions on our development, staging, demonstration and production environments.

I started out by created a new project folder to which all my various Visual Studio projects will be added. I moved my BizTalkUtilities projects into the Components folder as shown below, and then started adding the other components and UI projects as needed. Below is an overview of how I have my solution folder setup, which will probably change over time. The idea is that Components are reusable across all the UI and Services, and will probably have some more domain specific wrappers. Controllers under UI will be re-usable across each of the UI projects and provide an interface between the components and the UI.

• UnifiedAdmin
  • _Solutions
  • Components
    • BizTalkUtilities
    • BizTalkUtilitiesTest
  • Documentation
  • Scracth (Prototypes and other throw away code used for quick tests)
    • BizTalkMessageBrowser (Test win forms app for BizTalk Utilities)
  • Services
  • UI
    • Controllers
    • Silverlight
    • SilverlightMobile (Future project)
    • WPF (Future Project)

I decided that I will use the Entity Framework as my “ORM”, combined with Ado.Net Data Services as my primary web services mechanism. Combined with Silverlight, I’ll get to tackle three new technologies at once, and either learn allot, or give up, ultimately frustrated, wishing I would have chosen a few older tried and true technologies. Before we even get to the UI, I needed to start setting up my services and entity model. I have a feeling I’ll be re-arranging some of these projects, but for now I have a class library called Entities under Components, and a web project called UnifiedAdminService under Services.

I really don’t know what the best practice way for organizing my entity models are, and it seems like one entity model per project seems a bit of an over kill, however, putting all the entities I will be working with in the same project doesn’t seem to smell good either, as there defiantly a clear break between them. I started out with an entity model for a database called Utilities, which will be the “glue” that holds my Unified Admin tool together. It’s sort of a catch all database that currently contains tables for some SQL based monitoring I have setup, as well as users (who can access the UAT), and servers (what servers does the UAT work with). I created a new Ado.Net Entity data model and had it auto generated the model from the database schema. This was pretty easy and straight forward. I prefix all my table names in my schema with various prefixes for grouping and identification, such as “mon_t” which means the table is used for the monitoring functionality, and it’s a table. I don’t want these prefixes in my code, so I am going to rename the entities in the model. To start with I’m only renaming a couple until I see how the EM is updated and used throughout the code.

Next I created a new Ado.Net data service in the web project. This created a new .svc file with a code behind file that inherits from DataService<T>. I updated T to reference my entity model (Entities.UtilityEntities) and also configured the security to allow read access for entities. You do this by using the config.SetEntitySetAccessRule method in InitializeService. 

          public
          class TsiUtility
: DataService<Entities.UtilityEntities> { // This method is
called only once to initialize service-wide policies.publicstaticvoid InitializeService(IDataServiceConfiguration
config) { config.SetEntitySetAccessRule("*", EntitySetRights.AllRead);
} }

Even thought the auto-generated comments for InitializeService make it sound like it’s only called once in the life-cycle of an AppDomain, I wasn’t sure. This post talks a little bit about the InitializeService method, and does in fact point out that the InitalizeService method is only called once.

I attempted to browse to my newly created service and was greeted with an un-informative error, “The server encountered an error processing the request. See server logs for more details.”. Since I’m running the development server that’s included with Visual Studio, there are not much in the way of server logs (that I could find anyway). Jumping into debug mode showed that the error was caused by an incorrectly configured connection string. The connection string used my the Entity Framework is not your standard connection string, so you need to make sure that you copy the connection string created for you in your Entities project to your web.config in your web project (assuming your entity model is in a separate project). I was trying to use the Server, Database, Trusted_Connection syntax, and apparently that’s not OK.  Example connection string:

<add name="TsiUtilityEntities" connectionString="metadata=res://*/TsiUtility.csdl|res://*/TsiUtility.ssdl|res://*/TsiUtility.msl;provider=System.Data.SqlClient;provider connection string=&quot;Data Source=Server;Initial Catalog=Utility;Integrated Security=True;MultipleActiveResultSets=True&quot;" providerName="System.Data.EntityClient" />

Once I had the correct connection string, I was able to navigate my entity model using just my browser. Of course I haven’t done any type of authentication, and I don’t want to have just anybody browse to the URL for the UAT and start browsing, so it’s time to add some security. Ado.Net data services makes use of existing security provides as long as they set the HttpContext principle, so you can use HttpContext.Current.User.Identity.Name and then compare that against records returned by the EM. Something that I didn’t fully grasp at first, was that by the time Ado.Net Data Services “takes over” the user should have been authenticated, so there really is no “login” event in Ado.Net data services where you can set additional information.

For simplicity, I decided to use Integrated Authentication, and store additional information after the user is authenticated. Since this is a regular asp.net application, you can add a Global.asax, and add code to the AuthenticateRequest event handler to perform additional security related code. When AuthenticateRequest is called, whatever mechanism that is configured to handle authentication has finished, and there should be a value in HttpContext.Current.User. What I did was user the Name property to query my users table that was part of my entity model and cache the results in a hash table, which itself is stored in the application context. If the user does not exist in the database, I set the Current.User to null, and cache a null value with the key of the user name that was authenticated.

          protected
          void Application_AuthenticateRequest(object sender,
EventArgs e) { string userName = HttpContext.Current.User.Identity.Name; //Get
a collection of cached users. If it doesn't exist create and cache it. System.Collections.Generic.Dictionary<string,
Entities.User> users = (Dictionary<string, Entities.User>)HttpContext.Current.Cache["Tsi_Users"]; if (users
== null) { users = new Dictionary<string,
Entities.User>(); HttpContext.Current.Cache.Add("Tsi_Users",
users, null, DateTime.Now.AddHours(1), System.Web.Caching.Cache.NoSlidingExpiration,
System.Web.Caching.CacheItemPriority.Normal, null); } Entities.User
user = null; //Check to see if we have
a cached user for this username. Use ContainsKey as we will store//a
null value to indicate a user is not authorized.if (users.ContainsKey(userName))
user = users[userName]; else { Entities.TsiUtilityEntities
entities = new Entities.TsiUtilityEntities(); user = entities.UserSet.FirstOrDefault(u
=> u.WindowsUserName == userName && u.IsEnabled == true);
user.ua_tx_UserServers.Load(); //load servers this user has access
to. } //User doesn't exist in the database either, so un-authenticate
them//allow to continue thru so we add a null object with
the username to cacheif (user == null ||
HttpContext.Current.User.Identity.IsAuthenticated == false)
{ //When this is set to null, this method should finish, but no
data will display. //Seems like aspx pages will still display
though. However if you check the CurrentUser//it will be
unathenticated. user = null; HttpContext.Current.User
= null; } //save to users collection.
Double check to make sure it wasn't added somewhere else.if(users.ContainsKey(userName)
== false) users.Add(userName, user); }

What I have not decided upon, nor have I done the research into, is if I should be caching the DataContext in the application or session cache for the user.

So where does this leave me? Well, I certainly didn’t get even close to what I wanted to accomplish in one weekend, as I haven’t even touched SilverLight yet. I do have some basic authentication, but that’s more using traditional asp.net then doing anything special with Ado.Net data services. From the looks of it, I will have to add QueryInterceptors to every entity I wish to do security on, which seems like a pain and allot of extra un-necessary work. Next time I hope to accomplish the following:

1. Research to find out if you should cache the data context
2. Write out security requirements and research the best way to implement in Ado.Net Data Services
3. Figure how I am going to have one set of services that can connect to multiple databases (assuming the database schemas are kept in sync).

It’s been awhile since I’ve done any BizTalk development since my last project got canceled. However, we are still using BizTalk, and with that comes administration. One of the more tedious tasks is responding to suspended messages. There are a couple of common tasks that I do when I see that a message has been suspended.

• Resume because a destination location that was unavailable is now available (i.e. Customer Web Service)
• Terminate instance because it’s not a critical message and do nothing else
• Terminate instance, then fix and resubmit message

While BizTalk provides the BizTalk Administration tool in BizTalk 2006, which is a much needed improvement over the tools in BizTalk 2004, it leaves something to be desired. What I would like is a web based tool to manage my suspend queue, with some additional logic for filtering messages, so I can quickly determine if I need to terminate or resume. I’d like a web based tool, because I don’t have direct access to the SQL server that BizTalk uses as it’s in a DMZ. A web tool would allow me to manage the suspend queue from anywhere, even from home.

After a bit of searching, I didn’t find anything else out there that fit my exact needs. There was a project on CodePlex that looked like it might have been a good start, but didn’t look like it had suspend queue management (but it did look like it had support for configuring the various artifacts, like ports, orchestration, etc). I decided to write my own, as with most endeavors, it would serve as a good learning experience.

While searching for an already made tool, I found several references to Microsoft.BizTalk.Operations for getting messages out of BizTalk. After playing around for a bit I got something working that returns me a list of suspended messages.

          using Microsoft.BizTalk.Operations
... Operations operations = new Operations("localhost", "BizTalkMgmtDb");
List<BizTalkMessage> suspended = new List<BizTalkMessage>(); foreach(BizTalkMessage in operations.GetMessages().Cast<BizTalkMessage>())
{ if ((msg.MessageStatus & MessageStatus.SuspendedAll)
!= 0) suspended.Add(msg); } return suspended;

I found out that I needed some other Dll’s as well:

• Microsoft.BizTalk.DBAccessor (pulled from GAC)
• Microsoft.BizTalk.Operations (%Program Files%\Microsoft BizTalk Server 2006\)
• Microsoft.BizTalk.Pipeline (%Program Files%\Microsoft BizTalk Server 2006\)
• Microsoft.BizTalk.Tracing (pulled from GAC)
• BTSDBAccessor.dll (non-managed code. Add to project and set to copy to output directory)

Since I’m using BizTalk dll’s that are only available by installing BizTalk sever, I won’t be able to redeploy those, so you’ll have to add them your self and rebuild the project. So yes, eventually I’d like to release the source for this little project.

After I was able to get references to the suspended messages, that left inspecting the messages to get various information, like why it was suspend, and the actual message body, and finally executing the resume or terminate command.

Resume and terminate are really easy, as once you have the message, you can just use it’s InstanceId property and pass it to operations.ResumeInstance or operations.TerminateInstance. Getting the message body is a little more difficult, but not that bad.

          public
          static
          string GetMessageBodyAsString(BizTalkMessage
message) { string body = string.Empty; using (System.IO.StreamReader
reader = new System.IO.StreamReader(message.BodyPart.Data))
{ body = reader.ReadToEnd(); } return body; }

Ok, so it wasn’t that easy. When I went to run my code I got the following error when trying to access the Message.BodyPart property of BizTalkMessage: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B) – Microsoft.BizTalk.Pipeline. I thought that maybe I had an incompatibility between RTM and R2 versions of the various DLLs. Well, I fixed that but the error persisted. It was at this time I realized that the unmanaged code (BTSDBAccessor.dll), might not be compatible with my 64bit operating system. So I tried running this on a 32 bit box, and got another exception that indicated that I was most likely missing a dependency for BTSDBAccessor. Finally, I ran the code on a 32 bit box that had BizTalk installed, and it worked fine.

So you might be asking yourself, why wouldn’t you run this on the BizTalk box? Well I want this to be accessible via the web, and our BizTalk box does not do any front end web hosting, that is handled my a separate set of machines in another zone. I also wasn’t planning on installing BizTalk on the front end web servers either, so I needed to come up with a work around that avoided a BizTalk install. Using ProcessMonitor, I was able to come up with a list of dll’s that my application was accessing, which I have listed below. These dll’s reside in %Program Files%\Microsoft Biztalk Server 2006 on 32 bit systems, or in a bin64 sub-folder on 64 bit systems. Some of the dll’s need to be registered using regsvr32.

• BTSCache.dll (regsvr32)
• BTSDBAccessor.dll
• BTSErrorHandler.dll (regsvr32)
• BTSMessageAgent.dll (regsvr32)
• BTSPerfCounters.dll
• BTSSchemaCache.dll

So now I have my test app running on a 64 bit install of Server 2008, just like my web front end servers, and I am able to query messages, find the suspended messages, and terminate those messages that are suspended. My next step, and topic of part 2 will be turning this into some type of web based application. I haven’t decided if that will be Asp.Net, Asp.Net MVC, or Win Forms using WCF web services.

UPDATE:

I was having some problems registering the unmanaged DLL’s on another Server 2008 machine (error code 0x80070005), which seems be an access denied error. I should point out that I was using a batch file to register all of the dll’s, which I also tried doing a run as Administrator. That failed, but with a different and even less helpful error message. I eventually opened up a command prompt as an administrator and manually ran regsvr32, and that seemed to work.

One of the most interesting pieces of information I took away from BizTalk solution days was a comment made by Xterprise during their presentation where they said that the next version of BizTalk RFID would have features specifically for mobile devices. Based on Anush's reaction, I thought this was really super secret information.

Turns out that the fact there is a BizTalk RFID Mobile isn't all the super secret, although the feature set has not been released yet to the best of my knowledge.

BizTalk RFID Mobile Sightings:

• TechEd 08 for IT Professionals - Building Rich RFID-Enabled Applications for Windows Embedded CE Devices Using Microsoft BizTalk RFID Mobile
• http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2193649&SiteID=1
• http://blogs.msdn.com/biztalkrfid/archive/2007/04/29/biztalk-rfid-rfid-journal-live.aspx

An interesting note. The BizTalk RFID for mobile devices is part of the Windows Embedded track, but it only listed under TechEd for IT Professionals.

I am safely back in Madison, having returned from BizTalk RFID Solution Days 2008, held in Bellevue/Redmond Washington. You can read my four previous posts for some day by day coverage: Day 0, 1, 2, 3, 4.

Overall I enjoyed the conference and training. It was apparent that the conference was defiantly for management and the business types, and while the training was more technical, it still felt slightly biased towards non-technical people (more in the training later). The logistics were pretty solid with the location working out nicely. Had I know about the free Microsoft shuttle to the Microsoft Campus from the Westin hotel the first day, it would been even better. I can appreciate the abundance of electrical hookups at the tables in the main conference hall, but the lack of free wi-fi was like a punch in the stomach. As I mentioned in a previous post, actual guests of the Westin might have gotten free Wi-Fi, but I don't know why this wasn't extended to all conference attendees. At a minimum, they could have brought in a couple of hubs and added some wire drops to a portion of the main conference hall for those of us left out. In the end it was a minor inconvenience, although my EDVO reception inside was a little lacking at times on my smart phone.

I can't say enough about the Ogio backpack we all got. It's easily a $50 backpack, well built and survived the flight home as checked baggage (had too much stuff to bring back to fit in just the one bag I brought out with me). While it won't fit my 17" laptop, I have found another use for it. My wife's birthday was on Friday, and has been wanting a nice backpack for her new job, so guess what she got for her birthday? What can I say, I love my wife, and the fact that she is perfectly happy getting my conference backpack as her "gift" :)

I found great value in the key note presentation by John Fontanella, as well as good value in some of the other presentations. Specially, Cathexis, Freedom Shopping and Impinj. There was one thing lacking, and that was what we can expect from the next version of BizTalk RFID. A member of the Xterprise team did let a little piece of information slip which definetly caught my attention, and that was that the next version is going to have features for mobile devices (ka-ching). Also, a display showing off BizTalk RFID was strangely absent. Just because people attended the conference doesn't mean they are going to make use of the product, and I think alot of people were there to evaluate BizTalk RFID itself. Why not have a mock warehouse setup with some RFID readers and label printers running off BizTalk RFID?

Moving onto the training, I would like to say that I did learn a great deal of information. The concept of developing a "solution" starting with the first lab exercise and continuing to expand upon it for the duration of the class was an excellent idea and should be used more often. Instead of wasting time watching progress bars advance, having an environment already setup saved allot of time and allowed us to concentrate on actual substance starting with the first lab. That first lab which showed were stuff was installed, including log files, saved some time in later labs when I had to trouble shoot. I would like to note that it always seems like BAM gets shafted in BizTalk (and related classes), so I would almost like to see that brought forward for a change.

There were some disclaimers stating that the code implemented was not up to best practice standards. My question is, why isn't it? That is, why not show what best practice code looks like? Maybe for the parts that we had to type our selves you could cut some corners, but there were large portions of code that was done already for us that could have been implemented better and had complete unit tests. It's a perfect opportunity to show how to write decent code. Instead, the business type people and managers got to see how "easy" it was to get stuff working. Mick did make a couple of statements to try to avoid this incorrect conclusion, but I feel sorry for some poor developers out there who will get a line like "I got it to work and I'm not even a developer".

While the physical RFID reader we got for use in the lab was nice, it did create an issue with the solution we were developing. We really needed two RFID readers in order for the solution (parking garage with an entry and exit ramp) to make more sense. The retail price listed for the DLP-RFID1 is $119.95, but as you can see from this site, there are several lower cost options available, which if bought in bulk, might allow for 2 readers per student. Either that, or design a solution that only requires one reader (either change the solution, or add additional processing logic to make the solution work better with a single reader).

The Microsoft Conference center was top notch, but I might have been biased by the enormous cooler full of free beverages (soda, milk, juice). While I already mentioned it once, it deserves a second mention, and that is the free shuttle that runs Monday thru Friday from 7am to 8:30 PM between Lincoln Square (Westin Hotel in Bellevue) and the Microsoft Campus.

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.

Today was the first day of the training portion of BizTalk RFID solution days (see day 0, 1 and 2). The instructors are Mick Badran of Breeze Training, and Ram Venkatesh from S3 Edge (Ram was the software architect for BizTalk RFID and recently left Microsoft). The class is held on the Microsoft Campus in the Conference Center, Building #33. This is my first time at Microsoft and I'm impressed with the campus so far.

We started out with the obligatory introductions and moved right into the student manual to go over the agenda for the class. We will be designing a solution for a "parking garage" with enough features to get a good understanding of BizTalk RFID. Similar to other classes I have taken, we will be using virtual machines for the labs, and there are already completed solution files for each lab. We have been provided with a HF (13.56 Mhz) RFID reader from DLP Design to use in the labs and to take home with us.

Module 1 - Introduction to RFID and BizTalk RFID

This was an introduction to RFID, RFID technologies and BizTalk RFID. The first couple of slides were designed to make sure everyone had at least a basic understanding of RFID. I would wager that this was review for most people. The remaining slides went into an overview of BizTalk RFID.

RFID Tags:

• Low (< 135 Khz) - Short range, more reliable for liquids and metals
• High (13.56 MHz) - Short range, less expensive, reliable, slow bps
• UHF (868 to 915MHz) - Good balance between range and performance and pretty cheap.
• Microwave (2.45 GHz, 5.8 GHz) - Fast but expensive. Example is highway tolls.

Microsoft RFID Goals:

• Encourage widespread RFID adoption
  • Standards
  • Best Practices Architecture
• Build an RFID infrastructure
  • Event Processing
  • Device Abstraction and Management

Key Benefits of BizTalk RFID:

• Abstraction of device handling
• Rich RFID event processing model
• Reduce data "noise" and increase data relevancy - Use the BRE to create filters, alerts and transformations
• Robust framework to support agile processes

Additional Notes:

• The DSPI has both an application and management contract interface.
• Ram brought up the LLRP in response to a question about standards based protocols between hosts and RFID readers. I talked briefly about this in my Day 0 post. LLRP is a EPC standard, and I would expect to see more and more readers beginning to implement this. As such, it should be pretty easy to find a DSPI that will work with multiple readers. I know Impinj is using LLRP, or is planning to.

Module 2 - Installing BizTalk RFID Services

The student manual contains some basic slides on minimum requirements and installation stuff. Nothing really exciting there. The lab was very interesting and provided some great information. Instead of having you waste an hour installing BizTalk RFID, the VM comes pre-loaded with it already. The lab focuses on showing you where things are installed, command line tools, configuration, registry settings, etc.

• Default install directory is %Program Files%\Microsoft BizTalk RFID\bin, I will refer to this as %App%.
• It looks like everything you can do in the RFID Manager MMC, you can do from the command line RFIDClientConsole in %App%\Bin
  • We were shown how to export the server configuration to XML and and import from xml.
• Server listens on port 7891
• Notable stuff in %App%\Bin
  • clusrfid.vbs - Script that returns health of BizTalk RFID service
  • RfidServices.exe - Main application which run as a service
  • RfidTray.exe - Monitoring utility which runs in the SysTray
  • Web.Config - Mainly defines WCF configuration
• Registry
  • HKLM\Software\Microsoft\Microsoft BizTalk RFID
  • HKLM\Software\Microsoft\Business Rules\3.0 - Added a key called StaticSupport to allow us to call static classes from rules. See http://msdn2.microsoft.com/en-us/library/aa950269.aspx for more details.

Module 3 - Examining Physical Devices

This module was focused around an introduction to the DLP Design's RFID1 HF reader. We setup the USB redirector software which will enable us to connect to the USB based reader in our VM for all future labs. We were also supposed to write a .Net Application using the native drivers in order to illustrate how difficult it is to program devices. I decided to skip that example and move onto lab 4.

Module 4 - BizTalk RFID Device Providers

This was a pretty easy module where we went thru, registered a provider and established a connection to our DLP RFID1 device thru BizTalk RFID. A sample application was written to "register" a customer with a RFID tag for use in our parking garage solution. So far so good, so far so-so. I would have preferred writing the provider versus the .Net application.

An extra lab was provided in this module which showcases the "flexibility" of the provider model. The extra lab implements a file system provider, that is, it "reads tags" from the file system. Basically the tags are just files in side a directory tree. I don't remember the exact story told, but apparently a race team wanted to be able to capture sensor data from a race car. Looking at how the example is implemented, it's trying to force the solution in the BizTalk RFID domain (square peg into a round hole). Don't get me wrong, it's a cool implementation, but it just doesn't seem right.

Module 5 - Building BizTalk RFID Processes

Processes are respond to events raised by devices in an asynchronous manner. In the lab we created a process that dumped event data into a sql database. This is out of the box functionality and was pretty easy to configure and setup. Once that was done, we created a very simple report in reporting services.

Module 6 - Custom Event Handlers

One thing you would notice if you were completing module 5 yourself, is that while the storing of data to SQL is powerful, as implemented, it wasn't practical. You stored pretty much the same tag read data 100 times by just holding one of the test tags up to the reader for 1-2 seconds. This is were custom event handlers come in.

From the student manual, lab 6, custom event handlers can:

• Filter duplicate events (terminate event processing)
• Enrich events with custom data
• Cleanse event data before further processing takes place
• Integrate with downstream processes and services
• Insert tag events into a database and/or call a downstream service.

All of the out of the box functionality in BizTalk RFID at the process level is implemented on top of the EventHanlder model. This model is fully exposed as indicated in this module, and is the supported way to add additional functionality. There are some samples in the SDK and a Code Plex project started by Microsoft with additional event handlers (MSMQ, File, etc). 

In this lab we created a custom event handler component, add the custom component to an existing BizTalk RFID process and finally explore the use of the Import Process feature. Again, the programming was pretty straight forward. Naturally the incorporation of DAL code in my component brought a frown to my face. While I understand this is just a simple lab, since the DAL code was already written for us, adding it as a separate assembly to promote n-tier design would have been welcome.

I finished up the lab with my tag read events getting queued into a Message Queue after getting enriched (matching tag Id to customer information in our customer DB). Now I'm sure we'll get to this at some point, but I wanted to go a step further so I implemented a simple CBR scheme in BizTalk to dump the data to a file location.

Miscellaneous Notes

• BizTalk RFID server uses MSMQ for "routing" events to processes
• What is ALE - Application Level Events, part of the EPIC standard? A way to publish and subscribe events. Doesn't sound like there is ALE support out of the box, you would have to roll your own.
• Using a piece of 3rd party software called USB Redirector to bridge the USB based reader plugged into the physical host to the VM.
• Review functionality of BizTalk branch edition. It's only $1800 retail down from $8500 retail.
• There is a device simulator in the full SDK of BizTalk RFID.
• Computer Specs used in the class:
  • Dell Optiplex 745 (Vista Experience rating of 4.5)
  • Intel Core 2 - T6600 @ 2.4 Ghz
  • 3 GB of RAM
  • ATI X1650

Today was the second day of the conference and it started out on the same foot as the end of the first day. While there were two official tracks, the 3rd track consisting of talking to the vendors, seemed to draw as many people as the presentations themselves.

The first 3 presentations were:

Augusta Systems

This presentation talked mainly about their sensor bridge, a piece of hardware which allows you to connect multiple devices and peripherals to the sensor bridge. The Sensor bridge was then the only piece of middleware you had to deal with in terms of application and communication support.

Lowry

The presenter stated that he wasn't going to do a sales pitch, I think he ended up doing so anyway. At one point there was a slide which talked about the challenges an adopter of RFID must face which included: What labels and tags to use; where to apply the labels and tags; what hardware to use; compliance standards set by DoD and Wal-Mart. Of course Lowry can help you address all that. At the end, there was a slide with all the customers of Lowry, and an audience member was from one of the companies and asked what Lowry did for them. The presenter had no idea. Note to presenters, make sure you can talk about the stuff you put on your slides.

Avery Dennison

Avery Dennison talked about a solution they implemented for a supplier of Boeing in order to drive RFID down from the Tier 1 suppliers to the Tier 2 and beyond. They also touched on their customer focused initiatives which include RFID FastTrax (RFID process improvement and consulting), and their RFID System laboratory.

Freedom Shopping

The lunch time presentation was done by Freedom Shopping, who have implemented an RFID retail POS solution to allow for unmanned stores. I was impressed by the presentation and solution presented by Freedom Shopping.

Freedom Shopping has 7 patents pending covering their RFID checkout process, and 2 "products".  The first is a turn key solution, which allows new store owners to get up and running quickly. The second is an OEM solution which is more suited for existing stores to slowly transition into RFID.

Some interesting facts I found out about their solution:

• Running Windows XP on their Kiosks. Their demo running at their booth was actually running on Vista.
• Retail cost of their Kiosk (I'm not sure if this is for the full or 1/2 size) is $20,000, compared to $70,000 for a bar coded self service checkout
• Mentioned the cost of their tags were around 13 cents and use a modified Alien Squiggle
• They are tagging everything in the store, down to a pack of gum which sells for 99 cents.

Cathexis

After lunch I moved from the main room to the secondary room to hear Cathexis talk about their RFID-based Event Management System. The presenter was by far the best of the conference and kept me interested from start to finish. While he was ultimately pitching thier product, it really wasn't mentioned until 30 minutes in. 

The presentation started off with the conclusion (first time I've seen that), which had 4 points: Change Happens, Solutions are deigned to encourage specific attendee behavior, Trend analysis is at the heart of finding ROA in RFID, Solutions are tailored from small to large scenarios. Some of the benefits of their solution include: Real time traffic management, real time notifications, automated floor traffic analysis, promotions and data driven advertising.

Unfortunately I did not win the Xbox 360/Guitar Hero 3 combo they were giving away (and I walked past their booth so much).

The End

The last presentation was by Daenet, a German software company specializing in SOA, and RFID on a Microsoft Stack. They are also a member of the VSTS Inner Circle which I had never heard of before. What I took away from this presentation, was that my interpretation and implementation of SOA is shared by this company, which means I'm probably getting it right.

Tomorrow starts the hands on training and I can't wait. We even get our very own RFID reader to practice with and take home. I have no idea what time the class starts. I got an email stating we were supposed to be informed at the conference, but I must have missed that. I'm guessing we won't start before 8, so that's when I'll try to get there.

Today marked the official start of the BizTalk RFID Solutions Days conference. Showing up for the pre-conference reception was a good idea as the registration table was packed in this morning. Breakfast, lunch, afternoon snacks (including ice cream treats) and dinner were provided. There was no free WiFi available. It is possible that if you had a room at the hotel that you got access, but I saw plenty of people paying for WiFi though out the day.

Anush opened up the conference with a short welcoming presentation. His key point was that the goal of BizTalk RFID was to make it as easy to hook up RFID hardware, as it was to attach a mouse or other USB device. That is a pretty lofty goal, but from what I have seen and read, they are well on their way to accomplishing this. I will be able to comment more on this after I complete the training classes on Wednesday and Thursday.

Key Note

The keynote was delivered by John Fontanella from AMR Research, a company that specializes in researching technology for it's customers. This was a very good presentation about RFID as a technology, process and it's uses in business. John provided some good information which indicates that RFID will really start growing in another year or two.

Like RFID, barcodes faced a slow adoption process, going back to 1975 where an article in a grocery store industry magazine had a quote asking where the value was in barcodes. Now barcodes are everywhere and I doubt my generation even remembers a world without barcodes and from the numbers presented, we are headed the same with RFID.

One of the key points in the presentation was a claim that we have reached the "tipping point" of RFID, but that no one has really noticed yet. The evidence to support this is as follows:

• AMR is seeing an increase in the number of RFID inquiries
• Big Technology companies are back in the hunt for RFID solutions. Compare the list of attendees at this years RFID Live conference with years past and you should see an increase in large, well know companies
• Not dependent on Wal-Mart.
• Companies beginning to understand the value of RFID. In 1994, how many companies understood the value of a corporate web site?
• Large customer facing companies are starting to adopt RFID. An example I've seen, and that was brought up by an audience member, is the Ford RFID enabled pickup truck bed targeted at construction workers and companies.

Several slides in the presentation dealt with what is expected in the future, and how it will continue to drive RFID. For example, item level tagging is supposed to really take off starting in 2009, and one of the categories of targeted projects is Point of Sale, which depends on item level tagging. Terso has been doing item level tagging since it's inception a couple of years ago, so mass customer acceptance and familiarity with item level tagging is a positive development.

John made a comment on how in today's supply chains in the United States, that we have a 60 days supply worth of products, and that RFID and improved processes could help reduce how much back stock is in the supply chain, thus increasing efficiency. He asked if we really need a 60 days supply, and speculated we could get down to 7 days worth of back stock.

I actually find some re-assurance in that 60 day supply, as we are all extremely dependent on these supply chains for our survival (we are not exactly a country of farmers anymore). In the event of a wide spread terrorist attack or some kind of flu epidemic, that 2 months of supply chain back stock might actually equate to survival. Perhaps I've watched one to many end of the world movies lately.

Charles Johnson from Microsoft

The highlight of this presentation was the movie that Charles showed at the beginning, in which a product innovation was shown in an end to end solution starting with envisioning to the end consumer. The video starts out showing a formula one race car being monitored (Charles pointed out that Microsoft software is actually used in racing), and the focus shifted to the driver's seat, which is the product that was going to be developed.

The video changes to show a product management team working on a project plan on Microsoft Surface, both mounted on the wall, as well as in the table. Now Charles said that what we were seeing was real functioning software and hardware. Surface was showcased through out the video.

Some other highlights from the video included wearable headsets which overlayed assembly directions on the production line and RFID tracking of products, parts, and tools in the factory. The video concluded showing a end-customer building (on-line) and ordering a new car (which included the new seat), and the CEO using a Surface enabled desk to review sales data.

The rest of Charles's presentation was focused primarily on supply chain visibility and highlighted some Microsoft partners and the solutions they had developed. Some interesting things I picked up on was a hosted service provided by HP that allows BizTalk to talk to SAP via web services, and it sounded like Microsoft used SAP internally rather then Dynamics, but I'm not 100% sure on this.

There was an audience question at the end asking about the cost of BizTalk server (not the RFID version), and also commented that he thought it was too expensive. Charles responded that when you look at a TCO across an entire solution, BizTalk is a small portion of that. He also added that Microsoft is willing to work with companies to define a pricing model that will work for them.

Other

The rest of the presentations where done by some of the sponsors, and pretty much turned into sales pitches and statistical bragging. It's amazing how many different ways you can cut up the RFID solution space in order to claim you are a #1. While there were foot notes on the slides to "independent" 3rd party research, no one used the same company. Therefore, I will make the unsubstantiated claim that I am the number one blogger at BizTalk RFID solution days based on a set of criteria only known to me.

Companies presenting included Xterprise, who I thought was a systems integrator, but is actually a ISV, HP, Motorola, and Impinj. To be fair, the HP presentation was a 50/50 split between their implementation of RFID in manufacturing and supply chain and their enterprise services department. The Impinj presentation wasn't too bad, I liked the way they designed their firmware upgrades, and if their claims on power consumption (27W active power) are true, that would have some benefits.

We'll see what Day 2 holds.

I arrived in the Seattle area today to attend the BizTalk RFID Solution Days conference and hands on training, hosted by Microsoft. I was delayed in Madison due to ice for about 1.5 hours and barely made my connecting flight in Minneapolis, but everything worked out, and my baggage arrived with me.

I'm staying in downtown Bellevue at the Courtyard Marriott, which is a pretty nice hotel. It has free wired hi-speed Internet in the rooms, is there any other measure? The conference itself is about a 1/2 mile away at the Bellevue Westin. I'm just walking to avoid having to deal with parking and a rental car. I guess the weather here today and the next couple of days is unseasonably nice (sunny and a high of 50).

Bellevue seems like a city in the midst of an identity crisis. There are probably 10-15 hi-rise construction efforts underway, with signs indicating another 10-15 will be started soon. I have no doubt that if I were to return next year, I wouldn't recognize the city at all. I guess it's a good sign from the point of view of the economy. I also saw someone showing off a Lamborghini by revving it's engine and weaving in and out of Traffic. What can I say, we don't see many exotics (just our share of Honda Civic's) of those in Wisconsin.

The only other non-conference related note, was a commercial I saw for a place called Dave and Busters. It looks like an adult's version of Chuck E. Cheese, but with allot better food and better games. We defiantly need something like this in Madison, as there are some people out there who prefer to do something other then drink.

Tonight was the pre-conference reception and registration which was a good chance to hit up the vendors in a little less chaotic environment. Registration was easy and straight forward, and we got a really nice Ogio backpack (stylized with company logos). I was actually thinking about getting a small bag for my return flight, as my primary backpack with my 17" laptop was a little too unwieldy for 3 across seating on the plan.

Vendors

First vendor I talked to was Intermec, a manufacturer of RFID hardware including stationary readers, mobile readers, printers, and rugged tags. I spent most of my time talking about the Intermec IF61 (link), a new stationary reader running on top of a Linux OS. While a Linux OS is nothing new, it does come out of the box with Mono, which should allow it to run .Net Framework applications. On the hardware side, it can handle 95-264 V AC power, and has built in B/G Wifi. Intermec is releases a set of web services as part of a firmware upgrade to help with the management of the reader.

Next up was Impinj, another RFID hardware provider and tags. What I liked about them was that there reader API is based off LLRP, and open source project focused on RFID applications. Impinj's implementation of BizTalk DSPI wraps the LLRP (low level reader protocol) implementation. They are presenting on Monday, so I will have more about their speedway reading in tomorrow's post.

Zebra was my next stop and they had two printers on display. the first was a print and apply demo unit which had a clear side so you could see what was going on inside. The second was a standard label printer enabled with RFID. When I asked them about the printer API, they were quick to point out DSPI support, which wouldn't always work for me. Their DSPI implementation wraps the ZPL (Zebra Programming Language) so it is available if BizTalk RFID isn't.  Both printers have support for checking the RFID tag to make sure it's readable. For the standard label printer, if a tag isn't readable, it will print VOID on the tag (or anything else you configure).

Cathexis is one of two companies with a drawing for prizes (Guitar Hero 3 and an XBOX 360) and is based out of Canada. Signing up for the drawing incorporated RFID and some of their products, including a HFpen reader, and a long range HF antenna. The pen reader, is an RFID reader about the size of a dry erase marker and in addition to an HF  RFID reader also has blue tooth. Our name badges have an HF tag imbedded, so it is scanned by the pen reader and stored in a database. Every time you walk past their booth the long range HFantenna picks up the tag and enters you again. Needless to say, their booth is usually very busy. I think my biggest take away is an idea on how to setup a promotional give away for Terso. Don't get me wrong the Bluetooth pen reader is pretty cool just not very applicable in my current situation.

I will be attending the first annual Microsoft RFID Solution Days, February 18-21 in Washington. I'm hoping to make it for the Reception on Sunday but I'm still waiting for my travel itinerary to be finalized by the Travel Agency. I'm also on the wait list for the hands on training and hope to get into that as well.

While searching for information and ideas on configuration stores, I came across an article on better WMI scripting. Defiantly something I will need to review in the future as I get into automated BizTalk management.

Server

Today I tackled upgrading my development server from BizTalk 2006 (Developer Edition) to R2 (Developer Edition). You can read my previous post on installing R2 on a clean machine. Detailed instructions (for all supported install scenarios) can be downloaded from Microsoft Downloads (See below for another link).

Upgrading was extremely easy, and I encountered no errors or warnings. I used the same cab file I downloaded for my clean install, since it was the same platform (Windows Server 2003 32 bit). You need to stop all BizTalk related services, and IIS (this is detailed in the instructions) during the install, and then restart them after the upgrade is finished. There wasn't even a reboot required.

One thing I'd like to point out, is that upon first glance, it looks like you are still running BizTalk 2006. The banner in the admin console doesn't mention R2, there is no new group in start/programs, even though the upgrade process lists an unistall step of BizTalk 2006 and an install of R2, there is no R2 program listed in Add/Remove programs, and the 2006 is still listed. Re-Running the R2 installer gives you options to repair, modify or remove, so the installer seems to think everything is correctly installed.

Not quite convinced I decided to look into this further. There is a registry key, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BizTalk Server\, which lists versions. I had a sub key for 3.0 and 3.5_Migrated. On my clean install, there is no 3.5_Mirgrated key, the admin console, and Add/Remove programs all list 2006 (not R2), so I guess that's just the way it is. If you are in the admin console and go to Help\About Microsoft BizTalk Server Administration, it lists version 3.6.1404 (compared to version 3.5.1602 before the upgrade). I guess I had an expectation that it would say R2 somewhere.

Another gotcha, is that the new WCF adapters are not installed by default. After the upgrade process, you have to re-run the installer and choose modify. Then you can add the WCF adapters, both under the BizTalk runtime, and admin tool. That goes for any optional component. If it wasn't installed before the upgrade, you have to go in and add it after the fact.

Workstation

Figured now was as good as time as ever to upgrade my workstation (development components) as well. The link I posted above didn't have a guide for installing on Vista, but a quick search found another page on Microsoft Downloads that did have a Vista Guide. I wasn't planning on reading the guide, but I couldn't get the install process to even start under Vista, so figured some trickery might be involved.

The first thing I did was find the redistributable components for Vista, so I could start downloading those while reading the install guide. The link to the components in including in the Technical Appendix in the install guide, and at the time of this post, the direct link is: http://go.microsoft.com/fwlink/?LinkId=81432, and weigh in around 30MB.

Since I just want the development tools, I skipped to page 21 in the guide, which are where the install instructions start. There was no special steps listed for Vista. I ended up rebooting my computer, and still couldn't get it to start (clicking install BizTalk from the setup screen didn't seem to kick off the msi process). I tried running the msi directly, and got the expected error saying to run setup. So I went back to setup, and this time it worked, weird.

After I actually got the installer running, everything after that was as easy as the server upgrade. I could have appreciated support for VS 2008, but 2005 isn't all that bad. The only time I would notice a difference is if I am working on a class library instead of a BizTalk artifact.

Today I made my first attempt at installing (clean install) BizTalk 2006 R2 on our development server. I started out by reviewing the documentation for installing on Windows Server 2003 in a single server configuration. You can find this documentation by clicking the link on the initial install screen for BizTalk. This will take you to Microsoft to get the latest version of the documentation. I also picked up the multi server deployment (production environment), and Vista (development workstation).  The first part of the documentation is more of reference material. Starting on page 38 it switches to detailed installation instructions for each piece that needs to be installed, starting with Windows Server itself.

Installation Wizard

1. Click thru until you get to Select Components. There are obviously the required core components. I also selected items which I thought we might need in the future, but didn't impact the amount of pre-requisite software I needed to install. There is a very nice matrix in the install document that outlines what needs to be installed for each feature. Based on that I selected:

• Documentation
• Server Runtime
• BizTalk EDI/AS2 Runtime (Possible Future Need)
• WCF
• Portal Components
• BAM (Possible future use)
• Human Workflow Web Service (Possible Future Use)
• Administration Tools
• WCF
• Additional Software
• SSO Admin
• SSO Master Server
• BAM Client

I also had to change the install path from C:\ to E:\ to comply with IT standards.

Clicking next brings you to a screen where you select how you want certain pre-requisites (redistributables) downloaded and installed. Choosing the download option (not auto install), takes you to the MS downloads site and cancels the installation. The cab file I needed to download was 102MB, and will be needed for a couple of other installations, so downloading it separate was a good idea.

2. After downloading and coping the cab file to the server, I restarted the installation, re-selected my components, and then chose the option to install redistributables from the cab file. I opted to provide my password for automatic login after reboots. I've copied and pasted the summary of items to be installed that is displayed before you click install.

Prerequisites

The following component(s) will be installed automatically on this computer:

• - Microsoft SQL XML 3.0 Service Pack 3
• - Microsoft Office Web Components
• - Microsoft ADO MD.Net 8.0
• - Microsoft ADO MD.Net 8.0 Patch
• - Microsoft ADO MD.Net 9.0
• - Setup runtime files
• - Enterprise Single Sign-On Server
• - Enterprise Single Sign-On Administration
• - Microsoft Primary Interoperability Assemblies 2005
• - Microsoft Document Explorer 2005

Microsoft BizTalk Server 2006 Components

The following components will be installed:

• - Documentation
• - Server Runtime
• - BizTalk EDI/AS2 Runtime
• - Windows Communication Foundation Adapter
• - Portal Components
• - Business Activity Monitoring
• - Human Workflow Web Service
• - Administration Tools
• - Windows Communication Foundation Administration Tools
• - Additional Software
• - Enterprise Single Sign-On Administration Module
• - Enterprise Single Sign-On Master Secret Server
• - BAM Client

3. No reboots were required, and no errors were reported. By default, when you finish the install, you are taken to the Configuration Wizard.

Configuration Wizard

1. The first thing you have to do is select your configuration type from either Basic or Custom, with the main difference being what service accounts are used for what services. I chose basic, which sets up all of the services to use the same account.

On page 55 of the instructions, it states that the specified user account will be granted the necessary permissions, including SQL permissions. I went ahead and created a local machine account that belonged to the users (not power users) group. I then specified this account in the configuration wizard and clicked Configure.

2. A summary of the configuration about to be performed pops up. I did a quick review, and then clicked next. I then sat, with my fingers crossed as the progress bar ticked by, hoping everything configured correctly. I didn't want to find out what graphic is displayed for an error (on success a green check box is displayed next to each section that is configured). The EDI/AS2 runtime took the longest to configure. I might not install that next time.

3. Everything completed successfully, except there was one warning with SSO. I have a feeling it is a note to back up the SSO secret. Another possibility is that I am running the SSO service with a local, and not a domain account.

Backup SSO Secret

1. Start/Programs/Microsoft Enterprise Single Sign-On
2. Expand Enterprise Single Sign-on
3. Right Click System and choose backup secret
4. Choose a path, and enter a password.
5. Make sure to write down your password and backup the file that was created. I store all my passwords on this nature using KeePass. I also can attach the actual backup file to the password entry in KeePass. If you have problems coping the file, check the NTFS permissions on the file.

Simple Test - CBR

1. Pre-Conditions: Event logs were clear of errors and warnings at this point. I did a quick inspection of services to verify the ones I was aware of, were running.

• BizTalk Service BizTalk Group : BizTalkServerApplication
• Enterprise Single Sign-On Service
• SQL Server (MSSQLSERVER)
• SQL Server Agent (MSSQLSERVER) - Change startup from manual to automatic

2. Reboot and check event logs for errors on startup. I also took this opportunity to snapshot the VM so that I could clean out my CBR test.

3. I created a simple CBR scheme, using 2 local folders, 1 send and 1 receive port. The exact implementation details are outside the scope of this post.

What's Next

Next up, is the upgrade of a BizTalk 2006 install to 2006 R2, so check back for a write up of how that goes.

Some quick notes on installing a custom BizTalk adapter.

• Your assemblies do not have to be in the GAC. I just looked on 2 BizTalk applications that are installed and running, and the assemblies for the adapters are not in the GAC
• I inherited a VS setup project that appears to handle the registry stuff for you. I don't know if you get this out of the box when creating a new setup project and adding references to your BizTalk project.
• You need to register the custom adapters using a registry file.
  • This file can be created using a tool that comes in the SDK and is installed on my computer here: C:\Program Files\Microsoft BizTalk Server 2006\sdk\Utilities\AdapterRegistryWizard
  • Documentation on the Registry File: http://msdn2.microsoft.com/en-us/library/aa560561.aspx
  • Documentation on the AdapterRegistryWizard: http://msdn2.microsoft.com/en-us/library/ms966446.aspx
• You can install the adapter assemblies in the GAC, and then leave out the file paths in the registry file. From the notes on the registry file:

For OutboundAssemblyPath and AdapterMgmtAssemblyPath we recommend that you not include the local path in the property value, because the configuration could break when installed on different server locations. A better choice is to use a strong name and install it in the global assembly cache.