Here are the steps to install OrkAudio using installers on CentOS or Red Hat Enterprise Linux (RHEL).

Requirements

Installation

Requirements

Installation

Use the installer file provided to you by OrecX, e.g. orkaudio-1.2-657-x1463-win32-installer.zip . Copy this file to a temporary folder on the target machine, unzip it and run the embedded executable. This will install WinPcap as well as OrkAudio.

In this procedure, please replace version numbers with the relevant ones.

In this procedure, please replace version numbers with the relevant ones.

Audio output files are written to the c:\oreka\audio under Windows and in /var/log/orkaudio under Linux by default.

Audio files are classified according to the following default scheme (see also TapeFileNaming and TapePathNaming in the section called “File and Path Names in OrkAudio” ):

yyyy/MM/dd/hh

Audio file themselves are named after the following scheme:

yyyyMMdd_hhmmss_trackingID.extension

OrkAudio configuration files are located in the install directory under Windows and in /etc/oreka under Linux. The files are:

Log files are located in the install directory under Windows and in /var/log/oreka under Linux. By default, Oreka produces the following output:

Plugins exist as dll files under Windows and as DSO (Dynamic Shared Objects) with .so extensions under Linux. They are located in {OrkAudioInstallDirectory}/audiocaptureplugins under Windows and in /usr/lib under Linux.

Wire audio encodings are detected automatically by OrkAudio. Audio is not usually stored in its original wire format. Audio is recorded in real time to mcf files in order to maximize capturing performance and is later transcoded to the final storage format as specified in the section called “Storage audio formats” . The following encodings are supported:

Configuration of OrkAudio and its plugins is performed by modifying the config.xml file (see also the section called “Configuration Files” ). Core OrkAudio configuring parameters are the following:

It is possible to configure the path to which audio files are written as well as the audio file names through dynamic parameters

First, the TapeFileNaming tape processor needs to be added to the list of processors in the top node of the orkaudio config.xml file:

					
<TapeProcessors>BatchProcessing, TapeFileNaming, Reporting</TapeProcessors>
					
				

Secondly, the <TapeFileNaming> and/or <TapePathNaming> must also be added in the top node of the orkaudio config.xml file. They both contain a CSV list of elements. If an element appears between square brackets, it will be replaced by the value corresponding to the keyword. If an element appears without square brackets, it will be used verbatim in the file name. Example:

						
<TapeFileNaming>myrecordings-,[nativecallid]</TapeFileNaming>
						
					

with a native call ID of FDBCE@69.13.45.6 will result in the following file name: myrecordings-FDBCE@69.13.45.6.wav .

If the TapeFileNaming parameter is missing, the default naming scheme applies which is a timestamp plus the internal trackingID.

If the TapePathNaming parameter is missing, recordings are distributed to the default year/month/day/hour folder tree structure described in the section called “Files Location” .

Note: TapePathNaming configuration is always relative to AudioOutputPath.

Here is a list of acceptable keywords for tape and path naming:

You can also use any tag or additional custom extracted field in file names by using its tag/field name as a key. e.g for a SIP field called X-Unique-ID, add [X-Unique-ID] to TapeFileNaming or TapePathNaming. See also the section called “Extracting arbitrary fields from SIP headers”

Additional example:

					
<TapeFileNaming>myrecording,[hour],[min],[sec],_,[shortdirection],_,[remoteparty],_,[localparty],_,[hostname]</TapeFileNaming>
<TapePathNaming>mypathprefix/,[year],[month],/,[day]</TapePathNaming>
					
				

VoIP plugin specific configuration is found in the config.xml file under the VoIpPlugin tag. Many options are available for this plugin, such as limiting traffic, blocking traffic from/to a specific IP address, ... The default config.xml has some of the main options listed in it and commented out. If any of these parameters are not documented here, please contact <support@orecx.com> for more details.

						
<Devices>\Device\NPF_{E0E496FA-DABF-47C1-97C2-DD914DFD3354}</Devices>
						
					

						
<Devices>eth2</Devices>
						
					

						
<PcapFilter>host 192.168.0.34 or net 192.168.1.0/24</PcapFilter>
						
					

						
<SipExtractFields>contact, max-forwards, X-UNIQUE-ID</SipExtractFields>
						
					

