Aus Linux-Magazin 12/2012

Wie OX und Zarafa auf die APIs von sozialen Netzwerken zugreifen

© Valentyn Volkov Volkov, 123RF.com

Die Groupwaresysteme Open-Xchange und Zarafa zapfen die APIs von Facebook, Twitter und Xing an und übernehmen deren Informationen in ihren Datenbestand. Damit das klappt, bedarf es einer eigenen Taktik für jeden Dienst – dennoch ist die Informationsausbeute manchmal ziemlich mager.

Egal ob Privatperson oder Unternehmen, fast jeder Internetnutzer führt mittlerweile Benutzerkonten bei zahlreichen Social-Web-Diensten. Diese zu jonglieren und zu koordinieren ist gar nicht so einfach: Die Freunde chatten auf Facebook, die Kollegen vernetzen sich auf Xing, während alle auf Twitter-Nachrichten warten. Moderne Groupwaresysteme wie Open-Xchange und Zarafa zapfen auf Wunsch die Daten des Social Web an und führen sie mit den vorhandenen zusammen (Stichwort: Server Side Mashup). So findet der Groupwarebenutzer beispielsweise im Adressbuch automatisch auch die Kontakte aus Facebook – zumindest ist das die Grundidee.

Offener Austausch

Hinter der Groupware Open-Xchange (OX) steht die gleichnamige Firma in Nürnberg, die ihren Ursprung im Suse-Umfeld hat, und zwar mit dem SLOX (Suse Linux Open Xchange Server). Neben kommerziellen Varianten gibt es auch eine kostenlose Community Edition, die der GPLv2 unterliegt [1]. OX dürfte darüber hinaus vielen Kunden von 1&1 bekannt vorkommen: Das Unternehmen setzt die Groupware in einer Hosting-Variante unter dem Namen 1&1 Mailxchange als Drehscheibe für seine E-Mail-Dienste ein.

Einige Linux-Distributionen bringen OX bereits in den Repositories mit. Fehlen jedoch passende Pakete, gestaltet sich die Installation ziemlich fummelig, da zunächst diverse andere Komponenten, zum Beispiel Datenbank, Webserver und Postfix, eingerichtet sein wollen. Wer selbst keine OX-Installation aufsetzen möchte, findet unter [2] eine Testinstallation. Nach der notwendigen Registrierung lässt sich dort auch die Integration von Facebook & Co. online testen.

Das Backend mit der eigentlichen Anwendungslogik ist in Java geschrieben und kommt als so genanntes OSGI-Bundle [3] ins Haus, das mitgelieferte Frontend besteht aus einer normalen Webanwendung, die in jedem Browser läuft. OX integriert die Social Networks Facebook, Linked In, Twitter und Xing. Dabei importiert die Groupware Kontakte aus Facebook, Linked In und Xing, als Messaging-Dienst lassen sich Facebook und Twitter einbinden.

Schlüsselmeister

Jeden Dienst zapft im Hintergrund ein spezielles Plugin an. Mit Ausnahme von Xing nutzen die Plugins die von den Social Networks bereitgestellte Programmierschnittstelle (API). Damit das klappt, muss der Admin zunächst den Zugriff bei den Diensten erlauben. Dazu erstellt er als Erstes über die Entwicklerseiten von Facebook & Co. eine so genannte Anwendung (auch als Application bezeichnet). Der Kasten “Gezwitscher” zeigt exemplarisch, wie dies bei Twitter funktioniert.

Gezwitscher

Um OX den Zugriff auf Twitter zu erlauben, wechselt der Admin zunächst auf die Entwicklerseiten unter [4]. Dort meldet er sich an, klickt auf »Create a new application« und füllt das Formular aus. Der »Name« der Anwendung erscheint später in OX, wenn dort der Zugriff auf Twitter erlaubt wird (Abbildung 1). Die beiden URLs können auf die eigene Homepage verweisen, wichtig ist nur, dass eine Callback-URL existiert.

Abbildung 1: Damit OX auf Twitter zugreifen kann, muss der Entwickler zunächst eine Applikation erstellen.

