SOAP-Wrapper

E-Rechnung in Deutschland: So setzen Sie die Pflicht mit SAP Business One um

Ein SOAP-Wrapper ist eine Integrationsschicht, die die COM-basierte DI API von SAP Business One hinter einem Simple Object Access Protocol-Webservice verbirgt. Aufrufe werden als XML-Envelopes über HTTP(S) angenommen, vom Wrapper auf DI-API-Methoden gemappt und das Ergebnis wieder als SOAP-Response zurückgegeben. Klassischer Vertreter im SAP-Standard ist der DI-Server; darüber hinaus bauen Integratoren eigene SOAP-Wrapper, um Spezial-Geschäftslogik oder Add-on-Funktionen netzwerkfähig zu machen.

Kontext

SOAP-Wrapper entstehen dort, wo ein externes System mit der DI API arbeiten soll, aber weder die COM-Installation noch die Prozessbindung an einen Windows-Client übernehmen kann: Linux-Webanwendungen, Java-EAI-Systeme oder ältere Middleware-Plattformen, die WSDL-Verträge bevorzugen. Der Wrapper übernimmt Session-Handhabung (Login gegen die Company-DB, Ablage der Session-ID), Transaktionsklammerung und Fehler-Mapping, sodass Konsumenten mit generierten Proxy-Klassen aus der WSDL arbeiten können. In B1if-Szenarien wird der WSAS-Adapter genutzt, um SOAP-Nachrichten entgegenzunehmen oder abzusetzen; im Eigenbau kommen .NET-WCF-Services oder Java-JAX-WS-Endpoints zum Einsatz, die die DI API intern kapseln.

Abgrenzung

Ein SOAP-Wrapper ist keine SAP-Technologie, sondern ein Architekturmuster — er kann auf dem DI-Server aufsetzen oder diesen vollständig ersetzen. Gegenüber REST-APIs wie dem Service Layer bringt SOAP strikte WSDL-Verträge, XML-Payloads und mehr Protokoll-Overhead, aber auch etabliertes Tooling für Enterprise-Integration wie WS-Security und WS-ReliableMessaging. Für Neuentwicklungen empfiehlt SAP den Service Layer v2; SOAP-Wrapper bleiben vor allem dort sinnvoll, wo bestehende WSDL-Clients weiterlaufen müssen oder DI-API-Funktionen benötigt werden, die im Service Layer fehlen.