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

Peu de langages de programmation ont été déclarés morts aussi souvent qu’ABAP, et peu continuent de vivre aussi sûrement. Dans SAP S/4HANA Public Cloud, il est de retour, mais pas sous la forme de l’ABAP des user exits et des rapports Z que vous connaissez de vingt ans d’ECC. Le cadre s’appelle ABAP Cloud, le surnom Embedded Steampunk, et bien utilisé, c’est l’outil d’extension le plus précis que propose le Public Cloud. Dans nos projets, le démarrage échoue rarement sur la technique. Il échoue sur la terminologie.

En bref : S/4HANA Public Cloud offre trois niveaux d’extensibilité : l’extensibilité key user dans l’interface Fiori, la developer extensibility avec ABAP Cloud dans le système (Embedded Steampunk) et les extensions side-by-side sur SAP BTP. ABAP Cloud signifie uniquement des API publiées, RAP comme modèle de programmation et les ABAP Development Tools sous Eclipse. Commencez au niveau le plus bas qui résout le besoin, et vérifiez tôt si l’objet que vous voulez étendre est publié.

D’abord clarifier les termes

Il existe trois niveaux d’extensibilité dans et autour de S/4HANA Public Cloud, et ils sont mélangés en atelier avec une régularité remarquable :

L’extensibilité key user est le premier échelon : champs personnalisés, petits fragments de logique et écrans adaptés, directement dans l’interface Fiori et sans environnement de développement. Un utilisateur métier averti va étonnamment loin ici.

La developer extensibility, aussi appelée Embedded Steampunk, est du vrai ABAP à l’intérieur même de S/4HANA Public Cloud, dans le système de développement du paysage à trois systèmes. Même pile, même base de données, éditeur complet, mais sous les règles d’ABAP Cloud. SAP la décrit dans l’aide sur la developer extensibility dans S/4HANA Cloud Public Edition.

Le Steampunk side-by-side est l’environnement ABAP de SAP BTP : une plateforme ABAP séparée sur SAP BTP, avec sa propre base de données, découplée de l’ERP. La communication passe uniquement par des API.

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

Ce qu’ABAP Cloud signifie en pratique

ABAP Cloud n’est pas un nouvel ABAP, mais un sous-ensemble gouverné avec une clôture ferme. Quatre points à intégrer avant la première ligne de code :

• Seuls les objets et API publiés sont accessibles. Pas de SELECT direct sur des tables non publiées, pas de user exits, pas de modification du code SAP. Ce que SAP n’a pas marqué comme publié n’existe pas pour votre code.
• RAP est le modèle de programmation. L’ABAP RESTful Application Programming Model structure tout : des vues CDS comme modèle de données, des définitions de comportement pour la logique, des service bindings vers l’extérieur. Qui connaît RAP connaît Embedded Steampunk.
• Le développement se fait dans Eclipse. Les ABAP Development Tools (ADT) sont l’environnement de développement. Il n’y a pas de SE80 dans le Public Cloud, et personne ne la regrette longtemps.
• Les transports passent par des composants logiciels à travers le paysage à trois systèmes : les développeurs les libèrent depuis ADT, puis ils sont importés en test et en production avec l’application Import Collection.

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

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

1. Key user d’abord. Une quantité surprenante de besoins y trouve sa place : champs supplémentaires sur les documents, contrôles de champs, petites validations, mises en page adaptées. Sautez cet échelon et vous construirez des solutions de développeur pour des problèmes de configuration, payées deux fois.
2. Embedded Steampunk quand la logique doit tourner dans la pile. Déterminations et validations sur des objets métier publiés, applications Fiori sur des objets RAP spécifiques, logique qui s’insère de manière synchrone dans le flux de documents. C’est exactement ce pour quoi il est conçu.
3. BTP side-by-side quand il s’agit d’un produit à part entière. Applications avec leur propre cycle de vie et leur propre rythme de livraison, ou scénarios qui agrègent des données de plusieurs systèmes. Cela a sa place à côté de l’ERP, pas dedans ; voir SAP BTP chez Spadoom.

L’échelle paraît triviale. Elle fait pourtant gagner des semaines dans chaque projet, parce qu’elle transforme la discussion de « ce qui serait bien » en « ce qui est nécessaire ».

Trois choses que nous apportons à chaque projet

L’arbre de décision clean core, une page, première semaine. Avec l’informatique du client, nous dessinons dès la première semaine de projet un arbre de décision : quel besoin atterrit à quel niveau, et selon quels critères. Une page A4 règle la plupart des débats d’architecture futurs avant qu’ils ne commencent. Cela coûte une demi-journée.

Vérifier tôt la liste des API publiées. Ce sont les lacunes qui décident de l’architecture, pas les souhaits. Si l’objet que vous voulez étendre dispose d’API publiées, de BAdI et de vues CDS, cela se vérifie le deuxième jour, pas au cinquième sprint. Nous avons vu des initiatives planifiées pendant trois semaines comme solutions Embedded Steampunk, jusqu’à ce que quelqu’un vérifie et constate que l’objet cible n’était pas publié.

Laisser passer les mises à niveau. S/4HANA Public Cloud applique les mises à niveau de version selon le calendrier de SAP. Le code ABAP Cloud basé sur des API publiées y survit sans que personne n’y touche, parce que les API publiées sont des contrats que SAP maintient stables. Après des années de projets de mise à niveau avec des listes SPAU, la clôture autour d’ABAP Cloud se lit comme une fonctionnalité.

Les limites

Il n’y a pas de modification d’objets SAP, et tout ce que vous connaissez d’ECC n’est pas publié : certains BAPI et modules fonctionnels classiques manquent encore dans la liste des objets publiés.

Quand vous tombez sur une vraie lacune, il existe une voie éprouvée : déposer une demande d’influence auprès de SAP et construire entre-temps un pont side-by-side sur la BTP, à démonter dès que SAP publie ce dont vous avez besoin. Ce n’est pas un moment agréable, mais il est planifiable. Cela ne devient pénible que si vous découvrez la lacune pendant les tests d’intégration.

Prendre ces décisions tôt fait partie de ce que couvre l’évaluation de préparation S/4HANA. Les extensions restent rarement dans l’ERP : les mêmes règles clean core s’appliquent au côté CRM de la pile intégrée S/4HANA Public Cloud et Sales Cloud V2, et notre guide clean core avec SAP CAP montre l’équivalent sur la BTP. Si vous comparez des partenaires d’implémentation, consultez les meilleurs partenaires SAP S/4HANA Public Cloud en Suisse et notre guide du meilleur partenaire SAP pour le Cloud ERP et le CRM en Suisse.

Questions fréquentes

ABAP est-il mort dans S/4HANA Public Cloud ?

Non. ABAP fait partie de S/4HANA Public Cloud sous la forme d’ABAP Cloud, avec l’ABAP RESTful Application Programming Model (RAP) et des règles claires : uniquement des API publiées, aucune modification. Ce qui a disparu, ce sont les modifications et les programmes Z sans limites, et c’est ce qui rend les mises à niveau sans histoire.

Les développeurs ABAP expérimentés doivent-ils être entièrement reformés ?

Reformés oui, entièrement non. Le langage reste ABAP ; l’état d’esprit change : RAP au lieu de rapports, API publiées au lieu d’accès directs aux tables, ABAP Development Tools sous Eclipse au lieu de SE80. D’après notre expérience, c’est une montée en compétence ciblée de quelques semaines, à condition qu’une personne ayant la pratique de RAP accompagne les premiers objets.

Où vit le code ?

Dans le système de développement de votre paysage à trois systèmes S/4HANA Public Cloud, organisé en composants logiciels. Les développeurs libèrent les transports depuis les ABAP Development Tools, et les extensions sont importées dans le système de test puis de production avec l’application Import Collection. Aucune infrastructure séparée n’est nécessaire.

---

Vous planifiez des extensions dans S/4HANA Public Cloud et voulez régler la question d’architecture avant qu’elle ne coûte cher ? Nous apportons l’arbre de décision. Parlez à notre équipe.