Users and classes can be added, modified and deleted right from QM.

A list of users is presented and you can filter it by class or user name.

For each user, the login and full name are shown, together with the current class and any additional user keys. A user must be enabled in order to log on, so if you want to prevent somebody from logging on without deleting its user information, you can simply disable it. A number of default users are shipped with Enable: No in order to prevent unauthorized access.

The list of users is paged and you can use the top box named "Filter" in order to search for a specific user or a set of users that match the entered substring. You can also click on the column name to toggle ascending versus descending sort order.

The "Create new" button lets you add new users while the "Show classes" button leads to the class editor.

When you add or edit a user, you are presented with a list of fields to enter:

The "wizard’s hat" icon located under the User keys field opens a popup where all available pre-defined security keys are listed together with a description. By clicking on each checkbox is possible to assign/unassign the associated key to the user. The wizard helps the administrator to generate a valid keyset by computing key dependencies and/or uncompatibles key pairs and checking or unckecking keys accordingly.

Keys inherited from the class where the user is belonging to are greyed out. Is, moreover, possible to uncheck an inherited security key thus generating the proper negative definition for the edited user.

Flying over a checkbox with the mouse, a tooltip containing the associated security key value is shown.

Pressing Save closes the wizard and updates accordingly the User key list in the user definition page.

User classes can be configured freely; you can create individual key rings with special privileges to best suit your needs.

Each class has a set of keys that can be freely edited in much the same way as users by clicking on the "edit" icon (the pencil).

No class can be deleted as long as there is at least one user that is member of it.

The default classes should be enough to get most systems started:

Since version 18.04, QueueMetrics allows for user passwords to be encrypted, in order to guarantee greater security.

To manage the process of password encryption, two new system parameters have been added to the system configuration.

The first parameter, pwd.minAllowedLevel, dictates if the system allows users with non encrypted passwords to access the system. The two different behaviours are associated with two different values for the system parameter:

The second parameter, pwd.defaultLevel, indicates if the new passwords that are set will be encrypted or not. When saving a new password for a user, this property decides if the password is to be encrypted:

To encrypt a user’s password, the system administrator should first set pwd.defaultLevel to a value of 2 then, by accessing the Edit User page, a new password for the user must be set. With QueueMetrics 18.04 the user editing page has been modified to include a password confirmation field.

When the new password is set, and the modifications are saved, the new password will be saved as an encrypted password.

A list of queues must be set before accessing QM. Each queue can be made visible to only a specific set of users by adding a key - this can be useful if, for example, each queue has a manager viewing data for it, while only a CC manager sees data for all queues in the center.

You can search for a specific queue by entering data into the Filter box on top of the page, or change the default sort order for the list by clicking on one of the column names.

The default page shows:

The pencil icon will let you edit the queue, while the "People with pencil" icon lets you change queue associations. The 'pie chart' icon at the end allows to define/assign the set of queues on which agents can run reports. No specific key or property are required, but this feature is only available as of QueueMetrics version 12.10. For an administrator to make this feature available for the agent, it is necessary to have at least one queue and a report assigned to the agent.

For each queue you have to define:

By clicking on the Agents icon, you can define the position of each agent as a member of the service groups for that key. An agent cannot be a member of more than one group per each queue s/he is a member of.

It is of course perfectly legal for an agent defined not to be used in a specific queue.

To enable AMO (Assisted Manual Outbound) calls on a queue, you will need to open the Queue Settings page of a given Queue, and set the "Enabled" flag to "Yes" in the "AMO Settings" section.

This will mark the queue as an AMO queue, which will reflect in the Agent Page by showing the AMO tag on the selected queue.

Other important setting you can configure here are:

Once the AMO queue is configured correctly, you can move to the AMO editor, where you should immediately see the Queues that are AMO enabled, listed as AMO Campaigns (Each queue counts as a single AMO Campaign).

Clicking on the Queue name will navigate you back to the Queue Setting for the Queue associated with that AMO campaign.

Clicking on the pencil icon will navigate you to the List editor for that specific AMO campaign, where you can work on the list of numbers linked to the AMO Campaign in question.

