IBM Connections SPI - Eventbehandlung

Das Service Provider Interface ermög­licht es eine Ereignisbehandlung in IBM Connections zu rea­li­sier­bar. Damit ist es mög­lich bestimmte Aktionen aus­zu­füh­ren, wenn ein Event ein­tritt. Ebenfalls bie­tet es die Möglichkeit eigene Suchmaschinen an IBM Connections zu bin­den, um bei­spiels­weise eine Unternehmens weite Suche zu inte­grie­ren. In die­sem Beitrag soll die Eventbehandlung im Vordergrund stehen.

Bei der Ereignisbehandlung gibt es zwei ver­schie­dene Aktionen die abge­fan­gen wer­den. Zum einen gibt es eine Ereignisvorbehandlung, den soge­nann­ten Pre-Event-Handler und eine Ereignisnachbehandlung, den Post-Event-Handler. Der Pre-Event-Handler wird immer syn­chron (live) aus­ge­führt, das heißt, dass die kom­plette interne Ereignisbehandlung die in IBM Connections inte­griert ist, durch die neue Routine unter­bro­chen, sodass der Nutzer bei lang­wie­ri­gen Prozessen aus­ge­bremst wird. Es wird gewar­tet bis der neue Prozessabschnitt durch­ge­lau­fen ist und mit der inter­nen Abarbeitung fort­ge­führt wer­den kann. Bei der Ereignisnachbehandlung kann zwi­schen asyn­chron und syn­chron gewäh­len wer­den. Eine asyn­chrone Behandlung kann bewir­ken das Events bei Behandlung bereits einige Augenblicke ver­gan­gen sind, bis die neue Aktion aus­ge­führt wird. IBM emp­fiehlt eine asyn­chrone Ereignisbehandlung, da so die Ausführung des Hauptprozesses unab­hän­gig ist und nicht blo­ckiert wird.

Zusätzlich zu der Frage an wel­chen Zeitpunkt ein Ereignis abge­fan­gen wird, muss geklärt wer­den wel­che Ereignisse über­haupt abge­ar­bei­tet wer­den soll. IBM bie­tet dazu eine ziem­lich ein­fa­che, aber umfas­sende Möglichkeit. Es exis­tiert eine drei­ge­teilte Ereignis-Beschreibung, die in der jewei­li­gen Konfiguration ange­ge­ben wer­den muss. Der erste Teil die­ser Beschreibung gibt die Anwendung an, in der das Event auf­tritt. In der nach­fol­gen­den Tabelle wer­den alle Möglichkeiten auf­ge­führt und kurz beschrieben.

Anwendung	Schlüsselwort
alle Anwendungen	*
Aktivitäten	ACTIVITIES
Blogs	BLOGS
Lesezeichen	BOOKMARKS
Communities	COMMUNITIES
Dateien	FILES
Foren	FORUMS
Homepage	HOMEPAGE
Mobile Oberfläche	MOBILE
Neuigkeiten(Statusmeldungen, Benachrichtigungen)	NEWS
Profile	PROFILES
Suche (Aktualisierung des Suchindexes)	SEARCH
Wikis	WIKIS

Zusätzlich zur Anwendung muss noch die Aktion (oder Ereignistyp) gewählt wer­den, die über­wacht wer­den soll. Die mög­li­chen Eregnisse sind in der nach­fol­gen­den Tabelle aufgeführt:

