July 2012 - Posts

While browsing for the answer to the question: “How do I add SOAP-headers to a message sent using the WCF-custom or WCF-basicHttp adapter?” I never really found a good, short answer. So I thought I’d give it a go.

Setting SOAP headers

I assume you know what SOAP-headers are and why you might use them. If not, then back to basics.

In my case the client needed BizTalk to send request with the WS-addressing SOAP header called “To”. I needed to know the easiest way to do this and preferably using configuration and no orchestrations.

To the best of my knowledge, this is the simplest way to do it.

Using a pipeline

Use a pipeline component to promote this property: http://schemas.microsoft.com/BizTalk/2006/01/Adapters/WCF-properties#OutboundCustomHeaders.

My guess is that you local BizTalk-code hub already have a pipeline component to promote arbitrary values. If you do not, the code for promoting the property is here.

The only thing to remember is that the value of the property is a bit special. You can hard code the values of your headers, even using xml-formatting; no problem, but you have to surround the value with a <headers> tag.

<h:To xmlns:h="http://www.w3.org/2005/08/addressing">rcvAddr</h:To>

This will result in the WCF adapter serializing a SOAP envelope with SOAP headers that contains the value you give between the <headers> tag.

Here is the result in my environment:


Using an orchestration

This is a bit more work, but a very useful way to get the same result of you already have an orchestration. A bit more information can be found here.

What you basically do is setting the property from an assignment shape, much like you would access a FILE.RecieveFileName.

outboundMessageInstance(WCF.OutboundCustomHeaders) =
"<headers><add:To xmlns:add="http://www.w3.org/2005/08/addressing">rcvAddr</h:To></headers>"

There are a lot of things I do not know about BizTalk. The list is getting shorter but here is something I found.

I was trying to verify a flow within a known environment. Everything else seemed to work apart from this one flow. A technician submitted files to a directory and the file was picked up. However it did not show up on any tracking; neither the basic BizTalk tracking nor our BAM-implementation noticed the file.

The files was picked up and I verified that the file was picked up by BizTalk. I could not submit the file myself as I did not have access to the path.

After a while I remembered to check to log on the other BizTalk node in the cluster and then it became clear. A simple warning said: “The FILE receive adapter deleted the empty file "\\Server\Share\testfile.txt" without performing any processing.” I have to admit that I did not know that. It is actually a “know issue

What happens is that the file is picked up but as the technician just submitted files using the old Right-click + New the file is empty. BizTalk does not process empty streams as it were and the file is deleted without any trace in the tracking.

Here’s a tip

In some scenarios you might receive an empty file to start a flow within BizTalk. Perhaps some system is telling BizTalk “That data you’re so interested in is done”. Make sure that file contains some data. Perhaps just a repeat of the file name or the letter “M”.

This presentation is not present at Channel9 at the moment. That is a shame because this was, in my opinion, the best presentation of the whole conference.

The session was presented by Alex Jauch, currently at NetApp but he used to work for Microsoft. Actually he was behind the precursor that became the MCA. I had never even heard about this guy before and I would say that it is a shame. I have now though.

The heading for the session seem ominous and deterministic but given my personal experience I would say that it is not far from the truth to simply assume that “cloudification” will fail. Incidentally it is also the title of Alex’ book :-)

Alex (or should I say Mr. Jauch?) started the session by clearly stating that he was about to say things that not all of us would agree upon. He would also try to upset some people! Bold and funny in my opinion.


The, or even a, definition for what cloud computing really is, can be hard to come by and one definition might differ a lot from the next. Alex presented the definition made by NIST. He pointed to the fact that NIST is a governmental agency and these are notorious for not agreeing on anything. The fact that they have agreed on a definition for cloud computing gives some credibility to it.

According to them there are five essential characteristics that together form a cloud. If any of these are left out, you are not a true cloud provider. They are:

On-demand self-service. A consumer should be able to change provisioning in the cloud by him/herself.

Broad network access. Capabilities are available over the network and accessed through standard mechanisms.

Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model.

Rapid elasticity. Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand.

