Hi Kevin,

Thanks for the response.  What I think you've described in your
suggested solution is exactly what I tried to do with the current
Orchestration implementation, and failed.

I have all messages correlated by MessageType to a single instance of
the Orchestration through an MSMQt receive port.  What I had thought
would happen when I designed it this way was that the messages would be
routed to the MSMQt queue and be picked up by the Orchestration only
when it was ready to process them.  I thought that a message would stay
in the queue until the Orchestration was ready to process it.  However,
the behavior I saw was that all messages were routed _through_ the MSMQt
queue and associated with the Orchestration instance itself, thus the
extremely high MessageInstanceState count.

I think that my situation was simply caused by my not understanding the
way BizTalk is doing Pub-Sub.

So, how would I go about implementing the approach you described, where
the messages are left in the queue until the Orchestration is ready for
it?  One approach, I think, is to do what Thomas suggested : route the
messages to some external store, such as a database table, and have the
Orchestration manually pluck them out one at a time (though a Construct
Message shape and a .NET component, or something like that).  Is there
another that you can think of?

Thanks,
Craig




Kevin Farley wrote:[vbcol=seagreen]
> Craig -
>
> Allow me to think out loud here:
>
> 1. Your goal is to throttle messages to your vendor to both provide some
> type of sequence as well as rate of transaction in order to align with the
ir
> ability to process your load.
>
> 2. You are currently using an "Accumulator" pattern in an Orchestration an
d
> indeed you will suffer to persist/restore this "long-running process"
>
> I think you may want to apply the following pattern instead:
>
> 1. You already have the messages in a Queue. You have no need to Accumulat
e.
>
> 2. It appears that you are single threaded to your vendor so a single
> orchestration can run as you have it Correlating on MessageType but not
> Accumulating.
>
> 3. You can have an Orchestration Activate on a new Message of the Message
> Type, and then enter a Loop.
>
> a. The Loop will be to send the message to your vendor and wait for a
> response.
>
> b. Next in the Loop you wait a period of time for another message of the
> CorrelatedType. If you don't get one in the time frame, then you can end.
>
> c. If you do get one in the time frame you loop.
>
> d. If another message comes in later, a new orchestration is Activated.
>
> 4. This way, you have a Sequence and a Throttle, but no Accumulator.
>
> Does this sound right?
>
> Kevin Farley
>
> "Craig Vermeer" wrote:
> 

[ Post a follow-up to this message ]