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 is older than OData and still runs a great deal of real integration — B2B interfaces, government and regulatory filings, and partner systems built before REST was the default.
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
1
Exposing an ABAP function as a service. SOAMANAGER configures it and generates a WSDL — a document
describing the operations, the message structures and how to call them.
SOAMANAGER
2
Any SOAP-capable client reads that WSDL and generates a stub, so a .NET or Java caller never writes XML by
hand.
3
The shape differs from OData, and the contrast is the question.
SOAP operations you define: CreateSalesOrder, GetCustomerDetails.
Strongly typed per operation. Closer to a remote procedure
call.
OData resources and a generic query language: one entity set,
filtered and shaped by the caller.4
With SOAP, a consumer wanting orders filtered differently needs a new operation. With OData they change the
query. That is the productivity difference, and the reason SAP standardised on OData for Fiori.
5
What SOAP gives in return is a strict contract. The WSDL defines exactly what is sent and returned, which
is why regulated interfaces favour it.
6
Consuming an external service from ABAP. Point the proxy wizard at the WSDL and it generates proxy
classes matching the message types:
7
DATA(lo_proxy) = NEW zco_partner_service( ).
lo_proxy->get_status( EXPORTING input = ls_req IMPORTING output = ls_resp ).8
Ordinary ABAP method calls. No SOAP envelopes constructed by hand, no XML parsed. The proxy generation is
what makes SOAP bearable from ABAP despite the protocol's verbosity.
9
WS-Security is the reason some partners require SOAP. Message-level signing and encryption are part of
the standard — the message itself is signed, not just the transport.
10
That matters when a message passes through intermediaries: HTTPS protects it between two hops, while a
signed SOAP message stays verifiable end to end. Regulatory interfaces mandate this regularly.
11
Where it stands. New SAP-native development uses OData, with CPI and API Management around it. SOAP
remains necessary for what already exists and for partners whose systems require it.
12
The position to take in an interview is that one: still required in practice, not the direction for new
work — rather than dismissing it, since a lot of production integration depends on it.
13
What the interviewer is probing.1. "When would you still choose SOAP?" Probing: judgement. Stalls: "Never." Moves up:
where the counterparty requires it, or where WS-Security, signing and formal contracts are needed —
banking and government interfaces especially.
14
2. "How is a service consumed in ABAP?" Probing: the mechanics. Stalls: "A function call."
Moves up: a consumer proxy generated from the WSDL, with a logical port in SOAMANAGER holding the
endpoint and credentials.
15
3. "Why is SOAMANAGER configuration a common failure point?" Probing: the practical
experience. Stalls: "It is not." Moves up: endpoints and credentials are per system and not
transported, so a working development setup says nothing about production.
16
4. "How do you troubleshoot a failing call?" Probing: the method. Stalls: "Check the log."
Moves up: the SOAP runtime error log and message monitor in SRT_MONI, plus the payload trace,
which usually shows a certificate or schema mismatch.