12-15-04 02:27 AM
It depends on what do you call "processing" and "backend"
If three machines with BizTalk (1 db+sso, 2 bts) are your backend, then you
need an extra machine in front, in a case your backend (BTS) is down,
If these three machines are middle layer (as I would normally assume), then
it will be your "buffer" for backend downtime. In this case, BizTalk will
receive it (either through MSMQ or any other transport, you'd like),
process, send it to the backend system, and then outging transport will
employ retry logic in a case backend is down.
Using MSMQT on the connections facing backend is benefitial in this case,
because you automatically get about 1 month of retries in a case your
backend system is down -- clearly quite a bit more than you really neeed.
But most other transports may be also configured to try it again and again
for certain time using a generic BizTalk functionality.
Using MSMQT on incoming connection from the external world will give you
queuing capabilities if BTS system is down. In this case, you MSMQ-based
clients will just put the message in their local queues, and MSMQ will take
care of delivering when BTS system is up. Note that in this case messages
will accumulate in the external world -- on originating machines, that may
be not good enough if they are not always online.
In any case, you don't need basic MSMQ on BizTalk machines.
Also, notice that you can use upcoming MSMQ/C adapter for BizTalk. It has
somewhat restircted functionality compared to MSMQ/T (e.g. in-order
delivery), but it is based on standard MSMQ transport in Windows. In some
cases it may be more interesting solution than MSMQ/T.
Regards,
Eldar
http://weblogs.asp.net/eldarm/
This posting is provided "AS IS" with no warranties, and confers no rights.
EBusiness Server Team
--------------------[vbcol=seagreen]
we[vbcol=seagreen]
to[vbcol=seagreen]
require the[vbcol=seagreen]
the[vbcol=seagreen]
[ Post a follow-up to this message ]
|