Brimful of Azure

The “Yull” vacation has finally given be the chance to start digging into Windows Azure. There’s quite a few services in the Azure platform and as I’ve already spent some time looking at “BizTalk Services” before it was re-branded to .net Services I thought I’d take a look at SQL Data Services (SDS).
SDS is very easy to work with if you know a bit about WCF and choose to take the SOAP road. I labbed a bit with the REST stuff and found it more complex than SOAP, so I stuck with the SOAP client.
I’ve put up a couple of webcasts on BloggersGuides.net. Enjoy…

Orchestration Designer Crash

I recently encountered a troubling problem while creating a BizTalk 2006 R2 solution. Everything was working fine until I tried to open the Orchestration Designer to edit one of the orchestrations I had been working of for a couple of days. Visual Studio crashed immediately. I tried a few things, but I could not open any orchestration without Visual Studio crashing (no errors in event log, no dialog, nothing…).

I finally fixed it by backing up and deleting my Visual Studio profile. The profile information is stored in a folder. This folder is located in C:\Documents and Settings\user\Application Data\Microsoft\VisualStudio\8.0.

I don’t know what got messed up in the profile. Clearly some sort of VS/BizTalk bug.

PipelineTesting vs TestablePipeline

I recently wrote an entry describing in general terms the new Unit Testing features
in the BizTalk Server 2009 beta. However, I didn’t focus much on the functionality
available for testing pipelines and how it related to my own PipelineTesting library.

The BTS09 testing features work by having compiled pipelines derive from the new TestableReceivePipeline and TestableSendPipeline classes,
which define a TestPipeline() method for invoking the pipelines with
one or more files as input documents and the necessary schemas (as XSD files on disk).

Here’s the canonical sample of how it is used in the documentation:

[TestMethod]
public void TestMethod()
{
   string strSourcePO_XML = @"C:\BizTalkSamples\POProcessing\POInst.xml";

   ReceivePipeline1 rp = new ReceivePipeline1();

   StringCollection documents = new StringCollection();
   documents.Add(strSourcePO_XML);

   StringCollection parts = new StringCollection();
   parts.Add(@"C:\BizTalkSamples\POProcessing\POInst.xml");

   Dictionary<string, string>
schemas = new Dictionary<string, string>();
   schemas.Add("http://POProcessing.PO", @"C:\BizTalkSamples\POProcessing\PO.xsd");

   rp.TestPipeline(documents, parts, schemas);
}

By comparison, here’s what doing a similar thing with PipelineTesting might look like:

[Test]
public void TestPipeline()
{
   ReceivePipelineWrapper pipeline =
      Pipelines.Receive<CSV_FF_RecvPipeline>()
      .WithSpec<Schema3_FF>();
   IBaseMessage input = MessageHelper.CreateFromStream(
      DocLoader.LoadStream("CSV_FF_RecvInput.txt")
      );

   MessageCollection output = pipeline.Execute(input);
}

Both the BTS09 features as well as PipelineTesting rely on the venerable PipelineObjects.dll
assembly originally included in the SDK tools folder (but which now is a more integral
part of the product), so general behavior should be relatively similar.

The big difference, however, is flexibility. I designed the original PipelineTesting
library to be far more flexible and allow you to do a lot more than simply execute
a compiled BizTalk pipeline, which is all the BizTalk 2009 features allow you to do
at this time.

This flexibility allows you to also do the following tasks with PipelineTesting:

  • Composing pipelines from arbitrary components at runtime and execute them.

  • Work with compiled BizTalk Schemas instead of the raw XSD files.

  • Doesn’t require you to build a special version of your pipelines to test them.

  • Close control of each part of the pipeline execution process: Control the properties
    of each component, how schemas are resolved, transaction support, and other things
    like that.

  • Very good support for multi-part messages.

  • Support for per-instance pipeline configuration

All in all, I’m very happy with PipelineTesting and will favor it when working with
BizTalk Server 2009 over it’s own testing features. I also hope to take a couple of
ideas to improve PipelineTesting and make it even easier to use and more powerful.

Oslo and the OMG

One of the best ways to understand the concepts that lie behind a new technology is to compare and contrast it with similar technologies provided by other communities. ’Oslo’ addresses the modelling domain which has enjoyed a great deal of attention over several years. This article is an attempt to articulate something of the nature of Oslo by relating it to the wider world of modelling, especially as envisaged by the OMG (Object Management Group).

http://geekswithblogs.net/cyoung/archive/2009/01/05/128369.aspx

Busy travelling, busy speaking

 

So, I’ve been booked into the Microsoft 2009 SOA conference in Redmond at the end of this month to speak about the new version of the ESB Guidance (V2.0). For those of you who are familiar with version 1.0 of the guidance, I strongly recommend that you check out v2 (http://www.codeplex.com/esb). It has a number of great improvements that really help to "polish” up the concepts that were introduced in the initial release.  We now a visual Itinerary designer right inside VS 2008 (no more having to manually code up raw XML itineraries yeah!!!)  We’ve also got a new Itinerary database where we can store, version and retrieve our itineraries.  We also got a a new pipeline component called the ItineraryForwarder that allows us to chain together service calls without the need for an orchestrations (i.e. Call Service A and send the response to Service B and then send its response to service C).  We use to require a BizTalk orchestration for this, but now this kind of simple chaining can be done entirely using ports and pipelines.  Also, the team has done a nice job of cleaning up the install by giving us a Configuration application instead of requiring us to manually modify a bunch of different install scripts.

After I’m done at the SOA conference, I’ll have just enough time to fly home say a quick hello to my wife and bed before turning around and heading right back to Seattle to speak at our own internal TechReady conference about the same thing.  It appears like I’ll be making a big push early on in the year for that “elite” status on Air Canada 🙂