ActivityStream Integrationen in IBM Connections mit OAuth

In IBM Connections 4.0 wurde der ActivityStream als zen­tra­les Informationsquelle ein­ge­führt. IBM ver­wen­det dabei keine 100%ige Eigenentwicklung, son­dern hat mit zahl­rei­chen Partnern zu einem Standard ActivityStrea.ms zusam­men­ge­schlos­sen. Dadurch wird die Möglichkeit gebo­ten Erweiterungen für meh­rere Systeme ledig­lich durch gering­fü­gige Anpassung lauf­fä­hig umzu­set­zen. 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 defi­niert und gut doku­men­tiert. In die­sem Artikel soll die Integration von Twitter in IBM Connections exem­pla­risch vor­ge­stellt werden.

Wie bereits erwähnt ver­wen­det IBM Connections den ActivityStrea.ms-Standard zur Umsetzung ihres ActivityStreams. Dadurch sind einer­seits im Standard als auch in der Produktdokumentation von IBM kleine Bespiele und Informationen vor­han­den, die den Einstieg in die Thematik erleich­tern. Im Prinzip stellt IBM Connections eine Web-Schnittstelle bereit, die externe Events im JSON-Format ent­ge­gen nimmt und in den ent­spre­chen­den Stream ablegt. Connections ver­wal­tet für jeden Nutzer meh­rere Streams je Anwendung, die zuvor in der Administration regis­triert wurden.

In mei­nem Beispiel sol­len die Nachrichten meine Twitter-Homeline auch in IBM Connections erschei­nen und zwar mög­lichst zeit­nah und detail­liert  Dazu muss ein Service ange­legt wer­den, der aller x Minuten die let­zen Statusupdates mei­nes Twitter-Profils zu laden. Da dies wie die meis­ten per­sön­li­chen Informationen im Internet nicht ohne Anmeldung funk­tio­niert, muss mir der Service die Möglichkeit geben mich bei Twitter anzu­mel­den. Twitter bie­tet dazu eine OAuth-Schnittstelle, mit der ich exter­nen Anwendungen Zugriff zu mei­nen Statusupdates gewäh­ren las­sen kann. Für die Umsetzung bie­tet sich twitter4j an. Es han­delt sich dabei um eine Java-Implementierung der Twitter-API. Twitter4j beinhal­tet bereits OAuth zur Authentifizierung. Dadurch hat der Nutzer die Möglichkeit dem Service lesende oder schrei­bende 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 anmel­den und der exter­nen Anwendung die nöti­gen Rechte geben, im Hintergrund wer­den 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ög­lichst zeit­nah über neue Posts infor­miert wer­den möchte, bie­tet Twitter ent­we­der die Möglichkeit die Stream-API, eine Art Dauerverbindung zu Twitter, oder aber die maxi­male Anzahl an Abfrage pro Intervall zu ver­wen­den. Ich habe mich in die­sem Beispiel für den 2. Weg ent­schie­den, da Twitter je Nutzer und Anwendung (die bei Twitter regis­triert wer­den muss) 15 Anfragen in 15 Minuten erlaubt, sodass die Updates minüt­lich abge­fragt wer­den können.

Nachdem nun minüt­lich bei Twitter gefragt wird, ob neue Updates ver­füg­bar sind und diese zu laben müs­sen die Post nun noch in das JSON-Format gebracht wer­den und an den jewei­li­gen ActivityStream gepos­tet wer­den. Das JavaScript-Objekt, das erzeugt wird in rela­tiv über­sicht­lich auf­ge­baut. 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 meh­rer Aktivitäten  Anschließend wird der Actor defi­niert. Im Beispiel ist es ein fik­ti­ver Wert, da IBM Connections die­sen Wert zwar benö­tigt, aber nicht aus­wer­tet. Relevant im JavaScript-Objekt sind noch Title und Object. Title ist der Titel der Nachricht, der im ActivityStream ange­zeigt wird. Im Object wird der eigent­li­che Status hin­ter­legt. Summary wird unter­halb des Titels ange­zeigt, wenn keine "content"-Objekt vor­han­den ist.

Das JSON-Objekt wird anschlie­ßend an 

https://connections-server/connections/opensocial/basic/rest/activitystreams/user-id/@all/@all 

gepos­tet. Die 3 letz­ten Parameter sind ver­än­der­bar. Die user-id gibt den Nutzer an in des­sen Activity Stream gepos­tet wird. Erlaubte Werte sind die UUID des Nutzers oder @me für den eige­nen Stream. Der zweite Parameter gibt an, ob die nach­richt öffent­lich gepos­tet wer­den soll. @All ist hier Standard. Der dritte Parameter gibt an für wel­che Anwendung gepos­tet wer­den soll. Da im Generator die Anwendung defi­niert wurde kann hier getrost @all ver­wen­det werden.

Die end­gül­tige Umsetzung sieht dann wie folgt aus:

Auf der rech­ten Seite habe ich ein Widget ergänzt, der das Abonnieren des Services erlaubt. In der Mitte sieht man die Posts mei­ner Timeline.