aufbereitete History via XML-RPC / REST?

  • Hallo liebes Starface Forum,


    ich würde gerne unsere Anrufer History mit diversen anderen Daten anreichern und visualisieren.
    Die Daten die aus "Asuwertung -> Verbindungsdaten exportieren" als CSV herausfallen wären dafür ideal.
    Allerdings möchte ich nur ungern ständig händisch CSV Tabellen exportieren und wo anders importieren.


    Die Dokus zur XML-RPC Schnittstelle und REST Api habe ich mir angesehen.
    Wenn ich das richtig sehe, ist eine Abfrage der callerhistory via REST nicht möglich, korrekt?


    Die Daten aus der XML-RPC "Queue.getHistoryData" sind scheinbar nicht "aufbereitet", damit meine ich dass der gesamte caller trace rausfällt und noch mal aufbereitet werden müssten.


    Kleiner vergleich:
    CSV Daten, eine Zeile (Caller ID 51941), interessant für mich vor allem Felder wie "answered", "duration" und "login"

    Code
    81666   51941   0   c7372363-e529-4010-a73f-2858101fad62    [...] true    2166    635


    XML-RPC, insg. 5 Arrays mit gleicher callId und unterschiedlicher Daten (incomig, callLegUUID:


    Bei einem Test für den gleichen Zeitraum habe ich ~300 Einträge in der CSV und über 2200 über die XML-RPC.


    Gibt es eine Möglichkeit über eine der Schnittstellen automatisiert "aufbereitete" Daten abzufragen?
    Ist sowas ggf. geplant oder soll mit in die REST Schnittstelle intgeriert werden?
    Falls nicht anders möglich: Hat jemand - oder gibt es - einen "parser" (php, js, ...) um die Daten aus der XML Queue.getHistoryData passend zu mergen dass ein Array mit den gewünschten Infos rausfällt?


    Vielen lieben Dank für jede Info,
    Stefan

  • Hallo Stefan


    Eventuell hilft die die DB-Tabelle "CDRSummary" weiter:


    SQL
    SELECT id, callid, callleguuid, cdraccountid, calleraccountid, callercallerid, 
           callernumber, callername, calledaccountid, calledcallerid, callednumber, 
           calledname, serviceid, starttime, ringingtime, linktime, callresulttime, 
           callresult, callresultcausedby, lineid, linename, dialednumber, 
           callbacknumber, answeredelsewhere, incoming, answered, hasvoicemail, 
           hasmonitor, hasfax, deleted, privatecall, callbacknumberextern, 
           duration
      FROM cdrsummary;


    Ergebnis:


    Code
    1;13;"5d666b23-f9db-40df-86cb-be44f54f43b8";1001;1001;"821 821 821";"";"";0;"0041123456789";"";"";3;1456216064234;;1456216069502;1456216075276;"CONNECTED";;1012;"SIP/[ENTFERNT]";"";"0041123456789";"";f;t;f;f;f;f;f;t;5
    2;14;"82cfee62-b8fb-40e0-8e01-cb21ae0a4973";1001;1001;"821 821 821";"";"";0;"0041123456789";"";"";3;1456216126266;;1456216131909;1456216136508;"CONNECTED";;1012;"SIP/[ENTFERNT]";"";"0041123456789";"";f;t;f;f;f;f;f;t;4
    3;15;"2853352d-0615-48dd-8b22-7b72119831d5";1001;1001;"821 821 821";"";"";0;"0041123456789";"";"";3;1456216197036;;1456216202363;1456216206749;"CONNECTED";;1012;"SIP/[ENTFERNT]";"";"0041123456789";"";f;t;f;f;f;f;f;t;4
    4;16;"338b4b92-9e55-4861-a85b-324485eb1a4f";1001;1001;"821 821 821";"";"";0;"0041123456789";"";"";3;1456223229105;;1456223236043;1456223241249;"CONNECTED";;1012;"SIP/[ENTFERNT]";"";"0041123456789";"";f;t;f;f;f;f;f;t;5
    5;17;"688cb365-ec3d-4819-bd25-d1ca2d75c16e";1001;1001;"821 821 821";"";"";0;"0041123456789";"";"";3;1456241103047;;1456241110524;1456241120636;"CONNECTED";;1012;"SIP/[ENTFERNT]";"";"0041123456789";"";f;t;f;f;f;f;f;t;10
    6;25;"e424f26a-c849-49b5-8981-894a9a39d833";1000;1000;"100";"";"";0;"004171271818";"";"";3;1457421990237;;0;1457421996817;"NOT_CONNECTED";;1012;"SIP/[ENTFERNT]";"";"004171271818";"";f;f;f;f;f;f;f;t;0
    7;26;"31d560cb-ee67-4210-add6-e27630da59be";1023;0;"0041123456789";"";"";1023;"5102630 : HRN 630";"";"";2;1457422095762;1457422096038;1457422100532;1457422095675;"CONNECTED";;1012;"SIP/[ENTFERNT]";"";"0041123456789";"";t;t;f;f;f;f;f;t;5
    8;26;"525dfd12-f37a-420a-9c42-65cd45515c4e";1000;0;"0041123456789";"";"";1023;"5102630 : HRN 630";"";"";2;1457422095762;1457422096038;1457422100532;1457422105756;"CONNECTED";;1012;"SIP/[ENTFERNT]";"";"0041123456789";"";t;t;f;f;f;f;f;t;5


    Es könnte aber sein, dass die Tabelle "CDRSummary" die gleichen nicht Aufbereiteten Daten enthält, wie du via Rest erhälst.


    MfG


    Fabian

  • Zitat

    Es könnte aber sein, dass die Tabelle "CDRSummary" die gleichen nicht Aufbereiteten Daten enthält, wie du via Rest erhälst.


    'cdrsummary' enthält exakt die gleichen Daten wie der CSV-Export.


    Um daraus valide Statistiken generieren zu können, muss aber noch einiges gefiltert werden. In der Liste tauchen z.B. angenommene Gespräche an Gruppen doppelt auf - einmal als Anruf an die Gruppe, einmal als Anruf an denjenigen, der das Gespräch angenommen hat. Verpasste Anrufe an Gruppen tauchen dann noch öfter auf. (1x für jeden Nutzer in der Gruppe und 1x für die Gruppe selbst). Weiter geht's dann mit Anrufen, die weitergeleitet wurden nach Zeitüberschreitung, durch Voicemail angenommene Gespräche, Faxe, Konferenzen, usw. usw. ... Ich bin da auch gerade dran und hab 2 Tage gebraucht, eine sinnvolle Ausgabe aller ein- und ausgehenden Anrufe zu generieren. Jetzt kann ich aber loslegen mit Statistiken generieren :)

    Viele Grüße,


    Andreas Stein
    IT Fabrik Systemhaus GmbH & Co. KG


    STARFACE Excellence PLUS Partner

    Einmal editiert, zuletzt von andreas.stein ()

  • Hi Andreas,


    auch hierfür vielen herzlichen Dank!
    Wenn bei mir was brauchbares zusammen kommt, lass ich es Euch wissen.


    Viele Grüße, Stefan

  • Hallo Forum,


    ich habe mir die Tabellen und insb. die cdrsummary genauer angeschaut, die ist schon mal ganz hilfreich.
    Dabei sind jetzt zwei grundlegende Fragen aufgetaucht:
    1.: die auf unserer Anlage laufende PostgreSQL Version ist 8.4.20 ist seit July 2014 EOL, siehe https://www.postgresql.org/support/versioning/. Gehört das so? IMHO In Sachen Sicherheits-, Performance- und Featureaspekten problematisch. Kann die aktualisiert werden ohne was kaputt zu machen, gibt es eine Roadmap zur Aktualisierung?


    2.: die Spalten für die Zeiten (Beispiel starttime) sind bigints mit Milisec unixtime. Gib es da einen wichtigen Grund für? Als spaltentyp timestamp wäre das sehr viel performanter und einfacher zu handlen was Datumsoperationen (Auswertung innerhabl bestimmter Zeiträume, Gruppieren nach Zeiträumen etc.) angeht.
    Mich würde auch hier interessieren ob eine Änderung geplant ist.


    Viele Grüße, Stefan

    Einmal editiert, zuletzt von s.boehm () aus folgendem Grund: grüße vergessen :)

  • Hallo zusammen, ich könnte einen Tipp zum Aufbereiten der Daten gebrauchen.
    Ich möchte die Zeit berechnen, wie lange das Telefon desjenigen der dran gegangen ist geklingelt hat und die gesamte Wartezeit des Kunden, bevor jemand dran gegangen ist.
    Die Dauer des Telefonats ist ja einfach "callresulttime" - "linktime", doch mit den beiden anderen Sachen komme ich nicht ganz zurecht.


    In folgender Tabelle mal ein Beispiel (habe es schon ein bisschen um das reduziert)




    Die Anrufdauer sind etwa 81 Sekunden. Die Abweichungen im Timestamp sind da ja marginal.
    Doch wie lange hat das Telefon beim annehmenden geklingelt und wie lange hing der Anrufer in der Schleife?


    Waren es 3 Sek, 10 Sek oder 13? Wie muss ich das rechnen und welche der beiden Zeilen muss ich für die Berechnung nehmen?


    Liebe Grüße

    MfG 404notfound

    Einmal editiert, zuletzt von 404notfound ()


  • 1.: die auf unserer Anlage laufende PostgreSQL Version ist 8.4.20 ist seit July 2014 EOL, siehe https://www.postgresql.org/support/versioning/. Gehört das so? IMHO In Sachen Sicherheits-, Performance- und Featureaspekten problematisch. Kann die aktualisiert werden ohne was kaputt zu machen, gibt es eine Roadmap zur Aktualisierung?


    Es gibt keine Roadmaps und eine Aktualisierung bringt die Anlage in einen nicht supporteten Zustand. Das muß halt klar sein...




    2.: die Spalten für die Zeiten (Beispiel starttime) sind bigints mit Milisec unixtime. Gib es da einen wichtigen Grund für? Als spaltentyp timestamp wäre das sehr viel performanter und einfacher zu handlen was Datumsoperationen (Auswertung innerhabl bestimmter Zeiträume, Gruppieren nach Zeiträumen etc.) angeht.


    Zumindest was die Performance angeht, gibt es gegenteilige Messungen bzgl. indizierter timestamp- und bigint-Felder:
    https://www.postgresql.org/mes…020801@andromeiberica.com


    Ich habe es nicht nachgeprüft, aber wenn die Angaben dort stimmen, dauert ein SELECT über timestamp-Felder mit Auswahl von Zeiträumen knapp drei mal so lang, wie über bigint-Felder.
    Wenn man den Thread weiter verfolgt, so gibt es zwar Zweifel an den Messwerten, aber ein int8-Vergleich soll der schnellstmögliche sein. Timestamp hat einen kleinen Overhead...
    Die Speicherung erfolgt intern in beiden Fällen als 8-byte Integer.


    Was die Handhabung angeht, so gebe ich dir Recht. Aber innerhalb der STARFACE wird das ohnehin von Frameworks erledigt.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!