Explain Web Services & SOAP Integration in SAP in SAP

56 / 65

Integrationbeginner

Web Services & SOAP Integration in SAP

Exposing and consuming classic SOAP-based web services from ABAP, still relevant for legacy and enterprise B2B integration.

SOAP web services are the integration technology interviewers ask about specifically to check whether a candidate can work with older, still-common enterprise integration patterns - a huge amount of B2B/EDI-adjacent integration and older custom interfaces still run on SOAP rather than REST/OData, and understanding it remains a practical necessity in many real-world SAP landscapes even as SAP's own newer development has moved toward OData.

A SOAP service is like faxing a very specific, rigidly formatted government form to a partner organization - every field and section is strictly defined in advance (the WSDL), and both sides need the exact right form template to communicate at all, whereas OData is more like a flexible order form where the customer can check off exactly which fields and options they want from a shared, generic menu structure.

Key Concepts

Exposing an ABAP function module or class method as a SOAP web service traditionally used transaction SOAMANAGER (the modern successor to the older, now largely superseded WSCONFIG/WSADMIN transactions), which generates a WSDL (Web Services Description Language document) describing the service's operations, message structures, and binding details, letting any SOAP-capable client (regardless of platform - Java, .NET, another SAP system) generate a client stub and call the service without needing to hand-craft the exact XML request format. Unlike OData's uniform, generic query-oriented interface, a SOAP service's operations are custom-defined per interface (e.g., "CreateSalesOrder", "GetCustomerDetails"), each with its own strongly-typed request/response message structure defined in the WSDL - much closer in spirit to a strongly-typed RPC call than OData's generic, resource-oriented querying model.

SOAMANAGERWSCONFIGWSADMIN

Consuming an external SOAP service from ABAP uses a generated proxy class (via SE80/ABAP Development Tools' "Enterprise Service" wizard, which reads a WSDL and generates ABAP proxy classes/structures matching the service's message types), letting a developer call the external service through ordinary ABAP method calls rather than manually constructing SOAP envelopes and parsing raw XML responses - the proxy generation step is what makes SOAP consumption from ABAP relatively painless despite the underlying protocol's XML verbosity.

SE80

A senior-level answer is candid about SOAP's current position: it remains extremely common in legacy interfaces, many B2B/EDI-style integrations (especially with older non-SAP trading partners whose systems were built around SOAP/WS-* standards), and government/regulatory interfaces that mandate WS-Security or similar standards SOAP handles natively; but for new SAP-native development, OData (and CPI/API Management for broader integration) is the clear strategic direction, so a mature candidate frames SOAP competency as "still necessary for what's already out there and certain external partner requirements" rather than claiming it's SAP's forward path.