Migration S/4HANA : de Smartforms à Adobe Forms, retours du terrain

Sur la plupart des migrations S/4HANA qu'on conduit chez Kaï, le sujet de l'édition de documents finit toujours par revenir dans le périmètre. Smartforms ou Adobe Forms ? Que faire du parc existant ? Quels écueils éviter sur les volumes d'impression ? Voici notre retour de terrain.

L'édition de documents (factures, bons de livraison, commandes) est un sujet incontournable sur les projets ERP. Si Smartforms reste techniquement supporté pour faciliter les conversions, le standard SAP actuel repose sur Adobe Forms. En pratique, ce changement impacte surtout la manière dont on prépare les données côté ABAP avant la génération du PDF.

Contexte technique sous S/4HANA

Sur SAP ECC, on s'appuyait majoritairement sur Smartforms. Sur des formulaires simples, Smartforms reste suffisant. En revanche, certaines contraintes actuelles comme les QR Codes, les PDF interactifs ou les besoins d'archivage deviennent rapidement plus difficiles à maintenir.

Sous S/4HANA, le nouvel Output Management s'appuie principalement sur Adobe Forms, notamment pour les formulaires standards fournis par SAP. Smartforms reste supporté dans certains scénarios de compatibilité ou de reprise d'existant, mais les nouveaux développements s'orientent généralement vers Adobe Forms.

Le retour au code propre et débuggable

L'un des principaux intérêts d'Adobe Forms côté développement reste la séparation entre les données et l'affichage.

Sur un projet bien structuré, toute la logique métier (les SELECT, les calculs, les formatages) est codée dans le programme d'impression (le Driver Program). Qu'on l'appelle via la transaction classique NACE ou via le nouveau framework basé sur BRF+, le principe reste le même.

L'interface du formulaire Adobe sert principalement à exposer les structures et tables utilisées par le layout. Dans la pratique, il est préférable de conserver la logique métier côté ABAP afin de simplifier les phases de test et de maintenance.

Pourquoi on limite Smartforms aujourd'hui

Sur des projets récents, maintenir des Smartforms devient vite lourd, surtout lorsque les formulaires contiennent beaucoup de logique métier.

Un débogage difficile

Le débogage est plus délicat sur les anciens formulaires SAPscript ou Smartforms. La possibilité d'ajouter directement du code et des traitements métier dans les formulaires a souvent conduit à mélanger logique ABAP et logique d'affichage. En production, lorsqu'une donnée manquante provoque une erreur d'impression, l'analyse devient rapidement laborieuse, surtout sur des formulaires ayant évolué pendant plusieurs années.

Les contraintes de spool

Gérer des polices de caractères spécifiques ou des QR Codes (pour la facturation électronique, par exemple) demande souvent de configurer des drivers spécifiques sur les imprimantes physiques. Adobe Forms simplifie la gestion des QR Codes et des polices en s'appuyant directement sur la génération PDF.

L'architecture Adobe Forms en pratique

Le fonctionnement d'Adobe Forms implique trois éléments, avec une répartition claire entre le développement (ABAP) et l'administration système (Basis).

Le programme et l'interface (ABAP)

Le développeur prépare ses données dans le driver et les passe à l'interface, qui génère un module fonction standard.

Le Layout (Adobe Forms Designer)

C'est la partie graphique. On vient simplement lier (Binding) les champs de la maquette avec le flux de données XML généré par l'interface.

Le serveur ADS (Adobe Document Services)

C'est le moteur Java qui compile le document. Pour le développeur ABAP, c'est transparent. Notre module fonction fait un appel RFC vers ce serveur avec les données et le layout, et récupère un PDF. Si l'appel RFC échoue, c'est souvent un problème de configuration ou de charge côté serveur, un point qui se règle avec l'équipe Basis.

Smartforms vs Adobe Forms : tableau de décision

Pour un Tech Lead ou un responsable d'application qui arbitre, voici la grille qu'on applique en mission.

Cas concret : formulaire DREAL chez Kuhn

Sur un projet S/4HANA Greenfield, nous privilégions la refonte des documents critiques sous Adobe Forms.

Lors du projet pour le groupe Kuhn, nous avons notamment travaillé sur un formulaire de type "barré rouge", connu sous le nom DREAL, destiné aux véhicules modifiés. Le document reposait sur plusieurs tableaux dynamiques avec des règles d'affichage variables selon le contexte métier. La préparation des données était gérée via des CDS Views et du code ABAP, tandis que certains comportements visuels étaient pilotés directement dans Adobe Forms en JavaScript.

Avec Adobe Forms, l'approche a été beaucoup plus simple :

• Dans le programme d'impression, nous avons rempli une table interne standard avec les données brutes ;
• Le contenu de cette table a été traité et transmis à l'interface via un module fonction ;
• Dans la maquette Adobe, nous avons utilisé un peu de JavaScript pour gérer automatiquement l'affichage : masquage de sections, largeur des colonnes, polices et insertion d'images selon le contexte de la ligne.

Le programme ABAP-OO est resté léger, lisible, et l'ajustement visuel a été géré directement par le PDF.

Les points de vigilance

Performance lors des impressions en masse

L'appel au serveur ADS étant synchrone, la génération de plusieurs milliers de documents peut rapidement solliciter fortement le serveur Java et les ressources de spool. Un dimensionnement correct de l'infrastructure ADS reste donc important sur les projets avec de gros volumes d'impression.

Les transports

Les interfaces ABAP et les layouts Adobe étant transportés séparément, un oubli dans une demande de transport peut rapidement provoquer des erreurs de génération PDF en environnement de recette.

Le JavaScript "à l'ancienne" dans Adobe Forms Designer

Le moteur JS intégré à Adobe Forms Designer n'utilise pas les standards modernes (ES6+/Babel). Conséquence directe : les fonctions natives actuelles comme les boucles forEach ou map ne fonctionnent pas. Il faut coder en JavaScript basique, et déboguer cette partie directement dans l'outil peut vite devenir galère.

L'impact S/4HANA et le Clean Core

Cette approche s'intègre bien dans les principes Clean Core, puisqu'elle évite de disperser la logique métier dans les layouts. Garder les interfaces de formulaires vides de tout code métier permet de standardiser l'accès à la donnée.

Au lieu de faire des requêtes complexes, le programme d'impression peut s'appuyer sur l'ABAP Objet et l'architecture RAP, ou directement requêter des CDS Views. On peut même envisager d'alimenter certains formulaires via des services OData V4. Ainsi, les données imprimées proviennent de la même source que celles affichées sur les écrans Fiori de l'utilisateur.

En résumé

Dans beaucoup de projets S/4HANA, le passage à Adobe Forms est surtout l'occasion de remettre à plat les programmes d'impression existants. Le plus important n'est pas le layout PDF en lui-même, mais la manière dont les données sont préparées et structurées côté ABAP. Bien fait, ça aligne naturellement le parc de formulaires sur les principes Clean Core et facilite les futures évolutions.