SOAP
SOAP (Simple Object Access Protocol) ist ein standardisiertes Protokoll, über das Software-Systeme strukturierte Daten in Form von XML-Nachrichten austauschen. Im ERP-Umfeld dient SOAP als Schnittstelle, über die ein ERP-System streng definierte Anfragen und Antworten mit Drittsystemen wie Buchhaltung, Logistik oder älteren Unternehmensanwendungen abwickelt.
SOAP (Simple Object Access Protocol) ist ein standardisiertes Nachrichtenprotokoll, über das zwei Software-Systeme strukturierte Daten austauschen – und zwar strikt im Format XML. SOAP legt genau fest, wie eine Anfrage und die zugehörige Antwort aufgebaut sein müssen: Jede Nachricht steckt in einem festen „Umschlag“ (Envelope) mit Kopf- und Rumpfteil. Dadurch wissen beide Seiten exakt, welche Felder mit welchem Datentyp erwartet werden. SOAP ist damit ein sehr formaler, vertraglich geregelter Weg, Programme miteinander sprechen zu lassen – im Gegensatz zu leichtgewichtigeren Ansätzen wie REST.
Im ERP-Kontext ist SOAP eine klassische Integrationsschnittstelle. Über sie ruft ein ERP-System Funktionen eines anderen Systems auf oder stellt eigene Funktionen bereit – etwa um Aufträge zu übergeben, Bestände abzufragen oder Belege an die Finanzbuchhaltung zu schicken. SOAP ist älter als die heute dominierenden REST-APIs und gilt als schwergewichtiger, dafür aber besonders strikt und gut für sicherheitskritische, transaktionsintensive Umgebungen geeignet. Man begegnet ihm vor allem dort, wo etablierte Unternehmenssysteme, Banken, Versicherungen oder große ERP-Suiten im Spiel sind.
Auf einen Blick
- SOAP = Simple Object Access Protocol, ein XML-basiertes Nachrichtenprotokoll
- Jede Nachricht steckt in einem festen Envelope aus Header und Body
- Ein WSDL-Vertrag beschreibt maschinenlesbar, welche Funktionen und Felder existieren
- Sehr strikt und typisiert – dafür schwergewichtiger als REST
- Im ERP verbreitet bei älteren Systemen, Finanz- und B2B-Anbindungen
Wie SOAP funktioniert: Envelope, XML und WSDL
SOAP folgt einem klaren Frage-Antwort-Prinzip, verpackt aber jede Nachricht in eine fest vorgegebene Struktur. Kern ist der sogenannte Envelope – ein XML-Umschlag, der jede SOAP-Nachricht umschließt. Er besteht aus einem optionalen Header, der Metadaten wie Authentifizierung oder Transaktionsinformationen trägt, und einem Body, der die eigentlichen Nutzdaten oder den Funktionsaufruf enthält. Weil alles in XML formuliert ist, sind die Nachrichten ausführlich und für Menschen lesbar, zugleich aber deutlich umfangreicher als ein knappes JSON-Objekt.
Der eigentliche Datenaustausch läuft meist über das Web-Protokoll HTTP, kann aber auch andere Transportwege nutzen. Anders als bei REST ist SOAP nicht an HTTP gebunden – das Protokoll definiert die Nachricht selbst, nicht den Weg. Kommt es zu einem Fehler, antwortet der Server mit einem strukturierten „SOAP Fault“, der Fehlercode und Ursache maschinenlesbar beschreibt. So bleibt auch die Fehlerbehandlung standardisiert und lässt sich zuverlässig automatisiert auswerten.
Die Rolle der WSDL-Datei
Ein zentrales Merkmal von SOAP ist die WSDL-Datei (Web Services Description Language). Sie beschreibt maschinenlesbar, welche Funktionen ein Webservice anbietet, welche Parameter sie erwarten und welche Datentypen zurückkommen. Die WSDL wirkt wie ein technischer Vertrag: Entwickler können aus ihr automatisch Programmcode für die Anbindung generieren, ohne die interne Logik des Zielsystems zu kennen. Diese formale Selbstbeschreibung ist ein wesentlicher Grund, warum SOAP in großen, langlebigen Systemlandschaften geschätzt wird.
SOAP im ERP-System: typische Einsatzfelder
Im ERP-Umfeld dient SOAP als Brücke zwischen dem zentralen System und seiner Umgebung. Klassische Anwendungsfälle sind die Anbindung an Finanz- und Buchhaltungssysteme, an Banken für den Zahlungsverkehr, an Speditions- und Logistikdienstleister oder an übergeordnete Konzernsysteme. Viele etablierte ERP-Suiten und branchenspezifische Anwendungen stellen ihre Schnittstellen bis heute als SOAP-Webservices bereit, weil diese über Jahre stabil dokumentiert und in bestehende Prozesse eingebettet sind.
Gerade im B2B-Geschäft und bei regulierten Branchen spielt SOAP seine Stärken aus. Die strikte Typisierung und die eingebauten Standards für Sicherheit und Transaktionssicherheit (etwa WS-Security für verschlüsselte, signierte Nachrichten) machen es zu einer verlässlichen Wahl, wenn Datenintegrität und Nachvollziehbarkeit wichtiger sind als maximale Geschwindigkeit oder schlanke Nachrichten. Ein ERP, das an ein Bankensystem oder eine Behördenschnittstelle andocken muss, trifft dort häufig auf SOAP.
Abgrenzung: SOAP vs. REST
Die häufigste Frage in der Praxis lautet: SOAP oder REST? Beide sind Wege, über die Systeme Daten austauschen, unterscheiden sich aber grundlegend im Charakter. SOAP ist ein vollständiges Protokoll mit strengen Regeln, festem XML-Format und eingebauten Standards für Sicherheit und Transaktionen. REST (siehe REST-API) ist eher ein leichtgewichtiger Architekturstil, der meist kompaktes JSON über HTTP nutzt und weniger Vorgaben macht.
Für die Wahl gilt als Faustregel: REST ist schlanker, schneller zu implementieren und dominiert heute Web- und E-Commerce-Anbindungen, etwa zwischen ERP, Shop und Marktplatz. SOAP bleibt dort relevant, wo es auf strikte Verträge, hohe Sicherheitsanforderungen und garantierte Transaktionsverarbeitung ankommt – oder schlicht, weil ein bestehendes System nur eine SOAP-Schnittstelle bietet. Nicht selten muss ein ERP beides bedienen und beide Welten über eine Middleware verbinden.
Wann SOAP heute noch die richtige Wahl ist
Für ein neues Integrationsprojekt greifen Teams meist zu REST, weil es einfacher und breiter unterstützt ist. SOAP ist die richtige Wahl, wenn das Gegenüber es vorschreibt – etwa ein Legacy-ERP, ein Bankensystem oder eine Behördenschnittstelle – oder wenn formale Verträge, Signaturen und garantierte Zustellung zwingend gefordert sind. In solchen Fällen ist der höhere Aufwand von SOAP kein Nachteil, sondern gerade der Grund, es einzusetzen.
DACH-Bezug und Praxis: SOAP anbinden
Im deutschsprachigen Mittelstand trifft man SOAP vor allem bei langjährig gewachsenen Systemlandschaften an. Ältere Warenwirtschafts- und Branchenlösungen, DATEV-nahe Anbindungen, Bank- und Zahlungsschnittstellen sowie EDI-nahe B2B-Prozesse setzen häufig noch auf SOAP-Webservices. Wer ein modernes Cloud-ERP einführt, aber ein Bestandssystem oder einen Großkunden mit SOAP-Schnittstelle behalten muss, kommt um die Technik nicht herum.
In der Umsetzung übernimmt selten der Fachanwender die Anbindung selbst. Stattdessen kommen fertige Konnektoren, eine Middleware oder iPaaS-Plattformen zum Einsatz, die SOAP und REST übersetzen und Feld-Mapping sowie Fehlerbehandlung übernehmen. Für die ERP-Auswahl ist entscheidend, ob das System die benötigten Protokolle unterstützt – idealerweise sowohl moderne REST-APIs als auch SOAP, um sowohl neue Cloud-Dienste als auch bestehende Altsysteme anbinden zu können.
Praxisbeispiel
Beispiel: ERP bindet ein Bankensystem per SOAP an
Ein mittelständischer Großhändler führt ein neues Cloud-ERP ein, muss aber weiterhin täglich Zahlungsaufträge an seine Hausbank übergeben und Kontoauszüge einlesen. Die Bank stellt dafür ausschließlich einen SOAP-Webservice bereit, dessen WSDL genau beschreibt, welche Felder ein Zahlungsauftrag enthalten muss und in welchem Format die Antwort zurückkommt.
Statt die Schnittstelle direkt im ERP zu programmieren, schaltet der Händler eine Middleware dazwischen. Sie nimmt die Auftragsdaten aus dem ERP über dessen REST-API entgegen, verpackt sie in den geforderten SOAP-Envelope, signiert die Nachricht per WS-Security und schickt sie an die Bank. Kommt ein SOAP Fault zurück, meldet die Middleware den Fehler strukturiert zurück ins ERP. So arbeiten das moderne ERP und das strikte SOAP-System der Bank zuverlässig zusammen, ohne dass jemand Zahlungen manuell erfasst.
Häufige Fragen
Passende ERP-Systeme
Passende Leistungen
Fragen zu SOAP in deinem ERP-Projekt?
Wir beraten herstellerunabhängig – und setzen es auf Wunsch selbst um.