Einen SOAP-Webservice in SAP veröffentlichen: Vom Funktionsbaustein zur WSDL

OData und REST bekommen die meiste Aufmerksamkeit, doch in echten Projekten ist SOAP noch überall: Banken, Logistikpartner, Behördenportale und ältere Middleware erwarten oft eine WSDL. Die gute Nachricht: Auf einem SAP-ABAP-System ist ein SOAP-Service aus einem vorhandenen Funktionsbaustein in etwa einer Viertelstunde veröffentlicht.

Wir bauen einen kleinen Service, der zu einer Materialnummer die Basisdaten liefert.

Das ist der klassische On-Premise-Weg (S/4HANA oder ECC). Für Neuentwicklungen in ABAP Cloud ist OData/RAP vorzuziehen; in S/4HANA Cloud werden SOAP-Services über Communication Arrangements bereitgestellt.

#1. Ein RFC-fähiger Funktionsbaustein

Webservices aus einem Funktionsbaustein (Inside-Out) setzen einen RFC-fähigen Baustein voraus. Alle Parameter müssen als Wert übergeben werden.

Zuerst eine Struktur für das Ergebnis:

@EndUserText.label : 'Material info for web service'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
define structure zs_ws_material_info {
  matnr : matnr;
  maktx : maktx;
  mtart : mtart;
  matkl : matkl;
  meins : meins;
}

Dann der Funktionsbaustein (SE37 oder ADT). Unter Eigenschaften Remote-fähiger Baustein wählen:

FUNCTION z_ws_get_material_info
  IMPORTING
    VALUE(iv_matnr)    TYPE matnr
    VALUE(iv_language) TYPE spras DEFAULT sy-langu
  EXPORTING
    VALUE(es_material) TYPE zs_ws_material_info
    VALUE(ev_message)  TYPE bapi_msg.

  " Remote-enabled module (SE37 → Attributes → Remote-Enabled Module).
  " All parameters are passed by value – required for RFC and web services.

  DATA matnr TYPE matnr.

  " The caller sends the external format (e.g. without leading zeros)
  CALL FUNCTION 'CONVERSION_EXIT_MATN1_INPUT'
    EXPORTING  input  = iv_matnr
    IMPORTING  output = matnr
    EXCEPTIONS OTHERS = 1.
  IF sy-subrc <> 0.
    ev_message = |Invalid material number { iv_matnr }|.
    RETURN.
  ENDIF.

  SELECT SINGLE FROM mara AS m
    LEFT OUTER JOIN makt AS t ON t~matnr = m~matnr
                             AND t~spras = @iv_language
    FIELDS m~matnr, t~maktx, m~mtart, m~matkl, m~meins
    WHERE m~matnr = @matnr
    INTO CORRESPONDING FIELDS OF @es_material.

  IF sy-subrc <> 0.
    ev_message = |Material { iv_matnr } not found|.
  ENDIF.

ENDFUNCTION.

Zwei Details, die später Zeit sparen:

• Statt Ausnahmen ein Meldungsfeld zurückgeben — SOAP-Clients kommen mit einem gefüllten Feld deutlich besser zurecht als mit einem SOAP-Fault für „nicht gefunden".
• Konvertierungsexits selbst aufrufen (hier MATN1): Der Aufrufer sendet das externe Format.

#2. Service-Definition anlegen

In SE37 Hilfsmittel → Weitere Hilfsmittel → Web-Service anlegen → Aus dem Funktionsbaustein wählen (oder in SE80: Anlegen → Enterprise Service). Der Assistent fragt nach:

1. Name der Service-Definition — z. B. ZWS_MATERIAL_INFO und Kurzbeschreibung.
2. Endpunkt — unser Funktionsbaustein. Map Name abwählen, wenn die Elementnamen exakt IV_MATNR, ES_MATERIAL bleiben sollen.
3. SOAP-Profil — die Sicherheitsstufe des Service.
4. Paket und Transportauftrag.

Meine Empfehlung: Benutzer und Passwort mit Transportgarantie — Anmeldung nur über HTTPS. Zum Schluss die Service-Definition aktivieren.

#3. Binding in SOAMANAGER anlegen

Die Service-Definition beschreibt nur die Schnittstelle. Aufrufbar wird sie erst mit einem Binding (Endpunkt):

1. Transaktion SOAMANAGER starten (öffnet sich im Browser).
2. Service Administration → Web Service Configuration, nach ZWS_MATERIAL_INFO suchen.
3. Im Reiter Configurations auf Create Service klicken, Service- und Binding-Namen eingeben.
4. Sicherheit: Transport Guarantee = HTTPS, Authentication = User ID/Password.
5. Sichern — das Binding ist sofort aktiv.

Über Open Binding WSDL Generation erhalten Sie die WSDL-URL. Diesen Link schicken Sie dem Partner.

#4. Den Service testen

Die WSDL in SoapUI (oder Postman) importieren, Basic Authentication setzen und eine Anfrage senden:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:urn="urn:sap-com:document:sap:rfc:functions">
  <soapenv:Header/>
  <soapenv:Body>
    <urn:Z_WS_GET_MATERIAL_INFO>
      <IV_MATNR>MAT-1000</IV_MATNR>
    </urn:Z_WS_GET_MATERIAL_INFO>
  </soapenv:Body>
</soapenv:Envelope>

Die Antwort:

<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
  <soap-env:Header/>
  <soap-env:Body>
    <n0:Z_WS_GET_MATERIAL_INFOResponse xmlns:n0="urn:sap-com:document:sap:rfc:functions">
      <ES_MATERIAL>
        <MATNR>MAT-1000</MATNR>
        <MAKTX>Laptop 14 Developer Edition</MAKTX>
        <MTART>HAWA</MTART>
        <MATKL>IT01</MATKL>
        <MEINS>ST</MEINS>
      </ES_MATERIAL>
      <EV_MESSAGE/>
    </n0:Z_WS_GET_MATERIAL_INFOResponse>
  </soap-env:Body>
</soap-env:Envelope>

Der Aufrufer braucht einen SAP-Benutzer mit Berechtigung für den Service — Objekt S_SERVICE (und S_RFC für die Funktionsgruppe). Ein System- oder Kommunikationsbenutzer mit schmaler Rolle ist die saubere Lösung.

#5. Wenn etwas schiefgeht

In SRT_UTIL lässt sich für einen Benutzer zeitlich begrenzt ein Payload-Trace aktivieren — der schnellste Weg, um zu sehen, was wirklich gesendet wurde.

#Zusammenfassung

• RFC-fähiger Funktionsbaustein, Parameter als Wert, Meldungen statt Ausnahmen.
• Service-Definition per Assistent, Sicherheitsprofil mit HTTPS.
• Binding in SOAMANAGER, WSDL-URL an den Partner.
• Test in SoapUI, Analyse mit SRT_UTIL.

SOAP ist nicht glamourös, aber zuverlässig — und mit diesen Schritten ist ein Partner, der „eine WSDL braucht", kein Grund zur Sorge mehr.