In der Standardkonfiguration von HCL Connections Touchpoint bekamen wir das Feedback, dass die Software ständig automatisch neu aufgerufen werde. Nicht in Intervallen von Monaten, sondern Tagen – teils sogar Stunden. Dies war natürlich nicht Sinn der Sache. Zusammen mit Christoph Stöttner habe ich das Problem analysiert und es konnte ein Workaround gefunden werden.
Was ist Touchpoint?
Die Software ist möglicherweise noch gar nicht allen bekannt. Bei Touchpoint handelt es sich um eine Art Onboarding-Assistent: Neue Nutzer werden durch wichtige Systemfunktionen geführt. Dazu gehört beispielsweise das Ausfüllen ihres Profiles oder dem Folgen von Communitys/Kollegen. Zusätzlich kann man den Nutzer auf seine Datenschutzerklärung und Nutzungsbedingungen verweisen, sodass zur Verwendung des Systemes beides akzeptiert werden muss. Praktisch: Die Nutzungsbedingungen können versioniert werden. Steht eine neue Version zur Verfügung, öffnet sich der Touchpoint automatisch erneut.
Touchpoint gibt es zwar bereits seit einigen Jahren. Bisher jedoch als eigenständige Komponente, die händisch installiert werden musste. Mit Connections 6.5.1 änderte HCL dies und lieferte die Anwendung standardmäßig mit Connections aus – allerdings nicht aktiv. Wer sie nutzen möchte, muss sie in der touchpoint-config.xml aktivieren.
Wo werden die Daten gespeichert?
Diese Frage war essenziell, um das Problem überhaupt sinnvoll analysieren zu können. Sämtliche Daten werden als benutzerdefinierte Profilfelder in der PeopleDB-Tabelle PROFILE_EXTENSIONS gespeichert und somit einem Connections-Profil zugeordnet:
touchpointSession ist ein riesiges JSON-Dokument, binär gespeichert. Es enthält sämtliche Informationen zum und über den Benutzer, sobald er eine Touchpoint-Sitzung begonnen hat. Neben der Ausstiegsseite umfasst dies auch beispielsweise eingegebene Daten. Der Anwender muss also nicht von neuem beginnen, wenn er Touchpoint abbricht.
privacyAndGuidelines enthält die Version der Nutzungsbedingungen, die akzeptiert wurden. Im obigen Beispiel ist dies Version 1.0. Erscheint eine neue Version 1.1, kann das System dadurch erkennen, dass der Nutzer die neue Version noch nicht akzeptiert hat und leitet ihn daher zu Touchpoint um.
touchpointState speichert den Zeitstempel des erfolgreichen Abschlusses in einem kleinen JSON-Dokument. Dementsprechend wird es erst angelegt, nachdem der Touchpoint vollständig durchlaufen wurde.
Warum muss der Touchpoint ständig neu absolviert werden?
Zusammenfassend war meine Feststellung bei der Fehlersuche: Der Nutzer schließt den Touchpoint erfolgreich ab, wodurch die Profilfelder touchpointState und privacyAndGuidelines entsprechend gesetzt wurden. Die detailliertere Beobachtung zeigte jedoch, dass diese Daten später aus unerklärlichen Gründen wieder verschwanden. Folglich erscheint der Touchpoint erneut, da der Nutzer ihn laut vorliegenden Daten nie abgeschlossen hatte. Allerdings teils deutlich verzögert. Dies scheint mit verschiedenen Caching-Mechanismen auf Client- und Serverseite zusammenzuhängen. Weiter erschwert wurde die Analyse dadurch, dass nicht alle Benutzer betroffen waren. Es schien kein Muster zu geben – mal betraf es neue Nutzer die den Touchpoint erst kürzlich abgeschlossen haben. Teils auch ältere.
Die Ursache lag in einer problematischen Standardkonfiguration des TDI: Dieser geht davon aus, dass die Touchpoint-Daten im LDAP gespeichert sind. Dafür müsste man eine Schemaerweiterung für alle benötigten Felder durchführen. Ferner sehe ich wenig Sinn darin. Diese Daten gehören zu Connections und damit in die Datenbank der Anwendung. Gerade beim großen JSON-Dokument in touchpointSession sehe ich zudem Probleme. Nachvollziehbar wäre eine zentrale Speicherung höchstens noch beim privacyAndGuidelines Attribute. So könnte aus anderen Anwendungen heraus leicht abgefragt werden, ob und wenn ja welche Version der Nutzer akzeptiert hat.
Unabhängig davon versucht der TDI, die Felder aus dem LDAP in Connections zu synchronisieren. Und hier liegt das Problem: Fehlen die vom Touchpoint verwendeten LDAP-Felder, wird kein Fehler geworfen. Stattdessen geht der TDI von einem leeren Wert aus. Hat der Nutzer Touchpoint abgeschlossen, überschreibt der TDI beim nächsten Durchlauf diesen Datensatz. Allerdings nur, wenn sich an dem dazugehörigen LDAP-Nutzer auch etwas geändert hat. Dadurch war das Problem nur schwer zu erkennen und zu reproduzieren: Erst wenn der TDI eine Änderung erkennt, wird der Touchpoint durch die Löschung zurückgesetzt.
So lässt sich das automatische Löschen verhindern
Es gibt grundsätzlich zwei Möglichkeiten:
- Die TDI-Konfiguration wird angepasst, um sämtliche Touchpoint-Attribute nicht zu synchronisieren
- Man möchte die Daten im LDAP speichern und legt eine geeignete Schemaerweiterung selbstständig an
Aus obigen Gründen sehe ich Variante 2 als sinnvoller an. Hierzu reicht es jedoch nicht, sämtliche Attribute in der map_dbrepos_from_source.properties Konfigurationsdatei auf Null zu setzen:
extattr.touchpointSession=nullStattdessen müssen die Felder komplett aus der Konfiguration entfernt werden. Dabei beginnen wir bei den benutzerdefinierten Feldern in der Datei conf/LotusConnections-config/tdi-profiles-config.xml. Dort sind alle drei o.g. Felder definiert inklusive recommendedTags und departmentKey. Wie der Name vermuten lässt, sammelt das System in recommendedTags ein paar personalisierte Schlagwörter, die dem Nutzer angeboten werden sollen. Alle vier müssen dort wie folgt auskommentiert oder alternativ gelöscht werden:
<!--
These extension attributes are required by the 'Touchpoint' component
-->
<!--
<simpleAttribute extensionId="recommendedTags" length="256" sourceKey="recommendedTags" />
<!--<simpleAttribute extensionId="departmentKey" length="256" sourceKey="departmentKey" />
<simpleAttribute extensionId="privacyAndGuidelines" length="256" sourceKey="privacyAndGuidelines" />
<simpleAttribute extensionId="touchpointState" length="256" sourceKey="touchpointState" />
<richtextAttribute extensionId="touchpointSession" maxBytes="1000000" sourceKey="touchpointSession" />
-->
Anschließend die Definitionen auch in conf/LotusConnections-config/profiles-types.xml entfernen
<!--
<property>
<ref>recommendedTags</ref>
<updatability>readwrite</updatability>
<hidden>true</hidden>
<fullTextIndexed>false</fullTextIndexed>
</property>
<property>
<ref>departmentKey</ref>
<updatability>read</updatability>
<hidden>true</hidden>
<fullTextIndexed>true</fullTextIndexed>
</property>
<property>
<ref>privacyAndGuidelines</ref>
<updatability>readwrite</updatability>
<hidden>true</hidden>
<fullTextIndexed>false</fullTextIndexed>
</property>
<property>
<ref>touchpointState</ref>
<updatability>readwrite</updatability>
<hidden>true</hidden>
<fullTextIndexed>false</fullTextIndexed>
</property>
<property>
<ref>touchpointSession</ref>
<updatability>readwrite</updatability>
<hidden>true</hidden>
<fullTextIndexed>false</fullTextIndexed>
</property>
-->
Testlauf
Verifizieren lässt sich der Workaround mit folgenden Schritten, die im besten Falle mit einem eigens angelegten Testbenutzer durchgeführt werden:
- Der Benutzer schließt den Touchpoint ab
- In der Datenbank prüfen, dass der entsprechende Datensatz zum Abschluss vorliegt
- Ein synchronisiertes Feld im LDAP des Testbenutzers ändern, beispielsweise der Anzeigename (displayName)
- Nun den TDI durch Aufruf von ./sync_all_dns.sh synchronisieren lassen. Es muss eine Änderung im Log sichtbar sein:
After synchronization, added or modified records is 1 … - Ein erneuter Blick in die Datenbank sollte zeigen, dass der Abschluss für den Testbenutzer dort weiterhin gespeichert ist
Warum nicht einfach Connections mit dem Testbenutzer im Browser öffnen, statt in der Datenbank zu schauen?
Wie bereits oben erwähnt, gibt es hier offensichtlich mehrere Layer an Caches. Teilweise funktioniert es in einem Ikognito-Fenster bzw. nach dem Löschen aller clientseitigen Speicher des Browsers – jedoch nicht immer. Auch das neu einloggen ist keine Garantie. Dies hat die Fehlersuche anfangs verkompliziert, da der Touchpoint teilweise erst etliche Tage nach der Löschung des Datensatzes wieder sichtbar wurde. Die Datenbank ist daher am zuverlässigsten – früher oder später werden alle Caches geleert, dann zählt was in unserer DB steht.