Zeige Ergebnis 1 bis 8 von 8

Thema: aufbereitete History via XML-RPC / REST?

  1. #1
    STARFACE User

    Registriert seit
    06.10.2017
    Beiträge
    6

    Standard 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:
    Code:
    [0] => Array
       (
           [callId] => 51941
           [incoming] => 
           [callLegUUID] => c7372363-e529-4010-a73f-2858101fad62
           [agentId] => 635
           [...]
       )
    
    [1] => Array
       (
           [callId] => 51941
           [incoming] => 1
           [callLegUUID] => c7372363-e529-4010-a73f-2858101fad62
           [agentId] => 635
           [...]
       )
    
    [2] => Array
       (
           [callId] => 51941
           [incoming] => 1
           [callLegUUID] => 48f26092-af6a-4e80-bcf4-b6c01c998c6b
           [agentId] => 635
           [...]
       )
    
    [3] => Array
       (
           [callId] => 51941
           [incoming] => 1
           [callLegUUID] => 7cfcbc55-7942-4a0b-84ee-79dd71f4500a
           [agentId] => 635
           [...]
       )
    
    [4] => Array
       (
           [callId] => 51941
           [incoming] => 1
           [callLegUUID] => 7cfcbc55-7942-4a0b-84ee-79dd71f4500a
           [agentId] => 635
           [...]
       )
    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

  2. #2
    STARFACE Expert
    Benutzerbild von nucom
    Registriert seit
    11.12.2012
    Ort
    9443 Widnau
    Beiträge
    1.809

    Standard

    Hallo Stefan

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

    Code:
    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
    Modulhersteller aus der Schweiz
    __________________________________________________ ________
    STARFACE Excellence Partner: Info | Certified Module Creator Kontakt

  3. #3
    STARFACE User

    Registriert seit
    06.10.2017
    Beiträge
    6

    Standard

    Hallo Fabian,

    vielen Dank für die Info, das schau ich mir an!

  4. #4
    STARFACE Expert
    Benutzerbild von andreas.stein
    Registriert seit
    04.12.2014
    Ort
    Bitburg
    Beiträge
    632

    Standard

    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 :-)
    Geändert von andreas.stein (11.10.2017 um 23:14 Uhr)
    Viele Grüße,

    Andreas Stein
    IT Fabrik Systemhaus GmbH & Co. KG

    STARFACE Excellence Partner

  5. #5
    STARFACE User

    Registriert seit
    06.10.2017
    Beiträge
    6

    Standard

    Hi Andreas,

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

    Viele Grüße, Stefan

  6. #6
    STARFACE User

    Registriert seit
    06.10.2017
    Beiträge
    6

    Standard

    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
    Geändert von s.boehm (25.10.2017 um 14:20 Uhr) Grund: grüße vergessen :)

  7. #7
    STARFACE Newbie
    Registriert seit
    05.02.2018
    Beiträge
    4

    Standard

    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)

    callId callStepId callLegUUID cdrAccountId callerAccountId callerCallerId calledAccountId calledCallerId starttime ringingtime linktime callresultTime callResult callResultCausedBy lineId lineName callbackNumber answeredElsewhere incoming answered hasVoicemail hasMonitor callbackNumberExtern
    557514 0 1c7da34f-523e-4858-aca4-f524d03fd640 2585 0 211 : 0049123456789 2585 211 : Gruppe1 211 1520496153789 1520496163641 1520496166920 1520496248113 CONNECTED 2026 1229 SIP/01234567890 49123456789 1 1 0 0 1
    557514 0 5e0ec12e-2319-4b24-a09a-b29d285f81d1 2026 0 211 : 0049123456789 2585 211 : Gruppe1 211 1520496163564 1520496163641 1520496166920 1520496248111 CONNECTED 0 0 49123456789 1 1 0 0 1


    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
    Geändert von 404notfound (09.03.2018 um 13:19 Uhr)
    MfG 404notfound

  8. #8
    STARFACE Expert
    Benutzerbild von fwolf
    Registriert seit
    28.12.2011
    Ort
    72622 Nürtingen
    Beiträge
    2.330

    Standard

    Zitat Zitat von s.boehm Beitrag anzeigen
    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...


    Zitat Zitat von s.boehm Beitrag anzeigen
    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/message-i...omeiberica.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.
    Geändert von fwolf (09.03.2018 um 15:08 Uhr)
    Grüße,
    Fabian

    STARFACE Excellence Partnerwww.fluxpunkt.deinfo@fluxpunkt.de

    Informationen über Fluxpunkt Module für STARFACE
    Produktupdates, Neuigkeiten & sonstiges gezwitscher: Fluxpunkt bei Twitter

Ähnliche Themen

  1. Rest API
    Von ITC-B im Forum STARFACE Module
    Antworten: 4
    Letzter Beitrag: 15.09.2017, 09:12
  2. Call History
    Von ITC-B im Forum Off-Topic & Smalltalk
    Antworten: 0
    Letzter Beitrag: 14.03.2015, 17:19

Stichworte

Lesezeichen

Forumregeln

  • Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
  • Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
  • Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
  • Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.
  •