Hi Team

Do we have an established pattern ( for medium to high throughput scenario) , for queuing up requests to BizTalk ( when BizTalk is down) , without having to re-fire the same requests when BizTalk comes up.

Thanks

Amit

The patter is a queue and you have to use a queue for this. In case of BizTalk services exposed as web services, there would not be any pattern available.

Regards.

As Shankycheil mentions, a queue is most likely the best route for such a requirement.

Of course, a file share, ftp server or similar can also serve as an intermediate storage of messages between the sending system and BizTalk, enabling a form of dequeue when BizTalk is back up.

For any fully synchronous messaging such as web services, there is no valid solution for the receiving system being down and still having an automated queuing of messages unless the sending system can handle this. (By synchronous I mean not sync ws vs async ws, but rather that the communication is made directly between two systems with ack/nacks being sent).

Assuming the Requests are essentially One-Way, you can receive the requests by a custom IIS app/page that writes the incoming messages to MSMQ.

BizTalk will read from the queue so for instances where BizTalk is taken offline, the messages will remain in the queue.

It is MSMQ with old MSMQ adapter. And it is available if receive location is exposed as a web-service with WCF adapter. For this case you can use Msmq binding which works with MSMQ queues. I've implemented it once. It works fine.

As Markus mentioned it works only for a one-way MEX. If you want to implement two-way conversation, you can use one queue for inbound and the second independent queue for outbound, and it is not easy to implement it.