10-10-2010 03:27 PM - edited 03-14-2019 06:39 AM
I suppose you see where I might be going with this.... it would allow for long lasting loops without taking up more than one step.
Also... what is the downside of raising the max number of steps limit? I find I need about 9000 steps as I am checking a session for updated info once a second.
Solved! Go to Solution.
10-13-2010 01:38 PM
Even with the Do step, you can still hit the max steps limit since you can't predict how long you'll have to wait. A better solution would to use
java.util.concurrent.locks.ReentrantLock and java.util.concurrent.locks.Condition to implement a signal and wait feature in your script.
the steps are:
1. Create an instance of ReentrantLock() object that'll be shared in the two areas of your script
2. Use the lock object from step 1 to create an instance of Condition object
3. in one part of your script, wait for a signal.
4. In the other part of your script, send a signal when the data is available.
A sample code might look like this:
//this lock and condition object is to be shared in the two areas of your application: Area 1, and Area 2.
java.util.concurrent.locks.ReentrantLock lock = new java.util.concurrent.locks.ReentrantLock();
java.util.concurrent.locks.Condition condition = lock.newCondition();
//Area 1:
//--------------------
try{
lock.lock();
condition.await();
}finally{
lock.unlock();
}
//The only way the executing thread will get here is after receiving a signal from area 2.
//the rest of your ivr steps follows here.
//-------------------------
//Area 2 code:
//--------------------------
try{
lock.lock();
condition.signal();
}finally{
lock.unlock();
}
//----------------------------------
you read about locks and condition here: http://download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/locks/Condition.html
10-11-2010 11:54 AM
Well, you can create session variables, and go ahead and increase your max steps, just understand why it's there in the first place. If Cisco really didn't want you changing it, why list it on the parameters page, or make it editable?
I'm curious, what's the big picture here?
10-11-2010 12:31 PM
I have two applications running at the same time both referencing the session. App A is waiting for an agent to answer a call in App B. App B pushes a boolean "AgentAnswered" value into the session once this has happened. So that there is little delay App A checks the session once per second. There is where a while-do would be nice.
The bigger picture is that caller leaves a recording/voicemail (App A) which in turn waits in queue (App B), and then is played back to the agent. I don't save the recording permanently so I can't reference it in App B.... hey I just thought: can a wav file be an attribute of a session?
10-12-2010 12:20 PM
The bigger picture is that caller leaves a recording/voicemail (App A) which in turn waits in queue (App B), and then is played back to the agent.
If you have ccx premium you can do this in one app with the place call under call contacts.
10-12-2010 01:05 PM
I am already doing that. My question goes to loop flow: better to have a do {} while statement rather than approximating such a function using the following:
delay 1 sec
check session for var x = y
if var x = y then
goto next thing outside this loop
else start over
If a Do step has this code then we don't really increment the number of steps. For example:
do { delay } while var x != y
That would be ideal.
10-13-2010 01:38 PM
Even with the Do step, you can still hit the max steps limit since you can't predict how long you'll have to wait. A better solution would to use
java.util.concurrent.locks.ReentrantLock and java.util.concurrent.locks.Condition to implement a signal and wait feature in your script.
the steps are:
1. Create an instance of ReentrantLock() object that'll be shared in the two areas of your script
2. Use the lock object from step 1 to create an instance of Condition object
3. in one part of your script, wait for a signal.
4. In the other part of your script, send a signal when the data is available.
A sample code might look like this:
//this lock and condition object is to be shared in the two areas of your application: Area 1, and Area 2.
java.util.concurrent.locks.ReentrantLock lock = new java.util.concurrent.locks.ReentrantLock();
java.util.concurrent.locks.Condition condition = lock.newCondition();
//Area 1:
//--------------------
try{
lock.lock();
condition.await();
}finally{
lock.unlock();
}
//The only way the executing thread will get here is after receiving a signal from area 2.
//the rest of your ivr steps follows here.
//-------------------------
//Area 2 code:
//--------------------------
try{
lock.lock();
condition.signal();
}finally{
lock.unlock();
}
//----------------------------------
you read about locks and condition here: http://download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/locks/Condition.html
10-13-2010 01:52 PM
Ah, this looks like it is getting closer to what I'm thinking of...
Would I be using a custom Java class for the locking you described, or can I create those objects inside a step in the Step editor?
10-13-2010 03:03 PM
You can embed it in the script since this is just a few lines of code.
If you're already using custom jar file, your script might look cleaner if all of your code are in one place so you can re-use. so in that case, a custom jar file might be a better option.
10-13-2010 03:47 PM
Does Anthony's page on custom Java still work for UCCX 7?
Forgive my ignorance, but what step/s would I use to embed the code? Any step where I can put an expression in place?
10-14-2010 06:47 AM
You can use a Set step to embed code inside curly braces. There's an example of this at the site you posted: http://www.avholloway.com/vtools/ipcc/custom-java/soap/you-need-some-soap.aef.png
10-13-2010 05:34 AM
That's not exactly the big picture. A big picture would have been, "I am trying to implement a call back feature, where callers leave a message for the Agent."
On the other hand, you can store the voice recording document in the session variable.
10-13-2010 10:46 AM
Fair enough.
It is more elegant to store the wav file in the session, I really don't like having to use the Place Call step to a second application. If the wav file is pushed to the session then I see no reason I couldn't use the Trigger Application step in asynchronous mode, hand the new app the session ID and then terminate the original application.
Incidentally and unrelated, do you know how to pass the triggering contact to an app that has been triggered using the Trigger Application step? Or is it not possible? I've read your very good points on using subflows vs. call redirects vs. triggered apps.... I think it preferable typically to use triggered apps (there are exceptions to this), but I am hung up on how to pass the original triggered contact into that new app.....
B
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