The main problems that arise from exporting calls are:

We need to be able to select freely a number of calls for export, given one or more export criteria; we want to be able to review the results before they are final, and we want to exclude specific calls when reviewing.

The retrieval of audio causes a similar problem; first, audio retrieval was not really made for batch access, so seek times for individual files may be in the order of one per seconds; secondarily, those files may well require a large disk space when preparing the batch.

The call export feature works in batches, that is, at any given time there are a set of batches that an administrator creates and that are to be exported. Each of them has a name and a status.

This is the life-cycle of a batch:

The graph provides a visual representation of the whole process:

The process of building a batch may take a while – therefore there is a transaction that simply keeps displaying a page in a browser that shows a progress bar while the project is being exported.

In order to export calls, an administrator must first create a batch. To do this, they go to the Home Page → Import/Export calls:

From here you select List Export Jobs.

You can then create a new job.

When configuring the job, you have to specify:

These properties can be changed through the lifetime of the job.

From now on, users accessing the Detail of Taken Calls will see a gadget by the end of the page like the one shown here:

This basically lets you add all the calls above to the export job you select. If the export gadget should not be visible, you have to add it manually to the current report (its code is OD02 - see Block OD02 the section called “OD02 - Add to export job” ).

After you add sone calls to a job, the import transaction will confirm the add through a popup screen that displays the number of calls imported and the number of calls rejected (because they were already a member of this job). Only jobs in state Open will be availble for adding calls.

You can now see a list of calls from the Export Jobs page:

You can search calls within the current job and toggle their inclusion in the exported list by clicking on the reload icon next to each call.

When the job is ready for shipment, the administrator first has to Close it and then to Export it. This will take a while. Audio files will be retrieved through the curremtly configured Pluggable Module for audio records and will be saved in the job folder.

Thought the actual attributes used are based on the Implementor module used, the following are common attributes.

Batch attributes

Each call in the batch has the following attributes:

Batch disk format

A call batch appears on disk as a folder under the system call batch folder. The folder is created if not present (it must be in a Java-writable location). When the batch is in status "Ready to send", the audio files are copied to this folder; at the end of it all, a manifest file that includes the details is written. Each downloaded audio file is renamed in order to be unique and coherent, typical file names may be:

0000123-1.wav
0000123-2.mov

Both files are about the 123rd call, the first one being an audio recording and the second one a video recording.

When the batch is in status "Sent" QM no longer cares about the disk representation – it can be moved, sent as FTP, compressed and encrypted, whatever.

Manifest file format

The manifest file format should be chosen by the sysadmin – it is implemented as an abstract class for ease of change.

HTTP file transfer

This is the basic implementor and produces an XML file.

HTTP MP3 file transfer

This implementor does two things:

The following ID3 tags are created:

	Note
	this implementor DOES NOT transcode files to MP3 - they must already be in MP3 format or you should provide an external batch script to do the conversion. More details are provided in the following paragraph.

QueueMetrics lets you able to perform an external batch script call in order to convert call files to different format like, for example, wav files in mp3s. This feature is applied only for export jobs implemented with the "HTTP MP3 File Transfer" object. No external calls will be made for "HTTP File Transfer" enabled export jobs.

Assuming to have this type of export job parameters: Job name: MyJob Export folder (on server): /var/spool Implementor: HTTP MP3 File Transfer

the work flow followed by QueueMetrics, for HTTP MP3 File Transfer enabled jobs, will be like depicted below.

For each call in the job and for each file associated to a specific call:

When all files in the job are properly downloaded and converted, QueueMetrics will add all relevant QA information only to files with name ending with .mp3

Please note that:

To summarize the overall process, a simple example of working environment is provided:

In the configuration.properties is the key:

export.conversionCommand=/usr/local/apache-tomcat-5.5.25/webapps/ROOT/testbatch

and in the /usr/local/apache-tomcat-5.5.25 is an executable testbatch script:

[root@qmmachine ROOT]# ls -la testbatch
-rwxr-xr-x 1 root root 87 Mar 10 05:17 testbatch

In this simple example, the batch script copies the original file in the temporary folder (with a not unique name in this example)

#!/bin/bash
# $1 is the source file
# $2 is the output directory
# $3 is the job name
# $4 is the parameter field defined in the job definition page

cp $1 $2/testresult

The resulting working folder will contain something like:

....
-rw-r--r--  1 root root  408516 Mar 10 05:18 17619_testresult
-rw-r--r--  1 root root   50110 Mar 10 05:18 18542_testresult
-rw-r--r--  1 root root  884372 Mar 10 05:18 18795_testresult
-rw-r--r--  1 root root    4740 Mar 10 05:19 20110304_084640-99.wav
-rw-r--r--  1 root root  419784 Mar 10 05:19 20110304_084640.wav-99-1.avi
....

And the manifest something like:

....
<call>
<files>testresult,2071_testresult</files>
<errors></errors>
<chunks>2</chunks>
<uniqueid>3033212900899824</uniqueid>
<videocall>true</videocall>
<callid>4006</callid>
....