Starface UCC-CLient 6.7.1.212 - Vorschläge im Wählfeld Error Code 500

  • Sehr geehrte Damen und Herren,


    wir können seit dem Update des UC-CLients auf die Version 6.7.1.212 manche Vorschläge im Wählfeld nicht mehr anzeigen lassen. Wir haben ein ESTOS MetaDirectory in der Version 3.5 via LDAP als Adressbuch eingetragen.
    Es geht hierbei nur um die Vorschläge im Wählfeld des UC-CLients! Wenn das Adressbuch über den UC-Client aufgerufen wird können alle Einträge gefunden werden!
    Folgende Fehlermeldung steht im Log des UC-Clients, wenn ein Eintrag nicht als Vorschlag angezeigt wird:


    20-06-10 13:42:05.140 | 15 | ERROR | | UccAPI.RestApiResult | Write | Error code: 500, Error calling GetContact: Unhandled exception null | EXCEPTION:
    IO.Swagger.Client.ApiException: Error calling GetContact: Unhandled exception null
    bei IO.Swagger.Api.DefaultApi.GetContactWithHttpInfo(String contactId, String userId)
    bei UccAPI.UccRestApiWrapper.GetContactDetails(String contactId, UccAddressbookEntry& addressBookEntry, CallbackAsyncRestApiResult handler)
    bei UccAPI.UccRestApiWrapper.SearchContacts(String tagId, String searchTerm, Int32 page, Int32 pageSize, String sortBy, Boolean ascending, CallbackAsyncRestApiResult handler)
    bei UccAPI.UccRestApiWrapper.<>c__DisplayClass38_0.<SearchContactsAsync>b__0()
    bei UccAPI.UccRestApiWrapper.ExecuteActionWithLoginRetry(Action actionFunction, CallbackAsyncRestApiResult handler)


    Wenn der Eintrag gefunden wird (die Meisten Einträge werden gefunden), dann erhalten wir diesen Fehler nicht.


    Was haben wir versucht?
    - Getestet auf 4 unterschiedlichen PC's (2xWin10 Pro x64 / 2x Win 7 Pro x64 ESU)
    - Neuinstallation der Clients inkl. entfernen der Temporären Dateien, des Installationsverzeichnisses, AppData etc.
    - Auf "Fabrikneumen" PC installiert
    - LDAP-Datenbanken neu erstellen lassen (META-Directory)
    - Die Betroffenen "Ordner" in der Starface-Adressbuchkonfiguration neu hinzugefügt
    - Neustart alle betroffenen Systeme (Postgress-Datenbank, ESTOS-MetaDirectory, Telefonanlage)


    Was können wir noch prüfen? Hat jemand eine Idee an welcher Stelle wir noch etwas drehen können?
    Die Mitarbeiter wollten sich auf die Vorschläge verlassen können.


    Vielen Dank.


    barth Spedition / Lucas Wahl

  • Hallo barth


    Es sieht so aus, als ob die STARFACE beim Versuch die Details für einen Kontakt abzurufen in einen unerwarteten Nullpointer rennt.


    Vielleicht ist bei einem Kontakt ein gewisses Kontaktfeld nicht "leer" sondern "null", ist, und der parser im UCC-Client deshalb auf die Nase fällt.


    Eventuell findest du das Passende Gegenstück zu diesem Problem auf der STARFACE im Logfile des Restfull-interface findest, da das Adressbuch via REST abgeholt wird.
    Schau mal, ob er dort einen Stacktrace oder etwas drin hat, wenn du im UCC-Client den Fehler provozierst.


    MfG


    Fabian
    MfG


    Fabian

  • Hallo Lucas,


    mit welcher Server-Version ging es noch, mit welcher Server-Version ist es nun nicht in Ordnung?


    Habt Ihr in der Adressbuch-Konfiguration auf der ersten Karteikarte einen Ordner konfiguriert?



    Gruß Wolfgang


  • Hallo Wolfgang,


    die vorherige Serverversion war die 6.4.1, also schon etwas älter.
    Ich habe Dir 2 Screenshots von unserer Adressbuchkonfiguration angehängt - wir haben 4 Ordner Konfiguriert, da wir aus 4 verschiedenen Quellen des ESTOS-Metadirectory-Servers auslesen.


    Starface-Forum_UC-CLient-Fehler_2020-06-10_2.jpgStarface-Forum_UC-CLient-Fehler_2020-06-10_3.jpg


    Wir checken gerade das Logfile der REST-Api und melden uns gleich nochmals.


    Vielen Dank.


    Grüße


    Lucas


  • Hallo Fabian,


    erst mal vielen Dank für deine Antwort!
    Nachfolgend das Logfile der REST-Api. Wir haben das Logfile (Fehlerhafte Abfrage) mit dem Notepad++ verglichen bei dem die Abfrage funktioniert hat und konnten bei den Daten aus der LDAP-Abfrage keine Fehler oder 'null'-Werte oder ähnliches finden. Eventuell findet Dein geschultes Auge hier etwas mehr?
    Ab Zeile 107 bringt er den "java.lang.NullPointerException", jedoch ohne genauere Angaben weshalb.



    Und die Funktionierende Abfrage:



    Wir schauen auch gleich mal direkt auf der Datenbank nach.
    Kann es an den Sonderzeichen liegen bei "Zech, Jörg" ?


    Vielen Dank.


    Grüße


    Lucas

  • Hallo Lucas,


    es liegt nicht an einem konkreten Kontakt. Das hier habe ich schon gesehen:


    Code
    [2020-06-10 16:20:22,867] ERROR [http-8181-2] UnhandledExceptionMapper Unhandled exception 
    java.lang.NullPointerException
    	at de.starface.middleware.model.addressbook.Folder.getId(Folder.java:63)
    	at de.starface.middleware.model.addressbook.Folder.toTag(Folder.java:68)
    	at de.starface.rest.addressbook.model.converter.ContactConverter.fromMiddleware(ContactConverter.java:98)



    Allerdings kann ich es selbst nicht reproduzieren. Habt Ihr dazu einen Support-Fall erstellt?



    Gruß Wolfgang

  • Hallo Lucas,


    den Fehler im Log kann ich sofort provozieren, wenn ich zum Test ein Active Directory einbinde, aber KEINEN Ordner konfiguriere. Dann zeigt der Client im Adressbuch einen Reiter "Alle" mit Inhalt an, aber die Details eines Kontakts können nicht abgefragt werden und es kommt auch kein Ergebnis im Callmanager. Lege ich einen Ordner an, funktioniert es sofort korrekt.


    Bei Dir sind ja nun Ordner angelegt. Kannst Du zum Test mal (erst Backup machen) die vier konfigurierten Ordner entfernen und neu hinzufügen? Vielleicht ist es ja auch nur im Update-Fall fehlerhaft.




    Gruß Wolfgang

  • Hallo Lucas,


    ich habe noch eine Idee. Sind die Ordner aus dem Screenshot alle Ordner, die vom ESTOS bereitgestellt werden? Ich kann mir vorstellen, dass der Fehler erscheint, wenn ein Suchergebnis nicht in einem der konfigurierten Ornder ist.



    Gruß Wolfgang


  • Hallo Wolfgang,


    ich habe alle 4 Ordner im Starface unter Adressbuch --> Einstellungen entfernt und neu hinzugefügt, leider ohne Erfolg.
    Allerdings ist mir folgendes auf gefallen: Wenn wir das Adressbuch im UCC-Client öffnen und z.B. nach "LKW6" suchen erhalten wir 2 Ergebnisse, diese werden auch als Vorschlag im Wählfeld gefunden.
    Starface-Forum_UC-CLient-Fehler_2020-06-10_5.jpg
    Suchen wir jedoch im Adressbuch des UCC nach "LKW66" erhalten wir eine ganze Reihe von Ergebnissen die so gar nicht gefunden werden sollten.
    Starface-Forum_UC-CLient-Fehler_2020-06-10_4.jpg
    Alle Adressbücher sind über das ESTOS-Metadirectory angebunden (LDAP-Server). Wenn wir das Metadirectory direkt (via Web) aufrufen und nach "LKW66" suchen erhalten wir die richtigen Ergebnisse. Die Webseite sucht in allen Pfaden des Metadirectory (dc=226 und dc=238)
    Starface-Forum_UC-CLient-Fehler_2020-06-10_6.jpg
    Starface-Forum_UC-CLient-Fehler_2020-06-10_7.jpg
    Starface-Forum_UC-CLient-Fehler_2020-06-10_8.jpg


    Gibt es hier eventuell ein Thema mit der von uns erstellten Aufteilung in "dc=226 und dc=238 ? Sodass er in allen sucht, jedoch nur auf einen zugreifen kann und das Ergebnis deshalb nicht findet?



    Grüße


    Lucas


  • Hallo Wolfgang,


    super du hattest recht!
    Wir hatten den Ordner "Users" nicht eingebunden. Sobald in diesem etwas gefunden wurde konnte er es nicht aufrufen und hat den Fehler gebracht.
    Wir haben den Ordner hinzugefügt und nun zeigt er im Wählfeld den Vorschlag z.B. bei "Zech" an. Das hat vorher nicht funktioniert.


    Starface-Forum_UC-CLient-Fehler_2020-06-10_9.jpg


    Wenn wir jedoch nach "LKW66" suchen werden nun auch im Wählfeld unzählige Vorschläge zurück geworfen. Mit "LKW6" nur die beiden die es gibt.
    Starface-Forum_UC-CLient-Fehler_2020-06-10_10.jpg


    Hast Du noch eine Idee wir wir das Lösen könnten oder in welchem Log wir nachschauen können?


    VIELEN DANK! :)


    Grüße


    Lucas

  • Hallo Lucas,


    ich kann das mit den LKW reproduzieren. Stell mal das Adressbuch Log auf Debug Level. Und dann mach die Suchen nach LKW6 und LKW66. Siehe da im Log:


    Code
    [2020-06-12 12:08:23,017] DEBUG de.vertico.starface.persistence.connector.addressbook.AddressBookInterface starting search on: CN=Users,DC=labor,DC=loc with filter: (&(|(objectClass=person)(objectClass=inetOrgPerson))(|(telephoneNumber=*LKW6*)(givenName=*LKW6*)(homePhone=*LKW6*)(mobile=*LKW6*)(company=*LKW6*)(sn=*LKW6*)(facsimileTelephoneNumber=*LKW6*))) sorting: familyname 
    [2020-06-12 12:08:23,028] DEBUG de.vertico.starface.persistence.connector.addressbook.AddressBookInterface LDAP connection established 
    [2020-06-12 12:08:23,028] DEBUG de.vertico.starface.persistence.connector.addressbook.AddressBookInterface LDAPInterface.search ... searching (SCOPE_SUB) in CN=Users,DC=labor,DC=loc with filter (&(|(objectClass=person)(objectClass=inetOrgPerson))(|(telephoneNumber=*LKW6*)(givenName=*LKW6*)(homePhone=*LKW6*)(mobile=*LKW6*)(company=*LKW6*)(sn=*LKW6*)(facsimileTelephoneNumber=*LKW6*))) for attrs [telephoneNumber, givenName, homePhone, mobile, company, sn, facsimileTelephoneNumber] with contraints {'batchSize':='0', 'maxResults'='24', 'dereference'='0', 'serverTimeLimit'='0'} 
    [2020-06-12 12:08:23,030] DEBUG de.vertico.starface.persistence.connector.addressbook.AddressBookInterface LDAPInterface search returned 2 Entries 
    [2020-06-12 12:09:19,954] DEBUG de.vertico.starface.persistence.connector.addressbook.AddressBookInterface starting search on: CN=Users,DC=labor,DC=loc with filter: (&(|(objectClass=person)(objectClass=inetOrgPerson))(|(telephoneNumber=*66*)(givenName=*66*)(homePhone=*66*)(mobile=*66*)(company=*66*)(sn=*66*)(facsimileTelephoneNumber=*66*))) sorting: familyname


    Im ersten Fall wird korrekt nach LKW6 gesucht, im zweiten Fall nach 66


    Das werde ich mal nachverfolgen. Vielen Dank, Du hast mich weitergebracht.



    Gruß Wolfgang

  • Ich hab's. Sobald zwei Ziffern im Suchstring sind, wird die Eingabe als Telefonnummer betrachtet und die Nicht-Ziffern entfernt. Danach werden alle Einträge gefunden, deren Rufnummern die Ziffernfolge enthalten.


    Gruß Wolfgang

  • Ich hab's. Sobald zwei Ziffern im Suchstring sind, wird die Eingabe als Telefonnummer betrachtet und die Nicht-Ziffern entfernt. Danach werden alle Einträge gefunden, deren Rufnummern die Ziffernfolge enthalten.


    Gruß Wolfgang


    Hallo Wolfgang,


    als eher ein Feature und kein Bug :) Freut mich, dass ich helfen konnte.
    Gibt es eine Einstellung mit der wir das umgehen können bzw. den Wert auf 4 stellen können sodass wir unsere 3-Stelligen LKW-Nummern finden können?


    Vielen Dank.


    Grüße


    Lucas

Jetzt mitmachen!

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