Abbildung 1: Damit OX auf Twitter zugreifen kann, muss der Entwickler zunächst eine Applikation erstellen.

Jetzt am unteren Rand die Lizenzbedingungen abnicken, das Captcha ausfüllen und auf <C>Create your Twitter application<C> klicken. Im neuen Fenster wechselt der Admin auf das Register <C>Settings<C>, setzt den Zugriff (<C>Access<C>) auf <C>Read and Write<C> und lässt die Einstellungen via <C>Update this Twitter application’s settings<C> aktualisieren.

Schlüssel übertragen

Auf dem Register <C>Details<C> finden sich jetzt unter den <C>OAuth settings<C> zwei kryptische Schlüssel (Abbildung 2): <C>Consumer key<C> und <C>Consumer secret<C>. Diese packt der Admin in die Konfigurationsdatei <C>/opt/open-xchange/etc/groupware/twitter.properties<C>, den <C>Consumer key<C> trägt er hinter <C>com.openexchange.twitter.consumerKey=<C> ein, das <C>Consumer secret<C> hinter <C>com.openexchange.twitter.consumerSecret=<C>. Die vorhandenen kryptischen Zeichenketten kann er einfach überschreiben. Danach lässt sich das Twitter-Konto mit dem Assistenten einbinden.

Abbildung 2: Das Ergebnis sind zwei Schlüssel, die wiederum in der OX-Konfiguration landen müssen.

Abbildung 2: Das Ergebnis sind zwei Schlüssel, die wiederum in der OX-Konfiguration landen müssen.

Nun ist in OX noch jeder gewünschte Dienst einzurichten. Das übernimmt normalerweise der beim ersten Start der OX-Weboberfläche erscheinende Assistent (Abbildung 3). In ihm klickt man auf das Symbol des entsprechenden Dienstes, vergibt einen passenden Accountnamen und lässt den Zugriff per »OK« autorisieren. Dazu öffnet OX ein neues Fenster mit einer Seite des Dienstes. Auf dem gibt der Admin die Groupware noch einmal explizit frei, indem er Benutzernamen und Passwort eintippt. Fertig sieht das Ganze aus wie in Abbildung 4.

Abbildung 3: Der Assistent übernimmt die Integration des Social Network in OX.

Abbildung 3: Der Assistent übernimmt die Integration des Social Network in OX.

Abbildung 4: Nach der Anmeldung bei Twitter integriert OX die Tweets.

Abbildung 4: Nach der Anmeldung bei Twitter integriert OX die Tweets.

Am Ende erhält er einen oder mehrere Schlüssel (Keys), die er in der entsprechenden OX-Konfigurationsdatei hinterlegt. Die Twitter-Schlüssel gehören beispielsweise in die Datei »twitter.properties« . Der Schlüssel ist für den Betrieb zwingend erforderlich, die Gründe erläutert Karsten Will von der Open-Xchange GmbH: “Je nach Netz ist dieser spezifisch für die URL des Servers, auf dem die (aus der Sicht des Dienstes) Clientapplikation betrieben wird. Ohne Key kein Zugriff. Teilweise schränken die Netzwerke noch die Keys auf bestimmte Funktionen ein. Bei Linked In ist es beispielsweise so, dass reguläre Nutzer des API keinen Zugriff auf die E-Mail-Adressen von Connections oder Profilen erhalten. Dies ist privilegierten Partnern wie uns oder Microsoft vorbehalten.”

Bei Facebook anklopfen mit Oauth und Scribe

Die Authentifizierung erfolgt bei allen Diensten über das Oauth-Protokoll [5]. Die dabei ablaufende Kommunikation wickelt OX jedoch nicht selbst ab: “Wir benutzen [die Java-Bibliothek (Red.)] Scribe [6] als Grundlage für die Oauth-Authentifizierung gegenüber den Diensten, angepasst an unsere eigenen Bedürfnisse”, so Karsten Will.

Dank Scribe genügen die wenigen Zeilen aus Listing 1, um die Kontakte aus Facebook rauszusaugen. Das Listing zeigt gekürzt die Funktion »getContacts()« aus der Klasse »com.openexchange.oauth.FacebookServiceImpl« .

