BizTalk

BizTalk Project / Assembly Organization Gotcha

John Watson — Fri, 06 May 2005 14:45:00 GMT

I have a real-world experience to share for organizing your BizTalk projects and assemblies. I think the natural tendency is to group “like things” together so if you have an orchestration with a schema or two and a custom pipeline you'd define all these artifacts in the same project. This way they're always kept together in source control, on disk and deployed together.

That same “benefit” is also the “gotcha” to watch out for. In my case, the custom pipeline is used to specify a schema formatted as a flat-file. The problem comes mostly during development and testing. If you update the orchestration you must stop, unenlist, undeploy, rebuild, deploy, bind, enlist, start - we've all done that hundreds of times. The problem is when undeploying the *assembly* containing the orchestration you're also undeploying the custom pipeline attached to the send port that's in the same assembly. BizTalk will then fallback to the standard Xml pipeline adapter on that port by default. Then, when you redeploy you're adding back the custom pipeline again which is where I get tripped up - I keep forgetting to switch the send port back to the custom pipeline.

The moral of this story is to use separate projects/assemblies for your custom pipelines and schemas. While this creates lots of little assemblies running around in your GAC, it can greatly reduce the failed tests because you forgot to rebind things!

Last note: Jon Flanders has more to say about pipeline components. Too bad this came out during the last phases of development for my current project - not enough time and too much to do!

Specifying the output filename from a BizTalk orchestration

John Watson — Mon, 02 May 2005 20:40:00 GMT

Once again, I needed a short simple answer but found either examples that didn't match exactly or newsgroup posts that were cryptic. In my case, the target system I was feeding data to required me to specify a filename that included the month and day of posting as well as the next sequential number. Thus the format is MyOutputFile_mmdd-nnn.out where mm is the month, dd is the day and nnn is the next sequential number (in the case of multiple runs during the same day). To do this, within the message assignment block you specify:

OutgoingMsgName(FILE.ReceivedFileName) = BTSHelper.GenerateOutputFilename();

Here you are setting one of the message's context properties so it must be within the scope of the construct message. Then, in the SendPort configuration you can use the macro %SourceFileName% and it will be replaced with the filename you set in the message's context.

In this simplified example, BTSHelper.GenerateOutputFilename() is a method on a .NET helper class that contains logic for creating the filename.

Changing a VPC Computer Name with BizTalk

John Watson — Wed, 27 Apr 2005 17:56:00 GMT

Alan Smith asked about the steps to take to change a VPC computer name when distributing the same preloaded VPC image to multiple developers...”We have network problems if two or more images with the same computer name are started with network access (to SourceSafe). So I attempted to change the computer name in an image.”

While the BizTalk reload steps are painful, Megan Davis put together notes on sysprepping the VPC image before distributing so that it will do a “mini-install” when first starting up similar to how OEMs do it before shipping. Thus you can allow the computer name to be changed when starting up the image for the first time!

New BizTalk Wiki

John Watson — Wed, 27 Apr 2005 00:55:00 GMT

Aaron Skonnard has started The BizTalk Wiki

Accessing input queue name in an orchestration

John Watson — Wed, 13 Apr 2005 15:12:00 GMT

The name of the queue that a message was received on can also be obtained through the message context:

IncomingMsgName(BTS.InboundTransportLocation)

Accessing input filename in an orchestration

John Watson — Sat, 11 Dec 2004 21:39:00 GMT

I recently needed to access the incoming filename in an orchestration and found it difficult to find the simple answer. I found a few examples of doing so in a pipeline adapter and a couple of cryptic answers on newsgroups but nothing plain and simple. The incoming filename is made available in the message context and can be accessed via:

IncomingMsgName(FILE.ReceivedFileName)

Hope this helps somebody and saves some time.

New BizTalk Deployment with NAnt

John Watson — Wed, 08 Dec 2004 01:05:00 GMT

Scott has a major update to his award winning BizTalk deployment script.