This tip comes from Marty Waz (described yesterday in my post about Publishing as Web Services) .  As you’ll remember, I’m at the Virtual TS Boot Camp, where we did a simple BizTalk 101 project – Marty Waz Style.  Basically, it’s a Hello World Web-Services project, but using all best practices and done in 20 minutes.

Ok.  Not a problem.

But it turned out to be quite a problem.  The class is made up of mostly Virtual TS’s and actual Microsoft TS’s so it’s not like it’s a slacker group (although we’ve all run into the occasional bonehead TS).   Probably one of the best groups to program BizTalk outside of the actual BizTalk Server team at MS.   Anyway, enough praises – cause we sucked big time.  Not a single person was able to do the assignment even with extra time following all of Marty’s best practices.  Personally, I forgot to isolate the external schemas from the internal, used maps inside my orchestrations, and used Schemas directly as Messages.

Well, that last part is the topic of this post.  Marty showed us how to save an extreme amount of time by loosely coupling our messages inside our orchestrations.  No more messages of type schema.  It’s a little odd, so let’s start from the beginning.

Here’s the non-leet method: Create your orchestration.  Add a receive shape and a logical port.  Well, now I need a message.  Add a new Message in the Orchestration Explorer.   Set the Message Type to the schema you want.  Hook up your receive to that logical port.  Nothing out of the ordinary so far.  And let’s do something that should be pretty easy: change our schema type.  So we go to the Message, select the Message Type and select a different Schema.  We get the following error:

Property value is not valid: One or more Send or Receive actions are connected to Ports and are using this Message.  Please disconnect the actions before changing the Message Type.

Now this is a fairly common thing.  I mean, sometimes we change our schemas – during development this happens all the time.  The object oriented equivalent is changing variable “int foo” to “double foo” in code.  What if you couldn’t do that without removing all the references to foo.   That would suck.

Here’s Marty’s super hot way around this: Create your orchestration.  Add a receive shape.  Well, now I need a message.  ADD A NEW MULTI-PART MESSAGE TYPE.  Give it name that doesn’t include the schema –remember, you are using this as an abstraction over your schemas so you can change between types (Object oriented analogue: changing “int foo” to “double foo”).  Change the “MessagePart_1” to “Body” (CAPITAL B – it’s important).  Now set the Type for this to the schema you were going to use before.  NOW add a normal Message, name it, but instead of choosing a Schema for the Message Type, choose your Multi-part Message Type.  Use this message like you normally would.

Go ahead, try changing the underlying schema type.  Instead of doing it at the Message Level, you can do it at the Multi-part Message Type.   Your links are still valid because the ports are bound to the wrapper around the schema (multipart message), not the schema itself.  You have successfully changed from “int foo” to “double foo”.

Sounds pretty simple, but no one in the room knew it.  So I figured I would blog it so we don’t see any more of this in the field.  So, there you go, no more schema type messages, only multi-part messages.

[Editors note: this text is a little confusing without sitting down with an orchestration and trying it yourself.  I may post a video shortly that walks you through the changes.]