| Kevin Farley 2006-03-03, 6:17 pm |
| 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 they
can.
Try it and tell me how it works out.
--
Kevin Farley
"Craig Vermeer" wrote:
> 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:
>
|