Ich habe mit dem Displayname im Telefonbuch ein Problem.
Der Displayname Scheint innerhalb einer Anzahl von N Zeichen (also nicht über die gesamte Länge) eindeutig sein zu müssen. Leider steht das nirgends, wie so vieles Meine Displaynames sind teils sehr lang und trotzdem mehrfach vorhanden. Zuerst habe ich versucht die ID anzuhängen. Das hat aber nicht geklappt und zu den selben Fehlern geführt. Was mich zu der Annahme führt, dass die Eindeutigkeit auf die ersten N Zeichen beschränkt sein muss. Jetzt stelle ich die voran. Das sieht zwar blöd aus funktioniert aber.
Aufgefallen ist das durch die HTTP 409 Fehler beim Schreiben mit dem REST-API.
Ich verstehe ja, wenn es in der Datenbank einen Index über den Displayname gibt, aber warum muss der über N Zeichen eindeutig sein. Mein Vorschlag: Einfach, bis auf die ID, keine Feld im Telefonbuch eindeutig machen.
Update: Durch Ausprobieren habe ich jetzt herausgefunden dass der Displayname auf 80 Zeichen beschränkt ist und komplett eindeutig sein muss.
Deshalb ja der Wunsch nach einem eindeutigen Indexfeld. Wobei ich ich den entscheidenen Satz weggelassen habe. “…unabhängig vom Namen”. Also intern eine GUID oder sowas, die dann auch zurück geliefert wird beim Anlegen eines neues Kontakts über REST. Erst damit wäre ein “echter” Sync möglich. Anders kann man ja nicht verhindern, dass ein Eintrag plötzlich ein weiteres mal erscheint, beispielsweise weil ich der Kundenname geändert hat (Hochzeit, Scheidung, Umfimierung o.ä.).
Ohne eindeutigen Index über ein vom Namen abweichendes Feld m.E.n nicht lösbar. Und alle Einträge zuvor löschen ist auch keine Option, weil dann die manuell hinzugefügten ja ebenfalls weg sind und das dann auch wieder zu großen REST-Abfragen führt.
REST liefert doch die ID des Satzes zurück, wenn man einen neuen Satz anlegt.
Für den Sync habe ich mir aber einen anderen Trick überlegt, der gut funktioniert: Ich Setze so wie so ein Label um zu wissen aus welcher Datenbank der Satz kommt. Dem Label kann man ja einen Wert mit geben und in den schreibe ich einfach die ID des Satzes aus der Quelldatenbank. Damit kann ich dann die Sätze finden.
ich glaube es gibt hier ein grundsätzliches Verständnisproblem beim Connector und REST-API. Ich versuche das mal grob aufzuklären:
Der Displayname ist eindeutig (über die Komplette Länge, im Moment max. 80 Zeichen), damit eine Synchronisierung aus vielen Datenquellen möglich wird - so wird es z. b. auch beim User-Import usw. gehandhabt.
Wenn Datensätze über den Connector importiert werden, sind diese dem Profil zugeordnet
Datensätze, die nicht von einem entsprechenden Connectorprofil angelegt worden sind, werden von diesem Profil nicht angefasst. D. h. auch manuell in der WebUI oder über den Client erstellte Datensätze bleiben unberührt
Ich denke die meisten eurer Probleme verschwinden, wenn ihr von “Manuell die REST-API verwenden” auf “den Connector verwenden” umstellt.
Der einfachste Flow ist, 1x am Tag:
Aus dem Fremdsystem eine CSV Datei (mit allen Datensätzen) erstellen
Dieses an ein entsprechendes Connectorprofil verfüttern
Import durchführen. Der pascom-Server kümmert sich selbstständig um die Synchronisierung
Einzige Vorraussetzung: In einem Telefonbuch muss der Display-Name eindeutig sein, da dieser als Schlüssel verwendet wird.
Da es ja inzwischen Basic-Auth gibt, spricht nichts mehr dagegen, diese Weg zu gehen. Aber eine CSV ohne Schutz auf einem FTP-Server ist halt keine gute Idee und war in der Vergangenheit ein KO-Kriterium bei Cloud-basierten Anlagen.
Wie verhält es sich denn dann nach einem erneuten Sync, wenn sich der Name geändert haben sollte? Soweit ich das verstanden habe, löscht Pascom alle Telefonbucheinträge, die vom Connector importiert wurden und importiert neu.
Sehe ich dann im Journal trotzdem noch die letzten 3 Anrufe etc. weil die auf der Rufnummer basieren oder werden die anhand es Namens ermittelt?
Falls Name das Kriterium wäre, ist der Display-Name als Schlüsselfeld immer noch suboptimal.
Abgesehen davon sollte das auch per REST performant möglich sein, aber das führt an dieser Stelle zu weit und ist sicher ein eigenständiges Thema.
Wenn sich der Anzeigename ändert, wird der betreffende Eintrag gelöscht und neu angelegt. Die anderen Einträge bleiben erhalten.
Das “letzte 3 Anrufe”-Feature im Client arbeitet über die Telefonnummer in den Journaleinträgen. Das sollte nach wie vor funktionieren. Da beim Journaleintrag auch der jeweilige Name gespeichert ist, bleibt hier der alte Name erhalten. Was höchstwahrscheinlich bricht, ist die Zuordnung eines alten Journaleintrags zum Telefonbucheintrag (in den Details).
Eine wirklich fruchtbare Diskussion, die zeigt, dass es sich lohnt über die Dinge zu “sprechen”.
Dachte auch erst, dass das ein Problem sein könnte, aber man kann CSV-Daten per REST hochladen und dann importieren. Geht also auch ganz ohne Basic-AUTH.
Je länger ich mir das anschau und mit je mehr unterschiedlichen Quellen ich es zu tun bekomme desto weniger gut scheint mir die Idee des eindeutigen Displaynames eine gute zu sein.
Der Connector lässt sich meiner Meinung nach leicht so gestalten, dass der Displaname nicht eindeutig sein muss. Man braucht halt ein, zwei zusätzlich Datenbankfelder dazu, aber machbar ist es ganz sicher.
Spätestens hier scheitere ich nämlich mit dem Vorhaben den Displayname eindeutig zu machen:
Bei anderen Quellen bleibt mir nichts anderes übrig als den Displayname auf 70 Zeichen zu beschränken und dann einen Marker für die Quelle und die Satz-ID aus der Quelle anzuhängen nur um sicherzustellen dass der Displayname eindeutig wird.
Das ist alles andere als schön. Ich bleibe dabei, das es nicht gut ist dass der Displayname eindeutig sein muss.
Ich habe einen Kunden, welcher kommenden Monat über 100.000 Telefonbucheinträge in die pascom importiert bekommt. Da ist es auch alles andere als förderlich, dass der Displayname eindeutig sein muss.
Das Konzept ist alles andere als zu Ende gedacht und sollte überarbeitet werden.
Meine Displaynames sind teils sehr lang und trotzdem mehrfach vorhanden. Zuerst habe ich versucht die ID anzuhängen. Das hat aber nicht geklappt und zu den selben Fehlern geführt. Was mich zu der Annahme führt, dass die Eindeutigkeit auf die ersten N Zeichen beschränkt sein muss. Jetzt stelle ich die voran. Das sieht zwar blöd aus funktioniert aber.