07-15-2013 09:20 AM - edited 03-14-2019 12:04 PM
we are sending a vm message into queue in order that the vm may be routed to the next available agent. the problem that we are having is when the second vm is left in the queue, it is overwriting the first vm recorded. I believe this has to do with the session that is active and the second call taking over the same session number. What i need to do is force a new session on the second call.....I thought that this step would do it: but it doesnt.
it appears this step is grabbing the session that has remained active since that VM is still in queue. this whole process works famously for one call/vm at at time, it is only the second call that seems to not cooperate. any tips?
Solved! Go to Solution.
07-28-2013 09:16 PM
Great analogy of the Session and virtual folder Jon. I'll also add that you don't need Sessions to make the "call back with a recorded message" feature work. The script which the caller called in to stays active after they've disconnected, and therefore the Document which holds the recording stays in memory. You don't need to store it in a Session, Write Document, Upload Document, none of that.
In fact, since OP brought up Sessions and mappings, it's likely that this is the cause of the problem. The mapping ID might be a common value for all callers, and they could be overwritting, or referencing the incorrect Session to pull the recording value out of it. Removing the Session feature from the callback solution all together might be the best choice.
Anthony Holloway
Please use the star ratings to help drive great content to the top of searches.
07-27-2013 09:07 PM
The session itself is not the storage location for your recording. The audio is stored to a Document-type variable which you must be storing into a session. Think of the session as a virtual folder. If you save the same filename [variable name] to the same folder it will overwrite the existing data. All the mapping ID does is create an alias that you can use to find that session again later.
Every message-in-queue script I have encountered uses a unique session per-waiting message. You need to rethink your script logic.
Please remember to rate helpful responses and identify helpful or correct answers.
07-28-2013 09:16 PM
Great analogy of the Session and virtual folder Jon. I'll also add that you don't need Sessions to make the "call back with a recorded message" feature work. The script which the caller called in to stays active after they've disconnected, and therefore the Document which holds the recording stays in memory. You don't need to store it in a Session, Write Document, Upload Document, none of that.
In fact, since OP brought up Sessions and mappings, it's likely that this is the cause of the problem. The mapping ID might be a common value for all callers, and they could be overwritting, or referencing the incorrect Session to pull the recording value out of it. Removing the Session feature from the callback solution all together might be the best choice.
Anthony Holloway
Please use the star ratings to help drive great content to the top of searches.
08-21-2013 08:18 AM
hello experts. same script different problem! im hitting the maximum 1000 steps. my questions is have you increased that and what have you seen in the past? Im being told that we dont want to increase it past that, but i'm sure i;ve seen this 10,000 in the past. what do you think?
08-21-2013 05:52 PM
My thought is: if I need to change it, then I'll change it, with justification, and responsibility if things go wrong because of it. With great power, comes great responsibility.
Anthony Holloway
Please use the star ratings to help drive great content to the top of searches.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide