cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
950
Views
0
Helpful
6
Replies

Calls are not routed with Application Trigger step

ValeriKehayov
Level 1
Level 1

Dear All, 

 

We have CCX version 12.0.1.10000-24 and CUCM version 12.5.1.10000-22. 
What we are doing we have major application for different services and then we use trigger application step to open different AgentQueue application for all services. 

The problem is that if the call enters in the queue loop and all agents are "NOT READY" when someone became ready the agent status change to reserved and the call is never routed to the agent.

If the call enters the queue and there are ready agents the call is routed and answered without any issue.

 

If we are using session step and redirect the call, also the call is routed without any problem in both scenarios. 

 

It seems that the problem is related with Application Trigger Contact, Is there any bug related to the same matter?

You can check also a little sample from MIVR logs:

The exception is:

Exception=Resource Available Interruption: Rsrc Name:Test Agent ID:testagent IAQ Extn:3800, available on ESD: 69

 

40156: Jun 08 15:33:40.660 EEST %MIVR-APP_MGR-6-ABORTING_CONTACT: [MIVR_ENG_TASKS-31-33-TASK:0xa7a3582be_NewSupply-v16.aef] com.cisco.app.impl.ApplicationManagerImpl.TaskImpl Aborting contact: Application=NewSupply,Task id=45000000190,Contact id=26,Contact implementation id=26669/1,Contact Class=com.cisco.call.CallContact,Contact Type=Cisco JTAPI Call,Exception=Resource Available Interruption: Rsrc Name:Test Agent ID:testagent IAQ Extn:3800, available on ESD: 69
40157: Jun 08 15:33:40.660 EEST %MIVR-APP_MGR-6-EXCEPTION:Resource Available Interruption: Rsrc Name:Test Agent ID:testagent IAQ Extn:3800, available on ESD: 69
40158: Jun 08 15:33:40.660 EEST %MIVR-APP_MGR-6-EXCEPTION: at com.cisco.wf.subsystems.rmcm.Agent$2.run(Agent.java:11534)
40159: Jun 08 15:33:40.660 EEST %MIVR-APP_MGR-6-EXCEPTION: at com.cisco.executor.impl.ExecutorStubImpl$RequestImpl.runCommand(ExecutorStubImpl.java:690)
40160: Jun 08 15:33:40.661 EEST %MIVR-APP_MGR-6-EXCEPTION: at com.cisco.executor.impl.ExecutorStubImpl$RequestImpl.run(ExecutorStubImpl.java:486)
40161: Jun 08 15:33:40.661 EEST %MIVR-APP_MGR-6-EXCEPTION: at com.cisco.executor.impl.ExecutorStubImpl$RequestImpl.run(ExecutorStubImpl.java:762)
40162: Jun 08 15:33:40.661 EEST %MIVR-APP_MGR-6-EXCEPTION: at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:768)
40163: Jun 08 15:33:40.661 EEST %MIVR-APP_MGR-6-EXCEPTION: at com.cisco.executor.impl.PooledExecutorStubImpl$1$WorkerImpl.run(PooledExecutorStubImpl.java:99)
40164: Jun 08 15:33:40.661 EEST %MIVR-APP_MGR-6-EXCEPTION: at com.cisco.util.ThreadPoolFactory$ThreadImpl.run(ThreadPoolFactory.java:853)
40165: Jun 08 15:33:40.962 EEST %MIVR-REST_CLIENT-7-UNK: [SM Tomcat Poller Thread - 1] com.cisco.uccx.rest.client.SmRestClient SmRestClient().getCategoryWiseResponseFromSocialMiner :: QueryParam : {category=[version]}

 

 

Any suggestions would be much appreciated? 

1 Accepted Solution

Accepted Solutions

I can't open the main file because it's referencing a custom class. However, I do see you said the defects solve your issue, in that, it's just broken, and you need to reconfigure your solution.

I am curious if it works or not, so I'll still try it myself. Though, this isn't something I've ever done. The trigger app step for me only have value in its ability to be ran asynchronously, otherwise, I would call redirect to another trigger or call subflow to another script depending on the situation.

I can open the triggered script, and I don't see why, unless you remove some steps, you are getting the session and answering the contact. Neither of those steps seem to be necessary.

 

EDIT: After playing around with this a bit, I can already see a potential issue.  If you are not keeping the original script alive, where --Triggering Contact-- is referring to the caller, then the second script will lose it's Contact.  You see, even in Callback solutions, where two scripts share a reference to the --Triggering Contact--, the script which "creates" the Contact will "clean up" the Contact if the script ends.  Therefore, if you need the Contact to stay active and in use, so you can interact with it in another script like this, then you need to keep the original script active the entire time.  Which, if you think about it, is a waste of resources, holding two or more scripts in memory just to queue and answer a call.  Even with a subflow as a workaround this is doing the same thing.  It would be better to use Call Redirect, so you can free up resources as you pass the caller around the system.

 

