This document describes one reason why an error 500 appears in the Java Telephony Application Programming Interface (JTAPI) trigger page after the JTAPI trigger is switched to a new Computer Telephony Interface (CTI) route point and provides a workaround in a Cisco IP Contact Center (IPCC) Express Edition environment.
Cisco recommends that you have knowledge of these topics:
Cisco CallManager
Cisco Customer Response Solutions (CRS)
The information in this document is based on Cisco CRS version 3.1(1).
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
One of the JTAPI triggers for a specific application is changed to a new CTI route point directory number. When you click the new JTAPI: 8000 trigger in the Cisco Script Application page for this specific application, as this window shows, the JTAPI Trigger Configuration page should appear in a normal working condition. The number 8000 represents the new Computer Telephony Interface (CTI) route point directory number.
However, instead of this image, the error 500 appears in the JTAPI Trigger Configuration page, as this window shows:
Error: 500 Location: /appadmin/JTAPITrigger Internal Servlet Error: java.lang.NullPointerException at com.cisco.config.trigger.TriggerConfig.getSessions(TriggerConfig.java:78) at com.cisco.config.trigger.TriggerConfig.createSetTriggerCfg(TriggerConfig.java:118) at com.cisco.config.trigger.TriggerConfig.getTriggersByType(TriggerConfig.java:345) at com.cisco.appadmin.ui.GenericTriggerController.readTriggerList(GenericTriggerController.java:189) at com.cisco.appadmin.jtapi.ui.JTAPITriggerController.execute(JTAPITriggerController.java:131) at com.cisco.appadmin.ui.AppAdminServlet.processService(AppAdminServlet.java:251) at com.cisco.appadmin.ui.AppAdminServlet.doGet(AppAdminServlet.java:180) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection(Ajp12ConnectionHandler. java:166) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498) at java.lang.Thread.run(Unknown Source)
The problem is caused by a corrupted JTAPI trigger entry in the DC Directory. When the user assigns a new CTI route point directory number to this specific application as the JTAPI trigger, the old corrupted replaced JTAPI trigger for this application remains in the DC Directory.
The workaround is to delete the corrupted old JTAPI trigger. Complete these steps:
Log in to the DC Directory on the Cisco CallManager (Publisher).
Go to the Cisco web site and select CCN Apps > Configurations > Profiles > ccnwfapp > Triggers > JTAPI.
Right-click the old JTAPI trigger and select Delete.
Restart the Cisco CTIManager service from the CallManager Service Activation page.
After the old JTAPI trigger is deleted, the JTAPI Trigger Configuration page appears as normal.
Revision | Publish Date | Comments |
---|---|---|
1.0 |
23-Apr-2007 |
Initial Release |