Delivery Notification Scenarios with dynamic but configurable send ports

Recently we had to implement a content-based routing scenario with a couple of different send ports and the requirement to send a e-mail delivery notification after a successful delivery of another message. The delivery notification is actually not a problem if you can specify a later bound or dynamic port (you may have a look here http://kentweare.blogspot.com/2007/11/biztalk-delivery-notification.html). Here in our scenario, we could not use later bound ports (unless we won’t do enormous code duplication) and a dynamic port scenario would have lead to a configuration hell because you are not able to configure them from BizTalk admin console. Why we had insisted on the admin console? Well it provides us a nice and feature-complete user interface that can be used by operators without orchestration knowledge. So we needed a possibility to configure these ports from admin console and to get a message delivery notification.

There are now two possible approaches to reach the two goals. The first, and dirty one, utilizes role links and the destination party property to specificy which send port should be used to deliver the message. The magic of role links is described on http://blogs.msdn.com/richardbpi/archive/2006/03/08/546633.aspx or in the MSDN. The utilization of role links empowers us to use delivery notification as easy as on later bound ports and to configure the send ports in the admin UI. The drawbacks of this approach, it was not intended to use role links that way and you have to configure a lots of additional stuff, like parties and orchestration role link binding. Hence, its not realy easy to maintain and to explain to a third person.

The second apporach is straight forward. First we checked, which subscriptions are active when using delivery notification with later bound ports.

As you can see, an instance subscription is created based on a correlation token to report the ACK/NACK of the message delivery. This behavior can be implemented with the help of direct bound ports, too. The only thing is that you will have to implement the magic of delivery notification on your own.

1. So you need to set the BTS.AckRequired property of message you want to send to “true”. Also, you will have to specifiy a BTS.CorrelationToken, e.g. a new Guid.
2. Create two correlation sets. The first set  for BTS.AckRequired and the second for BTS.CorrelationToken. Initialize both on send shape.
3. Add two receive shapes after the send shape that will wait for messages of type System.Xml.XmlDocument (the first is a dummy that will receive a copy of the message sent and the second will receive the ACK/NACK). Both receive shapes have to follow BTS.CorrelationToken corellation set.
4. Check the BTS.AckType property of the ACK/NACK message received in the second receive shape. If it is equals to “ACK” the message could be delivered.

There is another nice, graphical, description about this procedure that can be found on http://agilior.pt/blogs/bruno.camara/archive/2008/04/17/4344.aspx.

With the second approach, we can use direct bound ports together with message delivery and admin console configurability.