Publier un service web SOAP dans SAP : du module fonction au WSDL

OData et REST attirent toute l'attention, mais SOAP reste partout dans les projets réels : banques, logisticiens, portails publics et anciens middlewares attendent souvent un WSDL. Bonne nouvelle : sur un système SAP ABAP, publier un service SOAP à partir d'un module fonction existant prend environ quinze minutes.

Nous allons créer un petit service qui renvoie les données de base d'un article à partir de son numéro.

C'est la méthode classique on-premise (S/4HANA ou ECC). Pour les nouveaux développements en ABAP Cloud, préférez OData/RAP ; dans S/4HANA Cloud, les services SOAP passent par des communication arrangements.

#1. Un module fonction compatible RFC

Un service web généré à partir d'un module fonction (inside-out) exige un module compatible RFC. Tous les paramètres doivent être passés par valeur.

D'abord une structure pour le résultat :

@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;
}

Puis le module fonction (SE37 ou ADT). Dans Attributs, choisissez Remote-Enabled Module :

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.

Deux détails qui font gagner du temps :

• Renvoyez un champ message plutôt que de lever des exceptions — les clients SOAP gèrent mieux un champ rempli qu'un SOAP fault pour « introuvable ».
• Appliquez vous-même les conversion exits (ici MATN1) : l'appelant envoie le format externe.

#2. Créer la définition de service

Dans SE37 : Utilities → More Utilities → Create Web Service → From the Function Module (ou dans SE80 : Create → Enterprise Service). L'assistant demande :

1. Nom de la définition de service — par exemple ZWS_MATERIAL_INFO et une description.
2. Endpoint — notre module fonction. Décochez Map Name pour garder exactement IV_MATNR, ES_MATERIAL.
3. Profil SOAP — le niveau de sécurité du service.
4. Package et ordre de transport.

Je recommande utilisateur et mot de passe avec garantie de transport — authentification uniquement via HTTPS. Activez la définition de service à la fin.

#3. Créer le binding dans SOAMANAGER

La définition décrit seulement l'interface. Pour l'appeler, il faut un binding (endpoint) :

1. Lancez la transaction SOAMANAGER (elle s'ouvre dans le navigateur).
2. Service Administration → Web Service Configuration, recherchez ZWS_MATERIAL_INFO.
3. Dans l'onglet Configurations, cliquez sur Create Service, saisissez un nom de service et de binding.
4. Sécurité : Transport Guarantee = HTTPS, Authentication = User ID/Password.
5. Sauvegardez — le binding est actif immédiatement.

Avec Open Binding WSDL Generation, vous obtenez l'URL du WSDL à transmettre au partenaire.

#4. Tester le service

Importez le WSDL dans SoapUI (ou Postman), configurez l'authentification basique et envoyez une requête :

<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>

La réponse :

<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>

L'appelant a besoin d'un utilisateur SAP autorisé — objet S_SERVICE (et S_RFC pour le groupe de fonctions). Un utilisateur système ou communication avec un rôle restreint est la solution propre.

#5. En cas de problème

Dans SRT_UTIL, vous pouvez activer une trace des payloads pour un utilisateur pendant une durée limitée — le moyen le plus rapide de voir ce qui a vraiment été envoyé.

#Résumé

• Module fonction compatible RFC, paramètres par valeur, messages plutôt qu'exceptions.
• Définition de service via l'assistant, profil de sécurité avec HTTPS.
• Binding dans SOAMANAGER, URL du WSDL au partenaire.
• Test dans SoapUI, analyse avec SRT_UTIL.

SOAP n'a rien de spectaculaire, mais il est fiable — et avec ces étapes, un partenaire qui « a besoin d'un WSDL » n'est plus une source d'inquiétude.