Obwohl von den 11 Personen nur vier programmieren konnten waren alle produktiv tätig. Es wurde getestet, Fehler behoben und Dokumentation verfasst. Eine Gruppe entwarf einen Fragebogen für eine Anwenderbefragung, eine andere überarbeitete Texte und Featurelisten für Infomaterialien und die in Kürze generalüberholte Portalseite. Vorwiegend in den Abend- und Nachtstunden malträtierten Gruppen von zwei bis vier Personen die mitgebrachte Spielekonsole, um entweder zu rocken, zu singen oder die Videspielfassung eines Familienquizes zu spielen.

Das Ende kam dann, wie immer, viel zu schnell – vermutlich hätten Teilnehmerinnen und Teilnehmer noch länge rmachen können. Für das nächste Jahr sollte überlegt werden ob es machbar ist das CodeCamp auf vier Tage auszudehnen.

• $WEBSERVICES_ENABLE legt fest, ob die Stud.IP-Webservices überhaupt aktiv sind. Notwendigerweise muss dieser auf TRUE gestellt werden, damit man mit den Stud.IP-Webservices experimentieren kann.
• $STUDIP_API_KEY stellt eine Art Passwort dar, mit dem in manchen Webservices geprüft wird, dass der Request authorisiert ist. Füllen Sie diese Konfigurationseinstellung mit einem langen String. Lassen Sie sich zum Beispiel einen generieren.

Ihr Stud.IP-System sollte jetzt Webservice-Requests bearbeiten. Überprüfen Sie die Endpoints:

• SOAP: http://{URL zu Ihrem Stud.IP-System}/soap.php (Beispiel: Entwicklungsserver)
• XML-RPC: http://{URL zu Ihrem Stud.IP-System}/xmlrpc.php (Beispiel: Entwicklungsserver)
• JSON-RPC: http://{URL zu Ihrem Stud.IP-System}/jsonrpc.php (Beispiel: Entwicklungsserver)

Für den SOAP- und XML-RPC-Endpoint sollten Sie die Dokumentation der zur Verfügung stehenden Methoden vorfinden.

Dokumentation der XML-RPC-API von Stud.IP

Nachdem nun alle Puzzleteile an ihrem Platz sind, kann es mit der echo-Methode losgehen. Den entsprechenden Quellcode habe ich in einem entsprechenden Stud.IP-Branch bei github.com (commit 8cd17b) abgelegt.

Eine Funktion, die ihr Argument einfach zurückgibt, sieht in PHP so aus:

function echo($string) {
  return $string;
}

Eigentlich sind wir damit schon fast fertig, damit daraus aber ein Webservice wird, müssen noch ein paar Formalitäten abgewickelt werden.

Zunächst möchte man diese Funktion sicher nicht im globalen Namensraum liegen haben. Da allerdings erst mit PHP 5.3 tatsächliche Namensräume vorhanden sind, behelfen wir uns mit einer Klasse, in der wir die Funktion als Methode einbetten:

class ExampleService {
  function echo($string) {
    return $string;
  }
}

Diese Klasse legen wir in einer neuen Datei lib/webservices/services/example_webservice.php ab.

Außerdem fallen weitere Konventionen an, denen genüge getan werden muss. Zum einen müssen die Endpoints von unserem Webservice erfahren. Dazu öffnet man die Dateien

• public/jsonrpc.php
• public/soap.php
• public/xmlrpc.php

und fügt dort jeweils in ca. Zeile 38 ein:

require_once 'lib/webservices/services/example_webservice.php';

Außerdem muss der Name unserer neuen Klasse in die Argumentliste bei der Instanzierung der Server-Objekte aufgenommen werden. Für beispielsweise die Datei soap.php fügen wir deshalb den String “ExampleService” so in Zeile 45 an:

$delegate =& new Studip_Ws_SoapDispatcher('UserService', 'SessionService',
  'SeminarService', 'ContentmoduleService', 'LectureTreeService',
  'InstituteService', 'ExampleService');

Für XML-RPC und JSON-RPC tut man das genauso.

Als nächstes Zugeständnis müssen Funktionen, die über einen Webservice zugänglich gemacht werden sollen, umbenannt und angemeldet werden. Die Umbenennung ist nicht schwer: Solche Funktionen müssen einfach auf “_action” enden. (Würde man das nicht tun, dürfte man z.B. niemals eine Funktion “list” haben, da dies in PHP ein reserviertes Wort ist.)

Die Anmeldung einer Funktion geschieht im Konstruktor der Klasse. Dort muss der Name (ohne das “_action”) und die Signatur genannt werden. Über die Signatur sprechen wir in einem zukünftigen Artikel, so dass hier nur der fertige Code gezeigt wird:

