Hi Kevin,

That's exactly how I have it implemented (well, not exactly... I had a
one-way port with delivery acknowledgment going out of the Orchestration
instead of a request/response port, but that shouldn't affect the
behavior).  The behavior I'm seeing is not what you describe, though.  I
see all of the messages get routed to the Orchestration instance, as I
described previously.

Have you actually implemented this solution and gotten it to work as you
expect?  If so, did you have to set anything on the receive port into
the Orchestration or the Send port to the MSMQt queue?  The reason I'm
asking is that when Tomas replied to my initial post he seemed to be
saying that this is expected behavior for BizTalk.

Thanks,
Craig

Kevin Farley wrote:
> Craig -
>
> Here is how you do it:
>
> 1. Receive Message of Type X: Activate Orchestration
>
> 2. Begin Loop while boolMessage (set this as a Var Initialized to True)
>
> 3. Send Msg to Vendor
>
> 4. Rcv Response from Vendor
>
> 5. Listen shape (this is the key!)
>
> a. In 1 parallel stream: Receive Message of Type X (correlate on this)
>
> b. In the other parallel stream: Delay 60 mins (whatever time you want)
>
> c. In the Delay stream after the Delay shape put Expression
> "boolMessage=false;"
>
> 6. End loop
>
> 7. End Orchestration
>
> 8. I would put this is a Scope with Exception Handling
>
> That's it. Now your Orchestration lets MSMQT Accumulate and it just drains
> the Q 1 at a time throttled to have the vendor process only as fast as the
y
> can.
>
> Try it and tell me how it works out.

[ Post a follow-up to this message ]