For Live Monitoring from OrkWeb to work, the 59120 port must be accessible on the server where OrkAudio is running. In Linux check the iptables settings. in Windows, the firewall settings.

See also the section called “Live Monitoring (On-Demand Recording)” for configuring OrkWeb.

Under Windows, start the OrkAudio service in Service Management (start/run/services.msc).

Under Linux, start the OrkAudio service by typing service orkaudio start on the command line.

You might need to double-check that the orkaudio service was started correctly.

In Linux, use the following command:

# ps -ef | grep orkaudio

A line showing that orkaudio is running must appear:

					root     32071     1  0 10:02 ?        00:00:00
					/usr/sbin/orkaudio
				

In Windows' Service Management tool (start/run/services.msc), ensure that the orkaudio service is started

During installation using the official installers, OrkAudio will install itself as an automatic service, i.e. a service that restarts automatically if the server is rebooted. This is important in the case of power failure, maintenance or other unpredictable events that may cause the system to fail or be restarted. Ensure that the service is configured properly as follows:

# orkaudio        0:off   1:off   2:on    3:on    4:on    5:on    6:off

If not, chkconfig orkaudio on will need to be executed.

If no recordings appear in the <AudioOutputPath> directory, Here is the checklist:

Recoded wav files should all be replayable by a media player such as Windows Media Player. Here is the checklist

Make sure that RTP traffic for both sides is actually seen on the considered network interface. A packet sniffer such as Ethereal can be used for that.

Use wireshark to see if signalling packets (e.g. SIP or Skinny) can be seen on your chosen sniffing NIC. Simply capture some traffic for 1 minute and type "sip" or "skinny" as a wireshark display filter in order to see only the relevant packets. If resultset is empty, it might mean that the packet interception strategy is missing some traffic, see the section called “Getting VoIP traffic to the Oreka Server” .

Here are the steps to install OrkWeb on CentOS or Red Hat Enterprise Linux (RHEL). For assistance with other Linux distributions, contact <support@orecx.com> .

To upgrade using .war files use the procedure below. The version of the .war file made available to you by OrecX may differ from the example below, but the procedure still applies.

If you prefer a more automated way of running this procedure, you can download and use the upweb.sh script available at http://files.orecx.com/tools/upweb.sh (usage example: ./upweb.sh 1.50-4295). Please read the header of the file for instructions on the steps you need to execute manually before and after running the script. For the Windows platform, you need to have Cygwin installed to use this script.

Note that there are two types of license files: trial and production. The trial type is sent to you by OrecX as a first license and allows you to record everything on the wire. It is good to start with this type of license to uncover any configuration tweaks that may be necessary.

For example, you may be seeing only the RTP streams but not the control packets, thus no phone number or extensions can be associated to calls. With a trial license, you will be able to quickly detect such a situation and correct it since all calls would be recorded and would appear in the OrkWeb Browse page with the local and remote party typically showing as IP addresses.

With a production license, users must be configured in OrkWeb with their phone numbers or extensions (or other) as a login string, for Oreka to be able to associate the local party in the VoIP packets with the configured user and thus recording the call. If no users have been configured in OrkWeb, a production license will inhibit all recording. See also the section called “Login Strings”

Before migrating to a production license, make sure all extensions, phone numbers, SIP URIs, ... that need to be recorded, are configured as login strings for defined users in OrkWeb. The login string field must match what you see in the local party field in the Browse page.

OrkWeb and OrkTrack have a set of configuration files that allow them to know where and how to access the database, and what information to write to log files. The main configuration files are shared between OrkWeb and OrkTrack and can be found under /etc/orkweb in Linux, and typically under C:\Program Files\OrkWeb in Windows. These folders contain 5 main files:

