Friday 11 July 2008

VQSM hangs when adding call subjects and Asset data - Dual-core / multi-processor machines

I had an issue the other week with a customer whereby some of their machines on one of their sites would hang when logging calls in VQSM and in particular when adding call subjects or selecting asset data. I had their internal support team try all the usual stuff like clearing the cache on the problem machines, checking that the settings were the same for those users as others without the problem but to no avail.

The machines that were experiencing the problem were in a team in what had up until recently been a separate company to the main VQSM deployment so I started looking for differences in the machines used on this site. One of differences to the main site was the fact that they were using of Symantec anti-virus. Initially thus did not look to be the issue as other machines on the site were using the same combination of Symantec and VQSM and did not experience the same problem. I did however do some research looking for issues related to VQSM and Symantec and this led me to a a solution that resolved the issue which it turns out is actually related to VQSM when running on Dual Core or Multi-Core systems.

The workaround for this is to set the affinity for the Portal applications on the client using the imagecfg.exe utility from Microsoft to set the CPU affinity for the QSM Portal Client and Designer applications permanently.

Steps to set up affinity

1. Make sure VQSM is not running on the machine.

2. Copy imagecfg.exe into the program directory for VQSM.

The Default is : C:\Program Files\Datawatch\VisualQSM Portal).

3. Open a cmd prompt Start -> Run cmd

4. Navigate to the VQSM directory

e.g. cd "C:\Program Files\Datawatch\VisualQSM Portal"

5. Execute the imagecfg utility using the following commands.

imagecfg.exe -u QSMPortalClient.exe
imagecfg.exe -a 0x1 QSMPortalClient.exe
imagecfg.exe -u QSMPortalDesigner.exe
imagecfg.exe -a 0x1 QSMPortalDesigner.exe

NOTE: I know it's pretty obvious but if you don't have the designer client installed on the machine just execute the first two lines.

Posted by:David Bland (Transforme Associates Limited)
Software: VQSM
Supplier: Datawatch
Version: 7.x
Database: Microsoft SQL, Oracle

Thursday 26 June 2008

VQSM and Windows Vista SP1

Although the majority of clients I work with still tend to have Windows XP deployed as their standard desktop, I am starting to see some look at Windows Vista and this will obviously become more common as time goes on.

