Voiceguide V7: Callque Entry Execution Inconsistent

[Guest BlackBird]

Hello Team,

 

I set up Voice Guide v7 (VG7) to use MS SQL as the main db, I also wrote an application that inserts a new call entry into the CallQue table and VG7 would execute the call as expected, without issues.

 

I had to rebuild my server, and got everything set up on my new server, but what I noticed is that VG7 seems to ignore the entries I insert with my application into the CallQue table (whereas it use to work before).

 

To troubleshoot further, I opened the Voice Guide Outbound Call Loader application, created at single entry to dial out 787 791 6831, once I loaded the call entry, I confirmed that the entry was inserted into my MS SQL DB, the call was made without issues.

 

Whle at the CallQue table I compared the Outbound Call Loader entry (phone number: 787 791 6831) to an entry that I created with my application (phone number: 787 478 3624), barring the different phone numbers, all other fields seemed to be a match and with valid formats and datatypes, including the date and time fields.

 

Despite the similarities in the format and syntax, VG7 made the call inserted to the MS SQL DB via the Outbound Call Loader, but, ignored all together the call inserted to the MS SQL DB via my application, which is my preferred method.

 

The Question:

If both entries are found at the CallQue table and both follow similar formats, why would VG7 ignore one entry over the other? As I understand VG, the premise would be that once in the CallQue table, then VG should execute the call at the specified date & time.

 

I attached the logs files for your review. Your guidance will be greatly appreciated.

 

Regards,

Ralph

0212_1131_vgEngine.zip

[SupportTeam]

VG7 made the call inserted to the MS SQL DB via the Outbound Call Loader, but, ignored all together the call inserted to the MS SQL DB via my application

 

This does suggest that there is some vital difference in the entries inserted by your application which prevents VG from retrieving the calls.

 

To let us see how the entries inserted by your app look like we would need to see the the database itself.

 

Can you do this:

 

Stop VG service.

Clear DB

Insert a call into DB using Outbound Call Loader

Insert a call into DB using your app

Backup the DB and .ZIP it up and post it here.

Indicate which call was inserted using which method.

 

 

You can also do some SQL tracing on the DB side to see what SQL queries are issued by VG and what results the DB returns to those queries.

[SupportTeam]

Also keep in mind that if you are doing insertions directly into the database yourself in v7 then you need to not only insert an entry into the main Call Que table, but you also need to insert an entry into the PortToUse table.

 

You can only omit PortToUse table insertion if the use of PortToUse has been explicitly disabled in the VoiceGuide configuration files.

[Guest BlackBird]

In my set up the PortToUse has been explicitly disabled all along, here is a snap shot out of my config.xml, where I am defining the MSSQL DB & Disabling the PortToUse.

 

<Dialer>

 

<OutDialQue_ADODB_Provider>System.Data.SqlClient</OutDialQue_ADODB_Provider>

<OutDialQue_Database>ASPNETDB</OutDialQue_Database>

<OutDialQue_ConnectString>Data Source=VOCALICO;Database=ASPNETDB;User ID=yyyy;Password=xxxx;</OutDialQue_ConnectString>

<OutDialQue_SqlPrefix></OutDialQue_SqlPrefix>

<OutDialQue_SqlSuffix></OutDialQue_SqlSuffix>

<OutDialQue_PortToUse_LinkField>Disable</OutDialQue_PortToUse_LinkField>

 

</Dialer>

I did notice that, even thought in the config.xml I disabled the PortToUse, in the SQL trace there are some calls for the PortToUse, is it possible that the PortToUse argument is not being applied?

 

 

The following outlines the steps I performed to produce the new set of logs and the SQL trace file:

1. Stopped the VG service
2. Confirmed that the config.xml has the correct ADO provider and the PortToUse disable argument
3. Deleted all logs
4. Dropped all existing DB tables associated with VG
5. Started the VG service
6. Verified that the VG service created the pertinent tables in MS SQL and confirmed that the Vistadb file was not created
7. Place a call via the Outbound call Loader, worked like a charm!
8. Placed a call via my application, the call got into the Callque table, but VG failed to make the call

Another small detail I noticed, is that once I insert via my app the call (7874782634) entry into the CallQue Table there is no trace of the in the VG log files, thus, I assume that no attempts was made by VG to place the call. The only call traces belong to phone number inserted via the Outbound Call Loader (787 791 6831)

 

 

The attachment contains:

• A spread sheet where you can see the values (directly from the DB) associated with each call, my app inserted phone number 7874782634 (failed to call), the Outbound Call Loader inserted phone number 787 791 6831 (made the call).
• A new batch of log files
• A SQL trace file