class ExampleService extends Studip_Ws_Service {

  function __construct() {
    $this->add_api_method('echo',
                          array('string'),
                          'string',
                          'example echo service');
  }

  function echo_action($string) {
    return $string;
  }
}

Die Argumente der Anmeldung (#add_api_method) im Konstruktor lassen sich so entschlüsseln:

• Der Name der Funktion lautet “echo” (ohne “_action”!).
• Der nächste Parameter enthält die Typen der Funktionsargumente als Liste. Wir verlangen einen Parameter, der ein String sein soll, so dass die Typliste so aussieht: “array(‘string’)”.
• Der dritte Parameter gibt den Typ des Rückgabewertes an. Hier ist das wie beabsichtigt ein String.
• Der letzte Parameter enthält eine kurze textuelle Beschreibung der Funktion.

Und damit sind wir schon fertig. Rufen Sie einen Endpunkt auf (z.B. für XML-RPC). Dort taucht nun in der Liste unsere echo-Methode auf. Probieren Sie sie z.B. im Debugger aus. Wie zu erwarten war, funktioniert alles einwandfrei

PHP-Funktionen über die studip-ws-Bibliothek ist also ganz einfach. Wenn man von den beschriebenen, minimalen Anforderungen absieht, ist dies nicht schwieriger, als eine Funktion in PHP zu schreiben, ohne jemals XML oder SOAP gesehen zu haben.

Im nächsten Teil geht es dann um die Signaturen der Funktionen. Bis dahin viel Spaß mit ihrem neuen echo-Service.

Stud.IP-Entwicklertagung 2009 in Osnabrück

Der diesjährige Stud.IP-Entwickler-Workshop im Zentrum virtUOS der Uni Osnabrück ist vorbei. Vier aufregende Tage voller spannender Vorträge, intensiver Diskussionen und hochmotivierter Weiterentwicklungen. Inhaltliche Resumés folgen noch; hier zunächst nur einige Impressionen der letzten vier Tage.

Donnerstag, 26.3., 8.00 Uhr

Carola und Ansgar sind schon fleißig, schleppen Kisten und Kabel in den Senatssitzungssaal. Dank ihrer perfekten Vorbereitung in den letzten 14 Tagen kann ich nur danebenstehen, und, wenn Not am Mann ist, mit zupacken. Schließlich steht alles bereit, Kaffee ist gekocht und die Gäste können eintrudeln. Kaffee, Saft und Kekse werden vom Stud.IP e.V. gesponsert, so dass der übliche Hut, der bei solchen Gelegenheiten kreist, um die Unkosten zu decken, in der Ecke liegen bleiben kann. An dieser Stelle ein Dank an alle Vereinsmitglieder, insbesondere die (derzeit drei) Mitgliedshochschulen, die mit ihren Beiträgen unter anderem Entwicklerworkshops ermöglichen und motivierender gestalten helfen!

Donnerstag, 26.3., 11.00 Uhr

Konzentriertes Zuhören bei den Vorträgen

Es geht los. Knapp dreißig Teilnehmer lauschen hochkonzentiert den Vorträgen und sind jederzeit bereit, bis ins Detail nachzufragen. Ein halbes Dutzend Nachzügler lässt die Teilnehmerzahl bis zum Mittag auf stolze 35 ansteigen. Beinah jeder Vortrag, jeder Einzelworkshop ist zu kurz. Bei Stud.IP-Entwicklervorträgen gibt es keine Hochglanz-Präsentationen, dafür werden aktuellste Entwicklungen vorgestellt. Manchmal sind sie bereits im Einsatz vor Ort, manchmal halbfertig, manchmal nur Ideen. Jeder Vortragende kann sich sicher sein: Das Publikum ist hochkompetent, begeisterungsfähig und kritisch. Präsentationsmängel werden leichter verziehen als halbgare Ideen. Deshalb sind Entwicklerworkshops Spezialistentagungen. Wer ganz neu dazustößt braucht eine Weile, um sich zu ortientieren. Aber er kann sich sicher sein: Es findet sich spätestens in der Pause zu jeder Frage jemand, der sie geduldig beantwortet.

Donnerstag, 26.3., 15 Uhr

Diskussion im virtUOS-Studio

Das »Schnitzel Florida« aus der Mensa ist verdaut, es herrscht angeregte Diskussionsatmosphäre. Für die Einzelworkshops wird das Plenum geteilt und je eine Gruppe verzieht sich ins angrenzende virtUOS-Filmstudio.  Manch einer wollte vor lauter spannender Videotechnik ringsum erstmal hinter die Kulissen kriechen, musste damit aber bis zum Abend warten. Während nach 6 Stunden intensiven Arbeitens die Core-Group noch eine zweistündige Sitzung zu absolvieren hatte, konnten sich die anderen in der Uni Osnabrück herumführen lassen und Aktuelles wie Historisches über virtUOS und Schloss erfahren.

Donnerstag, 26.3., 22 Uhr

Noch gut 20 Entwickler und andere Stud.IP-Interessierte sitzen im Unikeller bei Speis und Trank und können kaum von den angefangenen Diskussionen des Tages lassen. Neue Ideen werden zusammengesponnen, Erfahrungen ausgetauscht, aber auch ganz “normale” Kneipengespräche füllen die gemütlichen Gewölbe. Für die Einen ist es willkommenes Wiedersehen, andere lernen zum ersten Mal die Gesichter und Menschen hinter den tagtäglichen Forumsdiskussionen des Developerservers kennen. Irgendwann weit nach Mitternacht ruft das Hotelbett, denn morgen steht ein weiterer Workshoptag an.

Freitag, 27.3., 9 Uhr

Große Runde am Freitagmorgen

Dass alle pünktlich um 9 auf ihren Plätzen sitzen und meiner kritischen Betrachtung der formalen Regeln beim Entwickeln und Neue-Features-Einbringen lauschen, werte ich als höchst erfreuliches Zeichen. Das persönliche Engagement der Entwickler wird selbst bei vermeintlich trockenen Themen spürbar. Hier geht es darum, wie wir alle gemeinsam weiterarbeiten und wie und ob die selbstauferlegten Regeln nicht Kreativitätshemmnis, sondern verlässliche Orientierung sein können. Weiter geht es mit einer kurzweiligen Runde, in der im 5-Minuten-Takt kleine Plugins und lokale Erweiterungen vorgestellt werden.  “Verständnisfragen sofort, Diskussion in der Pause!” muss ich die Teilnehmer ermahnen und der Zeitplan rutscht trotzdem nach hinten.

Freitag, 27.3., 14.00 Uhr

Letzter offizieller Programmpunkt: André gibt eine launige Einführung in die Stud.IP-Entwicklung. Was ist zu beachten, wo lauern Altlasten, die man verstehen aber nicht mehr weiterverwenden sollte, wie orientiere ich mich im Dschungel aus Dateien, Funktionen und Klassen? Manch Neuling wünschte sich diese Runde für den Anfang der Tagung, aber auch alte Hasen sind sich einig: Einen solchen Überblick, zumal gewürzt mit Anekdoten und persönlichen Statements können wir häufiger (v)ertragen. Jeder, selbst wenn er wie ich in den vergangenen 5 Jahren vermutlich jede Stud.IP-Ecke schonmal gesehen hat, kann noch etwas mitnehmen und an der einen oder anderen Stelle einen zusätzlichen Motivationsschub für das anschließende Entwicklerwochenende bekommen.

Freitag, 27.3., 16.00 Uhr

Entwickler-Wochenende

Der offizielle Teil ist beendet, viele Teilnehmer müssen leider schon abreisen. Aber insgesamt ein gutes Dutzend Entwickler und anderweitig an der Stud.IP-Zukunft Interessierte können und wollen noch bleiben. Nach dem erfolgreichen ersten Stud.IP-Code-Camp auf dem Veganer-Hof in Laer im vergangenen August haben die Osnabrücker Entwickler zu einem rein freiwilligen und privaten Entwickler-Wochenende geladen. Wir ziehen mit unseren Notebooks in die Besprechungsräume des virtUOS um und sofort ist wieder diese knisternde Arbeitsatmosphäre aus Laer da: “Zeig mal, was du gebaut hast…”, “Guck dir mal diese Idee an…”, “Hast du Lust, mit mir zusammen endlich mal dieses Ärgernis anzugehen…”. Satzfetzen wie diese begleiten die Platzsuche und bald wird es seltsam still. Tastaturen klappern, technische Details werden halblaut ausgetauscht und alle haben etwas gefunden, an dem sie hochkonzentriert arbeiten. Zwischendurch immer wieder etwas für alle: Was zum Vorzeigen, zum Lachen, zum Rätseln, zum Beurteilen. Dass nach 23 Uhr kein Bringdienst mehr liefert, wäre uns beinah zum Verhängnis geworden, denn kaum jemand hat noch auf die Uhr geschaut. Die meisten gehen erst nach 3 ins Hotel oder ihre Wohnung zurück, noch die Worte murmelnd: Bis gleich!

Samstag, 28.3.2009, 10.00 Uhr

Aus Kaffee wird Code

Der Start um kurz vor 10 ist noch etwas schleppend aber bald brummt und summt das Changelog im SVN wieder vor lauter Aktivität. Wie schon im letzten Jahr halten sich Aufräumen, Dokumentation verbessern und Neues-Bauen ungefähr die Waage. Draußen regnet es fast den ganzen Tag, so dass kaum jemand in Versuchung geführt wird, aus dem virtUOS zu fliehen. So geht es produktiv voran und wieder verfliegt die Zeit fast unbemerkt. “Warum ist es plötzlich so dunkel draußen?” hört man den einen oder anderen verwundert sagen.

Samstag, 27.3., 23.00 Uhr

Die Singstar-Fraktion ist wieder aktiv. Wie auch schon gestern abend wird nebenan Lied für Lied geschmettert, nur die Sänger wechseln. Nach Lust und Laune klinkt sich der eine oder andere aus, um kurz abzuschalten. Im letzten August hatten Guitar-Hero-Sessions für Laune gesorgt, für das nächste Mal ist Rock-Band schon drohend angekündigt. Bezeichnend aber für die Code-Camp-Atmosphäre: Alles findet nebeneinander statt. Jemand starrt hochkonzentiert auch den Laptop-Bildschirm, um im Editor schließlich ein Komma einzufügen und einen neuen Datenbankdump einzuspielen, während kaum einen Meter entfernt die schlimmsten Hits der 90er nachgegröhlt werden.  So geht das – dank Zeitumstellung – bis kurz vor 4. Für alle Verbliebenen präsentiert die Stud.IP-Verschönerungsgruppe noch ihr neu entwickeltes Gewand für Stud.IP, das auf große Zustimmung stößt, für alle Nichtanwesenden aber noch bis zum Herbst verschlossen bleiben wird.

Sonntag, 28.3., 10 Uhr

Die Ostniedersachsen fahren direkt nach dem Frühstück heim, so dass nur noch Osnabrücker für den letzten Tag bleiben. Dank Regens und schlechter Busverbindungen bin ich der erste, der um 10 Uhr anfängt, die Reste zusammenzufegen, Flaschen einzusammeln und Pizzakartons zu falten. Dankenswerterweise konnte der Verein auch zum Entwicklerwochenende beitragen und Verpflegung sponsern. Merci nochmal an alle Mitglieder! Den Rest des Sonntags haben Till und ich dann damit zugebracht, den Homepagebaukasten als drigend notwendige Renovierung der persönlichen Homepages in Stud.IP nochmal ein entscheidendes Stück voranzubringen. Gesungen wurde aber nicht mehr.

Sonntag, 28.3., 18 Uhr

So. Schluss. 82 Stunden Stud.IP-Entwickler-Workshop liegen hinter uns. Die Schlafpausen waren kurz, die Konzentration hoch, die erzielten Ergebnisse liegen über den Erwartungen. Die vier Tage haben mir wieder einmal gezeigt, dass die Stud.IP-Entwickler-Gemeinde besonders aktiv, aber auch besonders kommunkativ und herzlich ist. Auf der Haben-Seite stehen jetzt mehrere Dutzend behobener Bugs der Kategorie “Nicht kritisch (denn die werden immer sofort behoben), aber nervig”, eine Menge neuer Dokumentation, entscheidende Fortschritte bei wichtigen Umbauvorhaben und viele frische Impuls und Ideen, von denen wir die nächsten Monate zehren werden.

Persönlich möchte ich mich bei allen so engagiert Beteiligten bedanken. Vor allem bei Carola und Ansgar für die Organisation, beim Verein und data-quest für die finanzielle Unterstützung. Auch bei den Arbeitgebern der  Entwickler dafür, dass es für sie so selbstverständlich ist, Reisekosten und zwei volle Arbeitstage für den Workshop in die Zukunft von Stud.IP zu investieren. Und vor allem bei denen, die wieder mal Ihre Freizeit genutzt haben, um ein Projekt, das Ihnen persönlich am Herzen liegt, voranzubringen.

Die Ergebnisse und Erfolge dieser vier Tage finden Sie, lieber Leser, wie gewohnt demnächst in Ihrer Stud.IP-Installation.

Grundsätzlich wird für die (RPC-basierten) Webservices in Stud.IP die Bibliothek studip-ws verwendet, die sich in einer üblichen Stud.IP-Installation im Verzeichnis /vendor/studip_ws/ befindet. Grundsätzlich ist diese Bibliothek die Abstraktion zweier anderer:

• PHPXML-RPC für den Zugriff auf die Webservices über XML-RPC
• NuSOAP für den Zugriff auf die Webservices über SOAP

Die Motivation für eine weitere Abstraktion über diesen schon nicht unbedingt simplen Protokollen bestand darin, bei der Implementation von Webservices möglichst wenig mit den teilweise ungewöhnlichen Details dieser Protokolle zu tun zu haben. Stattdessen war die Idealvorstellung, Methoden in Klassen in »normalem« PHP zu implementieren. Solange man sich in einer gewissen Untermenge von PHP bewegt, funktioniert das alles sehr gut.

Leider ist es für die Verwendung von SOAP unerlässlich, Signaturen für die zur Verfügung gestellten Methoden zu definieren. Aus dieser Einschränkung resultieren ein paar Eigenheiten, die unter anderem in den kommenden Artikeln vorgestellt werden sollen.

Um ein bisschen praktischen Nutzwert in diesem Artikel zu geben, soll der in der PHPXML-RPC-Bibliothek enthaltene Debugger vorgestellt werden. Wer den Debugger nicht selbst installieren möchte, kann mit genügend Vertrauen die öffentliche Demo-Version ausprobiert werden.

Trägt man dort in das Textfeld »Address« den Wert »phpxmlrpc.sourceforge.net« und in das Textfeld »Path« den Wert »/server.php«, werden einem nach Klick auf den Knopf »Execute« alle Methoden des eingetragenen XML-RPC-Servers aufgelistet. Von dort ausgehend können die Signaturen der Methoden untersucht werden oder auch tatsächliche RPCs ausgeführt werden.

Viel Spaß damit und bis zum nächsten Artikel, bei dem in einem (aktuellen) Stud.IP  eine weitere Methode hinzugefügt wird.

Die Stud.IP-Entwickler nennen die Zwischenschritte zwischen den großen Versionsveröffentlichungen “Service Releases”.
“Service” hört sich immer ein wenig nach Dienstleistung an, nach nice-to-have – aber nicht lebensnotwendig. Stud.IP 1.8 funktioniert ja auch so.

Das ist sicher richtig, trotzdem sollten alle Betreiber unbedingt ein Update auf Stud.IP 1.8.1 durchführen. Neben rund 60 kleineren und 2 kritischen Bugs wurden auch zwei, kürzlich bekannt gewordene, Sicherheitslücken geschlossen. Diese waren nicht hoch kritisch und hatten auch nichts mit personenbezogenen Daten zu tun, trotzdem ist es wichtig, sie zeitnah zu schließen.

Eine Liste der behobenen Bugs findet sich hier, ein Changelog steht hier zur Verfügung.

Download: Stud.IP 1.8.1

Großer Dank gebührt Elmar Ludwig, der das Servicerelease zusammengestellt hat. Und das, während die Arbeiten an Stud.IP 1.9 auf vollen Touren laufen.

Details folgen in Kürze.

So ganz vollkommen makellos und fehlerfrei ist Software ja nie und im Laufe der Jahre versammeln sich in staubigen Ecken größere Mengen scheintoter Käfer, die nur darauf warten, im richtigen Moment zuzuschlagen. Vor einigen Monaten wurden die nie endenden Versuche, die BIESTer zu bändigen, aus dem in grauer Vorzeit selbstgestrickten Stud.IP-Wiki-Formularverhau in ein viel mächtigeres trac verlegt. Was noch ausstand: Mal kräftig durchfegen und in alle Ecken gucken.

Jedes einzelne BIEST, das aus den vergangenen Jahren übriggeblieben ist und das irgendwann mal jemand gemeldet hat, ist jetzt sorgfältig untersucht worden. Die meisten bewegten sich irgendwo zwischen: “Auf der Semesterferienverwaltungsseite fehlt ein Punkt”, “Manchmal funktioniert bei mir irgendwas nicht ganz richtig” und “Ich habe eine Ausnahmesituation gefunden, in der die selten verwendete Funktion xy nicht das richtige Ergebnis liefert.” Viele angestaubte Käfer konnten gleich aussortiert werden, weil die Verbesserungen der letzten Versionen ihnen jeden Nährboden entzogen haben. Andere ließen sich beim besten Willen nicht aus ihrem Versteck hervorlocken und wurden deshalb abgeschrieben.

Jetzt können wir nicht ganz ohne Stolz verkünden: Der Bug-Zoo ist gut aufgeräumt. Ein paar BIESTern bleibt noch der Garaus zu machen, aber wir wissen jetzt genau, wo sie wohnen. Die Verschnaufpause wird allerdings nur kurz sein. Beim genauen Hinschauen haben wir schon ein paar ganz neue Arten frisch mutierter Krabbelviecher gefunden.