Here, you will see a list of AMO lists that are related to the currently selected AMO Campaign. You can always navigate back to the AMO campaigns list by clicking on the "< Back" button in the top-left of the screen.

Clicking on the pencil icon will navigate you to the editor for that specific AMO list. Here, you can edit the list itself, see its usage statistics, and upload numbers by uploading a CSV file.

The most convenient way to upload numbers into an AMO list, is to use the "Upload Numbers" button in the List editor. This will open a modal that allows you to drag and drop or click to upload a .csv file containing the numbers in question.

By clicking "OK", the file will be processed and uploaded to QueueMetrics, adding the numbers to the current list.

Agents should be configured so that they:

When editing an agent, the following screenshot appears:

For each agent in use, enter:

If you want an agent to log on to their own page, you also have to create a user with the same name.

On the bottom of the page, the current association of that agent to a set of queues is shown.

The Agent Detail page is accessed by selecting the "Edit agents" link on the QueueMetrics Home page and then clicking on the "Edit" icon for a specific agent.

The following configuration transaction lets you define locations for your agents. To access this page, a user must be holding the USR_LOCATION key.

Each location has a short name, a longer description, and a visibility key, so that only users holding that key may select that location as a source for reports.

A location cannot be deleted if at least one agent is defined for that location.

We define a call outcome as a flag to be added to a call, either when the call is ongoing or when the call has just finished, that will signal the result of the call from a business point of view. Such a flag is optional for QueueMetrics and can be added to both incoming and outgoing traffic.

The call outcome will be defined by a numeric sequence that the agent will either key in on their telephone terminal or report through QueueMetrics itself through the Agent’s page. QueueMetrics will not consider how the sequence is entered, as long as it’s present in the queue_log data it runs on. Such records can be generated, for example, by an outbound dialler that is able to pre-screen answered traffic.

To minimize internal searching costs, the call activity must be entered either while the call is in progress or within one hour of its completion. If more than one call activity code is entered, the latest takes precedence over the previous ones.

As you can see, each outcome can set two flags: a "This call qualifies as contact?", "The call qualifies as Qualified Contact" and a "This call qualifies as sale?" flag. This will be used in order to produce statistics on traffic (see section How are Call Outcomes calculated?).

If a call code is found but not defined through the configuration screen, QM will report on it and treat it as a "No contact" and "No sale" call.

The editor page lets you set:

For call centers that require to analyze agent performances at a level below call outcome, the concept of feature codes has been added since QueueMetrics version 15.09. A user can think about feature code like a sub-outcomes. They can, optionally, have hierarchical relationships with the primary outcome code. A simple example of the feature code concept is the pair of outcome/feature like "Not Interested"/"costs too much". A call may have an unlimited number of features associated with. Some features may be flagged as goal. Goal features are counted separately and generate separated statistical figures in reports.

Editing feature codes requires holding the key USR_OUTCOME.

By clicking on Create New button or on the pencil icon present on each feature code row in the list, a user can create or edit an already present feature code.

As told before, tag features can be linked with a specific outcome code set. To link a feature code with a specific outcome or set of outcomes, a user should select the outcome from the dropdown, then click on the Add button. The list of already associated outcomes are shown below the dropdown. To remove an outcome association, a user should select the proper outcome from the dropdown, then click on the Del button.

Clicking on Save updates the feature code on QueueMetrics database.

Some call centers require to report call set at the list level below campaign. This is frequently used for outbound campaings. The idea is to add the concept of generic tag to calls, so that, if assigned to each calls, it could be used to create a new level of reporting, parallel to the queue. When each call is associated to a single tag, the queue would be the physical medium for handling calls, while the tag could bee freely set. Imagine, for example, to set up a special number for a Tv Ad, or a printed advertising, that makes it possible to discriminate where the caller saw the Ad. Tags are set by the system (i.e. there is no way for QueueMetrics to add a tag on a specific call but is up to the PBX/dialplan to add a tag signature in the queue log); for more information on that, please refer to this paragraph. Tags associated to a call will be shown by QueueMetrics and decoded following the tag list defined by the administration page, as reported below.

