We have a scenario in which we publish a request to the broker. A C client then picks up that request for processing. the request can take up to 3 hours to process. In our publishing service we want to wait for a reply. The problem is, we don’t want to set the timeout of the reply to 3 hours. We want the option to send a warning email every 5 minutes.
As I understand it, as soon as I call reply, the service will block for the specified timeout in the publishAndWait step. Once the timeout expires, the request is abandoned. My problem is, what happens if the C client receives the document, and the request service times out before the C client has time to process and reply? We don’t want the scenario of processing the same request twice.
Request/reply really isn’t intended for this sort of usage. Request/reply is a technique used to simulate synchronous communication over a pub/sub (async) infrastructure. What you’ve described seems more like a long-running process to be addressed using other techniques rather than request/reply.
There are a number of ways you could do this. One would be to use Modeler to model the process. The current “requester” would be changed to simply publish the event that kicks off the processing. Then it logically waits for a “done” event to be published by your “C client.” That is, it isn’t waiting in a publishAndWait step. It maintains state (if needed) of the work it has been handed out (using correlation and process instance IDs). You could have it send e-mails or do anything else while it waits for the result.
Have a look at the “Getting Started with webMethods Business Process Management 6.1. and 6.1.5” document. It can be downloaded from Advantage if you don’t already have it. The sections starting on pages 22 and 109 probably apply best to the scenario you described.
Paul,
You may have requirements that will not let you do this, but I would not block and wait within an IS service flow for 3 hours if I didn’t have too. I would consider making this an asynch call and allow the C client to respond back via a simple publish when it is done. You may need to split up your flow logic into multiple services to do this. Kind of an asynch callback pattern. You may even need some sort of correlation id if the transaction needs to be associated with something else. I think this would end up being more reliable than a very long running block and wait.
As far as the email goes, that sounds like monitoring to me. I would generally suggest monitoring outside of the system that is being monitored. Many ways to do that… simple shell script to look for a file status, or database flag etc. It can then send alerts based upon your rules. Then if the IS server fails or the C client, your monitoring and alerting will not.
Last thought is if you have the process modeler and workflow, it is kind of made for this kind of stuff.
If you still need to do what you originally ask for you could I guess, set the timeout high and then start a background java thread within the flow service(before the publish step) that would be in charge of sending an email every 5 minutes. You would have to name and keep track of the thread so you could stop it once the reply comes back.
Thanks for all the replies. We have decided to go with the following:
Our is service will call publishAndWait. As suggested above, we will have an external process (scheduled task) to monitor the queue that the “c client” reads from. We decided not to go with process models (tried this as a first solution) as the overhead associated seems to be way too great (0.8 seconds with model, 0.2 without).
Thanks again for all your help, I would be happy to answer questions if anyone has them.