Wish list: "End" shape.

Often orchestrations have conditions that, when met, mean the orchestration should stop executing.

In .net code a developer could simply put a “return” keyword in the function to stop the execution and return to the caller; unfortunately there is no equivalent in orchestration development.

The only “clean” way to end an orchestration currently is to reach the built-in, fixed, red shape at the bottom of the orchestration designer.
This often means that decision shapes exist all over the orchestration with branches that have to drop all the way to the bottom. In large orchestrations this can be hard to follow up on.

It could have been made much nicer by allowing a developer to add as many “end” (or “return”) shapes as needed in various places in the process. Decisions, of course, will still exist, but their scope will be much smaller.

An alternative that exists currently is to use the terminate shape, but I find it to be a bit artificial – my view is that termination of processes may be relevant in exceptional scenarios, as part of error handling, etc. but not when the orchestration ends correctly (albeit before reaching the end of the schedule). The main problem with the terminate shape possibly is that the orchestration gets a “terminated” state and not “completed” which will make it difficult to report in HAT (and otherwise)

Microsoft goes open! (?)

Microsoft have released a press statement today announcing that they are implementing four principals accorss their high volumes products. These principals are -

(1) ensuring open connections;
(2) promoting data portability;
(3) enhancing support for industry standards;
(4) fostering more open engagement with customers and the industry, including open source communities.

So - what does that mean?

Primarily it would mean Microsoft would publish a lot more information about APIs to their products and protocols used within and between them, allowing developers to do even more with the products and integrate their own products/system more closely with Microsoft products.

It also means, or at least that is my understading, that Microsoft would now officially allow develpoers to use these patented protocols for non-commercial use or even for development of commercial code; distribution of commercial code that uses those protocols does require a license of course.

It seems that Microsoft, as part of this newly self-enforced commitment, are about to release a lot more information about their products, including, for example, how their are implementing variuos industry standards and when they have a variation or extension of the standard that would be made clear and public.

Some products, like Office for example, which already moved to a more open format of documents in it's latest version, will be opened further, by providing a new set of APIs that would allow third parties to control a lot more of the application's behaviour including, apparently, supporting other formats which would ultimately mean you could use word, for example, to author document in any format.

This is very exciting and it shows that Microsoft is listening to the public and is more than willing to engage better with the community (and it only took a few years of being chased down by the european courts :-)), but seriuosly - I have to admit that from my personal perspective Microsoft has been providing more than enough information for me to be able to do my work and advance my knowledge and expertise; through the MSDN web site, conferences, various partners programs, MVP etc I had more information that I could swallow.

I'm sure many do not share that feeling (and then there are those who just like to hate Microsoft), and I hope this very exciting move will help change a little bit of that mood.

On a conference I attended recently someone asked one of the Microsoft guys if they ever plan to slow down a bit with the amount of new stuff they release (products, frameworks, SDKs, documentation, standards) which leads to almost infinite time one needs to spend learning all of that; the answer, as you can imagine, was categorically no. but while I don't think anyone in the room epected it to be any different, I also don't think anyone anticipated such a big move on that front.

Read more

Casting between messages and classes demystified(?)

I wrote in the past already, as I've argued many times before, that messages should be manipulated using maps and xsls and not using code.

However, as stubborn (and purist?) as I may be I have to admit that some cases just call for the odd manipulation (or creation) of messages as classes in .net helper functions.

And so - it is very fortunate that BizTalk is intelligent enough to allow us to cast one to the other without any fuss.

To those of you who do not know yet it is quite possible to have the following -

A serializable class in any .net language.
A schema that correclty represents the xml representation of that class.
A class (idealy a different one) with a function (usualy static, but doesn't have to be) that accepts a paramter of the class above.
An orchestration that has a message of the schema above.
An expression shape that calls the method in that second class passing the message.

BizTalk will take care of the serialization of the message and will pass an instance of the class to the helper method.

Similarly it is possible to return a class from a function and use that function in an assign shape to create a new message (and, of course, the two approached can be combined as well)

Anyway, we've known that for a while now, and it has worked wonders for us; this technique makes both the functions and the orchestrations that need to use them so much simpler; but recently I nearly went mad when I tried to do just that and kept getting casting errors at build time for - as I thought at the time - no reason at all.

For some reason BizTalk was unwilling to accept that my schema and my class are one.
only after quite a few nerve racking attempts did I find out what I did wrong -

All of our classes have serialization attributes to control the xml generated; mostly we're making sure we use attributes whenever possilbe (as opposed to the default element serialization) and that the attribute/element names are short-ish.

In the particular class I used we had an XmlRootAttribute that set a (different, shorter) name to the root element representing the class; as soon as I removed the name from the attribute (it is optional) VS was happy to compile my orchestration.

It appears that BizTalk needs the root element of the class to have the name of the class; no shortcuts there.

By the way - a few months ago I've published this article suggesting that passing XlangParts as paremeters to helper functions may cause a memory leak.

As this would have prevented us from using this wonderfull casting technique we've asked Microsoft to kindly confirm if indeed my understanding at the time was correct and that one should not pass an XlangPart as a parameter to a function.

As I understand it now, and although it is not very clear from the KB article I've referred to in my post, passing XlangParts is ok as long as the lifetime of the message/part is not shorter than the the lifetime of the parameter - in other words - as long as you don't keep the message or message part in memory in your helper class you should be safe.

GAC stings again....

....or is it just me being stupid again...I don't know...


But anyway - I was working the other day making some changes to one of our classes and, as most of our classes have both code and schema representation, I went on to generate the schema from the modified class.

So - I've built the project with the class to generate an assembly, and in Visual Studio command line I swiftly 'CD'-ed to the bin folder the project and used XSD.exe to generate the schema in order to replace my existing one to reflect the recent changes.

However, to my great surprise, the generated schema did not have any of the added nodes I expected to see - it looked suspicously identical to the old schema I had.

It took me quite a few attempts before I've realised what's happening - as you can imagine from the title of this post the answer lies in the GAC - I had the older version of the assembly containing class in the GAC and so XSD.exe, although being pointed by me a specific assembly in the bin folder, has decided to pick the old one from the GAC and use it to reflect the class.

As soon as I removed the old version from the GAC XSD.exe was happy enough to generate the correct schema for me.