BizTalk 2004 Custom Functoids

 

 

The documentation wasn't as clear as it could have been, or I'm not as sharp today as I thought I was.  Took a little bit of wrangling, but I've been able to create my custom functoids for BTS2004.

 

Here are the steps that give consistent results:

 

1. Make sure the assembly has a unique Guid attribute

2. Derive a class from Microsoft.Biztalk.BaseFunctoid

3. Include appropriate resource infomration such as:

    Name

    Description

    Tooltip

    base64 encoded Bitmap

4. Close the Visual Studio IDE if the current project uses the functoid.  It caches a global reference to the .dll and you can't update the file until its released

5. Copy the .dll to \Program Files\Microsoft Biztalk Server 2004\Developer Tools\Mapper Extensions to make it available for a developer workstation.

6. GAC the .dll in order to make it available during runtime, including map validation.

 

The biggest hurdle is getting your image embedded in the resource file (.resx), which requires some custom code:

 

    Image img = Image.FromFile("yourimage.bmp");

    ResXResourceWriter rsxw = new ResXResourceWriter("test.resx");

    rsxw.AddResource("test", img);

    rsxw.Close();

 

This code snippet will create a .resx file that includes the bitmap image data ("yourimage.bmp") encoded as base 64.  This can be copied and pasted into your functoid project.  Its also screaming for a little tool support, or automation.

Check out the sample available from the SDK at \Program Files\Microsoft BizTalk Server 2004\SDK\Samples\XmlTools\CustomFunctoid. You'll need to get the SDK Refresh for this to be available.

 

 

______________________________________________________________________________________

Zach Bonham | Technical Consultant *BAMPH* | 972.687.4851 office | 972.896.7405 cell | zach.bonham@mkcorp.com

 

Ok, deployment doesn't look as bad as I had originally feared. Basically it creates a "binding" file that is used to bind physical locations to logical locations for each environment.

Modifying this, as in previous example below, should be relatively pain free.

Covered BizTalk Orchestrations today. The ability to model a business process using an orchestration is really appealing to me. Our current BizTalk implementation is entirely messaging only, no orchestrations.

It will be interesting to prototype some of our existing business flows using orchestrations and then some sort of testing like:

Benchmark straight messaging implementation with BTS2004, compare with BTS2002

Benchmark orchestration implementation with BTS2004, compare with BTS2002

BTW, there is an excellent demo, "Building Your First Business Process", by Mr. BTS himself covering some BizTalk orchestration basics.

Looks like Mariusz Borsa and Erik Leasburg have already begun trying to ease the pain of BizTalk deployment. Their utility takes an example input binding file, and Xpath expression and a value to assign (mapping a logical to a physical value). It got an honorable mention on Scott Woodgate's blog today, so might be worth checking out!

Somewhat disappointed in some of the features/enhancements that I was really looking forward in BizTalk 2004. There are two areas that I had hoped to see some immediate relief for: configuration/deployment and document tracking.

Configuration and Deployment
I had been told that there would be significant improvements in this area, specifically the mention of being able to create "logicals" and "physicals" (this had been touted for the last year). Its seriously overrated, or I seriously underestimate its potential.

For starters, with a BizTalk 2002 implementation well behind us, we've long since had a custom process in place for deployment and configuration. This process is not elegant, and its not all that easy, but it works. Its our equivalent of a "binding" file that BTS2004 will use to configure a server.

Of course, our existing configuration and deployment process will break with the new version of BTS. We leverage an object model that will no longer be available (it has counterparts, but not in its current form).

I'll be following up on this as I get deeper into the details..

Document Tracking
Once again, we have a specialized document tracking strategy that we had to develop because of poor support in previous versions of BTS. Maybe poor support is a bad choice of words, but it certainly didn't meet our requirements.

The new document tracking, dubbed "Health and Activity Tracking", or HAT, first looks to be what we would want. However, there are restrictions when it comes to running the application (an HTA app, BTW...where did that come from??): the user has to be a member of the BizTalk administrators group, which of course gives perms that you don't want your average BA having in your production environment.

It wouldn't be too difficult to re-write some of the functionality that the HAT tool provides, but our existing implementation is so much more robust it might be a difficult sell.

I am still holding out that Business Activity Monitoring, BAM, feature will be enough reason to carry us forward anyway. More on that later..

Going to Austin Texas next week for some Microsoft instructor led training on BizTalk 2004. Should be pretty enlightening!

We already use BizTalk 2002 where I work, but I've been eyeing the feature set of 2004 for some time!