Limitierung beim Gruppenhandling bei SF 6.7.x ff.?

Hallo in die Runde,

ich bin im Zusammenhang mit der Verwendung verketteter Gruppen bei einer Kundenanlage auf ein merkwürdiges Problem gestossen:

Der Kunde wollte den eigentlichen simplen Lösungsweg für ein banales Anrufhandling haben, bei dem Anrufe zunächst bei einem Benutzer für einige Sekunden klingeln, danach für weitere Sekunden an eine erste Gruppe von anderen Benutzern signalisiert werden und, falls diese nicht annehmen in einer zweiten Runde an weitere, andere Benutzer weitergegeben + wenn auch diese nicht abnehmen nach weiterer Klingelzeit auf der Mailboch landen.

Gelöst wurde das dann tatsächlich durch eine Weitergabe an zwei Gruppen, die Ihrerseits jeweils über separate mehrstellige Rufnummern angewählt werden. So weit - so gut - funktionierte lange Zeit für verschiedene Szenarien bei genau diesem Kunden auch so.

Mittlerweile ist der Kunde sehr stark gewachsen, hat ein zigfaches an Mitarbeitern und eben auch zusätzliche Anforderungen. Beim Anlegen zweier weiterer in dieser Form verketteter Gruppen gab es nunmehr für die letzte neu angelegte Gruppenkombination plötzlich den Effekt, dass alle, in der zweiten Gruppe befindlichen Gruppenmitglieder, sich nicht mehr via PrepiumApp an der Starface anmelden können. Es ist eindeutig so, dass es sich um benannte Gruppenmitglieder handelt und auch nur diese - kein anderer Benutzer ist betroffen. Bei Entfernen eines Benutzers aus jener zweiten Gruppenstufe kann der sich auch sofort wieder anmelden.

Gibt es für solche Gruppenkonstellationen mit Blick auf die Anzahl von Gruppen und Gesamtgruppenmitgliedern eine Limitierung?

Die bisher genutzten Gruppen sind bezüglich der Gruppenmitglieder sehr umfangreich, wobei es eine untere zweistellige Anzahl von Gruppen gibt. Die betreffende Starface-Installation ist bis an die Grenzen des vom genutzten Linuxunterbau überhaupt verarbeitbaren RAM und CPU bestückt, hat also von dieser Seite technisch eher gar keine Mühe damit und verhält sich mit Blick auf genutzte Ressourcen auch komplett unauffällig und ruhiger als so manche Standardinstallation ...

Gibt es dazu irgendwelche Hinweise?

@Starface?

Hallo Fabian,

danke für die Info - dann haben wir die Erklärung - da wird teils deutlich mehr transportiert (punktuell wohl über das Doppelte). Der Zusammenhang zum Umfang der UCI-Requests liegt dann sicher noch in Kombination an einer anderen Stelle, die ich hier gar nicht weiter erwähnen und beschreiben mag und die ich zum Glück nach längerer Überzeugungsarbeit dem Kunden ausreden konnte. Offenkundig wurde dann jetzt definitiv eine Schmerzgrenze überschritten - Dein Hinweis erklärt das jedenfalls.

Das heißt aber auch, dass diese Limitierung auch bei Folgeversionen der SF gilt, oder?

Hallo Fabian,

ich bin mir jetzt nicht sicher, ob ich an den richtigen Stellen dafür gesucht habe - in der mit bekannten Openfire-Konfiguration kann ich dazu nichts finden, aber vielleicht suche ich nach etwas Falschem oder an der falschen Stelle.

Sicherheitshalber: Die betreffende Angabe wäre exakt wo zu finden?

Hallo Fabian,

super - besten Dank ... damit passt es jetzt! Super und DANKE!

Nachdem Fabians Hinweis goldrichtig war und die Openfire-Anpassung sofort eindeutig nachvollziehbare Besserung gebracht hat, gibt es bei jener Instalation jetzt noch eine andere Auffälligkeit, die vermutlich eine andere Ursache hat:

Einer der Benutzer loggt sich mit seinem Windows-Client auf der Starface ein und dann beginnt nach einiger Zeit die sichtbare Chatverfügbarkeit in relativ schnellem Wechsel an und aus zu gehen. So ist das dann auf der Starface z.B. in BLFs sichtbar. Der Client bleibt auch selbst stabil angemeldet und zeigt sonst auf Seiten der Starface vermeintlich kein sonstig sichtbares Fehlverhalten.

Der Nutzer selbst beschreibt es so, dass er den Client teils gar nicht nutzen kann - sich das bei Ihm als "unverbunden" darstellt (was es aber definitiv nicht ist) - im Client wird beim genutzten Softphone ein ! angezeigt - der Chat witzigerweise als verfügbar.

Client-Alzheimer?

Auf Seiten der Starface kann man auch sehen, dass selbst Anrufe dorthin geleitet werden - also von Seiten der Anlage auch technisch von einem vorhandenen Client ausgegangen wird. Mit Blick auf den auswertbaren Chatstatus des Benutzers sieht es so aus, als gäbe es "mehrere Anmeldungen des gleichen Accounts" mit uneindeutigem - unterschiedlichem Ergebnis der Auswertung des Chatstatus.

Betroffen ist nur eben jener eine Nutzer (von über 350). Der Nutzer ist nicht neu - den gibt es so schon lange, funktioniert hat der bisher problemlos bis eben auch der sich zunächst nicht mehr anmelden konnte (siehe gelöstes Problem). Bei anderen Nutzern, die jenes erste Anmeldeproblem hatten, tritt das defitiv nicht auf.

Wo kann man ansetzen?

... den Client hat der benutzer wohl schon mehrfach neu auf seinem PC installiert (nach vorherig, vollständiger Entfernung).

In dem Fall handelt es sich aus rein organisatorischen Gründen (aktuell noch) um einen 6.7.x-Installation mit dem dafür passenden Client.

Hallo Fabian,

nein - von Deinen diesbezüglichen Modulen ist dort nichts installiert - hier wird ein eigenes Modul dafür verwendet (was es auch schon etwas länger als Deine diesbezüglichen Module gibt und auch etwas anders ausgerichtet ist ). Allerdings ist jenes Modul für den betroffenen Benutzer gar nicht aktiv und das Problem tritt auch dann auf, wenn das Modul bzw. dessen Instanzen komplett deaktiviert ist - in diese Richtung hatte ich auch schon gedacht.

Nachtrag:

Das Problem trat unvermittelt auf - funktionierte vorher monatelang völlig problemlos. Das Einzige, was wohl passiert ist: der Benutzerclient wurde dort in der Firma mehrfach neu installiert, als das Ursprungsproblem (aus diesem Beitrag) aufgetreten war.

Punkt 1 und 2 habe ich schon letzte Woche dem Kunden auch vorgeschlagen, um das ganze einkreisen zu können. Jetzt muss das zunächst nur auch mal umgesetzt werden ...

Den Hinweis zum Thema Outlook Terminplanung werde ich nochmal etwas genauer betrachten lassen.