Updating Existing Send Ports through Binding Files

When we make changes to our BizTalk environments, we always ensure that the changes are scripted so the Ops Team don’t really need worry about messing things up – as a result, we use Binding files everywhere. Normally, we do large scale solution deployments, but earlier this week we needed to update the subscription filter on a single Send Port; to my surprise, I was pleased to discover that Binding files can be used to update existing (unenlisted) Send Ports – no need to delete and re-create (via the binding file).

Consider the scenario above, we have a Send Port subscribing to messages where the Receive Port Name = ‘Sample Receive Port’:

Subscriptions After Update

To update the subscription using a bindings file, strip the Bindings file down to just the Send Port in question and update the <filters> element to include a new subscription (a filter on BTS.InboundTransportType has been added in this case, the operator of zero indicates that its an equals predicate):

Subscription Filter Xml Fragment

With the Send Port in the unenlisted state, import the updated bindings file either BizTalk Admin Console or BTSTask and the filter conditions on the Send Port will be updated:

Subscriptions After Update

Enlist and start the Send Port!

Note that any configuration property on a Send Port can be updated in this way.

Inaugural UK SOA/BPM User Group Meeting – Thursday 17th July 2008

My old colleague Mike Stephenson just e-mail me to help promote the inaugural UK SOA/BPM User Group Meeting, which will be taking place on Thursday 17th July 2008 at Microsoft’s London office.

The meeting will include a presentation on Oslo (Microsoft) and Enterprise Computing in 2015 (SunGard), plus the obligatory beer and pizza – full details can be found at the UK SOA and BPM User Group website.

If you’re in the London area, I’m sure it will be an excellent first meeting. Unfortunately, I can’t make it – I will be diving with seals off the coast of Northumberland – its a hard life!!

Clustering the ESSO Master Secret Server

I know I’m going to forget how to cluster the ESSO Master Secret Server, so I’m including a link to this technical article for Microsoft Host Integration Server 2004 which gives the most succinct version of the instructions to this non-trivial task I have found so far – see ‘5.4 Clustering the Master Secret Server’ in the document for the instructions.

Thanks to Tomas Restrepo for the pointer to the document.

Yet Another Non-Deterministic BizTalk Zombie Pattern

Victor Fehlberg’s article on Zombies has prompted me to blog about a similar problem I recently encountered with instances that have ‘completed without consuming all of their messages’ and propose yet another BizTalk Zombie Pattern.

The Technet article on Zombies in BizTalk 2006 details three types of Zombie messages:

  • Terminate control messages;
  • Parallel listen receives; and
  • Sequential convoys with non-deterministic endpoints.

Victor’s article deals with the common pattern that falls into the third category – a while loop surrounding a listen with one branch having a receive and the other having a delay shape, followed by a construct which sets a variable to indicate that the while loop should stop. This is non-deterministic since the delay could be triggered, but a message could still be delivered.

Non-Deterministic Orchestration - Creates ZombieBut I believe I’ve discovered yet another non-deterministic pattern that will always produce zombies; it doesn’t quite fit the pattern described above or on Technet, but it does use sequential convoys and in my opinion, is also non-deterministic.

The branching non-deterministic zombie pattern

Consider the orchestration in the image to the left, we have a sequential convoy (albeit without the while loop, but you get the idea) which can either branch and collect the next message in the convoy (down the ELSE branch) or terminate the orchestration (down the TERMINATE branch).

If a second message is received and correlated to this particular orchestration, but the workflow logic has determined that we will go down the TERMINATE branch, the second message will never be received by the orchestration, causing a zombie. Every. Single. Time. In my opinion, this is non-deterministic in the truest of senses: at the start of the orchestration you cannot determine whether the ELSE or TERMINATE branch will be traversed!

Is there a good reason for using this sort of pattern?

I’ve been trying to think why a sequential convoy would require this kind of branching functionality and I honestly can’t think of a good reason, unless the messages being delivered to the orchestration were controlled in some way. 

More to the point, I’m surprised that the XLANG/S compiler lets you even create an orchestration with the sort of potential damage that this pattern presents!

If you are using this kind of pattern, I’d be interested to know how (and why)?

And in case you’re wondering, a very similar pattern was noticed by our testing team who encountered missing messages on our UAT environment; on closer inspection of live, we had just over 10,500 suspended, zombie instances…. Ouch.

Debugging the problem took half a day and made me realise that we really do need a good tool to help search for subscriptions based on the context properties in a message, rather than the out-of-the-box Admin Console Subscription Viewer.

Sample project

If you’re interested in trying out the pattern for yourself, download the sample project and test messages.

Correctly Installing a Certificate for Two-Factor Authentication via the HTTP Send Adapter

I spent several hours last week banging my head against the proverbial brick wall while trying to identify the correct certificate store to be used for authentication by the HTTP Send Adapter – as the answer is a little obscure on the interweb, I’m posting the information here to help any weary BizTalk traveller in the future….

HTTP Transport Properties First, the obligatory background: The HTTP Send Adapter can use a public key certificate to identify itself as part of a two-factor authentication process when accessing a website (two-factor authentication ensures you are who you say you are by asking for information you know (i.e. username/password) and something you have (i.e. a RSA SecureID Token or a public key certificate)). The certificate it uses to perform this authentication is identified by the ‘SSL Client Certificate Thumbprint’ value of the Authentication tab on the adapter config dialog box, as shown to the left:

The adapter looks in the Personal Certificate Store of the user under which the BizTalk Windows Service is running, as detailed in the HTTP Send Adapter page on MSDN. Note that this is different to certificates used on the Send and Receive Ports and on Hosts, the settings for these can be found on MSDN at Certificate Stores that BizTalk Server 2006 Uses (which annoyingly doesn’t document the HTTP adapter).

More information on using two-factor authentication can be found at WindowsSecurity.com, however this article focuses on an end-to-end solution for securing a corporate web-site and is not very BizTalk specific; probably a good excuse to write a post on it in the future!