I think you would be using a custom action element to fetch data from DB using JDBC. So you can log all the activities as a part of activity log itself.
ActionData.addToLog("MyClassName","Starting DB connection");
//JDBC connections codes
ActionData.addToLog("MyClassName","Connection extablished");
.
.
.
Since you are using JDBC. For every call a new connection is been establised. Check if you have licensed enough database connections in Oracle and that you close the connection after the fetching the data.
Here you can take advantage of JNDI, which would open a connection pool and all the call would use the same connection to fetch the data.
Manoj Anantha
For the calls that are diverting directly to an agent, can you tell from
the Activity Logs whether the call gets as far as your database element?
If so, look at the time stamps and see the duration between the start of
the database interaction and the start of the transfer to an agent.
On 8/3/2010 12:17 PM, Cisco Developer Community Forums wrote:
> Zaki Qureshi has created a new message in the forum "New Feature
> Discussion":
>
> --------------------------------------------------------------
> Thanks Janine
> Â
> Database Interaction by ourselves yes we are logging into the database
> for each call as we are using JDBC connection. By the way most of the
> calls are working fine but some calls directly divert to agent without
> getting any menus. Let me check with team for "Fetchtimeout"Â
> changing the values but my question is here that why the other calls
> are working fine.
> Â
> Zaki,
>
> Is the database interaction being done through a Studio/Vxml Server
> application? If so, did you write the database interaction yourselves,
> or are you using the Database element? If you wrote it yourselves, are
> you logging into the database with each phone call (usually slow), or
> using Tomcat JNDI to log in and remain connected to the DB?
>
> If the app is written using Studio, you might try is changing the
> VoiceXML Property named "fetchtimeout" to "10s" (this can be done in the
> Root Document of the Stuido project, omit the quotes), because perhaps
> the VoiceXML Gateway is timing out waiting for the application to
> complete its database transaction.
>
> Janine
>
>
>
> On 8/2/2010 12:15 PM, Cisco Developer Community Forums wrote:
> > Zaki Qureshi has created a new message in the forum "New Feature
> > Discussion":
> >
> > --------------------------------------------------------------
> > Thanks for your reply. But here i have to mention one more thing is
> > that we just take itÿ wire sharkÿ traces and as we observe that the
> > request take only 0.5 sec to complete round trip from database to cvp
> > and back to CVP. Kindly advice on this my question is here that calls
> > successfully reach database but some call goes directly transfer to
> > agent without any options.
> > ÿ
> > ÿ
> > Will need more details. If you are not getting a response from
> > database and timing out then how are you catching/handling that event
> > in the IVR code?
> > Based on what you have written, if the call goes through IVR and hits
> > the database and does not come back then it is timeout issue. There
> > could be no things causing it. Please provide more details.
> > Hemal
> > ________________________________
> > From: Cisco Developer Community Forums [cdicuser@developer.cisco.com]
> > Sent: Sunday, August 01, 2010 8:35 PM
> > To: cdicuser@developer.cisco.com
> > Subject: New Message from Zaki Qureshi in Customer Voice Portal (CVP)
> > - New Feature Discussion: Some calls like 80% are connected with
> > database and 20% bypass the databas
> >
> > Zaki Qureshi has created a new message in the forum "New Feature
> > Discussion":
> >
> > --------------------------------------------------------------
> > Hi,
> >
> > We have issue with database connectivity most of the calls are
> > successfull and getting the IVR compeletly but some calls Bypass the
> > IVR its mean they didnt get the response from Database.
> >
> > This issue happen Site A which is connected through WAN.
> >
> > Let me add here that we have central Database which is connected to
> > Side B its mean Side B is connected Locally and there is no issue.
> >
> > The problem occurs only in PEAK Hours
> >
> > Looking for your support
> > --
> > To respond to this post, please click the following link:
> >
> >
> <http://developer.cisco.com/web/cvp/forums/-/message_boards/message/2399194>
> >
> > or simply reply to this email.
> >
> > --
> > To respond to this post, please click the following link:
> >
> >
> <http://developer.cisco.com/web/cvp/forums/-/message_boards/message/2401313>
> >
> > or simply reply to this email.
>
> --
> Janine Graves
> 781-990-1040
>
> --
> To respond to this post, please click the following link:
>
> <http://developer.cisco.com/web/cvp/forums/-/message_boards/message/2403264>
>
> or simply reply to this email.
--
Janine Graves
781-990-1040