Craig -

Whatever works for you is fine, but I find it architecturally abnormal to
have a Queue, drain the Queue into another Queue, and then play games to mak
e
Orchestrations work.

Playing devil's advocate, even with latency on the Rcv Location wouldn't
this still be better than the current situation of "unlimited" messages.
Also, you could put a pipeline component in that Receive to delay the
messages and perhaps even disable the receive location after it processed a
message.

(I'm just thinking out loud here...)

What if your Pipeline processed 1 message, Disabled the Recv Location and
then the Orchestration processed the message and Enabled the Rcv Location.
For latency, the Pipeline might sleep that interval....

I did recently review the fact that you could use the Suspended Message
feature of BizTalk 2006 in this case:

1. If you could correlate both on MessageType plus a SequenceID.

2. All new messages would Suspend in the MsgBox.

3. You "unsuspend" 1 message at a time in your loop.

In any case, whatever works for you, mainly I'm sharing the point of view
that you already have a Queue storing the messages, so I wouldn't tend to
re-queue them, this is purely a throttle condition....but it certainly is an
interesting balanced work-load issue that requires synchronization.

Another thought is to have the Pipeline check a Global reference to "Clear
to Send" from the Orchestration before processing the incoming msg. (or this
could really be an Adapter). The Orchestration could update a Global
Reference (a row in a table, a semaphore, etc) to "Do not send", then the
Adapter/Pipeline Sleeps until the "ReadyToSend" is back on.

I think I'm going to have to do an experiment here, but it will be a few
weeks because I have some other things on my plate first.
--
Kevin Farley

"Craig Vermeer" wrote:

> 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: 
>

[ Post a follow-up to this message ]