Listing 1

getContacts()

01 public List<Contact> getContacts(Session session, int user, int contextId, int accountId) {
02
03   List<Contact> contacts = new ArrayList<Contact>();
04   OAuthService service = new ServiceBuilder().provider(FacebookApi.class).apiKey(facebookMetaData.getAPIKey()).apiSecret(facebookMetaData.getAPISecret()).build();
05
06   OAuthAccount account = null;
07   account = oAuthService.getAccount(accountId, session, user, contextId);
08
09   // get the users own profile (for his id) with the given access token
10   Token accessToken = new Token(account.getToken(), account.getSecret());
11   OAuthRequest ownProfileRequest = new OAuthRequest(Verb.GET, "https://graph.facebook.com/me");
12   service.signRequest(accessToken, ownProfileRequest);
13   Response ownProfileResponse = ownProfileRequest.send();
14
15   String myuid = "";
16   JSONObject object = new JSONObject(ownProfileResponse.getBody());
17   myuid = object.getString("id");
18
19   // get the users connections
20   OAuthRequest connectionsRequest = new OauthRequest(
21   Verb.GET,
22   "https://api.facebook.com/method/fql.query?query=SELECT%20name,first_name,last_name,email,birthday_date,pic_big,hometown_location%20from%20user%20where%20uid%20in%20%28SELECT%20uid2%20from%20friend%20where%20uid1=" + myuid + "%29&format=JSON");
23   service.signRequest(accessToken, connectionsRequest);
24   Response connectionsResponse = connectionsRequest.send();
25
26   // parse the returned JSON into neat little contacts
27   contacts = parseIntoContacts(connectionsResponse.getBody());
28     }
29
30   return contacts;
31 }

Im ersten Schritt teilt OX Scribe mit, dass es auf Facebook zugreifen möchte. OX muss dazu in Zeile 4 nur die API-Schlüssel und eine Provider-Klasse »FacebookApi.class« übergeben. Diese verrät Scribe, dass ein Zugriff auf Facebook erwünscht ist.

In den Zeilen 6 bis 10 erstellt OX ein so genanntes Access-Token, das es jeder Anfrage an Facebook beifügen muss. Mit dem Token in der Hand generiert OX in Zeile 11 eine neue Anfrage an Facebook, mit der es Zugriff auf das Profil des Benutzers einfordert. Anschließend packt es das zuvor erstellte Token zur Anfrage (»service.signRequest()« ).

Die Anweisungen ab Zeile 15 lösen aus der Antwort die User-ID heraus. Mit ihr baut OX ab Zeile 20 eine neue Anfrage zusammen, die alle Kontakte dieses Benutzers aus Facebook abfragt. Das Ergebnis dieser Anfrage ist ein Json-Objekt, das »parseIntoContacts()« in eine Liste mit »Contact« -Objekten umwandelt.

Diese Objekte verarbeitet wiedrum OX weiter. “Intern werden aus den Daten der Sozialen Netzwerke erst Java- und dann Json-Objekte, die die Software zum Beispiel an den Browser weiterreicht”, erläutert Karsten Will. Wer in die einzelnen Abläufe noch tiefer eintauchen möchte, sollte sich zunächst Scribe und dort besonders die Beispielprogramme anschauen [7]. Sie erleichtern Einsteigern das Verständnis des OX-Codes.

Nicht alles geht einfach

Welche Informationen die Social-Plugins so aus den Diensten herausziehen können, hängt maßgeblich von dem bereitgestellten API des Dienstes ab. So liest das Facebook-Plugin für jeden Kontakt den Nickname, den Nachnamen, das Geburtsdatum, das Bild, den Wohnort, die Stadt und die Postleitzahl. Andere Plugins schaffen mehr, etwa das Xing-Plugin. Eine ausführliche Liste, welches Plugin welche Informationen aus welchen Diensten anzapft, findet sich unter [8]. Anfragen oder Aufträge zu Plugins für weitere Dienste nimmt übrigens die Open-Xchange GmbH gerne an.