Both the OrkWeb-OrkTrack applications, and the Tomcat web server have their own logging mechanisms. Below are the files of interest for both cases:

You can use ps -ef | grep mysqld to verify if mysqld is running, and service mysqld start to start it if it is not.

Once the MySQL is running, start the Apache Tomcat web server, e.g. service tomcat start .

Go to Start/Run... and type services.msc. This opens the Services Manager application. Ensure that the MySQL service is running. If not, start it.

Once the MySQL service is running, start the Apache Tomcat web server, by right-clicking on the Apache Tomcat service and selecting Start.

Each user can have multiple login strings entered as a cvs list of text strings. Those login strings serve two purposes:

When a new call occurs, if the local party field, as would be seen in the OrkWeb Browse page, matches one of the user's login strings, the recording will be associated to that user. The login string matching is case sensitive .

For example, Tom's login strings might be " tom, 5312 ". Any call to extension 5312 will be associated to Tom, and Tom will be able to log into OrkWeb using either " tom " or "5312" as an identifier (assuming Tom has a password defined. OrkWeb login is denied for users with blank passwords).

Configuration of users and login strings is very important for correct behavior when using production licenses. Refer to the section called “Trial versus Production license”

When you have a great number of users to define in OrkWeb, it could be a daunting task to create them all, one at a time, from the Admin/users page. In this case, you can use the Import Users feature available on that page. This feature allows you to import a comma-separate list of users directly into OrkWeb. Below are the fields that define the file format:

firstname, lastname, login string, password, recordable, force password change, email, group

Only the firstname and lastname fields are mandatory. The rest can be left blank if not required. Also, only one login string can be entered on one line. The "recordable" and "force password change" fields can be set to "false"/"true", "0"/"1" or "no"/"yes". The "force password change" field, if set, forces the corresponding user to change their password the next time they login. This is mainly useful when defining new users.

There are two other global settings that can be configured when importing users: "Keep old login strings" and "Recordable". "Keep old login strings" allows you to select whether a user in the csv list that already exists in OrkWeb should have their login string(s) replaced by the login string in the imported file, or whether the new login string is to be simply added to that user's existing login string(s).

If a login string already exists in the database with different firstname/lastname, no action is executed.

Sometimes, the local party reported by the OrkAudio appears in OrkWeb in a format that does not meet your requirements, e.g. MAC address, IP address, ... In cases where this cannot be modified at a configuration level neither at the recorder level nor at the telephony platform level, Oreka provides you with a special tool to circumvent the issue: local party mapping.

To map the local party to an extension (or other) to meet your requirements, create or edit a localpartyMap.csv file in the OrkWeb installation folder, and add the entries following the example below:

          10.10.1.1, 1540
          10.10.1.2, 1541
          00:08:5d:13:19:a0, 3523
          SIP/SOFTHONE034, 3681
          ...

The first entry is what you want to replace, the second, is the target output.

Once this file is completed, restart Tomcat (or at least OrkTrack), for the new changes to take effect.

This is the same as the local party mapping above, but for the remote party. The file name is remotepartyMap.csv in this case.

Oreka may be configured to automatically provision users based on recordings, i.e. whenever a new recording is detected, its local party can be automatically provisioned in OrkWeb. This feature is mainly useful in active recording setups using SIPREC, whereby the decision of what users to record is pre-configured in the telephony platform, hence ensuring that auto-provisioning will only occur for required users.

To configure UAP, first the OrkAudio config.xml configuration file needs to be updated as follows (OrkAudio needs to be restarted for this change to take effect):

						
	<SipUAPlugin>
		<SipRecReportLocalNameAsTag>yes</SipRecReportLocalNameAsTag>
	</SipUAPlugin>
						
					

