Re: Architecture for BizTalk Implementation
- From: "Kjell Wilhelmsen" <kjellw@xxxxxxxxx>
- Date: Mon, 4 Apr 2005 23:59:21 +0200
It's not possible to prioritize receive locations, so for a single BizTalk
host you cannot set any priorities this way.
What you could do is create a separate host for the real-time processing,
and one for the batch processing. The system I'm working on now are
configured this way, running on a two-processor server, and we're able to
process online transactions without any noticeable delay when performing
processor intensive batch-processing. I cannot guarantee that this will work
for you, but I think it will be worth a try. Of course, running the two
hosts on different physical servers would probably be even better.
Kjell
"Ryan G." <ryan.garner@xxxxxxxxx> wrote in message
news:1112631860.557608.201270@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Hello Everyone,
>
> I would like some architecture advice for a BizTalk implementation that
> may need modification for some new requirement.
>
> Here is the situation:
>
> Current:
>
> -Our business partner currently sends us requests to process at a rate
> of about 1 message every 10-20 seconds.
> -The application processes each message and sends it's response in
> approx 2.5 seconds per message.
> -All requests are real time, meaning a customer makes a request on our
> partners end, and our partner immediately places that request on a
> WebSphere MQ queue where our BizTalk application is listening.
>
> New Requirements:
>
> We have entered into new partnership with the same business partner
> that will leverage this current implementation and bring with it some
> new requirements.
>
> -Due to the business rules for this partnership, messages can not be
> sent real time. They must be batched up until customer payments clear.
> -This means messages will arrive in batch intervals 20 times a month
> and will include approx. 4000 messages per dump.
> ---This is 4000 messages over the course of approx. 1-3 seconds that
> will be placed on the Message Queue that our application is watching.
> -This dump can not adversely affect / slow down / crash our current
> real time partnership because in the real time scenario, our customers
> are waiting for the response in real time.
>
> Our partner has suggested we create an extra queue on MQ for the dumps
> and tweak our application to only process the dump messages when there
> are not messages on the real time queues. In short, the real time
> queues will always have priority over the dump queues.
>
> I have not heard much talk of priortizing Receive Locations and Send
> Ports, and this leads me to believe that there might be a more elegant
> design to consider than the proposed one mentioned above.
>
> How would you approach this?
>
> Thank you in advance,
> Ryan G.
>
.
- References:
- Architecture for BizTalk Implementation
- From: Ryan G.
- Architecture for BizTalk Implementation
- Prev by Date: Flat file schema creation
- Next by Date: Re: Re-Configuring Biztalk Server on a new box.
- Previous by thread: Re: Architecture for BizTalk Implementation
- Next by thread: Re: Architecture for BizTalk Implementation
- Index(es):
Relevant Pages
|