Kreuzweise anzapfen mit Screen-Scraping bei Xing

Ein kleiner Spezialfall ist Xing. Diesen Dienst zapft OX nicht über ein API, sondern per Screen-Scraping-Technik an. Dabei ruft OX die Xing-Seiten wie ein normaler Benutzer auf und liest dann aus den zurückgelieferten HTML-Seiten die benötigten Informationen aus. Warum Xing eine solche Extrawurst benötigt, erklärt Karsten Will: “Bei Xing nutzen wir noch Screen-Scraping, weil das Xing-API zwar seit letztem Dezember im Betatest ist, aber noch nicht über den initialen Kreis von 1000 Entwicklern hinaus verfügbar gemacht wurde.”

Wie OX an die Daten auf Xing herankommt, steuert die Datei »XING.yml« im Unterverzeichnis »/opt/open-xchange/etc/groupware/crawlers« . Durch diese Auslagerung der Programmlogik können die Entwickler schneller auf Änderungen bei Xing reagieren: Modifiziert Xing den HTML-Quellcode seiner Seiten, so müssen die OX-Entwickler lediglich die ».yml« -Datei aktualisieren.

Wie Listing 2 zeigt, ist diese noch nicht einmal besonders lang. Ihre Inhalte folgen der Auszeichnungssprache Yaml [9]. Interessant sind die Zeilen nach »steps« . Sie sind von oben nach unten recht einfach zu lesen und beschreiben den Login-Vorgang bei Xing sowie anschließend den Weg zu den Kontakten.

Listing 2

XING.yml

01 --- !com.openexchange.subscribe.crawler.CrawlerDescription
02 displayName: XING
03 id: com.openexchange.subscribe.xing
04 priority: 2
05 workflowString: |
06   --- !com.openexchange.subscribe.crawler.Workflow
07   steps:
08     - !com.openexchange.subscribe.crawler.LoginPageStep
09       baseUrl: "https://www.xing.com"
10       description: Login to www.xing.com
11       linkAvailableAfterLogin: /app/contact
12       nameOfLoginForm: loginform
13       nameOfPasswordField: login_password
14       nameOfUserField: login_user_name
15       pageTitleAfterLogin: /app/contact
16       password: ""
17       url: "https://www.xing.com"
18       username: ""
19     - !com.openexchange.subscribe.crawler.TextPagesByLinkStep
20       description: Get all vcards as text pages
21       linkpart: /app/contact?op=vcard;scr_id
22       offset: 10
23       urlAfterOffset: ""
24       urlBeforeOffset: "https://www.xing.com/app/contact?notags_filter=0;search_filter=;tags_filter=;offset="
25     - !com.openexchange.subscribe.crawler.ContactObjectsByVcardTextPagesStep {}

Kaffeezeit

Als Erstes öffnet OX die Homepage »www.xing.com« . Das Feld für die Eingabe des Benutzernamens hört auf den internen Namen »login_user_name« , wie ein Blick in den Seitenquelltext der Xing-Homepage beweist. Dort trägt OX den Benutzernamen ein. Nach dem gleichen Prinzip verfährt es mit den restlichen Elementen. Nach dem Login wechselt OX auf die Seite mit den Kontakten, indem es an die Basis-URL »www.xing.com« noch ein »/app/contact« anhängt und dann die Kontaktdaten im universellen Vcard-Format anfordert.

Den eigentlichen Aufruf beziehungsweise das Auslesen der Seite übernehmen die in Listing 2 genannten Java-Klassen. Um die Anmeldung kümmert sich beispielsweise »com.openexchange.subscribe.crawler.LoginPageStep« . Diese Klasse parst einfach die HTML-Seite, setzt die Login-Informationen in die entsprechenden Felder ein und schickt die manipulierte Seite wieder an Xing zurück.

Htmlunit

Listing 3 zeigt einen Ausschnitt aus der relevanten Methode »execute()« . Nach dem gleichen Prinzip arbeiten auch die übrigen Klassen. Wem die Klassen »HtmlForm« , »HtmlTextInput« & Co. bekannt vorkommen: OX greift auf die Hilfsbibliothek Htmlunit [10] zurück, eine Java-Bibliothek, die nützliche Funktionen zum Abholen und Manipulieren von HTML-Seiten anbietet.

