I've been crazy busy lately with BizTalk Server.  First, I'm happy to announce that Microsoft has recognized me as an MVP for BizTalk Server (and I got nominated for the Connected Systems group as well)!  I'm very pleased and look forward to doing as much as I can in the community this year to earn the reward. 

 

As for teaching BizTalk, I'm doing three deliveries of our Applied BizTalk Server for internal Microsoft groups, two of which are India.  So, I've just returned from Hyderabad and I'm heading back in a week and a half.  It is wreaking havoc on my internal clock, but the groups are great and I had a lot of fun teaching the class.  Awesome questions and great discussions as many of these people are working with BizTalk daily and already have some areas they wanted to understand more about. 

 

It was also fun to visit Hyderabad.  I've been to Bangalore once a year ago, so it was interesting to compare.  Microsoft has an impressive facility there and they are continuing to build.  A very exciting time for the city and the people from what I could tell.  I'm looking forward to my return trip and some more excellent Indian food (the Biryani was an especially good local specialty available right in the MS dining hall).  I also got some lessons in Cricket. I knew nothing going in, and I'm still mostly in the dark but at least not completely in the dark.  I have several pieces of information to help me know how it is different from baseball, as opposed to just knowing that it is different, which is where I started. 

 

I'm also frantically "playing" with some early bits of BizTalk R2.  I've got some upcoming talks where I am going to be showing BTS with WCF, WF and other technologies under the Connected Systems umbrella. So, I have some demos to get working so I don't get booed off the stage. :)  More on these talks in another post. 

 

Finally, I am doing an open enrollment BizTalk course here in Minneapolis in March.  If you want to get the best training on BizTalk Server (modest aren't I) then sign up on the course information page. I'd like to guarantee that the temperature won't be below 0 when you come, but who knows.  :)  Either way, it will be a fun informative week.   

 

 

I've seen many people in the forums trying to figure out the best way to get data from a workflow at runtime.  The root of the problem lies in the fact that while you can get a handle to a WorkflowInstance from the runtime, this is really a template and does not contain the values of properties on the workflow.  It is a common need to get the current state of your process, or get values from the class. 

 

One solution is to use the local communications activities and call back to the host and have a local service manage the values.  But, who wants to drop a bunch of CallExternalMethod activities in all of their workflows.  No the answer, not surprisingly, lies with tracking. 

 

Tracking in workflow provides so much power and flexibility to extract data that you are interested in. I've created a custom tracking service which tracks the workflow properties at runtime and stores them in a dictionary in the service.  When you want to get the current property values for a workflow, you get the tracking service from the runtime, then ask it for the properties which you get back as a Dictionary<string, object> just like the parameters you passed into the workflow. 

 

There are two keys to getting this work and both revolve around the tracking profile.  First, it is important to know that when you define an ActivityTrackPoint, you can add data extracts which define the data to extract and send to the tracking channel.  But those extracts can either be activity extracts, or workflow extracts.  So, I define an activity track point to track all activities on close and add Workflow level extracts to pull the properties off of the workflow at that point.  The second key piece is figuring out what properties are available on each workflow type.  This service would be pretty limited if it were tied to a specific workflow type.  Instead, when the profile is created based on a workflow type, I reflect on the type to get the public properties defined in this type (not the base classes though you can do that too) and build the extract definitions from them. 

 

So, when a workflow is run, the profile is created indicating that on each activity closed, the properties of the workflow should be sent to the tracking channel.  In the channel, I simply update the dictionary of values stored in the service.  Finally, when an instance completes or terminates, I remove the values from the dictionary. 

 

You could track more often by using other statuses on the activity tracking location, but beware of the overhead tracking may add in these cases. 

 

I hope this is helpful.  As always, comments and feedback are welcome. 

My article on building custom activities for Windows Workflow Foundation has finally posted to MSDN.  For those of you fortunate enough to get a printed copy, you got an entire week advanced screening. :) 

I tried to cover the basics of building an activity and the various components; designer, validator, etc, as well as touch on some of the things you can do for more advanced activities that need to listen for external data/events. 

 

I'll be writing more articles for MSDN Magazine on Windows Workflow Foundation in the coming months. If you have specific topcis that are of interest, post your feedback here and I'll consider it as I plan the next articles. 

 

Finally, working with released code! 

Get it here, along with the Visual Studio extensions and Windows SDK.

Now, if they could just get the Vista RTM out so I can do .NET 3.0 RTM development on my desktop.

I have been looking at scenarios involving Workflow and BizTalk and figured a good place to start was with Rules integration.  If you have rules already defined in the BizTalk BRE, then you should be able to take advantage of them from a Workflow instead of trying to translate all of those rules into the WF rules engine. 

 

The BRE activity allows you to reuse your investment in the BizTalk BRE be configuring and executing policies from your workflow.  It contains a custom activity designer that queries information about the policy/facts and builds a dynamic set of properties so that you can configure the facts right on the activity and use databinding. 

 

This is definitely a sample but works with my simple tests.  I have not added support for data connection or data row/table facts, but it should be easy enough for someone to add those into the designer. 

 

Hopefully this will be useful for some of you.  Any feedback is welcome. 

 

Grab the code here.

 

Get the details here:  http://support.microsoft.com/kb/924330/. 

 

My favorite fix is that the per instance pipeline configuration works as advertised/expected.  This was something a client of mine really needed as we had a pipeline template that we used with many different customers.  However, we had different configuration for each customer.  Essentially, we had file naming standards and different encryption key identifiers that we needed to configured.  Without this fix, we would have had to use a different pipeline definition for each port.  With the fix, we just updated our binding files to include the configuration of the pipeline components and we could reuse the same template over and over again.  Awesome, and of course, included in the 2006 version.

You might file this under the "it has always been this way and I'm late in figuring it out" category, but I just found the three letter snippet shortcut for Workflow dependency properties and events.  I didn't see this in earlier builds and was getting tired of CTRL+K -> CTRL+X then drilling into the menus to get to Worfklow Dependency property.  Especially since the EventHandler snippet always came first and the way they are worded I had to either move to the cursor keys or type 25+ characters to get it to move down to the property item. 

 

Now I just WDP + Tab + Tab and I'm happily editing a workflow dependency property. 

Or, I can WDE + Tab + Tab and edit my dependency property for an event handler. 

 

Awesome!

Kevin Lam has put together a great set of posts describing the direct binding options in BizTalk Server when using messaging shapes in Orchestration.  This is one of those powerful features of BizTalk that gets underutilized because people don't understand it, or even know about it.  It is also one of the areas where people get into real trouble because you need to understand it well in order to use it without getting yourself into trouble. 

 

 

I found this posting the other day and was surprised to find some things in here that I didn't realize had changed.  Not that I should be surprised, it's hard to keep up with a big product like BizTalk.  :) 

 

Interesting points include a new registry entry that allows you to invoke statics without having to assert the class into the runtime; support for generics; and allowing object traversal.  Unfortunately, the latter item is only available in code, which is a huge bummer since I find this to be one of the most frustrating things with the BRE composer. 

 

There are several other interesting tidbits so be sure to check it out if you do anything with the BRE in BizTalk.