Delivery Notifications outside Orchestrations – a pure Messaging approach

Scenario
You have a pure messaging solution (no orchestrations) and you wan’t to be able to keep track of messages delivered to their destination by send ports and adapters for internal logging purposes. That is, you want delivery notifications, or acknowledgements, that a message has been successfully delivered to it’s configured location by your send port adapter.

Background
Kevin B Smith (old Microsoft blog here) explains the concepts and functionality of Acknowledgements (ACK) and Negative Acknowledgements (NACK) in this post and Stephen W Thomas has a sample based on that explanation for download here. But both of those deals mainly with doing this from an orchestration. But how do you enable delivery notifications with messaging only and how do you handle the acknowledgement (or for that matter negative acknowledgements) returned?

Solution
It’s really quite simple. Kevin talks about how the system context property AckRequired is set to true. That’s what need to happen, for example in a custom pipeline component.

// Abbreviated version of a Custom Pipeline Components Excute method 

public IBaseMessage Execute(IPipelineContext pContext, IBaseMessage pInMsg)

{

    pInMsg.Context.Promote(“AckRequired”,

        “http://schemas.microsoft.com/BizTalk/2003/system-properties”

        true);

}

This will cause BizTalk to generate ACK and NACK messages when the adapter reports a message as succesfully delivered (or in the case of a NACK, when the adapter has failed and a message will be suspended). These messages are special and will only be published to the MsgBox if there is someone subscribing to them.

So you need a port, in the screenshot below a direct bound receive port in an orchestration, that filter on acknowledgement messages (in this case on BTS.AckType == “ACK”)

and something that you can use to correlate back to the message that was sent message. Me, in my internal logging solution, use a combination of BTS.InterchangeID and BTS.AckSendPortID. It might not work in all scenarios, but it does where I am using it. There are other properties you can use like BTS.AckID (that maps back to the original messages MessageID) or BTS.ReceivePortName (that maps back to the original receive port). To see a complete list of Message Context Properties available for ACK and NACK messages follow this link.

Limitations and possibilties
In this scenario receive ports are One-Way, and the goal is to keep track of the delivery of messages received by BizTalk to their subscribers internally within the BizTalk solution. There is however nothing that stops you from having a send port that filters on, for example, BTS.AckReceivePortName to route acknowledgements back to the original sender, in a pure messaging way, instead of an orchestration. And since BizTalk is publish-subscribe based, you can do this at the same time that you take the orchestration approach, if you so wish.

If there is a demand, I’ll package a sample, but the meat of the solution is above – the rest is just plumbing.