2008/9/16 Mick Knutson <[EMAIL PROTECTED]>: > 1 thought I had looking through the patterns is using an aggregator. Even > though there is only 1 message going out. > Then, I could passivate the AggregatorCollection. Then add a correclationId > to the outgoing message. Now I would expect the new message that was created > by the Python service to hav ethat correlationId.
Interesting thought; I guess you could use a WireTap to send a message to a timer endpoint and the service both with a common correlationID; then correlate the responses back together. The main difference though is you don't want to wait for both replies; if the timer comes back first you want to fire a failure message; if the other message comes back you might want to cancel the timer. > Note, the return message is not a respose. it is just a message that states > the change request was processed. I need this seperation because there is a > specific CR that can take 24 hours to complete. > > So then, when a new message is returned that has my correclationId, within > the alloted timeframe, we are complete, otherwise the aggreggator can have a > TTL then send a new message to the DLC. > > Does this sound correct? Sounds good. -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
