Hallo,
beim schreiben von sehr vielen (ca. 8.000) Telefonbucheinträgen per REST-API bekomme ich nach 2-6.000 Datensätzen, das ist unterschiedlich, einen HTTP 500 Fehler. Hängt das mit einem Ratelimit zusammen oder woher kommt das?
TIA
Matthias
Hallo @mahescho,
gibt es einen bestimmten Grund, nicht den Connector zum synchronisieren dieser Datenmengen zu verwenden?
Grüße,
Jan
Hmmm … den Connector hatte ich “übersehen”, aber wenn ich mir den so anschaue, dann gibt es aus meiner Sicht schon einen guten Grund den nicht zu nutzen. Es geht hier um eine Cloudanlage. Wenn, dann müsste ich “Fetch from url” machen. An sich kein Ding, aber ich müsste das CSV offen im Netz liegen lassen und laufe Gefahr, dass mich der Datenschützer erschlägt.
Geht denn beim “Fetch from url” zumindest Basic-Auth?
Am Rande: Was es in diesem Fall mit dem HTTP 500 auf sich hat beantwortet das aber nicht 
Hallo @mahescho,
Basic-Auth mit dem Connector gibt es mit der 19.09. Das Update der Cloud läuft über die kommenden Tage, siehe https://status.pascom.net/.
Warum über die REST API bei deinem Versuch ein HTTP 500 sehe ich mir bei Gelegenheit noch genauer an.
Besten Gruß
Sebastian
Das hört sich gut an, danke … führt mich aber zur nächsten Farge
Warum habe ich Cloudanlagen mit 19.8 und andere mit 19.7, wenn jetzt 19.9 kommt. Wie komme ich zu einheitlichen Ständen?
Damit bin ich auch schon auf die Nase gefallen und habe es am Ende so gemach, dass der Initial-Import per CSV erfolgt ist und laufende Änderungen dann per REST aus dem CRM, immer dann wenn sich ein Datensatz geändert hatte.
Gruß
Michael
Auch eine gute Idee, auch wenn ich das im Endeffekt so nicht machen kann, weil ich mich in die zwei führenden Systeme nicht einklinken kann um von dort getriggert zu ändern. Das ist aber auch nicht schlimm, weil ich so wie so pro Upstreamsystem ein Label setze und dort als Wert die ID vom Upstream setzen kann. Irgend wie muss ich die Sätze ja wiedererkennen.
An und für sich ist für mich auch der Erstimport per REST kein Problem, wenn ich nicht auf den Fehler laufen würde Denn wenn der 2 Stunden dauert ist das auch egal.
Update: Durch Ausprobieren habe ich jetzt herausgefunden dass der Displayname auf 80 Zeichen beschränkt ist und komplett eindeutig sein muss.
Ja, da habe ich es mit meinem CRM deutlich besser. Jegliche Änderungen werden per Event mitgeteilt, welches ich über das SDK von denen nur abonnieren muss.
Vielleicht wäre es ja noch eine Idee für Dich, die Datenmenge in kleine Häppchen aufzuteilen. Also immer in 100er-Schritten oder so.
Gruß
Michael
Das habe ich mir auch schon überlegt.
Was war eigentlich das Problem bei CSV-Lösung bei dir?
Alt, aber gerade wieder aktuell:
Problem ist hat beim CSV-Import, dass ich ich die ID vom Eintrag nicht zurück bekomme und somit immer alle Datensätze als CSV irgendwohin auf SFTP-Server schieben müsste. Da in den Daten aber z.B. auch die ID für die Zeiterfassung enthalten ist als Label, bin ich schon sehr interessiert daran, dass die Daten möglichst zeitnah vorhanden sind. Zumal ich darüber aus dem CRM leicht steuern kann, ob jmd. der einen Termin mit mir gebucht hat, auch außerhalb der Geschäftszeiten anrufen kann und am AB vorbei kommt etc.
Aktuell ist es so gelöst, dass ich initial die RestAPI nutze in kleinen Menge von 40 Datensätzen mit nem anschließenden Sleep() bevor die nächsten 40 kommen. Damit gelingt mit der Initial-Import und ab dem Zeitpunkt ist es dann Echtzeit. D.h. Datensatz im CRM geändert = Änderung im Telefonbuch. Dazu habe ich mir im CRM halt die Telefonbuch ID gemerkt.
Wird ein Datensatz gelöscht, lösche ich auch den Telefonbucheintrag.