BizTalk, BizTalk Server 2013, Licensing

BizTalk Server 2013 Developer Edition arrives

Microsoft BizTalk Server 2013 Developer Edition New SKUs and Changes

Effective November 1, 2013, Microsoft BizTalk Server (BTS) 2013 Developer Edition licenses will be available under the Developer Tools license model in the Open, Select Plus and Worldwide Government Partner programs. Previously offered as a free download in prior BTS versions, the new BTS 2013 Developer Edition offers the full functionality of the
BTS 2013 Enterprise Edition, licensed for development and test use only, and includes the newly released Host Integration Server (HIS) 2013 software.


You will also find it if you run the Microsoft License Advisor at


The Developer Tools license model

Previously with BizTalk Server 2010 you have bought BizTalk Server Licenses for servers only (Branch, Standard and Enterprise). The Developer Edition was free. With 2013 you must purchase this license per user, if they do NOT have MSDN. This is a per user license.

You must acquire a license for each user you permit to access or use the software. You may install any number of copies on any number of devices for access and use by one user to design, develop, test and demonstrate programs. Only licensed users may access the software.


My interpretation of “access the software” (but I am not a license expert!) is that it is ok for BizTalk Server to exist in a test environment where it routes traffic and perform integrations to and from other systems that at their end have users, devs or admins that are not licensed. It is also ok for other users of the same server to access the server where BizTalk is installed to, for example, administer Windows (as long as that in itself is properly licensed). The limiting factor are the users that in some form access the BizTalk Server software itself. Such as deploy, configure, administer or in other ways interact with the BizTalk Server GUIs or services.

Price Lists

Target prices seems to be around $37 Estimated Retail Price (ERP).


I have also seen $36 for price level C.