I should have mentioned earlier my system specs: VG 7 version 7.1.0.0, the system is a Win Server 2003 SP1 Enterprise Ed, with SQL 2005 Enterprise Ed. The odd thing is that with a previous VG 7 version the system (and my app inserts) the whole thing worked.

 

Please let me know if you require additional information.

 

-r

0213_0745_vgEngine.zip

[SupportTeam]

In the attached traces in what format is the .trc file?

How was it created and how can we view its contents?

[SupportTeam]

Can you please stop VG service then change the vgEngine log level in VG.INI to 20, then start the VoiceGuide service and after the service is started insert do the two inserts outbound calls again (one using VG Outbound Call Loader, and one by inserting entry directly into DB using your own apps).

 

The stop the VG service and post the vgEngine log here (.ZIPed)

[Guest BlackBird]

Certainly, the attachment contains refreshed versions of the VG Engine log files (log set to 20), along with the spread sheet (values from the CallQue table), and the SQL trace files.

 

The SQL trace file are saved by default to the .TRC format, which require SQL Server Profiler to view its content, however, I am providing a copy of the SQL Trace file in .xml format to facilitate the investigation.

 

-r

VG_Logs_And_SQL_Trace_2.zip

[SupportTeam]

vgEngine log shows that VoiceGuide is still using the PortToUse table.

 

The trace show that this SQL is issued to database:

 

SELECT TOP 1 porttouse.CallID, porttouse.CallGUID, porttouse.ActivateTime FROM porttouse WHERE ( (porttouse.ActivateTime <= @dateNow) AND ((porttouse.TimeStart_Sun <= @time4charNow) AND (porttouse.TimeStop_Sun > @time4charNow)) AND (porttouse.Scheduler = @iScheduler)) ;

 

The vgEngine trace also shows that OutDialQue_porttouse_LinkField field was not even read in from the Config.xml file:

 

014020.218 5 config.xml read: /VoiceGuideConfig/Dialer

014020.218 5 ReadXmlNodesSubEntryintoString(OutDialQue_porttouse_LinkField) node not found in: System.Xml.XmlElement

...

014020.218 5 db config zConfigXml_sDialer_OutDialQue_porttouse_LinkField = GUID (default for provider = System.Data.SqlClient)

 

So it looks like the use of PortToUse table is not turned off on this system.

 

Please check the Config.xml file on this system and confirm that the OutDialQue_porttouse_LinkField setting is correctly specified.

 

If you'd like, please .ZIP up and post the Config.xml file from your system and we can have a look at it as well.

[Guest BlackBird]

I concur with you, I got the suspicion that the Disable command associated with the OutDialQue_porttouse_LinkField tag found in the config.xml (please see attachment) is been ignored.

 

I don't want to take your focus away from solving the issue being discussed here, but, I have a side request to make: every time I post a reply, the moderator needs to review each reply prior to posting it to the forum. For international customers, on different timezones, the additional moderator reviews prolongs unnecessarily the communication on topics discussed in the forum, thus, if an issue being investigated affects a live production environment the communication will take quite a bit longer due to the additional moderator approval cycles. To mitigate downtime, will it be possible to alter the moderator's approval process? so that the review occurs to the initial post only and additional replies to the original post could flow faster without the need to be moderated..... Please do not misunderstand my request, I am very impressed with the commitment and response from VoiceGuide's Support Staff, which is first class!

 

 

Lastly, please let me know if I should make any changes to the config.xml tag.

 

Regards,

-r

Config.zip

[SupportTeam]

Looks like in the VG version installed on your system the Config.xml entry disabling the porttouse table needs to be:

 

<OutDialQue_porttouse_LinkField>Disable</OutDialQue_porttouse_LinkField>

 

(instead of : <OutDialQue_PortToUse_LinkField>Disable</OutDialQue_PortToUse_LinkField> - note PortToUse is changed to porttouse)

 

This is a bug, as it is not as per documentation, will be fixed in next VG v7 update.

 

 

 

Moderation is needed to prevent spam.

This free support forum has a target of responding to posts on a 24 hour turnaround basis, and most of the time it's quicker than that, even with post moderation.

For quicker support response we'd recommend contacting sales@voiceguide.com and inquiring about support contracts.

[Guest BlackBird]

I will change the case of the entry on my server, and will report back the result.

 

 

It is duly noted that the support forum is free service (for trial and paying customers) and a commendable job the support team performs. Last time I interacted in the support forum, the constant moderator review did not seem as obstructed, just pointing out that with such change, the communication turn around its noticeable, at least based on my past experience with the support forum....that said, also thanks for pointing out the paying support alternative, which I might need to consider once I go into production.

 

-r

[Guest BlackBird]

I confirmed with my server that the recommended fix resolves the bug found. Thank you for your efforts and the excellent support provided.

 

Best Regards,

Ralph

[SupportTeam]

OK, thanks for letting us know that its working now.