|
Home > Archive > BizTalk Server General > July 2004 > Biztalk bandwidtth throttling
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Biztalk bandwidtth throttling
|
|
|
| I'm currently evaluating Biztalk 2004 vis a vis 'traditional' polling
solutions for a retail environment. We have approximately 1000 stores each
with different bandwidth capabilities but all stores require to transmit
their sales data to HQ (i.e. a data file requires to be transferred from
every store to HQ so that the sales can then be loaded into a data warehouse
for centralised reporting)
If we used Biztalk in a low bamdwidth environment, is it possible using
Biztalk to perform file transfers using x% of the available bandwidth (i.e.
similar to P2P applications) so that Biztalk does not 'hog' the bandwidth
while the retail outlet is trading (credit card authorisations, emails &
other network activity happens on the same line.)
It is not possible for us to upgrade the bandwidth of 25% of our stores
because of geographic location. It is also a requirement that no other third
party tool performs the bandwidth throttling (Biztalk has to manage its own
bandwidth by itself)
There are other solutions on the market capable of this functionality but
(as a MCSD) I like the look of Biztalk's API and think it would be a
powerful tool for us but the bandwidth utilisation really would be a
show-stopper for us choosing it above another product such as Exellenet or
Axway as it would have the potential to stop one of our stores operating
correctly.
Hope someone can advise.
Thanks
Jon
| |
| Kartik Paramasivam 2004-07-09, 3:30 pm |
|
To solve your problem, you'll need to write an adapter to transmit message
to your backend.
Only your adapter will have knowledge of the available bandwidth to the
backend and how to share it.
Biztalk doesn't have any inbuilt mechanism to help you achieve this
functionality.
The logic will have to be built into your adapter.
Optionally you could even try moving some of this logic into the
orchestration schedule that is sending messages to the backend using your
adapter.. I am not sure if this option is applicable to you or not.
|
|
|
|
|