To those with an MSDN subscription ( the list of subscription types that has access to this seems to be quite large:

VS Pro with MSDN (VL)
VS Pro with MSDN Premium (Empower)
VS Pro with MSDN Premium (MPN)
VS Test Pro with MSDN (Retail)
VS Test Pro with MSDN (VL)
VS Ultimate with MSDN (MPN)
VS Ultimate with MSDN (NFR FTE)
VS Ultimate with MSDN (Retail)
VS Ultimate with MSDN (VL)
BizSpark Admin
Designer AA
DreamSpark Premium
DreamSpark Standard
MSDN Platforms
VS Premium with MSDN (MPN)
VS Premium with MSDN (Retail)
VS Premium with MSDN (VL)
VS Pro with MSDN (Retail)

See screenshot:


How do I get it?

Summarizing from above you would either have an eligible MSDN subscription, or you get it through traditional volume licensing channels.


BizTalk, WCF

BizTalk Send Ports, WS-Addressing, ClientVia and non-http prefixed To headers, Part 2

In a previous post I explained how we had a need to use the WS-Addressing To header to send a non-http prefixed URI, such as urn:company/path/subpath/Service1, and how that was supported, after a fashion, out of the box in BizTalk Server. It did however come with the limitation of not being able to edit the WCF config in the BizTalk Server Administration Console GUI once you loaded it from a binding file. I don’t like limitations.

In this post I’ll show you how you can create a very simple WCF behavior to help you to set a RemoteAddress EndpointAddress Uri to be able to accomplish the same thing, while still being able to continue to edit the port configuration.

WCF behaviors allows you to intercept and inspect or alter messages or metadata, or in other ways modify the runtime behavior or processing of the same as they are sent or received. In this case we are creating a client behavior.

The behavior is in essence very very simple, it’s only purpose is to alter the endpoint address at runtime. The place where I choose to implement this is in the ApplyClientBehavior method of the IEndpointBehavior interface.

void IEndpointBehavior.ApplyClientBehavior(ServiceEndpoint serviceEndpoint, ClientRuntime behavior)
    serviceEndpoint.Address = new System.ServiceModel.EndpointAddress(this.Uri);

Incidently, I borrowed this implementation with pride from the ClientVia behavior that comes with the .NET Framework. Apart from the fact that that behaviors sets the ClientRuntime.Via property and this sets the ServiceEndpoint.Address property the implementation is very close to exactly the same.

This allows you to configure BizTalk in the following manner.

The “Address (URI)” property can be set to anything (as long as it is http or https prefixed), since it will later be overridden.


In the behaviors section we now have two behaviors, clientVia:


and the new one I created, which I called remoteAddress:


clientVia is configured as the actual URI of the service we need to call, while the remoteAddress behaviors is configured with the value we want to have in the To header.

The solution contain three files of interest.


The App.config file holds a snippet of configuration that needs to be placed in machine.config or in the BizTalk WCF-Custom WCF extension part of the Send Handler of the host that handles the WCF calls being made. It exists to make the behavior available to the BizTalk process and looks like this:

    <add name="remoteAddress" type="bLogical.BizTalk.WSAHelper.RemoteAddressElement, bLogical.BizTalk.WSAHelper, Version=, Culture=neutral, PublicKeyToken=3672865486d21857"/>

It points to the RemoteAddressElement class, whose responsibility it is to point out the type of the behavior and create new instances.

The RemoteAddressBehavior then in turn does the already above explained logic.

The project and code is available here.

I suppose a custom pipeline component setting the Address, or a Dynamic Send port for easier cases of configuration might also do the trick.

BizTalk, WCF

BizTalk Send Ports, WS-Addressing, ClientVia and non-http prefixed To headers

Through WS-Addressing services can require a certain value in the ws-addressing <wsa:to> SOAP header. WCF has full support for this. This support is inherited by the WCF-Adapters. When using WS-addressing in a BizTalk Server Send Port what you enter in the “Address (URI)” of the WCF adapters configuration will also be the value that ends up in the <to> header.

Like so:


This will produce the following. Other headers and body removed for clarity.

<s:Envelope xmlns:s="" xmlns:a="">
    <a:To s:mustUnderstand="1">http://localhost:8990/Service1</a:To>

If you need to have a different value in the <to> header than the actual address that the service is hosted at it becomes a little bit trickier. You need to use the WCF-Custom adapter and add the ClientVia behavior. The value configured as the “Address (URI)” will still end up as the value in the <to> header, but the actual URI that the call will be made to will be the value you configure in the ClientVia’s viaUri property.

Like so:

image image

This will produce the following (again cleaned for clarity):

<s:Envelope xmlns:s="" xmlns:a="">
    <a:To s:mustUnderstand="1">http://somedummyvalue/</a:To>

Now, as long as the value that you want in the <to> header is http or https (depending on the bindings security settings) then you are fine. However, if you end up needing to have a value in your <to> header that looks for example like this: urn:company/path/subpath/Service1, then you’re in trouble.

You will get an error dialog saying that The specified address is invalid. Invalid address scheme; expecting “http” scheme.


Why? Because BizTalk Server in its diligence to help you configure things correctly will force you to enter an URI that is prefixed with either http or https (again, depending on the security setting of the binding). There is no way for you to configure a non-http prefixed port in the adapter GUI (that I know of).

A colleague of mine, Gustav Granlund, experienced this issue and found a solution: you can coup it in through a binding file, and the runtime will accept it. Doing this you can enter a “Address (URI)” like so:


And you are then able to send a message that looks like this (to an address of http://localhost:8990/Service1):

<s:Envelope xmlns:s="" xmlns:a="">
    <a:To s:mustUnderstand="1">urn:company/path/subpath/Service1</a:To>

The caveat is that after having done this you cannot open and change WCF adapter settings in the port through the administration console GUI and keep the urn:company/path/subpath/service1 style URI. But, as mentioned, BizTalk will happily run with it. In a follow up post I examine another option.




Things to consider with WCF-SQL

Suppose you have a SQL Server database that contains information you need to poll from BizTalk Server. The database contains events that you need to process one by one, with the oldest events first, but without there being any real in-order delivery demands. One way to start polling these would be to have a stored procedure that looks like this:

declare @Id int

select top(1) @Id=Id from MyTable Where MyCondition = 23

update MyTable set Processed = 1 where Id = @Id

select Id, MyData from MyTable where Id = 1

The first thing to take note of is WCF-SQL Transaction Level and SQL Server locking.

Let’s do that before we even bring BizTalk into the picture.

What we can see from this is that while this procedure triggers…

One of the ways to reduce locks is to reduce transaction isolation level. This is especially important if this database is not used by BizTalk alone, but might be a very active OLTP database in itself; a backend data store to a multi-user application. The WCF-SQL adapter will default to the Serializable isolation level. You can read more about isolation levels here. In short this means that a Shared/Read lock will be placed on all data read, and an exclusive/write lock on all data changed. Another procedure can read the same data if it has a read lock on it, but cannot read the data that has a write lock on it. And another procedure cannot update any data that has a lock on it.

Azure, BizTalk, News, Presentation

BizTalk Server futures–Presentations from TechEd North America

I have already relayed this information to so many, and given the links to more, that I though I’d put them up here for easy access. There is much and more to be written about the content, but I’ll settle for this. Information has been available around BizTalk Server 2010 R2 for some time, but it got much more real and saw some things unveiled not previously mentioned or detailed. In short:

Application Integration Futures: The Road Map and What’s Next on Windows Azure: Video Slides

Building Integration Solutions Using Microsoft BizTalk On-Premises and on Windows Azure: Video Slides