If you are considering running Vista and particularly Service Pack 1 you should be aware that you will need the version 7.4 Visual QSM client or above (this was confirmed to me by Datawatch support after a client of mine found that 7.2.1 wouldn't function under Vista). As VQSM does not support differing versions on server and client that will mean that even if you have just a couple of Vista desktops you will still need to upgrade your entire environment.

The good news is that in my experience 7.4 seems much more robust than the 7.1.x or 7.2.x releases so its definately worth doing anyway.


Posted by:David Bland (Transforme Associates Limited)
Software: VQSM
Supplier: Datawatch
Version: 7.x
Database: Microsoft SQL, Oracle

Friday 2 May 2008

Using keywords with the Daemon Process to Log Calls

One of the nice features of VQSM is the way you can use a pre-formatted email to pass in information when logging a call via the daemon process. By formatting the email correctly it is possible to set the all the main fields within QSM and even custom fields (something I might cover in a future post).

We used this recently to create a simple self service module for one of our clients that took users through a simple process to create the call and then using a little business intelligence built an email that logged the calls with a high degree of fidelity.

The following is a link to an Excel file that Datawatch have created which defines the format for the keywords.

KeywordSyntax.xls



Posted by: David Bland (Transforme Associates Limited)
Software: VQSM (Datawatch)
Version: 7.x
Database: Microsoft SQL, Oracle

Using the daemon process with Microsoft Exchange

VQSM supports three basic protocols for connecting to a companies existing email environment to send confirmation or escalation emails or to query a shared email account into which support calls are sent.

These are POP3/SMTP, IMAP, Lotus Notes and MAPI. For the first three of these it is immaterial what account the daemon process runs under as you specify the login details for the email system directly. Because of this I often find that clients have the daemon process running under the local system account.

When using Microsoft Exchange via MAPI however the daemon is tied to the user account and will by default use the MS Exchange Settings for that user. What I find frequently is that the individual setting up the connection will logon using an administration account they have been given, go to control panels and configure the MS Exchange Settings profile to access the correct mail box on the server. They run the daemon process manually from the QSM server and hey presto it works ! They then go and enable the daemon service and find that they get an error in the log saying that the daemon can't access the mailbox.

More often than not the issue is that they are running the daemon service using a different account than they used to set it up and frequently the local system account. This occurred a few weeks ago when I was called into an account where Datawatch had been in a couple of days before to upgrade to 7.4. As the client had recently moved to Exchange they also took the opportunity to ask the Datawatch consultant to switch them from POP3 to MAPI which he did. Unfortunately he left the daemon process running under the local system account as it had been previously so when he left no emails out and no processing of inbound emails either.

My suggestion when running with Exchange is always to run the daemon under the domain account associated with the shared main box that the daemon processes is accessing. That way you can be pretty sure it will work without issue.


Posted by: David Bland (Transforme Associates Limited)
Software: VQSM (Datawatch)
Version: 7.x
Database: Microsoft SQL, Oracle

Event Codes

One of the things I am often asked for by clients particularly when writting their own reports is a list of the event codes in VQSM. Although there is not a published list there is code in the standard call report used to print calls that contains the breakdown. The code can be copied from the report installed on the server but for those who want it, this is it:

if ({call_event.Eventcode} = 1 ) then "Call Logged"
else if ({call_event.Eventcode} = 2 ) then "Call Allocated"
else if ({call_event.Eventcode} = 3 ) then "Call Assigned"
else if ({call_event.Eventcode} = 4 ) then "Call Fixed"
else if ({call_event.Eventcode} = 5 ) then "Call Re-Opened"
else if ({call_event.Eventcode} = 6 ) then "Call Returned Unallocated)"
else if ({call_event.Eventcode} = 7 ) then "Call Picked Up"
else if ({call_event.Eventcode} = 8 ) then "Call Signed Off"
else if ({call_event.Eventcode} = 9 ) then "SLT1 Response"
else if ({call_event.Eventcode} = 10 ) then "Auto-Escalation"
else if ({call_event.Eventcode} = 11 ) then "External Group Targets Set"
else if ({call_event.Eventcode} = 12 ) then "External Group Response"
else if ({call_event.Eventcode} = 13 ) then "External Group Fix"
else if ({call_event.Eventcode} = 14 ) then "External Group Allocation"
else if ({call_event.Eventcode} = 15 ) then "Manual Escalation"
else if ({call_event.Eventcode} = 16 ) then "External Person Assign"
else if ({call_event.Eventcode} = 17 ) then "Call Targets Changed"
else if ({call_event.Eventcode} = 18 ) then "Call Placed On Hold"
else if ({call_event.Eventcode} = 19 ) then "Call Linked To Other Calls"
else if ({call_event.Eventcode} = 20 ) then "Auto-Escalation Resumed"
else if ({call_event.Eventcode} = 21 ) then "Manual release of call from Hold"
else if ({call_event.Eventcode} = 22 ) then "Call Unlinked"
else if ({call_event.Eventcode} = 23 ) then "Call Priority Changed"
else if ({call_event.Eventcode}= 24 ) then "External Group Targets Changed"
else if ({call_event.Eventcode} = 25 ) then "SLT1 Code Changed"
else if ({call_event.Eventcode} = 26 ) then "Mail Sent"
else if ({call_event.Eventcode}= 27 ) then "Mail Received"
else if ({call_event.Eventcode} = 28 ) then "Reply Sent"
else if ({call_event.Eventcode} = 29 ) then "OutBox Mail"
else if ({call_event.Eventcode} = 30 ) then "QLink Create Transmission"
else if ({call_event.Eventcode} = 31 ) then "QLink Create Acknowledge"
else if ({call_event.Eventcode} = 32 ) then "Qlink Update Transmission"
else if ({call_event.Eventcode} = 33 ) then "QLink Update Receive"
else if ({call_event.Eventcode} = 55 ) then "Client Linked"
else if ({call_event.Eventcode} = 56 ) then "Client Unlinked "
else if ({call_event.Eventcode} = 57 ) then "Config Linked "
else if ({call_event.Eventcode} = 58 ) then "Config Unlinked "
else if ({call_event.Eventcode} = 59) then "Logon Linked "
else if ({call_event.Eventcode} = 60 ) then "Logon Unlinked "
else if ({call_event.Eventcode} = 61 ) then "Item Linked "
else if ({call_event.Eventcode} = 62 ) then "Item Unlinked "
else if ({call_event.Eventcode} = 63 ) then "Client Updated"
else if ({call_event.Eventcode} = 64 ) then "Config Updated"
else if ({call_event.Eventcode} = 65 ) then "Logon Updated"
else if ({call_event.Eventcode} = 66 ) then "Item Updated"
else if ({call_event.Eventcode}= 67 ) then "Location Linked"
else if ({call_event.Eventcode} = 68 ) then "Location Unlinked"
else if ({call_event.Eventcode} = 69 ) then "Call Subject1 Added"
else if ({call_event.Eventcode}= 70 ) then "Call Subject1 Changed"
else if ({call_event.Eventcode} = 71 ) then "Call Subject2 Added"
else if ({call_event.Eventcode} = 72 ) then "Call Subject2 Changed"
else if ({call_event.Eventcode} = 73 ) then "Call Subject3 Added"
else if ({call_event.Eventcode} = 74 ) then "Call Subject3 Changed"
else if ({call_event.Eventcode} = 75 ) then "Comments Updated"
else if ({call_event.Eventcode} = 76 ) then "Organization Linked"
else if ({call_event.Eventcode} = 77 ) then "Organization Unlinked"
else if ({call_event.Eventcode} = 78 ) then "Organization Updated"
else if ({call_event.Eventcode} = 79 ) then "Call Subject2 Removed"
else if ({call_event.Eventcode} = 80 ) then "Call Subject3 Removed"
else if ({call_event.Eventcode} = 81 ) then "File Attached"
else if ({call_event.Eventcode} = 82 ) then "File Detached"
else if ({call_event.Eventcode} = 34 ) then "SLT2 Set Event"
else if ({call_event.Eventcode} = 35 ) then "SLT2 Changed"
else if ({call_event.Eventcode} = 36 ) then "SLT2 Removed"
else if ({call_event.Eventcode} = 37 ) then "Downtime Event "
else if ({call_event.Eventcode} = 83 ) then "Release Datetime Changed"


Posted by: David Bland (Transforme Associates Limited)
Software: VQSM (Datawatch)
Version: 7.x
Database: Microsoft SQL, Oracle

VQSM Full Text Indexing fails in SQL

A quick one at the moment to get the ball rolling, I just came back from a client that uses VQSM with SQL and they had an issue with full text indexing whereby their periodic update failed continuously.

VQSM has a scheduled job that should run to maintain the full text index for the call comments field. If you find that the job fails then it is worth checking that the full text index has been created and that nobody has subsequently deleted it.

You can find an entry for the index using enterprise manager by expanding the database and clicking on Full-Text Index. You should have an index named Call_Comments listed. If not you wiull need to create it using the following from Query analyser.

use [Database_Name] sp_fulltext_catalog N'Call_Comments', N'create'


Posted by: David Bland (Transforme Associates Limited)
Software: VQSM (Datawatch)
Version: 7.x
Database: Microsoft SQL