By clicking on Create New button or on the pencil icon present on each tag code row in the list, a user can create or edit an already present tag description.

Tags definition/listing is available only for users holding the USR_CALLTAG security key.

The agent’s time is defined in QueueMetrics as made up of different activities. The main activity for an agent will be "Available time", i.e. the time when an agent is ready taking or placing calls. When an agent pauses out of "Available time", they may want to flag the reason for the pausing, e.g. doing backend activities, lunch, etc. This way you can track agent activities punctually. If they don’t flag a pause, it will be computed as simply "Pause" time.

Each pause code is written on the queue log while the pause in progress, i.e. after the agent goes on pause and before the agent stops that pause. The pause code will usually be defined by a numeric sequence that the agent will either key in on their telephone terminal or report through QueueMetrics itself through the Agent’s page. QueueMetrics will not consider how the sequence is entered, as long as it’s present in the queue_log data it runs on.

For each pause code, it is possible to tell QueueMetrics whether that time is:

All activities are optional and may be added or deleted at will. The following fields apply:

An agent group is an attribute that is applied to an agent in order to keep track of their life-cycle. This is used as a filtering criterion in QM and is developed in the QA monitoring subsystem.

The idea here is that you can have e.g. "New hires", "Regular agents", "Expert agents"; each agent group has a different icon, that is displayed throughout QM whenever the agent name is displayed.

You can select different icons by clicking on them in the editor.

Skills are attributes that can be associated to a call and can be used to implement somethig useful like skill based routing on Asterisk queues. QueueMetrics reports can be filtered by a set of specific skills through the custom report page. Skill codes can be associated to labels through the skill configuration page available to all users holding the USR_SKILLS security key.

The list of available skills can be reached from the main page.

Clicking on the Create New button or the pencil icon on each skill reported in the table, is possible to create or edit a skill entry.

Apart from the skill code and the description for the skill that can be defined, a field named Sort Weight can be found. The weight field is used to define the order in which skills will be shown in report columns. Skills with a lower weight will always be placed before skills with a higher weight. If two skills have the same weight, they will be ordered based on the alphabetical order of their description.

The Visibility key field indicates that a user must possess the chosen key to use this particular skill.

Known numbers are phone numbers that are known to QueueMetrics and can have properties associated to them. They are meant to be used by the numberLookup API in order to implement strategies based on the calling number - see Using known numbers - and will be used to "improve" the display of said numbers as described in Displaying numbers.

QueueMetrics will use "known numbers" to:

In order to access this page, users must hold the security key USR_KNUMBERS.

When editing a record, you see a form like the following one:

The editor will track:

The editor will also display, in read-only mode:

The set of current QA forms can be configured through the QA form editor. It shows the current set of defined forms and lets you performs the usual operations (search, filter, sorting, paged listing…​).

The names of each section and the number of items that have been input for that form are shown on the front page. If a form has any number of items input, it is considered "locked" and cannot be modified anymore, though you can create a different form with the same set of items.

The form editor looks like the following page:

You can enter:

To edit the set of items that belong to a form, you should have no data reported for that form. If you have no data, the item editor icon will show from the main form page.

The editor looks like the following page:

To add a new element, just select an element on the top form and a section it should be added to.

On the main part of the page, you can edit the elements by changing them, moving them up or down and removing them.

The "Active if…​" field allows to enter a dependent rule, as described within the following chapter: "Handling dependent questions".

The Extra Score checkbox allows to give extra scoring to a particular question, in order to highlight an agent’s higher performance within a specific section, or to balance his/her averages. The question in the form will have two main characteristics: it can have a score above the 100 standard value (up to a maximum of 120) and the score assigned to the question will not be calculated within the denominator part, when totalling averages for the specific section and the overall QA form.

The "Non Scoring" checkbox, if checked, forces the engine to ignore the inserted question score when calculating the section and form average. Questions flagged as "Non Scoring" are not classified as "under or over performing items" in the QA form. Non scoring questions are aggregated on reports based on the number of times a particular score is found in the query period.

