Datenbank-Views

Insight Analytics schreibt Gesprächs-, Status- und Stammdaten der STARFACE fortlaufend in eine PostgreSQL-Datenbank Ihrer Wahl. Drittsysteme — Power BI, Grafana, Excel oder jede andere SQL-fähige BI- und Reporting-Lösung — lesen diese Daten direkt per SQL über versionslose Views, die das Modul über seinen versionierten Tabellen anlegt. Der Vertrag dieser Schnittstelle sind die Views und ihre Spalten, dokumentiert in der View-Referenz.

Verwendung durch Dritte

Diese Schnittstelle ist für die Nutzung durch Drittsysteme freigegeben. Änderungen und Erweiterungen werden je Version in den Release Notes dokumentiert.

Grundlagen

Typ: SQL-Datenbank — das Modul schreibt, Drittsysteme lesen.
Datenbanksysteme: Diese Referenz dokumentiert das Zielsystem PostgreSQL. In der Modulkonfiguration sind daneben MySQL, Microsoft SQL Server und Derby wählbar; Tabellen-, View- und Spaltennamen sind dort identisch, lediglich die Datentypen und die Anführungszeichen-Konvention weichen ab.
Lizenz: Der Datenbankexport erfordert die Enterprise-Edition von Insight Analytics. Ohne gültige Enterprise-Lizenz überträgt das Modul keine produktiven Daten (im Demo-Modus werden verfälschte Demodaten geschrieben).
Konfiguration: Tab Power BI – Einstellungen, Karte Datenbankverbindung — Felder Datenbanktyp, IP-Adresse / Hostname (optional mit Port, z. B. db.example.de:5433), Datenbankname, Benutzername, Passwort sowie — im Experten-Modus — Optionale Verbindungsparameter (JDBC-Optionen). Die Schaltfläche Verbindung testen prüft die Angaben; erst danach lässt sich der Schalter Datenexport in Datenbank aktivieren einschalten. Beim Aktivieren legt das Modul alle Tabellen und Views selbst an. Details: Power BI – Einstellungen.
Übertragungsrhythmus: Die Übertragung läuft zyklisch im Hintergrund. Standardintervalle: Gesprächsdaten alle 30 Sekunden, Live-Daten alle 10 Sekunden, Benutzer-/Gruppen-/Gerätezustände alle 60 Sekunden (Minimum 30 Sekunden, nur bei aktiviertem Statusexport). Nachträgliche Änderungen an Rückruf- und Kommentarfeldern gleicht das Modul stündlich per UPDATE ab. Konten- und Dienststammdaten werden als vollständige Momentaufnahme übertragen und ersetzen dabei den bisherigen Inhalt der jeweiligen Stammdaten-View.
Schreibverhalten: Gesprächs- und Statusdatensätze werden ausschließlich angefügt (INSERT); einzige Ausnahme sind die genannten Rückruf-/Kommentarspalten in CDR_Summary. Eine automatische Löschung alter Zeilen in der Zieldatenbank nimmt das Modul nicht vor — planen Sie Speicherplatz und Aufbewahrung in Ihrer Datenbank. Nur die Live-Views Agent_State und iQueue_State kann das Modul auf Wunsch zurücksetzen (Option Zurücksetzen der Live-Daten).
Zugriff für Drittsysteme: direkte SQL-Verbindung mit eigenen Zugangsdaten an dieselbe Datenbank. Das Modul stellt keinen eigenen Abfrage-Endpunkt bereit; lesende Zugriffe erfordern keine Modullizenz. Empfehlung: Legen Sie für BI-Werkzeuge ein rein lesendes Datenbankkonto an.
Netzzugriff: Für Installationen ohne direkte Verbindung zum Datenbankserver (z. B. STARFACE Cloud) bietet die Modulkonfiguration eine SSH-Tunnel-Einrichtung (reverse SSH-Tunnel von der Anlage in Ihr Netzwerk).
Pseudonymisierung: Ist die Pseudonymisierung im Modul aktiviert, werden personenbezogene Spalten (Namen, Rufnummern, Autoren) bereits vor dem Schreiben in die Datenbank pseudonymisiert. Bereits exportierte Zeilen bleiben unverändert.

Stabilitätsversprechen

