Das Service Provider Interface ermöglicht es eine Ereignisbehandlung in IBM Connections zu realisierbar. Damit ist es möglich bestimmte Aktionen auszuführen, wenn ein Event eintritt. Ebenfalls bietet es die Möglichkeit eigene Suchmaschinen an IBM Connections zu binden, um beispielsweise eine Unternehmens weite Suche zu integrieren. In diesem Beitrag soll die Eventbehandlung im Vordergrund stehen.
Bei der Ereignisbehandlung gibt es zwei verschiedene Aktionen die abgefangen werden. Zum einen gibt es eine Ereignisvorbehandlung, den sogenannten Pre-Event-Handler und eine Ereignisnachbehandlung, den Post-Event-Handler. Der Pre-Event-Handler wird immer synchron (live) ausgeführt, das heißt, dass die komplette interne Ereignisbehandlung die in IBM Connections integriert ist, durch die neue Routine unterbrochen, sodass der Nutzer bei langwierigen Prozessen ausgebremst wird. Es wird gewartet bis der neue Prozessabschnitt durchgelaufen ist und mit der internen Abarbeitung fortgeführt werden kann. Bei der Ereignisnachbehandlung kann zwischen asynchron und synchron gewählen werden. Eine asynchrone Behandlung kann bewirken das Events bei Behandlung bereits einige Augenblicke vergangen sind, bis die neue Aktion ausgeführt wird. IBM empfiehlt eine asynchrone Ereignisbehandlung, da so die Ausführung des Hauptprozesses unabhängig ist und nicht blockiert wird.
Zusätzlich zu der Frage an welchen Zeitpunkt ein Ereignis abgefangen wird, muss geklärt werden welche Ereignisse überhaupt abgearbeitet werden soll. IBM bietet dazu eine ziemlich einfache, aber umfassende Möglichkeit. Es existiert eine dreigeteilte Ereignis-Beschreibung, die in der jeweiligen Konfiguration angegeben werden muss. Der erste Teil dieser Beschreibung gibt die Anwendung an, in der das Event auftritt. In der nachfolgenden Tabelle werden alle Möglichkeiten aufgefü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 werden, die überwacht werden soll. Die möglichen Eregnisse sind in der nachfolgenden Tabelle aufgeführt:
Ereignis | Schlüsselwort |
alle Ereignisse | * |
For event representing the acknowledgment of a platform command. | ACKCOM |
For event representing the approval of content for moderation. | APPROVE |
For events generated specific to some audit need. | AUDIT |
For event representing the invocation of a platform command. | COMMAND |
For events representing the successful storage of some new content that is now visible in the product UI/APIs. | CREATE |
For events representing the deletion of some existing content e.g. a blog entry, tag, status update. | DELETE |
For event representing the moderation decision to not quarantine content. | DISMISS |
For event representing the moderation flagging of content. | FLAG |
For event representing an update to inactive content e.g. when in quarantine. | INACTIVE_UPDATE |
For events representing the modification of membership or access control for a given resource. | MEMBERSHIP |
For events generated specific to some moderation need. | MODERATE |
For events representing notifications. Should only be set in events created by the notification framework. | NOTIFY |
For event representing the moderation decision to quarantine content. | QUARANTINE |
For event representing the fact that content is pending moderation. | PEND |
For events representing initial creation of a resource before it is visible in the UI. | PRECREATE |
For events representing a user consuming existing information. Not regularly used. | READ |
For event representing the rejection of content for moderation. | REJECT |
For event representing the restoration of some inactive content to an active state. | RESTORE |
For event representing the fact that content is returned to author in post-moderation workflow. | RETURN |
For events representing the update of some existing content, e.g. by editing, adding new tags etc. | UPDATE |
Quelle: JavaDoc com.ibm.connections.spi.events.object.Event.Type |
In der dritten Option besteht die Möglicheit das Event genau zu beschreiben, sodass nur dies von Event-Handler abgefangen wird. Mögliche EventNamen sind auf folgender Seite zusammengefasst: IBM Connections wiki: Developing: Events Reference
Nachdem das Ereignis definiert und die Bearbeitungsart gewählt ist, kann mit der eignetlichen Implementierung begonnen werde. Das Event SPI besteht im eigentlichen aus einer Java-bibliothek, die in das eigene Programm integriert werden muss. Diese Bibliothek bietet die eigentlichen Schnittstellen, die für die Integration benötigt werden. Das Wichtigste daran sind die Methoden handleEvent(Event event)
, die in sowohl im Event-Handler als auch im Pre-EventHandler zur Verfügung stehen. Mit Hilfe dieser Methode lassen sich beliebige Ereignisse abfangen und behandeln.
Damit die Ereignis-Behandlung funktioniert muss die entstandene Java-Bibliothek noch in IBM Connections integriert werden. Dazu muss die JAR-Datei in das "Shared libraries"-Verzeichnis innerhalt des AppServers kopiert werden. Der Pfad des Verzeichnisses wird in der "Shared libraries" Variable des WebSphere Application Servers definiert.
Anschließend muss der Eventlistener noch in IBM Connections bekannt gemacht werden. Dies geschieht mit dem Eintrag in der "events-config.xml"-Datei der LotusConnections Konfiguration. In dieser Datei müssen alle bisher festgelegten Optionen angeben 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 obligatorischen Neustart des Servers steht der Event-Behandlung nichts mehr im Wege.