Then, the following setting must be enabled in the OrkWeb database:

						
	orkuserconfig.userAutoProvisioning = true
	orkuserconfig.uapNameSplitChars    = "_. "  or " "
						
					

The orkuserconfig.uapNameSplitChars field is usually required to contain a blank space.

The user first and last name will be obtained from the OrkAudio recorder typically in the format "firstname lastname", and will be parsed accordingly to provision the user.

Some important notes on how UAP works:

If you need assistance, please contact <support@orecx.com>> .

OrkWeb can be configured to act as a single sign on consumer, hence allowing user login based on authentication from an external platform. This may be complemented with user auto-provisioning (SSO UAP), which would automatically add/update the user to the OrkWeb database if SSO authentication succeeds.

When SSO is configured, users attempting to log into OrkWeb will be authenticated by the external platform instead of by OrkWeb. This occurs if the user already exists in the OrkWeb database as an "external" user and is not disabled, or if it is not in the database and SSO UAP is used (see section below). If the user exists as "external" but is disabled, login will be denied.

Two SSO sources (producers) may be configured for better reliability if needed. See ssoURL and ssoURLSecondary parameters below.

Here is a list of parameters to configure in the database to enable SSO functionality for Broadworks and LDAP:

						
	orkuserconfig.singleSignOn = true
	orkuserconfig.ssoType = "Broadworks"
	orkuserconfig.ssoURL = "https://xsp.bwvoip.net/com.broadsoft.xsi-actions/v2.0/user/$userId/profile"
	orkuserconfig.ssoURLSecondary = "https://secondary.source.com/v2.0/user/$userId/profile"
						
						

						
	orkuserconfig.singleSignOn = true
	orkuserconfig.ssoType = "LDAP"
	orkuserconfig.ssoURL = "ldap://ldap.forumsys.com:389/"
	orkuserconfig.ssoAuth = "simple"
	orkuserconfig.ssoPrincipal = "cn=$cn,dc=example,dc=com"
						
						

						
	orkuserconfig.ssoUap = true
						
						

If you need assistance, please contact <support@orecx.com>> .

Every user in Oreka belongs to one single security group which determines the access privileges for that user. Newly created users are implicitely associated to the default "Users" security group. There are 4 pre-defined groups in OrkWeb. More security groups can be created but it is typically much easier to adapt the existing security groups for your needs than to create completely new ones. The pre-defined security groups have sensible access policies defaults that are fine for most needs. Also, the pre-defined security groups cannot (and should not) be deleted:

Pre-existing security groups are:

Regular (non-security) groups can be useful e.g. for filtering or creating specific recording rules on a group of people. Users can belong to multiple regular groups. Groups can also be part of groups, thereby creating a group hierarchy of any depth.

When you click on the "view" link next to a group in the Admin/groups page, a "Managed Access Policies" button appears. Clicking on it displays the Access Policies definition page. You can create your own security groups and give them the access policies that you wish but it is easier to tweak an existing security group.

Users associated to a particular Security Group inherit that group's access policies.

In this example, call center agents shall be able to see their own recordings, supervisorA shall be able to see recordings for groupA and groupB, supervisorB shall be able to see recordings for groupB only. Here are the steps to configure this:

In this example, each end-customer is a company with several users and each company shall be mapped to a group. CompanyA shall be mapped to groupA, CompanyB shall be mapped to groupB. Within each company, one person shall be administering the system. Only this person might be abe to access the live monitoring system. It shall not be possible for any company user to see data for another company, or even know that it exists. Here are the steps to configure this:

In order to restrict what is recorded by Oreka, it is possible to create so-called recording programs from the Programs page. Those programs let OrkWeb administrators specifiy recording schedules as well as filtering criteria. Any number of these programs may be created to achieve high complexity recording rules.

Very important note: when at least one audio or screen recording program is active, recordings become subject to Programs and are no longer retained by default.

