Yossi Dahan [BizTalk]


Monday, December 29, 2008

Wish list: optional parameters when using call/start orchestration

I wasn’t sure how bit problem this was, and in any case thought that optional parameters are a VB thing, but I’ve been proven wrong, and not only because optional parameters are soon to become a c# thing :-)

When using call/start orchestration we increasingly, as our solution “matures”, find that we need to add optional parameters to our processes..

In c# I was trained that function overloading is the correct way to implement this, and although I can see the benefit of the slim optional parameters approach I do think that it is much clearer; we’re talking BizTalk though, and you can’t really overload a function, can you? :-)

So we [can] do several things -

When dealing with .net types we can simply break the interface, add the parameter, change all the calling processes to supply one, and – if they don’t actually need to supply a value for this new parameter make them pass one anyway (an empty string, or a 0, or even –1); not elegant to say the least, and quite time consuming which means upsetting both the architect and the project manager.

Same approach works quite well when dealing with optional messages as well, only that now constructing that unnecessary extra parameter, in the same of a content-less message, is even harder (see my post on creating messages from scratch).

Another option, valid for .net types only, is to have a <something>Parameters class which would include all the parameters a process takes as properties; this would allow you to add as many properties as you need, without forcing callers to specify them; there are downsides of course – it is less readable and intuitive in my view, there’s a bit more hassle for the caller (create instance of parameters class, assign members) and now it’s harder to force those non-optional parameters (can be done via the parameter class’ constructor)

But there’s not equivalent option for optional message parameters.

Last, but not least, there’s the closest thing to overloading – you could always create a second process, with the extended set of parameters and have the original process forward the original call while providing this empty parameter, effectively saving the hassle from the original caller.

This is really how a function overloading solution would look like only that a process is not a function; it has a lot more impact in term of compile time, configuration required, deployment so the overall maintenance cost of such an approach is quite enormous for any decent sized project.

So – I can no longer ignore this problem and have to agree – allowing optional parameters with default values, for orchestration is quite important.


2011? :-)

Labels: ,

Tuesday, December 16, 2008

Never thought Url would be case sensitive


Working on my Geneva Framework based STS scenario I’ve stumbled into a very weird and annoying case where by if the user typed a Url in the wrong case (compared to the case of the V-Dir) the browser would enter a circular redirect between the STS and the RP.


I’ve started a forum thread, which you can find here, that got an answered by Peter Kron from MS through which I’ve learnt that the path portion of a cookie is case sensitive; you can find this in this RFC spec as well (read 3.3.3) -

…the old  and new Domain attribute values compare equal, using a case-insensitive string-compare; and, the old and new Path attribute values string-compare equal (case-sensitive). …

I don’t know if that’s just me, but I find this really surprising as, as a web user, I was never “trained” to tread urls as case sensitive, but it appears that, according to the spec, any personalisation stored for a particular path might be lost if I enter the wrong url?

In the STS scenario case this would mean potentially me having to login again, although I have already logged in on the STS.


Peter suggest to store the cookie against the domain, which is not case sensitive, and is good enough for me (for now?), but I don’t know if that’s realistic for all scenarios…..

Labels: , ,

Thursday, December 11, 2008

Notes on BizTalk 2009

earlier this week Microsoft announced the release of the beta version of BizTalk 2009.

I’m sure detailed posts of various bits will follow soon, but for now I thought I’d list a few points I’ve picked up (in no particular order)-

BizTalk projects are now “first class citizens” of Visual Studio [2008]; in practice it seems they are really “special” c# projects.

This means quite a lot really, to start with, for the most part they look and feel like c# projects (in the beta build the icon for the project is even the c# icon), but this extends to the property pages, existence of assemblyinfo.cs and the project file structure (which is now pretty much standard msbuild file)

It also means that you could add any c# type to a BizTalk project although in the current build you can’t add a new class using the menu, you are always redirected to the template selector which only shows BizTalk types, so –even if I pick the Add new class option


I get the following dialog -


Not sure when this will be fixed, but the workaround is simply (yet annoying) – create the type elsewhere and use the “Add Existing Item” option.

This will allow you, for example, to include any helper classes you use from your orchestration with the process itself.

Another point to notice is that this is only true for C# types. you cannot add VB code files to a BizTalk project.


Also – as the project is now a standard msbuild project integration with TFS is tighter.

interesting to see in the installation process the following entry -


Basically installing this on a computer that has msbuild allows you to build BizTalk projects without having BizTalk or VisualStudio installed; using a build server for BizTalk is so much easier now!


The build process is completely incremental – each BizTalk artifact is a c# class, and so when building a project only those classes that have changed will be built, which should shorten the time it takes to build a BizTalk project.

Another fantastic addition is more “HAT” features in the admin console, but as Randal already blogged about this one in details I’ll point you there


Upgrading seems to be a breeze and both 2006 and 2006 R2 are supported. this can be done by opening any existing BizTalk project in VS 2009 and the migration wizard will pick it up and migrate it for you. as expected.

you can open a solution with multiple projects and they will all be upgraded and you can use devenv /upgrade with both projects and solutions to do that from script?


BizTalk 2009 supports debugging maps – this is done by selecting the “Debug Map” from any BTM file context menu -


This would use the test input instance and test output instance properties, and would basically open the XSL generated for this map and break at the root template


Worth noting that currently this does not support maps with multiple inputs or ones using extension objects.


I’m sure there’s a lot more to discover, but I have a 4 day old baby at home – so back to those nappies for me I’m afraid.

Labels: ,

Thursday, December 04, 2008

Geneva-based passive STS and .net 2.0 web applications

Over the last few weeks I’ve been working on implementing a Geneva Framework based STS that supports both active and passive scenarios.

This is progressing very well and I already have a fairly solid PoC running for both scenarios.

Generally, to make any web site participate in the federated identity “dance” all it takes is some configuration on the application’s web.config (separate post coming shortly), but up until today I have only done so for web applications developed as a .net 3.5 project.

Today I have created a bog standard .net 2.0 web application project (on VS 2008, though, not that it should matter) and applied exactly the same configuration as I did on the other web sites.

when I ran this, not so surprisingly, everything just worked. isn’t it great?!


Of course – considering that everything is implemented as HttpModules – this should not be very surprising, but still.

It is important to remember, though, that .net 3.5, as well as the Geneva Framework, must be installed on the machine running the web site for this to work of course.

Labels: ,

Wednesday, December 03, 2008

What I hadn’t appreciated about schema versioning in BizTalk Server

Most people know that when processing a message through the XmlDisassembler, if not explicitly told which schema to use through configuration, the disassembler would try to resolve the correct schema based on the message’s root node and namespace.

Most would also know, usually through the experience of getting it wrong so many times first, that if more than one assembly contains the same combination of root node and namespace for a schema, the receive pipeline, containing the disassembler, would fail with the error  “Cannot locate document specification because multiple schemas matched the message type “<your message type here>”.”

What some miss (ehm, ehm) is that this is not true if the two schemas exist in two versions of the same assembly.

So – if you have an assembly called MySchemas.dll, version, …. which contains schema SomeRootNode#SomeNamespace and you have MySchemas2.dll, Version…… which contains schema SomeRootNode#SomeNamespace (same one) – BizTalk would fail.

If, however, you have the assembly MySchemas.dll, version, …. which contains schema SomeRootNode#SomeNamespace and then create MySchemas.dll, version, …. which contains schema SomeRootNode#SomeNamespace BizTalk would quite happily ignore the former and use the latest version available.

Makes perfect sense, of course!

Labels: , ,