As explained above, in order to track performance you first have to express a set of business targets that express what is expected from your agents and how much deviations from each rule are comparatively worth, expressed in review points. This is called a ruleset.

This can be done through the proper configuration page by users holding the key "QA_PERF_RULES"; they will see a new link from the home page:

Selecting the link, a new page is shown listing rulesets already defined. In order to define a new ruleset, you press the "Create New" button.

The "Create New" button opens a new page where an empty rule is shown, like in the picture below.

The creator should assign to the new ruleset a name, a short description, and optionally a security key.

A rule is usually linked to a specific queue (or set of queues) and form. This is because we expect to have homogeneous statistic distributions in the same queue and form items. This might not be true outside a specific form and/or queue. The user should select a specific queue and form before pressing "Save".

A rule set can be inferred from the measured properties of a given data set; this basically lets you express differences in terms of a percentage of outliers expressed on the total number of calls.

In order to access the wizard, you click on the "pencil" icon:

In this modal dialog you define a start and end time period and the "yellow" and "red" percentage of calls the user wants to include in the resulting rule, the type of interval (internal or external) and whether the interval extreme values should be included or not in the resulting rule.

The "Go compute" button runs an internal analysis that reports, in the lower right table present in the dialog, the minimum and maximum values representing the interval fulfilling the inserted parameters and the number of calls analyzed. You can repeat the calculation until satisfied, then press "Save" to insert the rule in the rule-set or press "Cancel" to forget it.

Users holding the key USR_CUSTOMBLOCKS_EDIT can edit the list of Custom DataBlocks.

Since Version 22.11, QueueMetrics allows the user to create their own Custom DataBlocks, by specifying a source and a list of columns to show.

Custom DataBlocks are filtered views of existing DataBlocks. For this reason, these DataBlocks need to be based on an existing DataBlock (including another Custom DataBlock).

When creating a new Custom DataBlock, the user needs to input the following options:

Users holding the key USR_REPORTS_EXPORT_EDIT can edit the list of PDF and XLS export jobs.

Each job is associated to a specific query period, queue and report set meaning that, each time the report is run, QueueMetrics calculates the results based on the input parameters and exports the whole report set to the required format. The generated document is sent to the recipients list specified for the job. Each job is identified by a numeric id generated by QueueMetrics and shown in the Id column. As defined in the chapter Generate PDF and XLS reports and send them by e-mail this id has to be used to run the report by an external ROBOT profile.

The user can edit a specific job, by clicking on the pencil icon, or can run it immediately, by clicking on the blue button shown on the list.

Each time a user creates or edits a job, the next screen will be shown:

On this page the user is allowed to specify a title, needed to identify the job in the job list, and other relevant parameters like period, queue, report name (an already defined report set), report type (XLS or PDF) and the orientation (valid only for PDF documents). Each reports export job could be associated to optional visibility keys used to hide/show the job to a set of users. Finally, a list of e-mail recipients can be added - if present, on generation, the resulting report will be sent to them.

If an export job is included in a scheduled job, a clock icon will appear next to it in the export jobs list page. By clicking on the clock icon, the user will be taken to the scheduled jobs list where he can view the various scheduled jobs.

Users holding the key USR_CRONJOBS_EDIT can edit the list of available scheduled jobs.

Each Job represents a specific task, chosen between those available, that will be executed automatically at a specific point in time, or regularly at set intervals of time. The user can also specify particular days of the week or days of the month as a requirement for executing the job.

The user can edit a specific job, by clicking on the pencil icon shown on the list.

Each time a user creates or edits a Scheduled Job, the next screen will be shown:

On this page the user is allowed to choose a job type, and other relevant parameters like the time, the day requirements, and if the job is enabled or not.

One relevant parameter here is the "When" parameter. If this parameter is set to "Cyclical", the selected "Every" value will be intended as the interval between different executions of the Job. If "When" is set to "Once a day" instead, the "Time" value is intended as the actual time of intended execution.

