Internet Transaction Server SAP : Architecture, Configuration et Comparatif avec les Solutions Modernes

Accéder à SAP depuis un navigateur web sans installer le moindre client lourd — c’est exactement ce que promet l’Internet Transaction Server (ITS) depuis la fin des années 1990. Cette technologie, développée par SAP AG, a ouvert la voie à ce que l’on appelle aujourd’hui le SAP web access : la capacité de piloter des transactions ABAP directement depuis un poste client standard, sans configuration complexe côté utilisateur.

Si l’ITS SAP est souvent présenté comme une technologie « historique », il reste pleinement opérationnel dans de nombreux environnements SAP R/3, ECC 6.0 et même certaines architectures hybrides SAP S/4HANA. Comprendre son fonctionnement est indispensable pour tout consultant SAP BASIS, administrateur système ou architecte SI qui doit maintenir, auditer ou faire évoluer un paysage SAP existant.

Ce guide adopte une approche originale : plutôt que de simplement décrire l’ITS en isolation, nous le confrontons aux solutions qui lui ont succédé — SAP Fiori, SAP Business Client, SAP GUI for HTML — pour vous donner une vision claire de quand l’utiliser, comment le configurer, et quand envisager une migration.

🔍 Point clé	📌 Détail
🏗️ Architecture	Composants wgate (passerelle web) + agate (passerelle applicative)
🌐 Accès	Transactions SAP accessibles via navigateur standard (HTTP/HTTPS)
🔧 Compatibilité	SAP R/3 4.x, ECC 5.0/6.0, NetWeaver — ITS intégré depuis NW 7.0
⚡ Intégration moderne	Remplacé progressivement par SAP Fiori et SAP GUI for HTML
🔒 Sécurité	SSL/TLS, authentification SAP, gestion des rôles via SU01
📦 Déploiement	ITS standalone (externe) ou ITS intégré (embedded ITS)

Qu’est-ce que l’Internet Transaction Server et pourquoi a-t-il révolutionné l’accès SAP ?

L’Internet Transaction Server SAP est un middleware qui fait le lien entre un serveur web (Apache, IIS) et le système d’application SAP. Son rôle fondamental est de traduire les requêtes HTTP émises par un navigateur en appels RFC (Remote Function Call) compréhensibles par le serveur d’applications ABAP. En sens inverse, il convertit les réponses SAP en pages HTML envoyées au client.

Avant l’ITS, accéder à SAP imposait systématiquement l’installation du SAP GUI — un client lourd propriétaire — sur chaque poste utilisateur. Cette contrainte était particulièrement problématique pour les accès occasionnels, les utilisateurs externes (fournisseurs, prestataires) ou les environnements multi-sites. L’ITS a cassé ce modèle en proposant un accès universel via le navigateur, ce qui était une révolution dans les années 2000.

Concrètement, l’internet transaction server SAP permet d’exposer des transactions ABAP classiques (MM60, ME21N, VA01…) sous forme de pages web. Ces transactions sont soit rendues « telles quelles » via le mode SAP GUI for HTML, soit enrichies graphiquement via des templates HTML/CSS personnalisés appelés Internet Application Components (IAC). C’est cette flexibilité qui a fait sa longévité dans les grandes organisations.

Architecture ITS : comprendre wgate et agate pour mieux configurer

L’architecture de l’ITS SAP repose sur deux composants distincts qui communiquent entre eux : le wgate (Web Gateway) et l’agate (Application Gateway). Cette séparation physique, propre à l’ITS dit « standalone » ou externe, permet de placer le wgate en zone DMZ tout en maintenant l’agate dans le réseau interne sécurisé, proche du serveur SAP.

Le wgate est une extension de serveur web (un filtre ISAPI sous IIS ou un module sous Apache) qui intercepte les requêtes HTTP entrantes. Il ne contient aucune logique métier : son rôle se limite à router les requêtes vers le bon agate, à gérer les sessions HTTP et à renvoyer les réponses HTML au navigateur client. Le wgate est donc déployé sur le serveur web exposé à Internet ou à l’intranet.

L’agate, quant à lui, est le vrai moteur de l’ITS. C’est lui qui établit les connexions RFC avec le système SAP, qui gère le cache des templates HTML, qui exécute les scripts WML/HTML et qui maintient le contexte des sessions utilisateur. Un agate peut gérer plusieurs instances SAP simultanément, et plusieurs agates peuvent être configurés en cluster pour assurer la haute disponibilité. La communication entre wgate et agate utilise un protocole propriétaire SAP sur le port 1080 par défaut.

L’ITS intégré (Embedded ITS) : la simplification apportée par SAP NetWeaver

À partir de SAP NetWeaver 7.0 (2004-2005), SAP a intégré directement l’ITS dans le noyau du serveur d’applications ABAP. Cette version, appelée Embedded ITS ou SAP NetWeaver ITS, supprime la nécessité de déployer des composants wgate/agate séparés. Le serveur ICM (Internet Communication Manager) intégré à NetWeaver joue désormais le rôle de passerelle HTTP, simplifiant drastiquement l’architecture.

Avec l’embedded ITS, l’activation se fait directement depuis la transaction SICF (Service Infrastructure for Communication Framework). Les services web SAP sont activés ou désactivés individuellement, chaque transaction exposée devient un « service ICF » avec son propre chemin URL, ses paramètres de sécurité et ses handlers ABAP. Cette approche est plus fine, plus sécurisée et bien plus facile à administrer que l’ITS standalone.

SAP ITS Configuration : guide pas à pas pour déployer l’accès web

La configuration d’un ITS intégré (cas le plus courant sur les systèmes NetWeaver récents) s’articule autour de quelques étapes clés. Avant de commencer, vérifiez que le service ICM est bien démarré via la transaction SMICM et que le port HTTP ou HTTPS est actif. Sans ICM opérationnel, aucune requête web ne peut atteindre le système SAP.

La première étape concrète est l’activation des services ITS via SICF. Naviguez dans l’arborescence jusqu’au nœud /default_host/sap/bc/gui/sap/its/ pour trouver les services ITS standards. Chaque transaction SAP que vous souhaitez exposer doit avoir un service correspondant activé. Par exemple, le service webgui expose l’interface SAP GUI for HTML complète, tandis que des services spécifiques (comme ess pour Employee Self-Service) exposent des fonctionnalités ciblées.

La gestion des droits d’accès se configure à deux niveaux. Côté serveur, chaque service ICF peut avoir un handler d’authentification défini (Basic, SSO, certificat). Côté SAP, les autorisations classiques s’appliquent : l’utilisateur doit avoir les objets d’autorisation nécessaires pour exécuter la transaction concernée. Un point souvent négligé : l’objet d’autorisation S_ICF contrôle l’accès aux services ICF eux-mêmes et doit figurer dans le rôle de l’utilisateur.

Paramètres critiques à vérifier lors de la SAP ITS configuration

• Profil de l’instance : vérifier icm/server_port_X pour s’assurer que HTTP (80) et HTTPS (443) sont bien déclarés.
• SSL/TLS : importer les certificats serveur via la transaction STRUST et activer le protocole HTTPS sur l’ICM.
• Timeout de session : paramètre is/HTTP/session_timeout à ajuster selon vos politiques de sécurité (défaut : 600 secondes).
• Compression HTTP : activer icm/HTTP/enable_gzip pour améliorer les performances sur les liaisons lentes.
• Logging ICM : configurer les traces ICM via SMICM pour faciliter le débogage des problèmes de connexion.

Pour tester votre configuration, l’URL type d’accès au WebGUI SAP suit le pattern https://[host]:[port]/sap/bc/gui/sap/its/webgui. Si la page de login SAP s’affiche, votre ITS embedded est opérationnel. En cas d’erreur HTTP 500 ou de page blanche, commencez par consulter les traces ICM (SMICM > Goto > Trace File) et le journal SM21 pour identifier l’origine du problème.

Comparatif ITS vs SAP Fiori vs SAP GUI for HTML : quelle solution choisir ?

C’est la question centrale pour tout architecte SAP qui doit définir ou moderniser sa stratégie d’accès web. L’internet transaction server classique, SAP Fiori et SAP GUI for HTML répondent à des besoins différents, et une stratégie mature combine souvent ces trois approches plutôt que d’en choisir une seule.

Critère	ITS / WebGUI	SAP Fiori	SAP Business Client
🎯 Cible utilisateur	Utilisateurs techniques, accès occasionnel	Utilisateurs métier, usage quotidien	Power users, consultants
📱 Responsive / Mobile	Non (design daté)	Oui (natif)	Partiel
⚙️ Complexité déploiement	Faible (embedded ITS)	Élevée (ABAP Frontend Server, Launchpad)	Moyenne
🔄 Couverture fonctionnelle	Toutes les transactions ABAP	Applications Fiori disponibles uniquement	Très large
💰 Coût infrastructure	Minimal (inclus dans NW)	Élevé (licences, serveurs dédiés)	Moyen
🔮 Pérennité SAP	Maintenu mais non développé	Stratégie officielle SAP	Stable

SAP Fiori est clairement la direction stratégique de SAP pour les nouvelles implémentations, notamment sur S/4HANA. Son interface responsive, son modèle UX cohérent et son intégration native avec SAP S/4HANA en font le choix privilégié pour les projets greenfield ou les grandes transformations digitales. Cependant, Fiori ne couvre pas encore 100% des transactions SAP — les transactions de niche ou les développements ABAP custom restent souvent accessibles uniquement via ITS/WebGUI.

L’ITS via le mode SAP GUI for HTML (WebGUI) conserve donc une vraie pertinence opérationnelle. Il permet à un utilisateur occasionnel — un auditeur externe, un consultant en mission, un fournisseur — d’accéder à SAP depuis n’importe quel poste sans installation, avec une interface identique au SAP GUI traditionnel. Pour les équipes IT qui doivent maintenir des accès d’urgence ou gérer des transactions peu fréquentes, c’est souvent la solution la plus pragmatique et la moins coûteuse à maintenir.

Sécurité, erreurs courantes et bonnes pratiques ITS

La sécurité d’un accès ITS doit être traitée sérieusement, d’autant que l’ITS expose directement des transactions SAP sur le réseau. La première règle absolue : ne jamais exposer un service ITS sur Internet sans HTTPS. Configurez systématiquement SSL/TLS via STRUST, importez un certificat signé par une autorité de confiance (ou votre PKI interne) et forcez la redirection HTTP vers HTTPS au niveau de l’ICM ou du reverse proxy frontal.

La gestion des sessions est le deuxième point critique. L’ITS maintient des sessions SAP actives côté serveur, ce qui consomme des ressources de travail (work processes) même pour des utilisateurs inactifs. Définissez des timeouts appropriés et surveillez la transaction SM04 (Users overview) pour détecter des accumulations de sessions orphelines. En production, un monitoring régulier via SMICM et les alertes SAP Solution Manager permet d’anticiper les surcharges.

FAQ technique : erreurs fréquentes sur l’ITS SAP

Les problèmes les plus courants rencontrés lors du déploiement ou de l’exploitation d’un ITS méritent une attention particulière. Voici les cas les plus fréquents et leurs solutions :

• Erreur « Service not active » (HTTP 404) : le service ICF n’est pas activé. Aller dans SICF, localiser le service, clic droit > Activer.
• Page blanche après login : souvent lié à un problème de cookies tiers ou de configuration SSL. Vérifier les paramètres du profil login/create_sso2_ticket.
• Session timeout prématuré : revoir le paramètre is/HTTP/session_timeout et s’assurer que le reverse proxy ne coupe pas les connexions idle avant ce délai.
• Performances dégradées : activer la compression gzip (icm/HTTP/enable_gzip = 1) et vérifier le nombre de work processes dédiés aux connexions HTTP (transaction RZ04).
• Erreur d’authentification SSO : vérifier la synchronisation des horloges entre les serveurs (NTP) — un delta de plus de 5 minutes bloque les tickets SSO2.

Sur le plan des bonnes pratiques d’architecture, il est fortement recommandé de placer un reverse proxy (HAProxy, nginx, Apache avec mod_proxy) devant l’ICM SAP. Ce proxy joue le rôle de terminaison SSL, de pare-feu applicatif HTTP et de load balancer si plusieurs instances SAP doivent être exposées. Il permet également de centraliser les logs d’accès web indépendamment des logs SAP, ce qui simplifie les audits de sécurité.

Cas d’usage concrets : transactions SAP accessibles via ITS

