Author: Richard Seroter

Just returned from the Summit, and had a really great time meeting colleagues and seeing interesting content.  Without breaking any NDAs, I thought I’d share some thoughts on what I saw this past week.

• The CSD/BizTalk MVP group remains a smart bunch of guys with a diverse set of backgrounds.  I shared a hotel room with Yossi Dahan, and was thrilled to spend time with the likes of Mick Badran, Michael Stephenson, Saravana Kumar, Stephen Thomas, Leonid Ganeline, Ben Cline, Jon Fancey, Kevin Smith, Alan Smith, Mikael Håkansson, Jon Flanders, Matt Meleski, Tim Rayburn, Kent Weare, Bill Chestnut and many others.  The practical experiences these guys have with customers should be milked dry by the product teams.
• I finally spent some time on Azure (thanks to Steve Marx’s session) from a development platform perspective (i.e. not .NET Services) and I am quite impressed by the developer experience.  This seems to be something Microsoft will really bang on when trying to differentiate its offering from those of others in the “cloud computing” space.
• The Summit was also the first time I’ve REALLY looked at “M” since last year’s Summit, and I think it has potential to be useful.  I made this observation in a previous blog post, and plan to actively mess around with “M” for both data solutions and to emit actionable content.  The interesting thing is, the lengthiest work doesn’t seem to be writing the textual DSL as much as constructing the parser to do something with the output.  That is, in the examples referenced in the link above, “M” models are used to create orchestrations and BizTalk build processes, respectively.  Once the “M” part is done, both Yossi and Dana had to write the parser which took the MGraph and cycled through the objects to generate the final output (i.e., ODX file and executable deployment script).  Not a bad thing, just something that’s seemingly glossed over.
• We had a “BizTalk Next” brainstorming session, and I was happy to see some big ticket items on the minds of the BizTalk architecture team.  After sitting on the same runtime engine for 5 years, and mostly surface-level changes during the past 2 releases, it seems like “put up or shut up” time for these guys.  And they seem to be working hard to be in the former category.
• Ewan Fairweather led a strong session on BizTalk performance with a special focus on the impact of virtualizing BizTalk solutions in Hyper-V.  Ewan authored the BizTalk Server R2 Hyper-V Guide and BizTalk Server Performance Guide.  The results of Ewan’s recent exploits with his giant server farm will be making their way into public documentation shortly.  A few takeaways (which I was assured aren’t NDA!): (a) performance of “inline sends” vs. “logical ports” within orchestrations is nearly 4x faster with regards to throughput, (b) the performance impact of virtualization on BizTalk solutions is fairly negligible and (c) making a few well-known platform tweaks can nearly double performance.  Look for more approachable guidance in the near future (vs. massive, detailed whitepapers) as the team realizes that with such a developer-centric product as BizTalk, you need to remember that you aren’t always talking to your standard system administrators.

As for non-content related observations …

• Tim Rayburn can sing a mean Black Hole Sun, as experienced during one of the social parties of the week.
• Those two white guys who sang California Love?  Not so much.
• Mick Badran is a wild man, and a helluva great guy.  However, I worry that any “guys night out” with him always ends with something like “… and that’s how we ended up in a Chinese prison with two 85 year old women and $450 in nickels.”
• People need to stop with the corny gifts to Ballmer and the general Q&A shenanigans.  You’re embarrassing yourself folks.
• Conference attendees will take pictures of ANYTHING.  Seriously, random speakers, crowds, buses (inside and out), signs, buildings, hotel lobbies, plant life.  And what’s with the incessant picture taking of NDA slides?  SLIDES, people.  Write down the content if it’s that freakin’ important.  I’m convinced that these people are either (a) IBM spies or (b) crafting the most sleep-inducing scrapbook since my 3rd grade trip to the Liberty Bell.

Great time overall, looking forward to doing it again.

Technorati Tags: BizTalk, MVP

While at the Microsoft MVP Conference this week, I’ve added “modeling in ‘M’” to my “to do” list.  While I’ve kept only a peripheral view on “M” to date, the sessions here on “M” modeling have really gotten my mind working.  There seem to be plenty of opportunities to build both practical data sets and actionable content through textual DSLs. 

