Implementing end-to-end ordered delivery using Microsoft BizTalk Server and SQL Server Service Broker – New whitepaper on TechNet Wiki
I have co-authored a whitepaper on the TechNet Wiki based on a customer project. The paper “Implementing end-to-end ordered delivery using Microsoft BizTalk Server and SQL Server Service Broker” is available here: http://social.technet.microsoft.com/wiki/contents/articles/implementing-end-to-end-ordered-delivery-using-microsoft-biztalk-server-and-sql-server-service-broker.aspx.
Check it out on the TechNet Wiki!
Publishing this paper on the TechNet Wiki allows the co-authors to make changes as needed, and it allows them to subscribe to the page so they will be emailed when changes are made or comments are left.
Paper Synopsis
Park Nicollet Health Services uses Microsoft BizTalk Server as their middleware platform and has implemented a large number of HL7 interfaces. As with many healthcare applications, ordered delivery is essential for this middleware platform. When messages from a source system, e.g. Electronic Medical Record (EMR) system, are sent to BizTalk, these messages could be subscribed to by many downstream peripheral applications and systems. During system maintenance or unexpected downtime of these downstream systems, the source EMR system will continue sending messages to BizTalk. The source EMR system does not have the ability to queue messages and wait for subscribers to come back up again…the EMR system relies on the middleware platform (built on BizTalk Server) to take care of this queuing and ensure messages are delivered, in-order, when the downstream systems are back up.
If downstream systems are down for an extended period (for the weekend, for example), millions of messages could queue up in the MessageBox, resulting in significant growth in the size of the MessageBox database. When MessageBox overloading occurs, messages begin accumulating to such an extent that overall BizTalk performance can be impacted.
This paper presents an alternative queuing mechanism, using SQL Server Service Broker (SSB), to offload messages from the BizTalk MessageBox. When a downstream system is down, the messages will queue into an SSB queue. When the downstream system is back up, the messages will be sent to the downstream system, in order, until all messages are drained from the queue.
(No Ratings Yet)7 Comments
Leave a Reply
You must be logged in to post a comment.
Pingback: Dew Drop – February 3, 2011 | Alvin Ashcraft's Morning Dew
This is awesome. I was actually just debating how to handle these scenarios a few weeks ago and now I feel like i have a better guide and a great idea to try out myself.
I hope it helps you out!
Tim, I’m not able to locate this article in Technet. Please can you point me to an alternate location or get the article on Technet up.
Thanks!
Tim, I cant find the article either on Technet?
The article was removed from the TechNet wiki. The customer did not end up implementing the solution in production. During testing they found the stored procedures were not cleaning up the SSB conversations. After fixing that in the stored procedures, there was still a reliance on query notifications, which were found to be a bit unreliable. I.e. sometimes BizTalk would not get the notifications.
Tim, this is very interesting to me. I am in the same scenario of implementing end to end high performance order delivery. Can you please share this white paper we can see if we can improve this with out needing to reinvent the wheel. :)