So for example,

Another relevant parameter is the "Day of Week" parameter. If we select only "Monday" for example, the Job will be executed only on mondays.

The same goes for the "Day of Month" parameter. If we choose 2,5,13 for example, our Job will only be executed on the 2nd 5th and 13th day of the month.

The "Day of Week" and "Day of Month" conditions are mutually exclusive, so if we set "Monday" and then "5", our "Monday" choice will be deleted and the scheduled job will only consider the Month Day option "5".

The "As User" parameter indicates which user will be impersonated when the Job is executed automatically. The user can only set itself as the user or, if the user is editing a Scheduled Job created by another user, the creator of the Job.

Users holding the keys USR_IVR and USR_DNIS can edit the list of known IVR and DNIS names.

This list is used to decode the display of known IVR selections and DNIS numbers. Both configuartion pages behave the same way.

Elements that are not listed in the editor are displayed with the string they are recorded with at the Asterisk level.

IVR entries are also used to decorate IVR menus in IVR path traversal analysis. You simply add the name of the IVR menu and the decoded value.

Users holding the key USR_CBTS can edit the list of known CBT URLs and names.

This list is used to populate the selection of available CBTs and to define the common URLs will be used in the task detail for each CBT sent. The URL can be used to point to any kind of material, as appropriate (e.g. PDFs, videos, interactive courses…​). The URL may include a [U] token field that will be substituted with the login of the agent filling in the CBT, so that an external CBT system may keep track of why is filling it in or personalize the courseware.

Each CBT includes a read-only field that tracks the number of times the CBT was sent; this value is reported in the CBTs list. CBTs can be set active or not, so it’s possible to put CBTs off-line when they become obsolete.

Clienst and Cases act as a kind of mini-CRM within QueueMetrics; they can be created by agents and supervisors, and can be easily added to calls through the Agent’s page - to see how it works from there, see Clients and Cases in the Agent’s page.

They share a set of common principles:

Both Cases and Clients will appear in reports, under data block show in Historical reports - Cases and Clients.

It is possible to view details of calls (answered, unanswered) in a paginated order, rather than as a long list of data on a single page, allowing better readability when running a large result set.

To set this up, from the Home page you select "Edit Reports" which leads to the Configure QueueMetrics reports" page (Cfg Reports tab). Click on the "All reports" link and you will be shown all current reports. At the bottom of the screen select "Create New".

Enter a Short Name such as "New" and a Title such as "New Blocks" - you can choose different Name/Title if necessary. Also, the Visible in All Reports field should be set to "Yes". Now Save it.

Go back and select "New Blocks" which leads to the "Report: All Reports >> New Blocks >> Items" screen. Select "Create New".

Save it and select "Back" - you will now see the newly-created item.

If we run a Report we will see a new tab called "New", as shown below, where the calls are showing in pages, rather than as a listing (note the buttons to go forward/back and that the page is 1 of 2 pages)

In the image above, on the bottom right of the paginated list we can see a small icon just before the "next page" buttons. this icon allows us to add or remove columns within the displayed paginated listing. It is now possible to add the Music on Hold (MOH) columns "MOH events" and "MOH duration" which display the number of events where a caller was put on Hold with music and the total duration of such events. You can also add the columns "IVR duration/IVR path" which displays the time the caller spent within the IVR selections and the choices the caller made while going through the process. Adding the "DNIS" column allows to display the number dialled to reach the queue.

Configuring the new realtime page involves to set some configuration keys that are inherited from the old agent realtime page and a new set of keys specifically designed to operate with the new realtime page. This chapter summarize the most relevant keys needed to properly configure the new realtime page and the integrated softphone. For more details on each key, please refer to the Appendix C: System preferences

Enable/Disable the hotdesking:

A value different than zero enables the hotdesking.

Defines a custom CRM page that will be open on each new taken call:

Defines two other optional custom backgrounds:

Optional backgrounds can be opened as popups by setting the property agent.openUrlInPopup to true in the Edit System Parameters page.

