Reporting and Data Feeds

Data Feeds

Softdial Contact Center™ (SCC) provides highly configurable data feeds to Softdial Reporter™ 5 or any 3rd party reporting client, via Softdial Publisher™.

With Publisher, users can

This section focuses on the default SQL data model used for storage of session and agent data.

Publisher uses XSLT as a translation mechanism. End-user configuration requires a degree of learning effort and knowledge of XSLT. To bridge this knowledge gap, a standard data model based on the SQL model for Sytel's first-generation reporting suite was produced, and a set of XSLT transformations developed (in the Softdial/PUB/Primary/xml/xslt folder) to deliver this data set.

Not all of the transformations in this folder are used to populate the standard set of SQL tables.

Many users modify this data set to suit their specific requirements.

The default configuration for Publisher writes this data to a MySQL database, but Publisher is able to output data to any relational store.

The SQL schema provides what we believe is a best-fit normalisation of call center event data relating to:

  • media sessions (typically phone calls)
  • agent sessions (login / availability)
  • agent activity
  • queue activity
  • campaign activity

The tables are updated on completion of an event cycle, e.g:

  • the agent_states table is updated each time the agent state changes, resulting in an Agent Data [AZ] message
  • the callcycles table is updated after the call session is ended and a Session Data [IZ] message has been issued (by Softdial CallGem™).

Each tenant requires their own set of tables. This means that either a separate database instance must be created per tenant, or each tenant needs to have their own schema within a database instance.

Schema-per-tenant is the model most common with users. This minimises DBMS licensing costs and it makes for a simpler model for database replication as there is only 1 instance to replicate for multiple tenants.

The default DSN is SccReporter. On installation, this is configured to point to the pre-configured mySQL database (accessible from http://localhost/apanel - Tools - phpMyAdmin).

The mySQL based reporting database is intended for demo and training purposes only and should not be used in production.

After setting up the production database and configuring the DSN, Publisher must be set up to use the new DSN, as follows:

  1. Navigate to the Softdial/PUB/Primary/xml folder
  2. Open the Publisher Primary configuration.xml file in an XML editor
  3. Search for <module name="ODBC Reporter"...
  4. Change the dsn, user and pwd parameters as required

    <!-- The ODBC DSN name -->
    <param name="dsn" value="SccReporter"/>

    <!-- The ODBC DSN username -->
    <param name="user" value="root"/>

    <!-- The ODBC DSN password -->
    <param name="psw" value="root"/>

    <!-- When true, Publisher will use SQL transactions, i.e. adding 'BeginTransaction' before and SQL commands, and 'Commit' or 'Rollback' at the end -->
    <param name="transaction" value="true"/>

    <!-- When using the ExternalStorage module, documents will be deleted from the 'documents' table when they exceed <value> days old -->
    <param name="document expiry days" value="30"/>

    <!-- The database type e.g. MySQL, MSSQL -->
    <param name="dbtype" value="MYSQL"/>

    <!-- From V10.7.1567 - When set to "yes", Publisher will retrieve the agent and switch outcomes set in Softdial Repository™ and update the Publisher database-->
    <param name="Control AO and SO" value="no"/>

  5. Save the file.
  6. Restart the Publisher Primary service.

The transformation files use rules and parameters that are defined in the rules.xml file (also located in Softdial/PUB/Primary/xml).

The schema described is as per the default implementation. It is possible to modify every detail of this implementation.

Common possibilities are:

  • keying all tables by tenant and having a single output database across all tenants
  • making additional permuted data to optimise MIS reporting
  • extracting line-of-business information from the session data (assuming consistent format across campaigns) to add to the reporting model