PipelineTesting vs TestablePipeline

by | Jan 6, 2009 | BizTalk Community Blogs via Syndication

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

by | Jan 6, 2009 | BizTalk Community Blogs via Syndication

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

by | Jan 6, 2009 | BizTalk Community Blogs via Syndication

 

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 🙂