Die Grundlagen für unsere onOffice API wurden schon im Jahr 2006 gelegt. Zur Kommunikation zwischen GUI und Server wurde damals ein XML-Format mit Elementen entwickelt, die heute die Grundbausteine der onOffice API bilden. Über einen Prototypenstatus hinaus hat es das damalige GUI-Projekt nie geschafft. Zur internen Kommunikation wurde das Format und damit auch die erste onOffice API aber kurz danach eingesetzt. Die Generierung von PDF-Exposés wird zum Beispiel über einen solchen API-Request angestoßen.
Smartphone-App
Grundlegend überarbeitet wurde die API als 2012 die Entwicklung der onOffice iOS-App begonnen wurde. JSON ersetzte in dem Schritt die bisherigen XML-Requests und Responses sowie der Funktionsumfang wurden deutlich erweitert. User-Authentifizierung, Abfragen für Termine und vieles mehr wurden der API hinzugefügt.
WordPress
Der nächste große Entwicklungsschritt wurde vom onOffice WordPress-Plugin angestoßen. Viele benötigte API-Aktionen konnten vom Funktionsumfang der App wiederverwendet werden. Der größte Unterschied in der Anwendung zwischen iOS-App und WordPress-Plugin ist aber die Authentifizierung. Während sich in der App ein bekannter enterprise-Benutzer authentifiziert, haben wir im WordPress-Plugin anonyme Zugriffe. Um auch hier einen authentifizierten Zugriff über einen enterprise-Benutzer zulassen zu können, wurden die API-Benutzer entwickelt. API-Benutzer authentifizieren sich über Token und Secret, die jeweils generiert werden. Besonders wichtig: Diese API-Benutzer können mit den gleichen Rechten versehen werden, wie normale enterprise-Benutzer. Enthält die Webseite eine reine Darstellung von Daten werden dem API-Benutzer aus Sicherheitsgründen alle Schreibrechte genommen.
Die Veröffentlichung für Extern
Nachdem dieser Entwicklungsschritt abgeschlossen war, wurde die API Kunden und externen Entwicklern zur Verfügung gestellt. Die API-Dokumentation und ein API-SDK folgten. Unser API-Support hilft seitdem gerne über apisupport@onoffice.de weiter. Hier können direkt Entwickler kontaktiert werden, wenn Externe Probleme bei der Anbindung unserer API haben und die Dokumentation alleine nicht reicht.
Was kann die API aktuell?
Die bestehende Architektur des Hauptproduktes onOffice enterpise sieht bereits die Wiederverwendung vorhandener Logik-Klassen in anderen Produkten vor. So erreichen wir, dass die Schnittstellen zwischen den Systemen funktionieren. Aktuell liefert die API lesenden und schreibenden Zugriff auf alle großen Module (Adressen, Immobilien, Aufgaben, Kalender). Der lesende Zugriff bietet die Möglichkeit zu filtern. Schon mit diesen grundlegenden Aktionen wird ein sehr hoher Funktionalitätsgrad durch externe Entwickler geboten.
Neben diesen Basisaktionen bieten wir aber auch spezielle Aktionen, die komplexere Vorgänge in der Software auslösen – zum Beispiel die Generierung eines PDF-Exposés, der Upload von Dateien oder den Versand einer Adressvervollständigung.
Wie hat die API unsere Arbeit verändert?
Marketplace
In den vergangenen Jahren entstand der Wunsch, externe Dienstleister in unsere CRM-Software onOffice enterprise einzubinden. Die immer weiter steigende Anzahl an PropTechs (siehe hier einige Beispiele) liefert viele Zusatzfunktionen, die wir selbst nicht entwickeln wollen oder können.
Wir haben angefangen, die Schnittstellen zu diesen Dienstleistern zu nutzen oder individuelle Übertragungswege abzustimmen. So entstand neuer permanenter Aufwand, den wir nicht haben wollten. Sowohl die Erstanbindung als auch die Wartung der unterschiedlichen Schnittstellen erzeugte einen Entwicklungsaufwand, den wir lieber in unsere Kernprodukte investieren wollten.
So entstand die Idee, unsere eigene API zur Anbindung zu nutzen und den Ablauf zu standardisieren: der onOffice Marketplace. Über den Marketplace haben Anbieter die Möglichkeit, sich von uns per Konfiguration Einstiegspunkte an verschiedenen Stellen der Software aktivieren zu lassen. Hat ein User den Dienstleister aktiviert und den Zugriff über die API freigegeben, kommt er über einen Button oder Link zum externen Dienstleister, der über unsere API Daten lesen und schreiben kann. So können mittlerweile zum Beispiel Grundrisse optimiert, Rundgänge erstellt oder Wertermittlungen durchgeführt werden.
Weitere Informationen: https://www.marketplacedoc.onoffice.de/
Interner Einsatz
Auch intern setzen wir die API für kleine Zusatz-Tools ein. Wir haben ein lokales Wiki zur Dokumentation interner Abläufe. Jede Abteilung hat einen Bereich und einen Beauftragten, der die Verantwortung für die Struktur in seinem Abteilungsbereich trägt. Über die Wiki-API fragen wir nächtlich alle geänderten Artikel ab und erstellen über unsere eigene API Aufgaben für die Beauftragten. Alle geänderten Artikel werden so – durch Aufgaben abgesichert – geprüft.
Auch in der Entwicklung generieren wir Aufgaben über die onOffice API zum Beispiel zur Durchführung von Code-Reviews nach Commits. Wir versammeln so alle anstehenden Aufgaben an einer Stelle: in unserer eigenen Aufgabenliste. Entwickler müssen so nicht mehr aktiv in andere Tools schauen, um alle anstehenden Aufgaben zu sehen.
In der Web-Abteilung wird der Stand von Aufgaben-Backlogs per API abgefragt und statistisch ausgewertet. Und es gibt noch viele weitere Ideen, für die auch wir selbst in Zukunft unsere API nutzen möchten.
Fazit
Obwohl die API schon viele Jahre besteht, ist die Bedeutung gerade in den letzten zwei bis drei Jahren noch einmal deutlich gestiegen. Sowohl intern als auch bei unserer eigenen Webseite oder im Einsatz bei Kunden wächst das Thema API immer weiter.
Janosch Reuschenbach ist IT-Verantwortlicher bei onOffice und leitet die Bereiche Softwareentwicklung, Administration und Datenmigration. Janosch hat einen Hochschulabschluss in Technomathematik und ist seit 2006 fester Bestandteil unseres Teams.