ABAP est vivant : bien utiliser Embedded Steampunk dans S/4HANA Public Cloud

Peu de langages ont été enterrés aussi souvent qu’ABAP. Et peu survivent avec autant de constance. Dans SAP S/4HANA Public Cloud, il est de retour, mais pas sous la forme de l’ABAP des user exits et des programmes Z que l’on connaît de vingt ans d’ECC. Le règlement s’appelle ABAP Cloud, le surnom est Embedded Steampunk, et bien utilisé, c’est l’outil d’extension le plus précis que le Public Cloud ait à offrir. Dans nos projets, le démarrage échoue rarement sur la technique. Il échoue sur la terminologie.

D’abord trier les termes

Autour de S/4HANA Public Cloud, il existe trois niveaux d’extensibilité, et ils sont confondus en atelier avec une régularité remarquable :

L’extensibilité key user est le barreau le plus bas : champs personnalisés, petits fragments de logique, écrans adaptés, le tout directement dans l’interface Fiori et sans environnement de développement. Un power user métier compétent va étonnamment loin ici, sans aucun développeur.

L’extensibilité développeur, alias Embedded Steampunk, c’est du vrai ABAP dans le tenant de développement du système S/4HANA Public Cloud lui-même. Même stack, même base de données, éditeur complet. Mais sous le règlement d’ABAP Cloud, nous y venons.

Le Steampunk side-by-side est le BTP ABAP Environment : une plateforme ABAP autonome sur SAP BTP, avec sa propre base HANA, découplée de l’ERP. La communication passe exclusivement par des API.

Si vous préférez construire en side-by-side sans ABAP, Cloud Foundry sur la BTP vous est aussi ouvert ; nous avons décrit à quoi cela ressemble dans un article dédié.

Ce qu’ABAP Cloud signifie concrètement

ABAP Cloud n’est pas un nouvel ABAP, c’est un sous-ensemble avec une clôture stricte. Quatre choses à intérioriser avant la première ligne de code :

• Seuls les objets et API released sont accessibles. Pas de SELECT direct sur des tables non released, pas de user exits, pas de modification du code SAP. Ce que SAP n’a pas marqué comme released n’existe tout simplement pas pour votre code.
• RAP est le modèle de programmation. L’ABAP RESTful Application Programming Model structure tout : les vues CDS comme modèle de données, les behavior definitions pour la logique, les service bindings pour le monde extérieur. Qui maîtrise RAP maîtrise Embedded Steampunk.
• On développe dans Eclipse. Les ABAP Development Tools (ADT) sont le seul IDE. Il n’y a pas de SE80 dans le Public Cloud, et personne ne la regrette longtemps.
• Le transport passe par des software components basés sur gCTS, à travers les trois systèmes DEV → TEST → PROD. Versionnement Git inclus, un vrai progrès par rapport à tout régime de transport classique.

L’échelle de décision issue de nos projets

Pour décider à quel niveau atterrit une exigence, une échelle simple a fait ses preuves. On commence en bas et on ne monte que s’il n’y a pas d’autre voie :

1. Key user d’abord. Une quantité étonnante de besoins tient ici : champs supplémentaires sur les documents, contrôles de champs, petites validations, mises en page adaptées. Sautez ce barreau et vous construirez des solutions de développeur pour des problèmes de configuration, en les payant deux fois.
2. Embedded Steampunk quand la logique doit tourner dans le stack. Déterminations et validations sur des business objects released, applications Fiori personnalisées sur vos propres objets RAP, logique qui siège de manière synchrone dans le flux documentaire. C’est exactement pour cela qu’il est fait.
3. Side-by-side sur la BTP quand c’est un produit à part entière. Applications avec leur propre cycle de vie, leur propre rythme de release, ou scénarios qui agrègent des données de plusieurs systèmes. Cela se place à côté de l’ERP, pas dedans.

L’échelle semble banale. Elle fait pourtant gagner des semaines dans chaque projet, parce qu’elle fait passer la discussion de « qu’est-ce qui serait sympa » à « qu’est-ce qui est nécessaire ».

Trois choses que nous apportons à chaque projet

L’arbre de décision clean core, une page, semaine une. Avec l’informatique du client, nous dessinons dès la première semaine de projet un arbre de décision : quelle exigence atterrit à quel niveau, et selon quels critères ? Une page A4, prête à plastifier. Cette seule page règle chaque futur débat d’architecture avant qu’il ne commence. L’effort tient en une demi-journée ; le retour, c’est chaque ronde d’escalade qui n’a jamais lieu.

Vérifier tôt la liste des API released. Ce ne sont pas les souhaits qui décident de l’architecture, ce sont les lacunes. Savoir si l’objet que vous voulez étendre dispose d’API, de BAdI et de vues CDS released se clarifie au jour deux, pas au sprint cinq. Nous avons vu des initiatives planifiées pendant trois semaines comme solutions Embedded Steampunk, jusqu’à ce que quelqu’un vérifie et constate : l’objet cible n’est pas released. Retour à la case départ.

Les upgrades trimestriels passent tout seuls. S/4HANA Public Cloud applique les upgrades de release automatiquement. Le code ABAP Cloud sur des API released les traverse sans que personne n’y touche ; les API released sont des contrats, et SAP les maintient stables. C’est tout le sens de l’exercice. Qui l’a vécu une fois, après des années de projets d’upgrade avec listes SPAU, comprend soudain la clôture autour d’ABAP Cloud comme une fonctionnalité.

Les limites honnêtes

Il n’y a pas de modification des objets SAP. Point final, pas d’exception, pas d’astuce. Et tout ce que l’on connaît d’ECC n’est pas released : certains BAPI et modules fonction classiques manquent encore aujourd’hui dans la liste.

Face à une lacune dure, il existe un chemin éprouvé : déposer une influence request auprès de SAP (les cycles de release sont courts, les chances réelles, nous avons vu des libérations arriver en deux cycles) et construire entre-temps un pont side-by-side sur la BTP, à démonter plus tard. Pas un moment agréable, mais un moment planifiable. Cela ne devient laid que si vous découvrez la lacune pendant les tests d’intégration, voir plus haut.

Questions fréquentes

ABAP est-il mort dans le Public Cloud ?

Non, bien au contraire. ABAP est de retour dans S/4HANA Public Cloud sous la forme d’ABAP Cloud : moderne, avec RAP comme modèle de programmation et un règlement clair. Ce qui a disparu, ce sont les modifications et les programmes Z sauvages. Vous pouvez appeler cela une perte. Nous appelons cela de la discipline, et le bilan des upgrades donne raison à cette lecture.

Les développeurs ABAP expérimentés doivent-ils tout réapprendre ?

Réapprendre oui, tout non. Le langage reste ABAP, l’état d’esprit change : RAP au lieu des reports, API released au lieu de l’accès direct, Eclipse au lieu de SE80. D’après notre expérience, c’est une montée en compétence ciblée de quelques semaines, pas de mois, à condition qu’une personne rodée à RAP accompagne les premiers objets.

Où vit le code, au juste ?

Dans le tenant de développement de votre propre instance S/4HANA Public Cloud, organisé en software components. De là, il voyage sur base gCTS, versionné, à travers DEV → TEST → PROD. Pas de système séparé, pas d’infrastructure à vous, mais une séparation propre du standard SAP.

Vous planifiez des extensions dans S/4HANA Public Cloud et voulez répondre à la question d’architecture avant qu’elle ne devienne coûteuse ? Nous apportons l’arbre de décision. Parlez-nous.