A program is initiated by a trigger event, which causes a set of criteria to be evaluated. If the criteria are met, a corresponding action is taken. Hence, the Programs feature's usefulness is not limited to selective recording. The criteria-based functionalities allowed by programs are:

The Copy, Move, Delete and Email recordings programs collectively define what we call the Media Manager feature.

Triggers are events such as a pre-configured time or the completion of a recording. Scheduled (time-based) triggers may be one-time events or repeatable triggers that restart at a given frequency.

One-shot triggers are configured by setting the "Trigger first execution" field. Recurring triggers also set the "Trigger repeat period (in days)" field which establishes the frequency of the trigger.

Only Media Manager programs currently use those explicit triggers. Audio recording programs have implicit triggers based on the completion of the recording process.

Criteria are conditions that are evaluated when the trigger event occurs. If met, they cause the program action to be executed. Examples of criteria are target user, target group, local party, remote party, ... The available criteria depend on the type of program in question. The "Handle as exclusion criteria" option ensures that the action is taken only if the criteria are NOT met.

The criteria list may vary between different programs. Local and remote party criteria where available, support regular expressions (as opposed to wildcards). For example, in order to retain all recordings made to or received from phone numbers starting by the digit 5,6 or 7, enter "[5-7].*" in the remote party field of your program.

Be careful with the Target group criteria: it applies to the recording's user's parent groups as well as all their subgroups.

Scheduled Media Manager programs include among other, the following criteria:

Actions are executed when the program is evaluated and the criteria are met. Actions may be one of the following:

Selective recording can be achieved with the Audio recording and Screen recording (scheduled) types of programs.

The basic Audio recording program will simply keep or discard a recording based on the defined criteria. The decision is made when the recording completes. Almost any recording metadata may be used as a program criteria including local party, remote party, call direction, duration, user associated to the recording, time of the recording, ... There is also a "recording percentage" criteria that ensures that only a certain random percentage of recordings is kept.

The Audio recording program may also be used to trigger screen recordings that are to be associated to the audio recordings with the "Trigger Screen Recording?" option. This option is only available when Screen Recording is licensed. In this scenario, when an audio recording starts, the program in question automatically triggers a screen recording. It also sends a message to the screen recorder to stop the recording when the audio recording completes, and associates it to the audio recording counterpart.

The other type of selective recording is Screen recording (scheduled) . This is for screen recordings only, and provides the ability to configure time-based trigger events for starting and stopping the screen recording (e.g. record only between 10AM and 2PM, or only on Thursdays, ...).

The Media Manager (MM) functionality provides a mechanism to apply certain actions to existing recordings. The Media Manager is essentially an extension of the File Manager and Auto-Delete functionalities. The File Manager and Auto-Delete are global in scope and do not permit the definition of criteria. The Media Manager on the other hand provides finer granularity functionality, with the addition of criteria-based execution.

These MM actions may be scheduled (time-based), or triggered when a recording completes. The latter is available for the copy and move programs, but not for the delete program (since it is equivalent to an Audio recording program that would not keep such a recording).

For copy and move programs, the actions are defined by the following parameters:

Delete programs have the following action parameters:

Below are but a few examples of the many Media Manager uses:

Since multiple programs may be defined, a legitimate question that often comes up is: what happens when a given recording meets the criteria of two or more programs? Which program(s) gets priority and which one(s) decides on the fate of the recording?

The answer is that it depends on the priority configuration. By default all deployments give priority to "negative" programs, i.e. to programs that would cause the rejection of a recording. Hence, even if many programs report that a recording should be kept, all it takes is for one program to reject the recording for it to be discarded.

This behavior may be reversed in the database configuration to ensure that one "positive" program guarantees that the recording gets kept.

All recording programs get evaluated for every new recording. When multiple programs agree that a recording should be kept, they all get associated to that recording.

When running multiple servers, it is necessary to use the standard replay mode or the centralized replay mode. This setting can be configured in the OrkWeb config page.

