I’m experiencing a mental block trying to set up the following scenario: A document is delivered from an external system to my IS by HTTP post. I want to publish this document locally, indicate in the HTTP response that it was received and provide a reference or tracking number in the response body. A subscribing service delivers the document by FTP to a legacy system. I don’t want to block until that system is done with it. But when it is done, I want to close the loop by publishing a reply that includes more data. I tried to do this with asynchronous publish-and-wait, returning the ‘tag’ number in the response and waiting for the reply document when all processing is complete. But although the process is ‘asynchronous’ the HTTP response is not truly issued until the top level service completes, and this doesn’t happen until waitForReply completes or the timeout is reached.
I have a nagging feeling I’m going about this in completely the wrong way. Would it help if I invoked waitForReply in a separate thread? Should I be using publish, rather than publish-and-wait? Should I finally force myself to learn Modeler and set up a business process model instead? Suggestions welcome. Thanks,
I did get this working by writing a wrapper service that calls waitForReply with the tag number and timeout interval as inputs. I then call this service in a new thread, which allows the top level service to complete and the HTTP response to be set. It works, but it has a kludg-y feel, and I think it’s going to require a lot of extra error handling. I’d still be interested in hearing if anybody else is doing anything similar or has any “better” practices for this scenario. Thanks,
Tim,
I’ve gone through this several times. I will say first there is no one answer, at least in my opinion for what that’s worth. To me there are two kinds of asynch processing in my mind: 1) Asynch in which you dump off a message to the IS/Broker and then disconnect 2) Asynch in which you dump off a message and spawn a background thread to keep the connection open and wait for a response. Kind of the way AJAX works. It’s really only asynch in that it lets the user keep working in the browser doing whatever while also waiting for a response. But you are really still blocking even though it is under the covers, the connection is still open.
I prefer Method 1 when I can get away with it, it’s the most scalable, reliable and the least problematic. You can send the user back an email later with the confirmation number or whatever.
That however doesn’t always meet requirements when they need to continue doing something after the reply and with the reply data. If the reply is relative short in wait time then request/reply is perfectly acceptable, really no need to spawn a background thread unless the client needs to do other processing while waiting. If it is long running then Method 1 is better.
Another option that you already mentioned is the Process Modeler. I done some stuff where I posted the message into the IS server with a correlation ID. This started the process which did some work (asynch, the client is long gone) and then responded back to the client with the results along with the correlation id. They then used that to do some work and then respond back to the process which fired up based upon the correlation id and did some more processing. This is much more complex and should be used for more complex long running processes in my opinion.
If all the client needs is a confirm. number I would lean towards method 1. Low complexity, very reliable. The problem with background threads on the IS server side is that if they time out or get stranded, they don’t go away until a restart.