Anyway, since I cannot see your full solution, I'm just guessing that this is the issue you're running into.  If you can remove the dependency on the external java class, I could then look at it closer.  I'll keep researching the solution on my end too; as I'm not quite done yet.

 

EDIT 2: Ok, so I've done some light testing on this and I have a hypothesis.  Similar to what I was saying about cleaning up resources when a script ends, I believe the originating application where the contact was created, is the only application which can be triggered by the interruptible nature of the Select Resource step.  The event seems to be missing the target trying to be executed, because it doesn't exist within the context of the originating App.

 

I've never done it this way before, so I learned something here.  Too bad the Trigger Application step isn't more robust, but that's how it is.

View solution in original post

6 Replies 6

Konstantin Vaksin
Cisco Employee
Cisco Employee
In the configuration of the CTI Ports, you have an option to configure CSS/Partitions.

Please make sure, they are configured correctly

Kostia

Thank you for the answer.
CTI port configuration is fine as the call is routed normally if the agent is in READY status. The problem is only when the agent is NO READY and when the status change to READY while the call is in the queue loop, then the call is routed after let's say 40 seconds or so, meanwhile the agent status is RESERVED.

Anthony Holloway
Cisco Employee
Cisco Employee
Can you create a test scenario with a barebones solution just to prove out the important parts and then share those two scripts with us? I can visualize what you're doing, but I need to see the details to really make it clear. If I have some time today, I'll try to re-create the scenario in the lab to see how it's behaving.

Hi Anthony,

 

I hope you are well :)

Thank you for your answer!

 

I've attached the scripts, they are very simple.

You can test it. If the agent is "Ready" the call is routed correctly. If the agent is first "Not Ready" and after the call is in the queue became "Ready". The agent goes in "Reserved" state and the call is not routed at all or routed with abnormal delay maybe 30-40 secs or more.

 

I've opened TAC case for the same issue and the case is already closed as the engineer pointed me to few bugs: 

 

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCtx99183

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCve95730

 

It seems that the same issue is observed long time ago and it was never fixed. 

 

Thank you!

I can't open the main file because it's referencing a custom class. However, I do see you said the defects solve your issue, in that, it's just broken, and you need to reconfigure your solution.

I am curious if it works or not, so I'll still try it myself. Though, this isn't something I've ever done. The trigger app step for me only have value in its ability to be ran asynchronously, otherwise, I would call redirect to another trigger or call subflow to another script depending on the situation.

I can open the triggered script, and I don't see why, unless you remove some steps, you are getting the session and answering the contact. Neither of those steps seem to be necessary.

 

EDIT: After playing around with this a bit, I can already see a potential issue.  If you are not keeping the original script alive, where --Triggering Contact-- is referring to the caller, then the second script will lose it's Contact.  You see, even in Callback solutions, where two scripts share a reference to the --Triggering Contact--, the script which "creates" the Contact will "clean up" the Contact if the script ends.  Therefore, if you need the Contact to stay active and in use, so you can interact with it in another script like this, then you need to keep the original script active the entire time.  Which, if you think about it, is a waste of resources, holding two or more scripts in memory just to queue and answer a call.  Even with a subflow as a workaround this is doing the same thing.  It would be better to use Call Redirect, so you can free up resources as you pass the caller around the system.

 

Anyway, since I cannot see your full solution, I'm just guessing that this is the issue you're running into.  If you can remove the dependency on the external java class, I could then look at it closer.  I'll keep researching the solution on my end too; as I'm not quite done yet.

 

EDIT 2: Ok, so I've done some light testing on this and I have a hypothesis.  Similar to what I was saying about cleaning up resources when a script ends, I believe the originating application where the contact was created, is the only application which can be triggered by the interruptible nature of the Select Resource step.  The event seems to be missing the target trying to be executed, because it doesn't exist within the context of the originating App.

 

I've never done it this way before, so I learned something here.  Too bad the Trigger Application step isn't more robust, but that's how it is.

Hi Anthony,

Thank you for the investigation. I just attached the scripts, probably the issue about opening the scripts is because the default Language was custom and you do not have it. Anyway I've attached the scripts again. The issue is easily reproducible.  I hope you will be able to open those files.

 

Well, the reasons behind why I want to use Trigger Application are:

1. For reporting requirements customer did not want to have call redirect..

2. Subflows are pretty hard to debug especially in development state and if the scripts are complicated, it's not very convenient.

Anyways I guess the customer had to live with these things. I will use call redirect and session steps in order to pass data between scripts.

 

The problem is exactly what you explained about triggering contact.

Thank you a lot for the info!

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: