SAP Gateway
SAP Gateway est le framework ABAP qui expose les services OData des systèmes SAP tels que SAP S/4HANA et SAP ERP, en assurant l'enregistrement des services, le routage, les contrôles d'autorisation et la journalisation des erreurs pour les applications SAP Fiori. SAP Gateway s'exécute soit en mode embedded dans le système back-end, soit sur un système hub distinct, un choix de déploiement aux conséquences durables pour l'exploitation.
L'essentiel
- Type
- Framework ABAP pour services OData (software component SAP_GWFND)
- Couche
- Services et API
- Options de déploiement
- Embedded (recommandé pour SAP S/4HANA) ou hub
- Transactions clés
- /IWFND/MAINT_SERVICE, /IWFND/V4_ADMIN, /IWFND/ERROR_LOG, /IWBEP/ERROR_LOG, /IWFND/GW_CLIENT
- Qui l'utilise
- Administrateurs Basis, développeurs ABAP, équipes de support SAP Fiori
- S'applique à
- SAP S/4HANA on-premise et Private Edition, SAP ERP (ECC)
Couche : Services et APIOù se situe-t-il ? ▾
Couche : Services et API
Ouvrir la carte d'architecture →Comment fonctionne SAP Gateway ?
SAP Gateway répartit le traitement OData entre un côté hub et un côté back-end, qui peuvent s'exécuter dans le même système ou dans deux systèmes :
- Une application SAP Fiori envoie une requête OData à une URL située sous le chemin ICF des services OData.
- Le composant hub la reçoit, vérifie que le service est enregistré et actif, et contrôle l'autorisation de démarrage du service pour l'utilisateur (objet d'autorisation S_SERVICE).
- Le hub utilise le system alias du service pour acheminer la requête vers le back-end qui l'implémente — le même système dans une configuration embedded, ou un back-end atteint via une connexion RFC dans une configuration hub.
- Le composant back-end exécute l'implémentation du service : un business object RAP, de la logique basée sur CDS ou les classes d'un projet SEGW.
- La réponse repart par le même chemin, et toute erreur est consignée dans le journal des erreurs du hub ou du back-end.
SAP Gateway est donc la couche de trafic entre les applications SAP Fiori et la logique métier ABAP, et non l'endroit où réside cette logique.
Faut-il choisir le déploiement embedded ou hub ?
SAP documente deux options de déploiement de SAP Gateway dans le cadre du SAP Fiori front-end server :
| Déploiement embedded | Déploiement hub | |
|---|---|---|
| Où les services sont enregistrés | Dans le système back-end lui-même | Sur un système hub distinct |
| Connexion au back-end | Locale (system alias LOCAL) | Connexion RFC plus system alias |
| Cycle de vie | Mis à niveau en même temps que SAP S/4HANA | Mis à niveau selon son propre calendrier |
| Statut pour SAP S/4HANA | Recommandé pour les nouvelles installations | Déprécié pour SAP S/4HANA, deviendra obsolète dans une release ultérieure |
L'option hub offrait autrefois un pilotage centralisé de plusieurs back-ends et un cycle de mise à niveau distinct pour la couche d'interface. Pour SAP S/4HANA, SAP recommande désormais le déploiement embedded et a annoncé la dépréciation du hub autonome, qui deviendra obsolète dans une future release, avec un chemin de migration documenté de l'autonome vers l'embedded. Les environnements qui servent encore d'anciens back-ends SAP ERP depuis un même hub nécessitent un plan distinct. Pour un nouveau système SAP S/4HANA, la décision de déploiement de SAP Gateway est de fait déjà prise : embedded.
Quelles transactions les administrateurs SAP Gateway utilisent-ils ?
| Tâche | Transaction |
|---|---|
| Enregistrer et activer des services OData V2, attribuer des system aliases | /IWFND/MAINT_SERVICE |
| Publier et gérer des groupes de services OData V4 | /IWFND/V4_ADMIN |
| Analyser les erreurs côté hub | /IWFND/ERROR_LOG |
| Analyser les erreurs dans le back-end | /IWBEP/ERROR_LOG |
| Envoyer ou rejouer des requêtes de test | /IWFND/GW_CLIENT |
| Tracer les payloads et les performances pour un utilisateur | /IWFND/TRACES |
| Vider le cache des métadonnées après des modifications | /IWFND/CACHE_CLEANUP et /IWBEP/CACHE_CLEANUP |
| Modéliser et générer des services classiques | SEGW (SAP Gateway Service Builder) |
| Activer les nœuds ICF et vérifier les connexions RFC | SICF et SM59 |
Le préfixe /IWFND/ appartient au composant hub et le préfixe /IWBEP/ au composant back-end ; dans un déploiement embedded, les deux ensembles s'exécutent dans le même système. Savoir de quel côté relève une transaction est le moyen le plus rapide de s'orienter dans SAP Gateway.
Où SAP Gateway s'applique-t-il selon les éditions de SAP S/4HANA et SAP BTP ?
- SAP S/4HANA on-premise et Private Edition : les clients ou leur partenaire d'exploitation administrent directement SAP Gateway, avec les transactions ci-dessus.
- SAP ERP (ECC) : SAP Gateway sert aussi les applications SAP Fiori pour SAP ERP, souvent depuis un hub qui héberge également le SAP Fiori Launchpad. Les fonctionnalités dépendent de la release SAP NetWeaver ; l'exposition en OData V4, par exemple, nécessite SAP NetWeaver 7.50 SP04 ou supérieur.
- SAP S/4HANA Cloud Public Edition : les transactions SAP Gateway de cette fiche sont documentées pour les systèmes on-premise et Private Edition ; en Public Edition, les API sont exposées aux autres systèmes via des communication arrangements.
- SAP BTP : les services de l'environnement ABAP sont publiés via des service bindings RAP et exposés aux autres systèmes via des communication scenarios, et CAP sert lui-même OData : le travail se fait donc dans ces outils plutôt que dans les transactions SAP Gateway.
SAP Gateway est un sujet d'administration principalement là où le client exploite la pile ABAP.
Comment dépanner un problème SAP Gateway ?
Lorsqu'une application SAP Fiori chez Alder Manufacturing affiche « no data » ou une erreur générique, parcourez les couches dans l'ordre :
- Trouver la requête en échec. Dans les outils de développement du navigateur, repérez l'appel OData (souvent à l'intérieur d'un
$batch) et notez le statut HTTP et le message. - 401 ou 403 : vérifiez l'autorisation de démarrage du service pour l'utilisateur avec SU53, et confirmez que le nœud ICF est actif dans SICF.
- 404 ou « service not found » : vérifiez l'enregistrement du service et le system alias dans /IWFND/MAINT_SERVICE, ou le groupe de services dans /IWFND/V4_ADMIN.
- Erreurs 500 : ouvrez /IWFND/ERROR_LOG, puis suivez l'entrée dans /IWBEP/ERROR_LOG pour identifier la cause côté back-end.
- Comportement inchangé après un transport : videz les caches de métadonnées des deux côtés.
- Reproduisez la requête dans /IWFND/GW_CLIENT pour écarter l'application.
Une plainte fréquente dans les communautés de praticiens est le temps perdu à déboguer du code SAPUI5 alors que la cause se trouvait dans la configuration. Vérifier SAP Gateway couche par couche permet de distinguer les lacunes d'enregistrement et d'autorisation des anomalies de code.
SAP Gateway ou OData : quelle différence ?
| SAP Gateway | OData | |
|---|---|---|
| De quoi s'agit-il | Framework et environnement d'exécution ABAP | Protocole ouvert d'accès aux données via HTTP |
| Où il existe | Dans les systèmes ABAP (SAP S/4HANA, SAP ERP) | Dans tout système qui implémente le protocole, y compris CAP sur SAP BTP |
| Question à laquelle il répond | Comment un système ABAP expose-t-il et achemine-t-il un service ? | Comment un client lit-il et modifie-t-il les données ? |
| Défaillance type | Service non enregistré, system alias erroné, autorisation de démarrage manquante | Options de requête mal formées, opération non prise en charge, incompatibilité de version |
OData définit la conversation ; SAP Gateway est l'un des environnements d'exécution qui la parlent pour les systèmes ABAP.
Questions fréquentes
SAP Gateway, est-ce la même chose que SAP NetWeaver Gateway ?
Oui. SAP NetWeaver Gateway est l'ancien nom du produit. La documentation SAP actuelle décrit le framework sous le nom SAP Gateway Foundation, livré dans le software component ABAP SAP_GWFND, qui fait partie de la plateforme ABAP sous-jacente à SAP S/4HANA.
SAP S/4HANA prend-il encore en charge un hub Gateway central ?
SAP a déprécié l'option de déploiement hub du SAP Fiori front-end server pour SAP S/4HANA et recommande le déploiement embedded, avec un chemin de migration documenté. Les environnements hub existants continuent de fonctionner pour l'instant, mais doivent planifier la transition avant que l'option ne devienne obsolète.
Les applications SAP Fiori ont-elles besoin de SAP Gateway ?
Les applications SAP Fiori qui appellent des services OData dans un système ABAP tel que SAP S/4HANA utilisent SAP Gateway pour atteindre ces services. Les applications dont les services s'exécutent sur SAP BTP, par exemple avec CAP, n'utilisent pas le runtime Gateway ABAP.
Qu'est-ce qu'un system alias dans SAP Gateway ?
Un system alias indique à SAP Gateway quel système back-end traite un service enregistré. Dans un déploiement embedded, l'alias pointe généralement vers le système local, tandis que dans un déploiement hub il pointe vers un back-end atteint via une connexion RFC.
Pourquoi un service OData renvoie-t-il encore d'anciennes métadonnées après une modification ?
SAP Gateway met en cache les métadonnées des services côté hub et côté back-end. Après le transport de modifications du modèle, les administrateurs vident les deux caches avec les transactions de nettoyage du cache afin que l'application SAP Fiori reçoive les nouvelles métadonnées à sa prochaine requête.
Sources
- SAP Help Portal: Embedded Versus Hub Deployment (SAP Gateway Foundation)
- SAP Help Portal: Hub Deployment Option of Front-End Server Is Deprecated (SAP S/4HANA 2025)
- SAP Help Portal: Embedded Deployment of SAP Fiori Front-End Server (Recommended)
- SAP Help Portal: Which Tools Can Be Used for Troubleshooting? (SAP Gateway Foundation)
- SAP Help Portal: Providing an OData Service (ABAP environment, service binding and communication scenario)
- S'applique à
- SAP S/4HANA on-premise · SAP S/4HANA Cloud Private Edition · SAP ERP (ECC)
- Dernière relecture