Custom background pages can also expand a set of placeholders that carry useful information.

If CRM and/or custom backgrounds are not needed, it’s possible to override the default background changing the key:

In order to use the integrated softphone, the steps required are: 1. Configure the SIP server and the WebRTC URL 2. Add, for each agent, a SIP username, password and SIP Realm authentication.

Depending on our setup (normal or clustered mode), the SIP server and the WebRTC urls are set by changing the below configuration keys. For a not clustered QueueMetrics install:

For a clustered QueueMetrics install, be sure you’re setting the following keys for each server in your setup:

Then, for each agent, set the SIP username, password and SIP Realm authentication through the Agent Configuration Pages, as explained in Configuring agents

The Logon Panel allows to pre-validate the agent code and the agent extension needed by the login/logout process. In order to validate these codes, a two set of keys have to be set:

The Logon Panel allows to mark as read only the agent code field. This could be accomplished by setting the following key:

The list of available queues for each agent is defined by the following key:

Relevant values for this key are:

Agents can insert pauses through the Pauses panel. Pauses without a specified pause codes can be rejected by setting the following key:

Agents can grade taken calls only if they hold the QA_TRACK key.

In order to save time and make sure that QM is always up-to-date with the underlying Asterisk configuration, it is possible to run a wizard that will load the following data straight from Asterisk configuration files:

It is also possible to automatically create users out of the defined agents, so that they can log-on to QueueMetrics with the very same password they use to log-on to Asterisk.

In order for the wizard to be run, the user must hold the grants to administer users, edit queues, edit agents, and must hold the CONFIG key too.

If the user holds the required keys, the label "Setup wizard" will be shown on the front page:

By clicking on it, the administrator will be lead to the first step of the wizard.

At the top of this page is a dropdown menu that defines where asterisk configuration could be found. Actually the wizard is able to read information from:

By selecting the "File" source, the three edit boxes will let the administrator able to specify the local paths for the agents.conf, queues.conf and the users.conf file.

By selecting "Queue Log File" as source, the associated edit box will let the administrator able to specify the local path for the queue_log file.

For sources different than "File", or "Queue Log File", the wizard will use some configuration options to know how to reach the required information. More details can be found in Configuring system preferences and in Appendix C: System preferences.

When you have selected the source you want to be read, click on Next button. You will be redirected on the validation page. This page will inform you if the provided sources were succesfully read or, in the worst case, it will show you a message reporting an explanation of the error found.

If the validation fails, clicking on Next button you’ll be forwarded back to the first step, otherwise, you’ll be redirected to the next step.

The wizard will scan the available agents and presents you a list of agents to be created or updated. By default, this wizard will try not to modify an agent or a queue that is already present in QM, that is the found data will be shown but unchecked. Check on the items to include/exclude them as needed.

If no agents will be selected, by clicking on Next button the wizard will skip the next step and will forward you directly to the queue selection step. If at least one agent was selected, instead, when you click on Next button you’ll be redirected to the window shown below.

If the corresponding QM users, for selected agents only, are not present, they are created automatically by this mask.

Please note that if the wizard is not able to read the password associated to a specific user (because the password is not specified in the configuration files or because the wizard is reading information from AMI or realtime, or the queue log file, where password for agents are not shown) it will use the following rules:

The queues will be created or updated as needed; existing queues will not usually be overwritten without explicit user permission.

If you click to the Next button you’ll be redirected to the page above reported. This page will display a summary of the QueueMetrics database updates that have been scheduled to be performed. Clicking on the Yes button, the scheduled actions will be run and you will be redirected to the last page where a table listing the related operations results will be presented. Clicking on No button, instead, you’ll be forwarded back to the first wizard step.

The QueueMetrics database is now updated with the information found in the selected sources. You can go back to the home page clicking on Next button.

QueueMetrics could be updated and configured by means of external http queries made in a known format. This is really interesting for setting up a cron job to be completed sometimes during the day. When QueueMetrics receives external http queries, it will perform all the configuration wizard steps together (see QueueMetrics configuration wizard) assuming default answers. This will result in a background synchronization between your asterisk boxes and the QueueMetrics database. To be able to run periodic QueueMetrics update, you need:

