PipelineTesting: Pre-built Pipelines and Messages

PipelineTesting: Pre-built Pipelines and Messages

by | Jul 25, 2007 | BizTalk Community Blogs via Syndication

Here are some more syntax examples for the new library version:

3. Using pre-built pipelines:

If you have existing, already compiled, BizTalk pipelines, I currently have two options
for using them: 

ReceivePipelineWrapper pipeline = Pipelines.NewReceive(typeof(MyPipeline));

Or: 

ReceivePipelineWrapper pipeline = Pipelines.NewReceive<MyPipeline>();

4. Adding Document Specifications:

It’s also important to add any necessary document specifications (schemas) to the
pipeline before executing it so that disassembler and assembler components can find
them. This is now possible as well during construction: 

SendPipelineWrapper pipeline = Pipelines.NewReceive()
   .AddAssembler(new XmlAsmComp())
.WithSpec<MySchemaType>() .End();

One thing I’m not quite sure about here is with the standard XML pipelines and prebuilt
pipelines. For them, the current factory methods in the Pipelines class don’t
return a builder object (like the one returned by the empty NewReceive() and NewSend()
methods I introduced last
time), so if you want to add known document specifications to those, you still
need to use the old AddDocSpec() method in the ReceivePipelineWrapper and SendPipelineWrapper
classes. It’s not much more complexity, but the asymmetry makes me dislike it a bit.

So I’ll probably be changing the code so that all pipeline creation methods return
builder objects and not the actual pipeline objects. Any objections?

5. Executing Send Pipelines:

One annoying part of the current API is that when executing Send pipelines you need
to explicitly create a MessageCollection instance, add your input messages to it and
then call Execute() with it. Not too bad, but inconvenient if you only have one or
two messages (which is most of the time).

I thought about several possible syntaxes to simplify this, but in the end decided
to do the simplest fix: I added a new overload to SendPipelineWrapper.Execute() that
has a params array of IBaseMessage instances. So you can now do this: 

IBaseMessage output = pipeline.Execute(message1, message2);

Simple, but effective!

Slides and Demos for BizTalk R2 Advanced Concepts Presentation Available For Download

by | Jul 24, 2007 | BizTalk Community Blogs via Syndication

I have uploaded slides and demos I presented at Tech Ed if anyone is interested in taking a look at them. I presented this last month atin Orlando.

The demos show Dynamic Mapping, Self-Correlation Ports, Untyped Messages, and WCF Calls in Messaging. The WCF demos will require BizTalk Server R2. These demos are as is and mayneed someconfiguration changes to work on your system.

To view the power point slides, Office 07 is required.

The slides and demos can be found here.

I was to thank everyone who attended the presentation! I hope to be back next year.

BizTalk R2 Tech Ed Demos and Slides Now Available for Download

by | Jul 24, 2007 | Stephen's BizTalk and Integration Blog

I have placed the Demos and Slides I presented at Tech Ed online if anyone is interested in taking a look at them.  This was presented last month at Tech Ed 2007 in Orlando.

The demos show how to use Untyped Messages, Dynamic Mapping, Self-Correlation Ports, and WCF Calls in pure messaging.  The WCF demos require R2.  These demos are as-is and may not run on your system without some configuration changes. 

To view the power points, Office 07 is required.

The demos and slides can be found here.

Thanks to everyone who attended the presentation!

Reading text value from node using XPath function directly in BizTalk orchestrations

by | Jul 24, 2007 | BizTalk Community Blogs via Syndication

The XPath function that’s available directly inside BizTalk orchestration is a powerful little tool. However I’ve seen a couple of project where developers just grown tired of it and started creating their own little libraries instead. I’ll be the first to admit that the XPath function isn’t perfect, and it sure doesn’t work like most of the other XPath engines (which is the biggest problem) but it’s still inside the orchestration and you can use it to both read and assign values to a message which is super useful! Basically I don’t see a valid reason for bringing more complexity into your solution by adding another library – as long as you’re just going to read or set value using XPath.

However there is one trick that you should know of when it comes to reading a text value from a node. Basically you have to use both the string() and
text() XPath functions. Both Charles Young and Yossi Dahan has good post on this subject. Also if your new to writing XPath expressions for complex schemas with loads of namespaces and stuff (like schemas in BizTalk) this post could be useful for you.

Finally a nice tool for writing and testing small XPath expression inside Visual Studio (if you don’t want to spend x minutes waiting for XmlSpy to start up …) is XPathmania. Read about it here – I use it all the time!

Reading text value from node using XPath function directly in BizTalk orchestrations

by | Jul 24, 2007 | BizTalk Community Blogs via Syndication

The XPath function that’s available directly inside BizTalk orchestration is a powerful little tool. However I’ve seen a couple of project where developers just grown tired of it and started creating their own little libraries instead. I’ll be the first to admit that the XPath function isn’t perfect, and it sure doesn’t work like most of the other XPath engines […]

PipelineTesting: Creating Pipelines

PipelineTesting: Creating Pipelines

by | Jul 23, 2007 | BizTalk Community Blogs via Syndication

Here are some options I’m exploring for creating pipelines for testing.

1. Using default pipelines

To use standard pipelines right now you need to reference Microsoft.BizTalk.DefaultPipelines
and do something like this: 

using Microsoft.BizTalk.DefaultPipelines; //
... ReceivePipelineWrapper receivePipeline = PipelineFactory.CreateReceivePipeline(typeof(XMLReceive));

Not hard, but a bit inconvenient. Instead, I’m thinking of: 

ReceivePipelineWrapper pipeline = Pipelines.Xml.NewReceive();

2. Creating a pipeline from scratch

To create a pipeline from scratch in the current code you need create an empty pipeline
and add each component at the proper stage. Unfortunately, the API here is pretty
generic, and thus very verbose. Here’s what I’m thinking of: 

SendPipelineWrapper pipeline = Pipelines.NewSend()
   .AddAssembler(new XmlAsmComp())
.AddEncder(new MIME_SMIME_Encoder()) .End();

I’m also thinking about doing something to make it easier to use built-in assembler/disassembler
components with specific schemas, as this is pretty hard to do with the current version
without using a pre-compiled pipeline (because of how the properties in the components
are defined).

A Better Interface for PipelineTesting

A Better Interface for PipelineTesting

by | Jul 23, 2007 | BizTalk Community Blogs via Syndication

Last year I wrote the initial version of my PipelineTesting library,
a wrapper library that makes it possible to automate testing of BizTalk
Server 2006 pipelines and pipeline components. Since then, I’ve used the library successfully
on several projects and I’m extremely happy I spent the time creating it, as it has
made my life a lot easier when working with Pipelines.

However, the original API for the library was not the best. While not hard to use,
it was not completely intuitive and it was very verbose, for no good reason except
that it resembled (partially) the original API in the PipelineObjects library from
Microsoft.

Finally this bothered enough that I decided to do something about it and improve the
API with something better. My goals are:

  • Keep the original API compatible. In other words, you should still be able
    to use the original API if you so want (if only to keep compatibility for existing
    users).
  • Make it less verbose, but more readable.
  • Fix pain points in the current API.

The current API works, but it is somewhat painful in the following aspects:

  • Creating pipelines from scratch and using default pipelines
  • Executing Send pipelines (since you need to create collections even if you’re only
    going to use one input message)
  • Manipulating messages

I’ll be exploring some options to fix these issues in following posts, and I’d sure
appreciate any feedback!