Jede Tabelle trägt ihre Schemaversion im Namen (z. B. CDR_Summary_4). Über jeder Tabelle legt das Modul eine View ohne Versionsnummer an (CDR_Summary), definiert als SELECT * auf die jeweils aktuelle Tabellenversion. Bauen Sie Ihre Auswertungen ausschließlich auf die versionslosen Views — sie sind die zugesicherte Vertragsfläche dieser Schnittstelle.

Was Sie sich darauf verlassen können:

Bestehende Spalten und Tabellen werden nie gelöscht oder umbenannt. Das ist eine verbindliche Entwicklungsregel des Moduls.
Schemaänderungen sind ausschließlich Erweiterungen: Neue Spalten oder Tabellen kommen hinzu, die Versionsnummer der Tabelle wird erhöht, und die versionslose View wird auf die neue Tabellenversion umgehängt.
Die alten versionierten Tabellen bleiben unverändert in der Datenbank erhalten, einschließlich ihrer Daten.

Was sich ändern darf:

In den Views können mit einem Modul-Update neue Spalten erscheinen. Verwenden Sie in Integrationen daher explizite Spaltenlisten statt SELECT *, wenn Ihr Zielsystem auf eine feste Spaltenanzahl angewiesen ist.
Nach einem Versionssprung beginnt der Upload in die neue Tabellenversion von vorn (begrenzt durch die Einstellung Älteste Daten, Standard 3 650 Tage, und die CDR-Vorhaltezeit der Anlage). Historische Auswertungen über den Versionswechsel hinweg erfordern ggf. die alten versionierten Tabellen.

Views

Das Modul legt 24 Views an. Vollständige Spaltenbeschreibungen enthält die View-Referenz; hier der Katalog nach Datenart:

View	Datenart	Inhalt
`CDR_Summary`	Gesprächsdaten (Summary)	Ein aufbereiteter, klassifizierter Datensatz je Anruf bzw. Weiterleitungsziel — die zentrale Auswertungsquelle
`CDR_Data`	Gesprächsdaten (Detail)	Rohdaten je einzelnem Anrufschritt aus dem STARFACE-CDR
`CDR_Account`, `Caller_Account`, `Called_Account`, `Call_Result_Account`, `User_Call_Account`, `Group_Call_Account`	Konten	Stammdaten aller Benutzer-, Gruppen- und iQueue-Konten — Nachschlage-Views zu den ID-Spalten von `CDR_Summary`
`CDR_Account_CDR_Data`, `Caller_Account_CDR_Data`, `Called_Account_CDR_Data`, `Call_Result_Account_CDR_Data`	Konten	Dieselben Kontenstammdaten als Nachschlage-Views zu `CDR_Data`
`Group_Account_for_User_Group_States`	Konten	Kontenstammdaten als Nachschlage-View zu `User_Group_States`
`Service_for_CDR_Summary`, `Service_for_CDR_Data`	Dienste	STARFACE-Dienste (`service_id` → Name) zu den Gesprächsdaten
`Module_Message_for_CDR_Summary`, `Module_Message_for_CDR_Data`	Modulnachrichten	Schema für anrufbezogene Modulnachrichten (derzeit ohne Inhalte)
`Constant_Values`	Kennzahlen	Ziel- und Maximalwerte aus den Moduleinstellungen (Berichts-Grenzwerte)
`Measurements`	Kennzahlen	Hilfstabelle der Power-BI-Kennzahlen; in der SQL-Datenbank ohne Nutzdaten
`User_States`	Benutzerzustände	Momentaufnahmen je Benutzer: DND, Immer-Umleitung
`User_Group_States`	Gruppenzustände	Momentaufnahmen je Gruppenmitglied: An-/Abmeldestatus in der Gruppe
`User_Device_States`	Gerätezustände	Momentaufnahmen je Benutzer und Endgerät: Telefon aktiv/inaktiv
`Agent_State`	Live-Daten	Momentaufnahmen je iQueue-Agent: Präsenz, Telefoniestatus, aktueller Anruf
`iQueue_State`	Live-Daten	Momentaufnahmen je Warteschlange: verbundene und wartende Anrufe

Hinweis zur Schreibweise: In PostgreSQL legt das Modul alle Bezeichner in doppelten Anführungszeichen an. Tabellen-, View- und Spaltennamen sind dadurch case-sensitiv und müssen in Abfragen exakt und in doppelten Anführungszeichen angegeben werden — SELECT … FROM "CDR_Summary", nicht from cdr_summary.

