SOAP-Wrapper

E-invoicing in Germany: How to implement the obligation with SAP Business One

On SOAP-Wrapper is an integration layer that the COM-based DI API from SAP Business One behind a Simple Object Access Protocol-web service is hidden. Calls are accepted as XML envelopes over HTTP(S), mapped to DI-API methods by the wrapper, and the result is returned as a SOAP response. A classic example in the SAP standard is the DI server; Furthermore, integrators build their own SOAP wrappers to make specialised business logic or add-on functions network-capable.

Context

SOAP wrappers are created where an external system needs to interact with the DI API, but cannot handle either the COM installation or the process binding to a Windows client: Linux web applications, Java EAI systems, or older middleware platforms that prefer WSDL contracts. The wrapper takes over session handling (login against the Company DB, storage of the session ID), transaction grouping, and error mapping, so that consumers can work with generated proxy classes from the WSDL. In B1if scenarios, the WSAS- Adapter used to receive or send SOAP messages; custom-built .NET WCF services or Java JAX-WS endpoints are used, encapsulating the DI API internally.

Demarcation

A SOAP wrapper is not an SAP technology, but rather an architectural pattern – it can build upon or completely replace the DI server. Compared to REST APIs like the Service Layer, SOAP offers strict WSDL contracts, XML payloads, and more protocol overhead, but also established tooling for enterprise integration like WS-Security and WS-ReliableMessaging. For new developments, SAP recommends Service Layer v2; SOAP wrappers remain particularly useful where existing WSDL clients need to continue running or where DI API functions that are missing in the Service Layer are required.