I have to develop a system where a customer can query information and waits until he gets a result back. I will do this using a publish and wait.
The problem is: WHAT IF the customer gets tired of waiting and disconnects!
So my question is: does this means that the system is stuck in a WAIT state (message can not be delivered)? Does the system automatically clean up the WAIT state and the response (that can’t be delivered)?
I hope someone knows the answer
As far as I understand, requested service publishes the response and doesn’t care if it will be delivered or not. It depends on some other factors like document’s storage type or TTL. Even if Broker is unavailable, the Integration Server should enqueue a document in outbound client store and allow its services further processing.
So, there is no such thing as WAIT state that you have to take care about.
You can specify a wait time in milliseconds… if the reply does not come in that time, process would timeout and return an error.
But that’s on the client side only. Moreover, if you timeout you don’t get an error. You successfully move to another step with the null instead of expected response document.
Thanx for the quick response!
Maybe a bit more explanation is needed:
A Customer calls to an IVR System (Interactive Voice Response System), this system posts a request for information to the EAI System, the customer has to stay on the phone to hear his returned information.
So, you use a publish and wait to wait for the requested information to get back and to pass it on to the customer.
Now, what happens if the customer hangs up the phone, before the information reached him, maybe because he got tired of waiting or if he hangs up immediately after he does the request?
Does the request for information stop?
Does the returned information get lost (and causes a memory leak)?
Or is there some sort of fail safe that cleans up these “floating” messages and stops the handling of these “transactions”.
Interested in hearing your thoughts
Once request is sent, it is going to be processed. The server is not aware that client might be gone. When it sends the response document it is enqueued in Subscriber’s queue, even if subscriber is presently unavailable. If you define some TTL of your document it will be removed from the queue after specified time (you may call it timeout).
However, as far as I understand your architecture, you will have really only one client in pub/sub communication - your IVR (or its Adapter). So, the IVR will always get a response and it is its responsibility to pass it to proper customer or discard it if customer has already hang up.
I hope this help you a little bit
Thank you very very much for your answer!!! It was very helpful and I think you got it spot on.
We did develop a similar solution using webMethods Enterprise 4.6 for a TELCo, where their customers used to call to find out their billing information.
We used client groups with destroy and disconnect status. In that case, when the EAI returns the information and if the customer has disconnected the phone, the IVR Client Process used to disconnect, so the queue was destroyed, and the returned query was not saved (we used volatile documents).
Thanx for your answer. It seems that we are doing exactly the same project as you did!
I’m going to check your solution asap. If I have any questions can I contact you?
Thanx a million
We had developed it between ADC Singl.eView Convergent Billing and an IVR. Do let me know if I can help you in anyway.