cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1393
Views
0
Helpful
4
Replies

UCCX scripting session question... for vm in queue

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.

Capture.PNG

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?

1 Accepted Solution

Accepted Solutions

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.

View solution in original post

4 Replies 4

Jonathan Schulenberg
Hall of Fame
Hall of Fame

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.

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.

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?

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.