Sage 100 REST API: Was die offizielle Schnittstelle kann und wo sie aufhört

„Gibt es eine REST-API für Sage 100?“ So steht die Frage im Sage-Forum, und sie wird uns in Erstgesprächen ähnlich oft gestellt. Die Antwort lautet ja. Sie ist nur kürzer, als die meisten hoffen.

Denn die offizielle Schnittstelle deckt vier Ressourcen ab. Vier. Wer seinen Onlineshop an den Artikelstamm hängen will, ist damit gut bedient. Wer Produktionsrückmeldungen zurückschreiben oder Auswertungen ziehen möchte, steht vor einer Lücke. Und merkt das meist erst, wenn das Projekt schon läuft.

Dieser Artikel zeigt, was die offizielle API kann, wo sie aufhört, welche Voraussetzungen kaum jemand vorher liest und welche Wege bleiben, wenn der Standard nicht reicht.

Was die offizielle Sage-100-API abdeckt

Ein Blick in die offizielle Dokumentation unter openapi.sage100.de beendet jede Spekulation. Dort stehen genau vier Module in Version 1.0.0: Kunden, Lieferanten, Artikel und Belegerfassung. Drei Stammdatenbereiche und ein Belegbereich, jeweils mit Referenz, OpenAPI-Spezifikation und C#-Codegenerierung.

Für eine ganze Reihe von Vorhaben genügt das vollkommen. Shop-Anbindung, Kundenportal, eine Außendienst-App, die Artikel und Preise zieht und Aufträge zurückgibt: Alles machbar, sauber dokumentiert, mit klaren JSON-Strukturen und HTTPS.

Und wo sie aufhört

Alles, was nicht in diesen vier Modulen steht, steht eben nicht drin. Produktionsrückmeldungen, Zeitbuchungen und Materialverbräuche aus der Fertigung. Offene Posten, Salden, Umsätze für ein BI-Dashboard. Die Übergabe an die Finanzbuchhaltung. Und jedes Feld, das Sie sich im Laufe der Jahre selbst angelegt haben.

Der typische Verlauf sieht so aus: Der Shop läuft nach drei Wochen. Dann kommt die Fertigung und möchte Rückmeldungen automatisch buchen. Und plötzlich steht die Frage im Raum, ob man das Ganze nicht doch anders hätte aufziehen sollen.

Die Voraussetzungen, die selten jemand vorher liest

Bevor die erste Zeile Code entsteht, sind drei Dinge zu klären, und sie entscheiden manchmal über das ganze Vorhaben.

Sage 100 Connected, ab Version 9.0.4. Die API setzt Sage 100 Connected voraus. Läuft bei Ihnen eine ältere Installation oder ein klassisches Kaufmodell, führt der Weg über die offizielle Schnittstelle nicht weiter, bevor diese Frage geklärt ist.

Client-ID und Secret kommen von Sage. Die Zugangsdaten für die Authentifizierung fordern Sie bei Sage an (developer@sage.de). Das ist kein Selbstbedienungsportal, in dem Sie sich in fünf Minuten einen Schlüssel generieren. Planen Sie diesen Schritt zeitlich ein.

Von außen wird es teurer. Greift Ihre Anwendung aus demselben Netz zu, genügt eine Sage-100-Benutzerlizenz oder eine entsprechende 3rd-Party-Connector-Lizenz. Soll der Zugriff aber von außen kommen, etwa aus einer Cloud-Anwendung, einer mobilen App oder einem gehosteten Shop, dann läuft er über das 3rd Party Gateway von Sage. Das ist eine Zusatzlösung und wird je Benutzer lizenziert. Die Konditionen nennt Ihnen der Sage-Vertrieb; für die Projektkalkulation ist wichtig, dass dieser Posten überhaupt existiert. Nachträglich entdeckt, kippt er schon mal eine Wirtschaftlichkeitsrechnung.

Diese Angaben stammen aus der offiziellen Sage-Dokumentation. Ein Teil der weiterführenden Unterlagen, etwa das SDK, steht allerdings nur Tech-Partnern offen, was die Recherche für Anwender mühsam macht.

Die vier Wege in ein Sage 100 hinein

Reicht der Standard nicht, bleiben Alternativen. Drei davon sind sinnvoll, eine ist eine Falle.

• Web API (REST). Der offizielle Weg für externe Systeme. Modern, dokumentiert, zukunftssicher. Begrenzt auf die vier Module.
• BOI, die Geschäftsobjekt-Schnittstelle. Läuft serverseitig und kommt an deutlich mehr Funktionen heran als die Web API. Sie eignet sich für Massenimporte, Hintergrundjobs und Erweiterungen, die auf dem Server leben. Für eine mobile App, die von unterwegs zugreift, ist sie der falsche Ansatz.
• Eigene Endpunkte über den AppDesigner. Wenn genau ein Feld oder eine Operation fehlt, erweitern Sie die Web API gezielt, statt einen zweiten Integrationsweg aufzumachen.
• Direkter Schreibzugriff auf die SQL-Datenbank. Technisch möglich, und genau deshalb so verführerisch. Sie umgehen damit sämtliche Prüfungen und Folgebuchungen, die Sage im Hintergrund ausführt. Die Inkonsistenzen tauchen nicht sofort auf, sondern beim Jahresabschluss. Lesend, für ein Reporting, ist es vertretbar. Schreibend nicht.

Welcher Weg zu Ihrem Vorhaben passt, hängt an drei Fragen:

Selbst bauen oder fertig nehmen?

Wenn Sie nur den Artikelstamm brauchen, bauen Sie das selbst. Der Aufwand ist überschaubar, die Dokumentation trägt, und Sie behalten die Kontrolle.

Anders sieht es aus, sobald mehrere Bereiche zusammenkommen. Dann bauen Sie nicht eine Schnittstelle, sondern eine kleine Plattform: Authentifizierung, Fehlerbehandlung, Wiederholungslogik bei Netzausfällen, Protokollierung, Versionierung. Und das alles nochmal, wenn Sage ein Release veröffentlicht. Genau an dieser Stelle stellt sich die Frage, ob Sie das dauerhaft selbst pflegen wollen.

Wir haben deshalb einen REST-Service gebaut, der die komplette Sage-100-Funktionalität abbildet, nicht nur die vier Standardmodule.

Ob sich das für Sie rechnet, hängt davon ab, wie viele Bereiche Sie tatsächlich anbinden und wer die Schnittstelle in drei Jahren pflegt. Bei einer einzigen Shop-Anbindung raten wir davon ab.

Häufige Fragen

Worauf es hinausläuft

Die offizielle Sage-100-API ist besser als ihr Ruf. Sie ist nur kleiner, als viele erwarten. Prüfen Sie zuerst, ob Ihr Vorhaben mit Kunden, Lieferanten, Artikeln und Belegen auskommt. Wenn ja, nehmen Sie den Standardweg. Wenn nein, entscheiden Sie bewusst, welchen der übrigen Wege Sie gehen. Und nicht erst dann, wenn das Projekt schon zur Hälfte gebaut ist.