Accepted Solutions
I didn't try running your script, however this is what I think is causing your issue:
Let me know if this helps. If not, I'll run it through a reactive debug and see what's missing.
-Sean
The original poster's problem was that they were dealing with two different Triggering Contacts' Sessions, and was storing data in one, while reading from the other; that's not going to work.
So, yes, you were right in your assumption that a Call Redirect might have been more appropriate. Not only from a Session handling perspective, but from a call flow perspective. But, what do I know, maybe he actually meant to use the Place Call step.
There were a few mistakes on your part, and I wasn't going to correct them, since the OP already marked your reply as the solution; however, it looks like there is some misinformation going around about how to work with Sessions.
Take this YouTube video for example, which looks similar to your Rev2 script solution:
https://www.youtube.com/watch?v=9HXivETA8bE
There's a few things wrong here, and I'd like to address them.
1) UCCX automatically creates a new session for every call, and so, you don't have to. Not only do you not need to, you really shouldn't, because you're now causing UCCX to create two sessions for every call.
Using Real Time Reporting (RTR), we can see what a Session looks like for a call, where UCCX creates it automatically:
2) If you were actually in need of a separate and new session from the one automatically created for you, like say if you were wanting to hold some cached data for all Contacts to use, then you would use the Get Session step, and provide it with a mapping ID.
Notice how my completely arbitrary mapping name of "banana" shows up as the Mapping ID in RTR.
The reason for the mapping ID in the first place is because, like I said before, UCCX will create a new Session for every call. So, a caller who just called back, would likely have a previous session existing already, and we'd need a way to retrieve that existing session. The way we do that is by using the Session Mapping, which we might map to, let's say the caller's phone number, or perhaps we asked them for their account number, we could use that instead.
Note that if you assign the same mapping to two different Sessions, the last session to get the mapping will steal it from the previous, leaving the previous session with no mapping at all, and no way* to retrieve it. Therefore, be careful what you use for mappings.
Also note that you can assign more than one Mapping to a Session, so you'll have the possibility of recalling it in multiple ways. This isn't really necessary, but it's interesting to know nonetheless.
What you don't want to do, is use the Session object as the Mapping ID like you did, because at the time of Session creation, the value of the Session object is null, and now your Session is known as nothing.
Notice how the Mapping ID is blank. You might not think that's all that bad. But consider this: If you took in a second call, while that first Session was still active/idle, then when you create the new Session again, with null as your Mapping ID, the second call will overwrite the first call's Session data.
This actually saved you in your test. See, in your first script, you created a new Session with null mapping, and then in your second script you did it again, but unknowingly using null as the mapping, causing it to retrieve the original Session. This is one reason why you should test some of your scripts under load, and not just with a single call.
3) Your use of the Set step, to set the sessionCustomerInfo to its own self, is unnecessary.
*I said there was no way to retrieve a session once you steal its mapping, but actually, if you understood everything I said so far, then you could retrieve it by using a null mapping.
I hope you find my reply helpful. Let me know if you have any questions.
