Craig -

Aha. Ok, at least we clarified that your not explicitly accumulating in the
Orchestration. Here is what I think is going on relative to the subscription
on the correlated receive port.

The Subscription is currently such that the Orchestration is subscribing to
all messages from the Q's receive port. So the Rcv Location processes all of
the Q items an publishes them to the MsgBox. The Orchestration is subscribed
to all of the Msgs from this Rcv Location so the Orch gets all of the Msgs
even tho it can only process 1 at a time.

So, I now see that it is an interesting subscription problem. I haven't had
this exact problem before, but my approach would be to try to throttle
receives in the Rcv Location. So I think I might try to turn on and off the
receive process so the orchestration can allow the Q to maintain the
Accumulation.

I will think about this more to find the precise answer, but my approach
would be to keep the Orch as is, and throttle in the Rcv side.

More to come.

Kevin
--
Kevin Farley - Technical Principal
Internosis, Inc. www.internosis.com


"Craig Vermeer" wrote:

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

[ Post a follow-up to this message ]