Standard Replay: use this if you want the client media players to stream the audio data directly from the OrkAudio server where it has been recorded.

Centralized Replay: use this if you need all audio to be relayed by the OrkWeb server. This can be useful when allowing access to OrkWeb on a public IP address where you need everything to go through a single TCP port (the Tomcat TCP port).

Simple Replay: This mode is only for single server deployments. This is the default setting.

If media files are served from a recorder (via tomcat, or apache httpd, or equivalent) using a port that is different from the default port 8080, make sure that the "File serve port" of the service associated with the recorder in question in config/services has the correct value. For more information on services, please see the section called “Services” .

Below are the instructions for how to configure Oreka to delete all media files in the system and their database info, if they are older than 180 days (approximately 6 months):

The "Stop Auto-Delete" button provides a quick mean for turning off this feature. It resets the "Delete files in filesystem" and "Delete entries in database" to Disabled, and "Wake-up period" to 0.

For deletion of remote files, an ssh server needs to be running on the remote server. Also, the corresponding service must be configured with the ssh parameters in OrkWeb, in the Config/services page. Refer to the section called “Services”

It is recommended to delete both files and database info with this feature. Deleting only database info leaves orphaned recordings that are neither easily accessible nor identifiable, while deleting files only and leaving the corresponding data in the database means that the Auto-Delete feature will unnecessarily re-attempt to remove already deleted files every time it wakes up.

The File Manager can run in one of two modes: real-time or scheduled. For now, these two modes are mutually exclusive. The sections below give more details.

It is possible to configure the media files path and filename as a combination of the following dynamic parameters. Note that the pathname refers only to the secondary part ( Secondary pathname ) of the pathname that typically defaults to year/month/day/hour/ .

The first step in setting up QM is to create one or more scorecards. Scorecards establish the criteria that will be used to evaluate a recording. Scorecards may include one or more sections which in turn may host one or more questions. Each question may allow several answers with a different score associated to each. Sections and question scores may also be weighted differently.

Other scorecard features are:

Creating a scorecard requires filling a CSV scorecard template file. Please refer to the section called “How do I configure a scorecard for QM?” for more details on the format of the scorecard CSV file.

If a scorecard needs to apply to more than one group, one of two approaches may be used:

Once a scorecard is created and configured to be associated to a group, it may be imported in OrkWeb in the Admin/scorecards page. Errors in the scorecard are detected and reported by the import function, and will cause the entire scorecard to be rejected.

To "score" a recording, click on the scorecard icon in the OrkWeb "Browse" page or go to the recording details page and select the "Scorecards" tab. OrkWeb looks for the group(s) associated to recording's user, and makes any scorecard template associated to that user's parent groups available for the evaluation. Once the call is “scored”, the scorecard results may be saved for later review as well as for generating QM statistical reports.

Reporting on QM is possible through several reports with the ability to define a slew of filters for greater flexibility. In fact, all search filters that are available in the Browse are applicable to the QM statistics reports below. Reports may be generated in 3 formats: PDF, HTML and CSV unless explicitely specified otherwise. Here is a summary of the types of reports available:

Securing access to media files in Oreka ensures that only users legitimately logged in to OrkWeb are allowed accessing the files. To configure this protection level, two configuration actions are required:

Secure access to OrkWeb uses SSL, and requires that the URL to the application rely on https instead of http. To configure this functionality, simply edit the web.xml file stored under $tomcat/webapps/orkweb/WEB-INF , and modify the line:

					
<transport-guarantee>NONE</transport-guarantee>
					
				

to

					
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
					
				

After this change, access to OrkWeb becomes https://localhost:8443/orkweb . If you continue using http://localhost:8080/orkweb , you will be automatically re-directed to the new https URL.

Note: the change above assumes that Tomcat was installed by the OrecX OrkWeb installer. The installer performs some customizations to the Tomcat server.xml file to make the functionality above accessible. Contact <support@orecx.com> if your server.xml file does not contain these customizations.

