Hi Kevin,

Unfortunately, I don't think that #1 will work.  BizTalk caches its
configuration information, and only refreshes that configuration every
60 seconds by default.  So, I can't get that fine-grained control over
the Receive Locations from within the Orchestration.  I'd turn the
Recieve Port on, but may not start receiving messages for 60 seconds.
Likewise with turning the Receive Location off.

What I'm going to try first is the solution that I outlined earlier, to
change my correlation so that I can avoid too many messages accumulating
to a single Orchestration instance.  For example, correlating on
ReceiveDate rounded to the nearest minute/hour/five minute interval.  I
can tweak the correlation to try to find a manageable number of messages
per Orchestration instance.

I think my second option will be what Tomas described, and what I think
you described as option #2.  I'll let the messages accumulate in a queue
or database or something, and create an intermediary component that I
can use from within the Orchestration to pull the messages out one at a
time.

If you think of something better, feel free to let me know.  Thanks for
the help!

Craig




Kevin Farley wrote:[vbcol=seagreen]
> A bit more on this. The interesting issue is that the BizTalk MsgBox does 
not
> expect to have Messages received that have no Subscribers, and with your
> Orchestration intending to act as a Throttle, the result is non-optimal un
der
> load.
>
> So, the solution is to throttle prior to the Orchestration. I would not
> advocate creating another Accumulator, since you have a MSMQT already.
>
> I see two reasonable approaches:
>
> 1. Disable/Enable the Receive location programmatically in your
> Orchestration. In your Loop you could Disable the ReceiveLocation after th
e
> Correlated Receive and then Re-enable the ReceiveLocation prior to the Lis
ten
> Shape.
>
> The following URL provides guidance on programmatically Enabling Receive
> locations:
> http://msdn.microsoft.com/library/d...e_core_odws.asp
>
> You could conceivably throttle in a pipeline to slow down the rate of
> Interchanges to balance but you probably don't need to do this here.
>
> 2. You could make an Intermediary component to not "drain" the MSMQT at a
> rate higher than your solution could process, this has the effect of letti
ng
> the MSMQT be the true Accumulator and adding more business rules, controls
> and events to a process that can monitor Queue size, processing rate, Noti
fy
> parties if certain conditions occur.
>
> Both solutions address the issue of not taking in more Messages from your
> MSMQT at a rate higher than you want to process them which is your issue.
>
> It would be interesting to write solution 1 for you and as a general
> solution for re-use to demonstrate Throttling. I'll put it on my list but 
I
> have some other things I have to work on ahead of that.
>
> Hopefully this will work for you.
>
> Kevin
>
> "Kevin Farley" wrote:
> 

[ Post a follow-up to this message ]