One great example of applying “M” to existing products/technologies is this great post by Dana Kaufman entitled A BizTalk DSL using “Oslo” which shows how one could write a simple textual language that gets converted to an ODX file.  It’ll be fun watching folks figure out cool ways to take existing data and tasks and make them easier to understand by abstracting them into a easily maintained textual representation.

Update: Yossi Dahan has also posted details about his current side project of creating an “M” representation of a BizTalk deployment process.  He’s done a good job on this, and may have come up with a very clean way of packaging up BizTalk solutions. Keep it coming.

Technorati Tags: Oslo, BizTalk

This has come up twice for me in the past week: once while reading the tech review comments on my own book (due out in April), and again while I was tech reviewing another BizTalk book (due out in July).  That is, we presumptively say that the BizTalk “message type” always equals http://namespace#root when that’s not necessarily true.  Let’s look at two cases demonstrated here.

This first simple case looks at a situation where an XML schema actually has no namespace.  Consider this schema:

Perfectly fine schema, no target namespace.  I’ve gone ahead and created another schema (with namespace) and mapped the no-namespace schema to the namespace schema.  After I deploy this solution and create the necessary ports to both pick up and drop off the message, I can stop the send port and observe the context properties of the inbound message.

Notice that my message type is set to ReturnRequest which is the name of the root node of my schema.  Obviously, no namespace is required here.  If I throw my map on the send port, I can also see that the source schema is successfully found and used when mapping to my destination format.

So, for case #1, you can have schemas with no namespace, and the message type for that message traveling through BizTalk is in no worse shape.

For case #2, I wanted to try creating my own message type arbitrarily and keep it as something BizTalk doesn’t generate.  For instance, let’s say I receive binary files (e.g. PDFs) but want to add not only promoted fields about the PDF, but also type the message itself.  The PDF file has a specific name which reflects the type of data it contains (e.g. ProductRefund_982100.pdf and ProductReturn_20032.pdf).  The file location where these PDFs are dropped have names based on the country of origin, like so:

So I can set a “type” for the message based on the file name prefix, and I can set a promoted “country” value based on the location I picked it up from.  After adding a new property schema to my existing BizTalk solution, I next built a custom pipeline component which could work this magic for me.  The guts of the pipeline component, the Execute operation, is shown here:

public IBaseMessage Execute(
     IPipelineContext pContext, 
     IBaseMessage pInMsg)
{
 //get context pointer
 IBaseMessageContext context = pInMsg.Context;

 //read file name and path 
 string filePath = context.Read("ReceivedFileName", 
 "http://schemas.microsoft.com/BizTalk/2003/file-properties").ToString();
            
 //parse file name to determine message type
 string fileName = Path.GetFileNameWithoutExtension(filePath);
 string[] namePieces = fileName.Split('_');
 string messageType = namePieces[0];
            
 //get last folder which indicates country this pertains to
 string[] directories = filePath.Split(Path.DirectorySeparatorChar);
 string country = directories[directories.Length - 2];

 //set message type
 pInMsg.Context.Promote("MessageType", 
  "http://schemas.microsoft.com/BizTalk/2003/system-properties", 
   messageType);	

 //set promoted data value
 pInMsg.Context.Promote("Country", 
   "http://Blog.BizTalk.MessageTypeEvaluation.ProductReturn_PropSchema", 
   country);

 return pInMsg;
}

After compiling this and adding to the “Pipeline Components” directory in the BizTalk install folder, I added a new receive pipeline to my existing BizTalk solution and added my BinaryPromoter component.

After deploying, I added a single receive port with two receive locations that each point to a different “country” pickup folder.  Each receive location uses my new custom receive pipeline.

I have two send ports, each subscribing to a different “message type” value.  My second send port, shown here, also subscribes on my custom “country” promoted value.

When I drop a PDF “product refund” file into the “USA” folder, I can observe that my message (of PDF type) has a message type and promoted data value.

Neat.  So while it’s important to have BizTalk-defined message types when doing many operations, be aware that you can (a) still have message types without namespaces, and (b) define completely custom message types for use in message routing.

Technorati Tags: BizTalk Server