The URL to be used to start the unattended configuration system has to be formatted as follow:

The meaning of specified parameters is below reported:

The user, pass and stype are mandatory; the other parameters are optional and have no meaning when the requested source is different from "file".

The other parameters are:

When QueueMetrics terminates the procedure, it will answer with a result page where the term "SUCCESS", or "FAIL", will be present reflecting the operation success status. In this page will be also present a list of the performed operation (and their result status). An example page is reported below:

System preferences are stored on a database table, and can be edited either though a guided transaction or through a free-form page. You can check the current set of system preferences from the Using the DbTest Diagnostic Tools page.

A complete list of preferences recognised by QM can be found in the chapter Appendix C: System preferences.

Once a preferences is changed, it is enough for the user to log off and log on again; restarting the servlet container is not needed.

Once your copy of QueueMetrics is correctly installed, the Queue Runner can be run using a script that is available as WEB-INF/mysql-utils/agaw-runner/agaw-runner.sh under the QM directory.

This file must be edited to set its running parameters, that are:

Path to the java virtual machine. Please point to a Java JDK version 8 or newer (OpenJDK is fine). The default path points to the default JDK that comes with the automatic QueueMetrics installation.

The options for the Virtual Machine. Should be okay for most servers.

The username and password of a user the transactions will be run under. This should be a regular user or an administrator with visibility to all queues to be selected.

The JDBC URL to connect to the same database as the main QueueMetrics instance (see your web.xml file).

The system path to the local QueueMetrics installation. You can find it on the local Licence page.

The number of iterations that will be run by the Java process before terminating and spawning a new Java process. This is done so that there is no problem with potential memory leaks, as the JVM is periodically rebuilt. A higher ITER count means more iterations using the same JVM and avoids the burden of reloading classes and libraries.

The idle time in milliseconds between one interaction and the other.

If RUNLOG is set to TRUE, a detailed run log will be created under the RUNLOGDIR. This directory must be writeable by the Java process and MUST be cleaned periodically - enabling this feature causes a lot of information to be written. See Debugging with Runlogs.

These are the names of the Java classes bundles that contain the local version of QM and of its TPF architecture. These must match the ones under WEB-INF/lib or you will get "Class not found" errors on startup. In a standard QueueMetrics release, QMARCH and QMJAR items are correctly set by the build system to match the current JARs.

This points to the servlet API used by your Tomcat installation. The default path is okay for a standard QM installation.

Once you set everything up, you can simply set the script executable and start it to see its output.

Please note that the script will loop indefinitely, so it must be stopped through a kill -9 command.

The DbTest page, available at the address http://127.0.0.1:8080/queuemetrics/dbtest , will not only let you update the database, but also check a number of QueueMetrics subsystems. It is invaluable for debugging QueueMetrics installations where you suspect some problem may be.

It is also possible to access this page directly from the QueueMetrics home page by selecting the 'System diagnostic tools' link, which can be found within the available Administrative tools.

QueueMetrics keeps track of a number of activities that happen on the system; for example, every time a user logs on or off, this fact and the related IP address is added to the audit log. The same happens when the configuration is modified or large reports are run.

Administrators who hold the key USR_SYSLOG can access the audit log from 'Home Page' → 'View Audit Log'.

The page displayed is very simple; it allows searching in a given date range, by a substring of the values that appear on screen, and by "family" of events.

A number of different records are tracked throughout the system - see the Appendix for complete details.

Since QueueMetrics 20, the User Information page will allow each user to select his own theme, based on a selection of available themes.

System administrators are able to set a default theme for all users, by setting the following system property:

This property decides the default theme for ALL users.

Example values for the property are:

or

where default, dark are Theme IDs.

If the propery is empty for whatever reason, it will always revert back to the value "default".

If the theme name is not available to the user (For example the name is spelled wrong, the "default" theme does not exist, or the selected theme was removed), then a fallback theme will be provided (See Below).