Listing 3

execute()

01 public void execute(final WebClient webClient) throws SubscriptionException {
02   HtmlPage loginPage = null;;
03   try {
04     // Get the page, fill in the credentials and submit the login form
05     loginPage = webClient.getPage(url);
06     this.loginPage = loginPage;
07     final HtmlForm loginForm = loginPage.getFormByName(nameOfLoginForm);
08     final HtmlTextInput userfield = loginForm.getInputByName(nameOfUserField);
09     userfield.setValueAttribute(username);
10     final HtmlPasswordInput passwordfield = loginForm.getInputByName(nameOfPasswordField);
11     passwordfield.setValueAttribute(password);
12     final HtmlPage pageAfterLogin = (HtmlPage) loginForm.submit(null);
13     output = pageAfterLogin;
14  [...]

Die von den Plugins aus den Social Networks gezogenen Daten integriert OX in seinen Datenbestand. So tauchen die Adressen aus Facebook unter den »Kontakten« auf. Von dort aus reicht sie OX auf Wunsch sogar an andere OX-Installationen weiter oder macht sie Freunden und Kollegen über eine eigene URL zugänglich. Alle diese Funktionen und Konzepte fasst der Hersteller unter dem Begriff Social OX zusammen.

Soziale Giraffe

Hinter der Groupware Zarafa steht die gleichnamige niederländische Firma. In Deutschland hat sie Niederlassungen in Hannover (in Form der Zarafa Deutschland GmbH) und in Plochingen bei Stuttgart. Genau wie OX gibt es Zarafa in mehreren kommerziellen und einer kostenlosen Open-Source-Variante, die unter der Affero GPLv3 steht [11]. Fertige Pakete stehen für die größeren Distributionen bereit, in der Distribution Zentyal ist Zarafa zudem bereits enthalten.

Um die Verwaltung der Daten kümmert sich im Hintergrund der in C++ geschriebene Zarafa-Server. Seine Dienste lassen sich über verschiedene Schnittstellen in Anspruch nehmen. In der Regel verwalten die Nutzer ihre Daten über die Zarafa-Webapp, eine kleine Webanwendung (Abbildung 5, [12]).

Abbildung 5: Wer unter Zarafa eine E-Mail öffnet, die auf einen Twitter-Account verweist, dem zeigt das Twidget-Plugin (hier ganz rechts im Bild) die dortigen Tweets an.

Abbildung 5: Wer unter Zarafa eine E-Mail öffnet, die auf einen Twitter-Account verweist, dem zeigt das Twidget-Plugin (hier ganz rechts im Bild) die dortigen Tweets an.

Um die Anbindung von Twitter kümmert sich das Twidget-Plugin [13]. Innerhalb der Webapp erscheint es als Widget, das man auf die Startseite oder in die Leiste am rechten Rand legen kann. Dort aktiviert durchsucht es den Text einer gerade geöffneten E-Mail nach einem Twitter-Account. Sofern dieser in der Form »twitter.com/timschuermann« oder »@timschuermann« auftaucht, zeigt das Widget die letzten Nachrichten in einer Liste an (Abbildung 5). Mehr kann es nicht – was durchaus gewollt ist: Das Twidget-Plugin diente beim Entwicklertreffen Zarafa Summercamp als Beispiel, wie einfach und schnell sich eigene Widgets entwickeln lassen [13].

Wie alle Widgets besteht auch das Twidget-Plugin aus ein bisschen Javascript. An den Quellcode gelangt, wer sich das Plugin herunterlädt, es entpackt und das dabei herausgepurzelte Archiv »twidget-1.1.zip« extrahiert. Die eigentliche Logik steckt in der Datei »Twidget.js« im Unterverzeichnis »twidget-1.1/js« . Die darin enthaltenen Funktionen sind gut kommentiert, die Hauptarbeit steckt in der Funktion »loadRecord« (Listing 4).

Listing 4

loadRecord()

01 loadRecord : function(record)
02 {
03   var body = record.getBody(false);
04   var re = new RegExp("twitter.com/(\\w+)");
05   var twitter = undefined;
06
07   var match = re.exec(body);
08   if (Ext.isEmpty(match)) {
09     re = new RegExp("^(.*?\\W)?@(\\w{1,15})\\b");
10     match = re.exec(body);
11     twitter = match[2];
12   } else {
13     twitter = match[1];
14   }
15
16   if (twitter !== undefined) {
17     var count = this.get('max_count');
18     var rts = this.get('include_rts');
19
20     Ext.ux.JSONP.request({
21       url : 'https://api.twitter.com/1/statuses/user_timeline.json',
22       params: {
23         screen_name: twitter,
24         count: String(count),
25         include_rts: String(rts)
26       },
27       success : this.onTwitterUpdate,
28       callbackKey : 'callback',
29       scope : this
30     });
31   }
32 },

Twitter und Regex

Zunächst löst sie mit Hilfe von regulären Ausdrücken die Twitter-Adresse aus dem Text einer E-Mail. Sofern sie eine solche Twitter-Adresse gefunden hat (»twitter« ist in dem Fall nicht »undefined« ), baut sie eine Anfrage an Twitter im Jsonp-Format [14] zusammen und schickt das Ganze los. Um die von Twitter zurückgelieferten Nachrichten kümmert sich die (Callback-)Funktion »onTwitterUpdate()« , die wiederum die Nachrichten anzeigt. »max_count« und »include_rts« sind Einstellungen des Twidget, die man in der Webapp mit einem Klick auf das Zahnradsymbol ändern kann.

Neben dem Plugin für Twitter gibt es auch noch zwei Kollegen für Facebook. Das erste zeigt auf der Startseite die Einträge einer Pinnwand an (Abbildung 6). Von welcher Seite die Pinnwand-Nachrichten stammen, gibt der Admin in den Einstellungen des Plugins vor. Dort hinterlegt er jedoch nicht etwa den Benutzernamen eines Facebook-Mitglieds, sondern die URL einer Internetseite, die den offiziellen Facebook-Knopf »Gefällt mir« anbietet.

Abbildung 6: Das Facebook-Widget in Zarafa zeigt lediglich die Einträge der Pinnwand an, hier rechts im Bild die des Linux-Magazin-Facebook-Accounts.

Abbildung 6: Das Facebook-Widget in Zarafa zeigt lediglich die Einträge der Pinnwand an, hier rechts im Bild die des Linux-Magazin-Facebook-Accounts.

Unter der Haube funktioniert das Facebook-Plugin ähnlich wie das Twidget: Es bindet auf der Zarafa-Seite einen Iframe ein, in dem es wiederum den Inhalt der Seite http://www.facebook.com/plugins/activity.php?site=linux-magazin.de anzeigt. »linux-magazin.de« ist dabei die in den Einstellungen hinterlegte Seite. Dieses Verfahren hat zwar den Vorteil, dass sich Zarafa nicht bei Facebook anmelden muss, im Gegenzug bleiben die Kontakte und alle weiteren persönlichen Informationen aber ungenutzt.

Versteckspiel

Schließlich existiert noch ein drittes Plugin, das die Veranstaltungen aus Facebook in den Kalender von Zarafa übernimmt. An die Daten gelangt das Plugin über das offizielle Facebook-API, es bedarf folglich wie bei OX zunächst einer Facebook-Anwendung, dann muss der Admin den Schlüssel wiederum dem Plugin mitteilen. Genau diese komplizierte Installation ist auch der Grund, warum die Zarafa-Entwickler das Plugin noch nicht offiziell freigegeben haben.

Ivo Timmermans von Zarafa erklärt dazu: “Das Problem mit diesem Plugin ist, dass Facebook nur eine Seite pro Installation erlaubt und damit von jedem Administrator, der dieses Plugin nutzen möchte, verlangt, eine Anwendung auf Facebook zu erstellen. Er benötigt somit jeweils einen Facebook-Account und muss durch den Registrierungsprozess einer Facebook-Anwendung gehen. Dass die Namen dieser Anwendungen zudem global eindeutig sein müssen, macht die Installation kompliziert.”

Der Quellcode des Facebook-Plugins liegt der Webapp allerdings schon bei. Wer mag, kann es direkt in Betrieb nehmen, ist dabei aber gänzlich auf sich allein gestellt: Bis auf eine magere Wiki-Seite [15] existiert bislang keine Dokumentation. Das Veranstaltungs-Plugin besteht wie seine beiden Kollegen aus Javascript-Code, der wiederum einfach auf das offizielle Facebook-Javascript-SDK [16] zurückgreift.

Hat man sich einmal durch dessen Dokumentation gekämpft, erweisen sich die Dateien als leicht zu lesen: Zunächst initialisiert »FacebookEventsPlugin« das Facebook-SDK über die dafür vorgesehene Funktion »FB.init()« aus Listing 5. Dabei erhält die Funktion auch die Anwendungs-ID, die das Anlegen der Facebook-Anwendung erzeugt.

Listing 5

FB.init()

01 fbinit: function()
02   {
03   // Init the SDK
04   FB.init({
05     appId      : '223761867729127', // App ID
06     channelUrl : '//'+'zarafa.com.test'+'/channel', // Path to your Channel File
07     status     : true, // check login status
08     cookie     : true, // enable cookies to allow the server to access the session
09     xfbml      : true  // parse XFBML
10   });
11 },

Die eigentliche Abfrage führt dann »FbEventProxy« mit seiner Funktion »doRequest()« aus, die Listing 6 zeigt. Sie aktiviert lediglich die Funktion »FB.api()« aus dem Facebook-SDK, die wiederum alle Veranstaltungen (»events« ) des Benutzers (»me« ) abruft [17]. Alle übrigen Javascript-Objekte und -Funktionen des Zarafa-Plugins dienen im Wesentlichen dazu, die zurückgelieferten Daten auszuwerten beziehungsweise anzuzeigen. Wer weiter in den Quellcode hinabsteigen möchte, findet die Facebook-Plugins im Webapp-Quellcode-Archiv [12] in den Unterverzeichnissen »plugins/facebook« und »plugins/facebookwidget« .

Listing 6

doRequest() aus FbEventProxy

01 doRequest: function(action, rs, params, reader, callback, scope, options) {
02   if (action == 'read') {
03     FB.api('/me/events', function(data) {
04       callback.call(scope, reader.readRecords(data), {}, true);
05     });
06   }
07 }

Fazit

Wie Open-Xchange beweist, kostet es derzeit einigen Aufwand, um die Daten aus den Social Networks herauszuholen und zu verarbeiten. Dies liegt aber weniger an den Groupware-Entwicklern als an den Diensten selbst. Sie zwingen dem Administrator zunächst online das Erstellen einer Anwendung auf und rücken dann auch noch nicht einmal alle Informationen heraus. Wo ein API fehlt, muss OX sogar umständlich per Screen-Scraping die HTML-Seiten auseinandernehmen – eine Methode, bei der die Entwickler den Änderungen des Dienstes zwangsweise hinterherlaufen.

Die Entwickler von Zarafa machen es sich hingegen leicht: Das Facebook-Plugin für die Veranstaltungen bleibt versteckt, die anderen zapfen einfach nur die öffentlichen Streams von Twitter und Facebook an. Das geht allerdings auch ganz unkompliziert ohne den Einsatz von Hilfsbibliotheken wie Scribe.

DIESEN ARTIKEL ALS PDF KAUFEN
EXPRESS-KAUF ALS PDFUmfang: 6 HeftseitenPreis €0,99
(inkl. 19% MwSt.)
LINUX-MAGAZIN KAUFEN
EINZELNE AUSGABE Print-Ausgaben Digitale Ausgaben
ABONNEMENTS Print-Abos Digitales Abo
TABLET & SMARTPHONE APPS Readly Logo
E-Mail Benachrichtigung
Benachrichtige mich zu:
0 Kommentare
Älteste
Neuste Beste Bewertung
Inline Feedbacks
Alle Kommentare anzeigen
Nach oben