Pipeline Component Wizard

BizTalk 2006 has only poor support for developing custom pipeline components. Luckily, there is some kind of tool on Codeplex, which makes it easy to create custom pipeline components. The tool is a project creation wizard within Visual Studio. It comes together with its own project type and is able to generate pipeline component projects from scratch depending on several parameters.

So far, version 2.00 is the current one for Visual Studio 2005 and BizTalk 2006. Unfotunately, this version has a bug. Each time you use the wizard to create a new project you get the error.

System.ArgumentException : Value does not fall withing the expected range

There is no official solution yet. An unofficial way to solve it is:

Change the file BizTalkPipelineComponentWizard.cs around line 304

FROM
[...]
// get a handle to the project. using mySolution will not work.
pipelineComponentProject = this._Application.Solution.Projects.Item(Path.Combine(Path.GetFileNameWithoutExtension(projectFileName), projectFileName));
[...]

TO
[...]
// get a handle to the project. using mySolution will not work.
if (this._Application.Solution.Projects.Count == 1)
pipelineComponentProject = this._Application.Solution.Projects.Item(1);
else
{
// In Doubt: Which project is the target?
pipelineComponentProject = this._Application.Solution.Projects.Item(projectFileName);
}
[...]

See Source

After that, you have to complie the source code and (re)install the wizard.

Dis-/Assembling EDI streams is ending up with an unhelpful error description

Last week, I came up with a BizTalk hotfix which improves the EDI error descriptions. Normally, when you disassemble an EDIFACT stream in BizTalk 2006 R2 and it does not work, the serivce instance suspends with an error like

An output message of the component "Unknown" in receive pipeline "Microsoft.BizTalk.Edi.DefaultPipelines.EdiReceive, Microsoft.BizTalk.Edi.EdiPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" is suspended due to the following error: Unknown. The sequence number of the suspended message is 1.

In this case, looking into the EventLog is crucial. If you have several biztalk host instances on different servers like us, this is an annoying job. In the past, we wrote us a custom component which looks up the Event Log for the error descriptions. But since we installed the hotfix, we have everything we need in BizTalk and we do not need to look somewhere else anymore. Very useful (See Hotfix 955303)

Nested transactional scopes just because of non serializable code

It's good to avoid having non serializable code in an orchestration. I give you an example: Let's say you have non serializable code in an expression shape which need not to be executed transactional. The pitty is, that you have to put an atomic transaction scope around it. The reason is that BizTalk only allows non serializable code in this kind of scope. In addition to that, you need another long running transaction scope around the first one, if you want to do some exception handling. BizTalk does not allow you to add an exception handler to an atomic transaction scope. So, there is a lot of overhead just because of the non serializable code in the beginning. If performance is a critical factor, here is potential. The best way would be to make the code serializable or to outsource it to a custom .NET class. For the second option it is important to make the methods static which are called by the orchestration. The benefit would be that you only need one non transactional scope in the given example. (See Biztalk : Atomic Transaction for Exception handling and Atomic scope for Non Serializable code)

Details of Errors caused by ThrowException Shape

When you design a BizTalk orchestration and you want to suspend the orchestration with a ThrowException shape, it is useful to initialize the exception variable in an Expression shape with a descriptive error message in advance.

Example:

incomingMessageNotFoundException = new System.Exception("No referenced incomingMessage found"); (*)

(*): In this example incomingMessageNotFoundException is the exception variable of type System.Exception.

The result is that the error message "No referenced incomingMessage found" is shown in the Error Information tab of the Service Details window if an orchestration instance gets suspended because of this error. If you do not initialize the variable yourself, BizTalk uses the default constructor and you only get the information that an exception of type System.Exception has occured in your orchestration. This does not help much.