Ereignis	Schlüsselwort
alle Ereignisse	*
For event repre­sen­ting the ack­now­ledgment of a plat­form command.	ACKCOM
For event repre­sen­ting the appro­val of con­tent for moderation.	APPROVE
For events gene­ra­ted spe­ci­fic to some audit need.	AUDIT
For event repre­sen­ting the invo­ca­tion of a plat­form command.	COMMAND
For events repre­sen­ting the suc­cess­ful sto­rage of some new con­tent that is now visi­ble in the pro­duct UI/APIs.	CREATE
For events repre­sen­ting the dele­tion of some exis­ting con­tent e.g. a blog entry, tag, sta­tus update.	DELETE
For event repre­sen­ting the mode­ra­tion decision to not qua­ran­tine content.	DISMISS
For event repre­sen­ting the mode­ra­tion flag­ging of content.	FLAG
For event repre­sen­ting an update to inac­tive con­tent e.g. when in quarantine.	INACTIVE_UPDATE
For events repre­sen­ting the modi­fi­ca­tion of mem­bers­hip or access con­trol for a given resource.	MEMBERSHIP
For events gene­ra­ted spe­ci­fic to some mode­ra­tion need.	MODERATE
For events repre­sen­ting noti­fi­ca­ti­ons. Should only be set in events crea­ted by the noti­fi­ca­tion framework.	NOTIFY
For event repre­sen­ting the mode­ra­tion decision to qua­ran­tine content.	QUARANTINE
For event repre­sen­ting the fact that con­tent is pen­ding moderation.	PEND
For events repre­sen­ting initial crea­tion of a resource before it is visi­ble in the UI.	PRECREATE
For events repre­sen­ting a user con­suming exis­ting infor­ma­tion. Not regu­larly used.	READ
For event repre­sen­ting the rejec­tion of con­tent for moderation.	REJECT
For event repre­sen­ting the res­to­ra­tion of some inac­tive con­tent to an active state.	RESTORE
For event repre­sen­ting the fact that con­tent is retur­ned to aut­hor in post-moderation workflow.	RETURN
For events repre­sen­ting the update of some exis­ting con­tent, e.g. by edi­t­ing, adding new tags etc.	UPDATE
Quelle: JavaDoc com.ibm.connections.spi.events.object.Event.Type

In der drit­ten Option besteht die Möglicheit das Event genau zu beschrei­ben, sodass nur dies von Event-Handler abge­fan­gen wird. Mögliche EventNamen sind auf fol­gen­der Seite zusam­men­ge­fasst: IBM Connections wiki: Developing: Events Reference

Nachdem das Ereignis defi­niert und die Bearbeitungsart gewählt ist, kann mit der eig­net­li­chen Implementierung begon­nen werde. Das Event SPI besteht im eigent­li­chen aus einer Java-bibliothek, die in das eigene Programm inte­griert wer­den muss. Diese Bibliothek bie­tet die eigent­li­chen Schnittstellen, die für die Integration benö­tigt wer­den. Das Wichtigste daran sind die Methoden handleEvent(Event event), die in sowohl im Event-Handler als auch im Pre-EventHandler zur Verfügung ste­hen. Mit Hilfe die­ser Methode las­sen sich belie­bige Ereignisse abfan­gen und behandeln.

Damit die Ereignis-Behandlung funk­tio­niert muss die ent­stan­dene Java-Bibliothek noch in IBM Connections inte­griert wer­den. Dazu muss die JAR-Datei in das "Shared libraries"-Verzeichnis inner­halt des AppServers kopiert wer­den. Der Pfad des Verzeichnisses wird in der "Shared libra­ries" Variable des WebSphere Application Servers definiert.

Anschließend muss der Eventlistener noch in IBM Connections bekannt gemacht wer­den. Dies geschieht mit dem Eintrag in der "events-config.xml"-Datei der LotusConnections Konfiguration. In die­ser Datei müs­sen alle bis­her fest­ge­leg­ten Optionen ange­ben werden:

...
<preHandlers>
    ...
    <preHandler enabled="true" name="Name des Handlers" class="Beizeichnung der Java-Klasse mit Package">
        <subscriptions>
            <subscription source="Name der Anwendung (siehe Tabelle 1)" type="Ereignistyp (siehe Tabelle 2)" 
                     eventName="Ereignisname (siehe Events Reference)" />
            ...
        </subscriptions>
        (es können noch RequestDataSets und Properties übergeben werden)
    </preHandler>
    ...
</preHandlers>
...

oder

...
<postHandlers>
    ...
    <postHandler enabled="true" name="Name des Handlers" class="Beizeichnung der Java-Klasse mit Package">
        <subscriptions>
            <subscription source="Name der Anwendung (siehe Tabelle 1)" type="Ereignistyp (siehe Tabelle 2)" 
                     eventName="Ereignisname (siehe Events Reference)" />
            ...
        </subscriptions>
        (es können noch Properties übergeben werden)
    </postHandler>
    ...
</postHandlers>
...

Nach einem Synchronisieren der Server-Knoten und dem obli­ga­to­ri­schen Neustart des Servers steht der Event-Behandlung nichts mehr im Wege.