BizTalk, Download, Messaging, Pipeline Components

Pure Messaging Acknowledgements – Follow up

This post is a follow up to my previous post Delivery Notifications outside Orchestrations – a pure Messaging approach. The sole reason for this is to provide a downloadable demo and a walkthrough of that. The demo features a solution with one pipeline component and one passthrough pipeline using the component. It also contains a bindings file to configure the ports needed. Like I said in my first post, there really isn’t much to it, but here it is…and this is how you get it running:

  1. Build Blogical.Shared.PipelineComponents.

  2. Copy Blogical.Shared.PipelineComponents.dll to <biztalk_install_dir>Pipeline Components and add it to the GAC.

  3. Build and Deploy Blogical.Shared.Pipelines. By default it deploys to the BizTalk Application AckRequired.

  4. Open the BizTalk Adminitration Console and import the AckRequired.Bindings.xml file in the solutions root folder. This will give you one receive port with one receive location

    and two send ports.

  5. Configure the FILE adapter settings on the ports.

  6. Drop a file for the AckRequired Receive Port.

  7. Notice the file that goes out through the send port and the ACK that goes out through the other send port.

  8. For more information read the original post and explore (what little there is) of the sample.

Adapters, BizTalk, Configuration, Messaging, Pipeline Components

Delivery Notifications outside Orchestrations – a pure Messaging approach

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.

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?

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)

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.