Beispielabfragen

Servicelevel je Warteschlange und Tag — Anteil der Anrufe, die innerhalb von 30 Sekunden angenommen wurden (laufender Monat):

SELECT g."Account_Name"                                   AS warteschlange,
       s."start_time_day"::date                           AS tag,
       COUNT(*)                                           AS anrufe,
       COUNT(*) FILTER (WHERE s."answered")               AS angenommen,
       ROUND(100.0 * COUNT(*) FILTER (WHERE s."answered"
                       AND s."waiting_time_s" <= 30)
             / COUNT(*), 1)                               AS servicelevel_30s
  FROM "CDR_Summary" s
  JOIN "Group_Call_Account" g
    ON g."Account_ID" = s."group_call_account_id"
 WHERE s."is_iqueue_call"
   AND s."incoming"
   AND NOT s."is_garbage"
   AND s."start_time" >= date_trunc('month', CURRENT_DATE)
 GROUP BY 1, 2
 ORDER BY 2, 1;

Verpasste externe Anrufe der letzten sieben Tage, die noch nicht zurückgerufen wurden — inklusive der im Modul gepflegten Kommentare:

SELECT s."start_time"          AS zeitpunkt,
       s."caller_name_number"  AS anrufer,
       s."called_name"         AS ziel,
       s."comment"             AS kommentar
  FROM "CDR_Summary" s
 WHERE s."incoming"
   AND NOT s."answered"
   AND NOT s."called_back"
   AND NOT s."is_garbage"
   AND s."call_origin_type" = 'External'
   AND s."start_time" >= CURRENT_DATE - INTERVAL '7 days'
 ORDER BY s."start_time" DESC;

Auslastung der Warteschlangen im Tagesverlauf — maximale und durchschnittliche Anzahl wartender Anrufe je Warteschlange und Stunde (heutige Live-Daten):

SELECT q."queue_name"                     AS warteschlange,
       date_trunc('hour', q."timestamp")  AS stunde,
       MAX(q."waiting_calls")             AS max_wartend,
       ROUND(AVG(q."waiting_calls"), 2)   AS schnitt_wartend
  FROM "iQueue_State" q
 WHERE q."timestamp" >= CURRENT_DATE
 GROUP BY 1, 2
 ORDER BY 1, 2;

Anwendungsbeispiel

Ein Kunde betreibt sein Berichtswesen vollständig in Grafana. Er verbindet Grafana über die PostgreSQL-Datenquelle mit der Zieldatenbank von Insight Analytics und baut seine Panels auf die Views CDR_Summary und iQueue_State auf. Erreichbarkeit, Servicelevel und Warteschlangenauslastung stehen damit im selben Dashboard wie die übrigen Unternehmenskennzahlen — und überstehen jedes Modul-Update ohne Anpassung.

Versionierung & Kompatibilität

Aktuelle Schemaversionen: Gesprächs-, Stamm-, Kennzahlen- und Zustandsdaten liegen in Tabellen der Version 4 (Suffix _4), die Live-Daten Agent_State und iQueue_State in Version 1 (Suffix _1). Die versionslosen Views zeigen stets auf die aktuelle Version.
Schemaerhöhung: Bringt ein Modul-Update eine neue Schemaversion mit, meldet die Administrationsoberfläche ein erforderliches Datenstruktur-Update. Erst mit dessen Bestätigung (Datenbank aktualisieren) legt das Modul die neuen Tabellen an und hängt die Views um; anschließend beginnt der Upload in die neuen Tabellen von vorn. Die alten versionierten Tabellen und ihre Daten bleiben unverändert erhalten.
Abwärtskompatibilität: Spalten und Tabellen werden nie gelöscht oder umbenannt; Änderungen sind ausschließlich additiv (siehe Stabilitätsversprechen).
Änderungsnachweis: Schema-Erweiterungen werden je Modulversion in den Release Notes dokumentiert.

Grundlagen​

Stabilitätsversprechen​

Views​

Beispielabfragen​

Versionierung & Kompatibilität​

Grundlagen

Stabilitätsversprechen

Views

Beispielabfragen

Versionierung & Kompatibilität