In IBM Connections 4.0 wurde der ActivityStream als zentrales Informationsquelle eingeführt. IBM verwendet dabei keine 100%ige Eigenentwicklung, sondern hat mit zahlreichen Partnern zu einem Standard ActivityStrea.ms zusammengeschlossen. Dadurch wird die Möglichkeit geboten Erweiterungen für mehrere Systeme lediglich durch geringfügige Anpassung lauffähig umzusetzen. Nutzer des Standards sind neben IBM auch Facebook, Google Buzz, MySpace und Windows Live (siehe ActivityStrea.ms - Implementors). Durch den Standard sind die Schnittstellen klar definiert und gut dokumentiert. In diesem Artikel soll die Integration von Twitter in IBM Connections exemplarisch vorgestellt werden.
Wie bereits erwähnt verwendet IBM Connections den ActivityStrea.ms-Standard zur Umsetzung ihres ActivityStreams. Dadurch sind einerseits im Standard als auch in der Produktdokumentation von IBM kleine Bespiele und Informationen vorhanden, die den Einstieg in die Thematik erleichtern. Im Prinzip stellt IBM Connections eine Web-Schnittstelle bereit, die externe Events im JSON-Format entgegen nimmt und in den entsprechenden Stream ablegt. Connections verwaltet für jeden Nutzer mehrere Streams je Anwendung, die zuvor in der Administration registriert wurden.
In meinem Beispiel sollen die Nachrichten meine Twitter-Homeline auch in IBM Connections erscheinen und zwar möglichst zeitnah und detailliert Dazu muss ein Service angelegt werden, der aller x Minuten die letzen Statusupdates meines Twitter-Profils zu laden. Da dies wie die meisten persönlichen Informationen im Internet nicht ohne Anmeldung funktioniert, muss mir der Service die Möglichkeit geben mich bei Twitter anzumelden. Twitter bietet dazu eine OAuth-Schnittstelle, mit der ich externen Anwendungen Zugriff zu meinen Statusupdates gewähren lassen kann. Für die Umsetzung bietet sich twitter4j an. Es handelt sich dabei um eine Java-Implementierung der Twitter-API. Twitter4j beinhaltet bereits OAuth zur Authentifizierung. Dadurch hat der Nutzer die Möglichkeit dem Service lesende oder schreibende Rechte auf seine Twitter-Daten zu geben ohne das der Service Nutzernamen oder Passwort des Twitteraccount sichern muss. Beim Abonnieren der Twitter-Updates muss sich der Nutzer bei Twitter anmelden und der externen Anwendung die nötigen Rechte geben, im Hintergrund werden dann Request- und Access-Token getauscht, sodass anschließend die Anfragen des Services bei Twitter erlaubt werden.
Apropos Anfragen, da ich wie bereits erwähnt möglichst zeitnah über neue Posts informiert werden möchte, bietet Twitter entweder die Möglichkeit die Stream-API, eine Art Dauerverbindung zu Twitter, oder aber die maximale Anzahl an Abfrage pro Intervall zu verwenden. Ich habe mich in diesem Beispiel für den 2. Weg entschieden, da Twitter je Nutzer und Anwendung (die bei Twitter registriert werden muss) 15 Anfragen in 15 Minuten erlaubt, sodass die Updates minütlich abgefragt werden können.
Nachdem nun minütlich bei Twitter gefragt wird, ob neue Updates verfügbar sind und diese zu laben müssen die Post nun noch in das JSON-Format gebracht werden und an den jeweiligen ActivityStream gepostet werden. Das JavaScript-Objekt, das erzeugt wird in relativ übersichtlich aufgebaut. Hier ein Beipiel:
{
"generator": {
"image": { "url": "https://twitter.com/images/resources/twitter-bird-blue-on-white.png"},
"id": "tweetApp",
"displayName": "Twitter",
"url": "http://www.twitter.com/"
},
"actor": { "id": "TwitterAuthor" },
"verb": "post",
"title": "User has posted a status.",
"updated": "2012-05-08T12:00:00.000Z",
"object": {
"summary": "This is a test message",
"objectType": "note",
"id": "XXXXXXXXXXXXXXXXXXXXXXX",
"displayName": "User has posted a status",
"url": "https://twitter.com/User/status/XXXXXXXXXXXXXXXXXXXXXXX",
}
}
Der Generator gibt an wie die Anwendung heißt, die das ActivityStream-Objekt erzeugt hat. Im Beipiel ist es Twitter. Die ID darin nutzt IBM Connections zur Zuordnung der mehrer Aktivitäten Anschließend wird der Actor definiert. Im Beispiel ist es ein fiktiver Wert, da IBM Connections diesen Wert zwar benötigt, aber nicht auswertet. Relevant im JavaScript-Objekt sind noch Title und Object. Title ist der Titel der Nachricht, der im ActivityStream angezeigt wird. Im Object wird der eigentliche Status hinterlegt. Summary wird unterhalb des Titels angezeigt, wenn keine "content"-Objekt vorhanden ist.
Das JSON-Objekt wird anschließend an
https://connections-server/connections/opensocial/basic/rest/activitystreams/user-id/@all/@all
gepostet. Die 3 letzten Parameter sind veränderbar. Die user-id gibt den Nutzer an in dessen Activity Stream gepostet wird. Erlaubte Werte sind die UUID des Nutzers oder @me für den eigenen Stream. Der zweite Parameter gibt an, ob die nachricht öffentlich gepostet werden soll. @All ist hier Standard. Der dritte Parameter gibt an für welche Anwendung gepostet werden soll. Da im Generator die Anwendung definiert wurde kann hier getrost @all verwendet werden.
Die endgültige Umsetzung sieht dann wie folgt aus:
Auf der rechten Seite habe ich ein Widget ergänzt, der das Abonnieren des Services erlaubt. In der Mitte sieht man die Posts meiner Timeline.