Measured service. Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.

So if your cloud does not have a portal for adding resources in a way that the consumer can do it, you do not have a cloud service.

The full definition (2 pages) can be found here.

So why do we fail?

I say that it comes down to this comparative table

Traditional IT Customer Centric IT (Cloud)
Sets IT standards Supports business requirements
Focus on operations excellence Focus on customer satisfaction
Engineering is key skillset Consulting is key skillset
Sets policy Seek input
Focus on large projects Focus on smaller projects
Organized by technology Organized by customer
Technology focus Business value focus
Delivers most projects in house Brokers external vendors as needed

It is not around technology we fail. It is in how we use it and the attitudes in those that implement the technology. When trying to run a cloud service as “we always have”, in a traditional manner that is when we fail.

In order to run a successful a successful cloud shop, we must change focus and really (am he means really) focus on the customer. A very telling quote from the session was around the focus on operations vs. focus on customer.

“’We had a 100% uptime last month’ What does that mean if the customer still has not manage to sell anything?”

So if someone is telling you: "We sell cloud”, at least ask them about the 5 points from the NIST definition.

If you (or your organization) is thinking about deliver cloud capacity: Good luck.

Be being recognized by others you gain confidence. Also to some of us it simply feels good :-)

Steef-Jan Wiggers (MVP, author, BizTalker, Dutchman and avid tweeter) runs a “Meet the community” series on his blog. I am the subject of that last installment.

Full title: “Achieving Enterprise Integration Patterns with Windows Azure Service Bus”. Or another way to put it: ”What will happen to BizTalk when it gets cloudy”.

Well I would say, after the session, that BizTalk had very little o do with this. If you are a BizTalk developer you probably saw how things you do every day can be done in the Service Bus. Basically Clemens showed some of the most common patterns and how they are implemented in the Service bus. For instance splitter/aggregator, content based routing and recipient list.

There were some news that he told us.


This is a very small, binary and lightweight protocol for queues that will be supported in the next version of the Service Bus (coming End Of Year).

SharePoint and Workflows

The next version of Sharepoint will stand on top of WF that in turn will stand on top of queues in the Service Bus. WF will store it’s state using sessions in the queues. I also think that “will” can be replaced by “is possible to”.

A real product

For some of us who have been around to see MS try to launch integration products like Windows Server AppFabric (Dublin) for instance. I have to say that this time it feel like MS think this is a real product. They have some customers using it today and Clemens show a couple of them. So I get a feeling that this is for real. I did not get that from Windows Server AppFabric. (A good product though).

Side note: To all who have not yet read the integration bible: Patterns of Enterprise Application Architecture, Clemens recommends it too.

Why the Azure Service Bus?

In short, Microsoft sees a future where you have to be able to process large quantities of messages (small) and that the flow of these messages might vary over time. Not only during the month but also the flow might start small but increase heavily during a short time. Examples of this might be smart meter readers for household electricity that collet readings but also receives messages from the suppler.

In scenarios like this, it is much smarter to by capacity on demand; Cloud and the Service Bus makes these scenarios possible.

Another example might be something that Clemens built; a smart thermostat for AC-units. He has even written an article in the current issue of MSDN magazine about it.

Ok, so new stuff

Right now the maximum size of a message is 256 kb (including headers). There might be an increase to this size but it will “almost certainly guaranteed” not go over 1 mb.

In the end of year (might be December the 62nd) there will be a new release that will contain part of that which is called project Iguazo, which is basically a message distribution system in which you can build trees of subscriptions. Divisions and sub-divisions and further sub-divisions make up the branches that at the end of the branch is a device. This makes for a very easy distribution to individual devices but also entire countries of devices just by smart addressing.

Some tips at the end then

NHTTP is one of Clemens little side projects and it is basically the use of the headers in http to send data in a key-value fashion. The N stands for NoHyperText and to use it you can simply prefix your properties with a P- and the access them from your code by accessing the HTTP headers directly. More info here.

When you configure queues and topics, use an auditing queue that gets a copy of all messages sent to the bus.