The following foreign languages are currently included in OrkWeb:

For other languages, please contact <support@orecx.com> .

The selection of the OrkWeb language usually occurs automatically by default, and depends on your Operating System language. For example, if you are running the Spanish version of Windows, OrkWeb will appear in Spanish by default.

If you would like to change the displayed language, you would have to use the Language Options in your Browser as described below:

In Internet Explorer:

In FireFox:

If you wish to brand your application by simply changing the logos that appear in orkweb, all you need to do is modify the 3 files under $tomcat/webapps/orkweb/images: application-logo.png , company-logo.png and company-logo.jpg . Make sure to keep copies of those files in case you upgrade orkweb in the future.

Otherwise, customizations of layout, style and color are a simple matter of tweaking html/css/icon files by a web designer. css files are found in $tomcat/webapps/orkweb/css. icon files are found in $tomcat/webapps/orkweb/images and can be modified with a tools such as Phostoshop. It is also possible to modify application html files in $tomcat/webapps/orkweb/WEB-INF e.g. for inserting proprietary content or tweaking the layout. If you do this, you will need to ensure that such changes are re-applied to any future upgrade of orkweb (refer to the next section).

Any modification to OrkWeb will need to be re-applied every time a software upgrade is performed. Tools such as diff and patch might help for automating the application of small changes to html and css files, and this, even if the upgraded html and css files have been altered by OrecX since the software version you had customized.

For example, to access the application as http://server:8080/myrecorder instead, here is the procedure:

To access the OrkWeb application without specifying a port number in the URL, such as http://servername/orkweb instead of the typical http://servername:8080/orkweb , you will need to either replace the Connector entry in Tomcat's server.xml configuration file for port 8080 with port 80, or simply copy and paste that connector to a new one for port 80, the default Tomcat port. If there are any other references in that file to port 8080, they also need to be modified (or duplicated) to use port 80 instead.

Most likely, the database server is down or there is something wrong in the database URL and credentials in the database.hbm.xml configuration file.

If you fail to replay recordings through OrkWeb, here is the checklist:

You need to add at least one login string for the user. Users can log into OrkWeb using any of the login strings they own. For more details, please refer to the section called “Login Strings”

Make sure the end date in the multi-criteria search form is not in the past.

Verify that the database indexes were created properly. For a list of indexes, download the script at create_indexes.sql . If the indexes are missing in your database, you will need to run that script. Usage syntax is explained in the header of the file.

Indexing on a large database may take serveral minutes. Hence, it is highly recommended it be done during off hours, when Tomcat is not running.

# Oreka sample scorecard CSV file: Scorecard_Generic_Example2_Sales.csv  
# Below 
is a summary description of the fields required:
#
#   Scorecard,name,comments
#   Group,name
#   Section,name,weight,comments
#   
Question,name,weight,comments 
#   Answer,text,value,excluded,autofail,comments
#
Scorecard,"Sales QA 
Form",
Group,"Sales"
#
Section,"Opening Call",,""
Question,"Professional Greeting - Intro",,""
Answer,"No",0,,,
Answer,"Yes",1,false,false,""
#
Section,"Information 
Verification / Data Collection",,""
Question,"Verify Zip Code",,
Answer,"No",0,,,
Answer,"Yes",1,,,
Question,"Collect 
Name",1.0,""
Answer,"No",0,,,
Answer,"Yes",2,,,
Question,"Collect Phone Number",1.0,""
Answer,"No",0,,,
Answer,"Yes",2,,,
Question,"Verify 
if Existing Customer and if Residence or Business",1.0,""
Answer,"No",0,,,
Answer,"Yes",2,,,
#
Section,"Establishing 
Purpose of Call",1.0,""
Question,"Reason for Call",1.0,""
Answer,"No",0,,,
Answer,"Yes",1,,,
Question,"Lead 
Source",1.0,""
Answer,"No",0,,,
Answer,"Yes",4,,,
#
...