Comprendre l’ITS dans l’abstrait, c’est bien. Voir quelles transactions SAP deviennent réellement accessibles via navigateur, c’est mieux. L’approche ITS/WebGUI est particulièrement efficace dans trois familles de cas d’usage qui coexistent dans la plupart des grandes organisations SAP.

Le premier cas d’usage est l’accès fournisseur et partenaire. Via des services ITS dédiés (Supplier Self-Service, anciennement SUS), les fournisseurs peuvent consulter leurs bons de commande, confirmer des livraisons ou télécharger des factures sans avoir besoin d’un compte SAP GUI. La transaction ME23N (affichage commande d’achat) accessible via WebGUI est un exemple typique d’un accès en lecture seule sécurisé pour des tiers.

Le deuxième cas est le support technique à distance. Lorsqu’un consultant doit intervenir ponctuellement sur un système client sans VPN configuré ou sans SAP GUI installé sur son poste, le WebGUI ITS devient une bouée de sauvetage. Des transactions comme SM59 (destinations RFC), SU01 (gestion utilisateurs) ou ST05 (trace SQL) sont parfaitement utilisables via navigateur pour un diagnostic rapide.

Le troisième cas concerne les applications IAC custom développées historiquement en ABAP + HTML Business. Ces applications, développées sur mesure pour des processus métier spécifiques (approbation de congés, saisie de temps, consultation de stocks), ont souvent été construites spécifiquement pour l’ITS. Leur migration vers Fiori représente un coût non négligeable, ce qui explique pourquoi de nombreuses entreprises maintiennent l’ITS opérationnel en parallèle d’un déploiement Fiori progressif.

Évolution et avenir de l’Internet Transaction Server dans l’écosystème SAP

SAP a officiellement intégré l’ITS dans le noyau NetWeaver et ne le commercialise plus comme produit séparé depuis la fin des années 2000. Cette intégration signifie que l’ITS embedded est disponible et maintenu sur toutes les versions NetWeaver supportées, y compris les systèmes ECC 6.0 qui bénéficient de la maintenance étendue SAP jusqu’en 2027-2030. Autrement dit, l’ITS ne disparaît pas du jour au lendemain — il s’efface progressivement au rythme des migrations S/4HANA.

Dans un contexte S/4HANA, l’ITS reste techniquement présent (le serveur d’applications ABAP est toujours là), mais SAP Fiori devient le canal d’accès principal recommandé. SAP investit massivement dans l’enrichissement du catalogue Fiori : plusieurs milliers d’applications Fiori couvrent désormais la majorité des processus core SAP. Pour les transactions encore non couvertes, le WebGUI via ITS reste la solution de transition pragmatique.

La vraie rupture technologique viendra probablement avec SAP Business Technology Platform (BTP) et les architectures cloud-native où les transactions ABAP traditionnelles n’ont plus leur place. Mais pour les entreprises en mode hybride — S/4HANA on-premise ou private cloud — l’ITS continuera d’avoir sa place comme filet de sécurité fonctionnel pour encore de nombreuses années.

Internet Transaction Server SAP : ce qu’il faut retenir pour prendre les bonnes décisions

L’internet transaction server n’est pas une relique du passé que l’on doit s’empresser de supprimer — c’est un composant mature, stable et toujours pertinent dans la majorité des paysages SAP en production. Sa valeur tient dans sa capacité à rendre accessible la totalité du catalogue transactionnel SAP sans infrastructure additionnelle coûteuse, avec un niveau de sécurité configurable et une compatibilité universelle côté client.

La stratégie gagnante pour une organisation SAP mature est une cohabitation raisonnée : déployer SAP Fiori pour les processus métier à fort volume et fort enjeu d’expérience utilisateur, maintenir le WebGUI ITS pour les accès techniques, les transactions rares et les utilisateurs occasionnels, et planifier la migration des IAC custom vers Fiori à un rythme cohérent avec les cycles de projet.

Vous gérez un environnement SAP et vous vous interrogez sur l’évolution de votre stratégie d’accès web ? Parcourez les autres ressources techniques de stce.fr pour approfondir les sujets BASIS, NetWeaver et architecture SAP — ou contactez notre équipe pour un audit personnalisé de votre configuration ITS et de votre roadmap vers SAP Fiori.