Jump to: navigation, search

Reporting Server

The Reporting Server component of GVP provides a comprehensive view of the calls serviced by a GVP deployment. The Reporting Server receives data from the Media Control Platform for VoiceXML applications, from the Call Control Platform for CCXML applications, and from other components involved in servicing a call, such as the Resource Manager.

The Reporting Server is one of the key components of the GVP logging and reporting feature, which is referred to as GVP Reporting.

In GVP 8.1.2, the Reporting Server is an optional component. See Options to Deploying VP Reporting Server.

Reporting Server 8.1.3 and above are backwards compatible with 8.1.1 and 8.1.2 reporting clients.

This section provides an overview of the following topics:

GVP Reporting Architecture

GVP Reporting uses a client/server architecture. The figure below illustrates the GVP Reporting architecture.

Figure: GVP Reporting Architecture


GVP Logging

  • Each component, or GVP Application object, uses a GVP Logging interface to emit call and logging events that are related to component activity and to route the logs to one or more log sinks. For more information, see Logging and Reporting. An API that is used by each call-processing component (Media Control Platform, Call Control Platform, or Resource Manager) submits logging, reporting, service-quality, latency, and Operational Reporting data, such as:

    CDR Service

    • Call Detail Record (CDR) Service, through which the components submit CDRs that contain specific call information such as start time, end time, and the IVR Profile and tenant that are associated with the call to the Reporting Server. For more information about CDRs, see CDR Reporting.

    OR Service

    • Operational Reporting Service, which accumulates call arrival and call peak statistics. (These statistics are applicable for the Resource Manager, Media Control Platform, and Call Control Platform.) For more information about Operational Reporting, see OR Service.

    SQ Reporting Service

    • Service Quality (SQ) Reporting Service, in which the Media Control Platform generates INFO-level logs that are used by the Reporting Server to generate SQ and latency calculations and call-tracking information. For more information about Service Quality Reporting, see SQA Service.

      Service Quality reports apply to NGi VoiceXML applications, and are found in Genesys Administrator. GVP 8.1.5 and above are NGi-only platforms unless you run MCP 8.1.4 to incorporate support for GVPi applications.

VAR

  • A <log> tag interface supports the Voice Application Reporter (VAR) reporting product, which is delivered by the Reporting Server. The <log>tag interface enables users to demarcate their VoiceXML applications into logical transactions, and to assign success or failure either to individual transactions or to a call as a whole. The <log> tag interface also provides a means of attaching application-specific data such as call notes and custom name-value pairs to calls.

The Reporting Server accumulates summary statistics based on the processing of appropriately formatted VAR <log> tags. The summary statistics that it derives are accessible through web services and Genesys Administrator.

For more information, see VAR Metrics. For more information about how developers can use Composer to customize the VAR and SQA reporting features, see Customizing SQA and VAR by Using Composer.

Reporting Server

  • The Reporting Server stores and summarizes data and statistics that are submitted from the Reporting Clients on the call-processing servers, to provide5-minute, 30-minute, hourly, daily, weekly, and monthly reports.

The Reporting Server manages the following types of data:

  • Call-detail records
  • Call events
  • Call arrival and peak data
  • Usage-per-IVR Profile data
  • Usage-per-tenant data
  • Service-quality (SQ) summary statistics
  • SQ latency histograms
  • VAR summary statistics

The Reporting Server receives data from the Reporting Clients on a TLS socket, which can be configured by using the options in the messaging section of the Reporting Server Application. See the section "Important Reporting Server Configuration Options" in the GVP 8.1 User's Guide.

For more information about the Reporting Server, see Reporting Server.

One Reporting Server in a GVP deployment can provide adequate call-data management; however, high availability configuration for Reporting Server, which is supported in GVP 8.5 and later releases, requires two Reporting Servers.

For more information about HA for Reporting Server, see High Availability and Scalability.

Customizing SQA and VAR by Using Composer

The SQA and VAR features represent two separate reporting features; the first forces an SQA failure, the second defines a VAR call result. If you are customizing these features by using Composer, keep the following information in mind:

SQA

  • If a VoiceXML <log> tag is logged with the label com.genesyslab.quality.failure or com.genesyslab.quality.failure, the session is considered a failed call for SQA.

VAR

  • The platform provides an extension to the <<log>> tag, using the label=com.genesyslab.var. CallResult label, that allows application developers to specify a VAR Result for a call in the following syntax:

<log> label="com.genesyslab.var.CallResult">result[|reason]</log>

  • result must be SUCCESS, FAILED, or UNKNOWN (default). The call result is not case-sensitive and any preceding or trailing white space is ignored.
  • reason is an optional, textual reason for the call result. The maximum length of the reason is 256 characters and it is not case sensitive. Any text beyond the character limit is truncated.

Reporting Server Functions

The Reporting Server retrieves accurate call related data, VAR reports (call peak and arrival summary data which are not call-specific), OR summaries, and call events. The OR summaries and VAR reports are rolled into higher level summary reports.

The Reporting Server provides:

  • Near-real-time call event and CDR data collection and processing information is submitted as soon as it is available or committed.
  • Data reliability through guaranteed data delivery policies. These policies ensure that accumulated data is not lost if the Reporting Server or the Reporting Server database are offline for a period of time.
  • Efficient organization of the database, by partitioning CDR and Call Event tables so that each partition represents a predetermined period of time (1 hour to 1 day), allowing database operations to occur at times when data accumulation is heavy, such as, when the call rate is high or the data retentionperiod is long.
  • Multi-site reporting, by aggregating reports from multiple independent Reporting Servers, allowing administrators to view data that is aggregated across multiple sites.
  • Open data access interfaces (through Reporting Web Services) that allow multiple user interfaces, including third-party interfaces, to access call-related data.
  • An interface that provides relevant data in various reporting formats to suit many business and operational needs.
  • XML reports that correspond to report requests made through Reporting Web Services. The Web Services are exposed over HTTP, and returned in XML format.
  • Provides support for queries and traps by communicating with the Genesys SNMP Master Agent through its SNMP interface.
  • Retrieves application data from the Supplementary Services Gateway components.

For more information about how GVP Reporting works, see Logging and Reporting.

For information about high availability for Reporting Server, see High Availability and Scalability.

For information about installing the Reporting Server, with a basic configuration, see Specifications and Standards.

Tip
GVP Reporting is unable to track Media Server services use at the tenant level (by tenant or by application). Applications that use URS centric routing have the following reporting issue:
During an MSML call into GVP, if SIP Server changes the X-Genesys-gsw-ivr-profile-name or the X-Genesys-gvp-tenant-id parameters in the middle of the call (e.g. applying different treatments that use different IVR profiles), the change is not reflected by Resource Manager, Media Control Platform or Reporting Server. All reporting for the call will be against the original IVR profile.
This page was last edited on January 13, 2015, at 23:56.
Comments or questions about this documentation? Contact us for support!