ABAP Cloud et Released Objects : préparer son code S/4HANA à la fin d'ECC

La date couperet arrive vite. SAP a confirmé fin de maintenance standard pour ECC 6.0 au 31 décembre 2027, avec une extension possible jusqu'en 2030 moyennant un contrat de maintenance étendue. Pour un DSI qui pilote un parc SAP avec des dizaines voire des centaines de programmes Z accumulés depuis 15-20 ans, l'enjeu n'est pas seulement de migrer techniquement. C'est de migrer un code custom qui restera maintenable et upgradeable sur les 10 prochaines années.

C'est exactement ce que SAP propose avec le concept ABAP Cloud et la notion de Released Objects. Sur les missions Kaï que je pilote, l'audit du code custom sur ce critère arrive en tête des chantiers de migration. Voici la méthode qu'on applique, et le retex concret du programme Kuhn Group.

Released Objects : la nouvelle frontière du custom SAP

Un Released Object est une API SAP publiée officiellement pour usage dans le code custom. SAP s'engage contractuellement sur sa stabilité dans le temps : pas de changement de signature, pas de suppression sans préavis, compatibilité montante garantie sur plusieurs versions.

Concrètement, chaque CDS View, classe, BAPI ou Service Definition exposé par SAP porte une annotation de release state :

• Use system-internally : usage interne SAP uniquement, à proscrire en code custom
• Use restricted : usage autorisé sous contrainte (généralement pour partenaires SAP)
• Use : Released, utilisable librement dans le code custom et garanti stable

Le principe est simple : tout ce qui n'est pas Use peut changer ou disparaître à n'importe quel upgrade S/4HANA, sans aucun préavis. Si votre code Z appelle un Function Module non released ou interroge directement une table standard SAP sans CDS View Released, vous prenez le risque que votre programme casse au prochain Service Pack.

ABAP Cloud et le modèle d'extensibilité 3-tier

ABAP Cloud est le nom commercial du modèle de développement SAP fondé sur l'usage exclusif des Released Objects. Il se décline en trois couches d'extensibilité, à choisir selon la nature du besoin.

Tier 1, Key User Extensibility

Pour les extensions légères (champ supplémentaire sur un écran Fiori, règle métier simple) effectuées par un utilisateur clé via les outils standards Fiori. Pas de code ABAP, pas de transport. Toujours upgrade-safe.

Tier 2, Developer Extensibility on-stack

Pour les extensions plus complexes développées par un développeur ABAP dans le système S/4HANA lui-même, en utilisant uniquement les Released Objects. Le code custom devient officiellement Cloud-ready et upgrade-safe. C'est la cible recommandée pour la plupart des développements custom sur S/4HANA.

Tier 3, Side-by-side extensions sur SAP BTP

Pour les extensions très spécifiques ou les applications qui doivent vivre indépendamment du cycle SAP. Le code tourne sur SAP BTP et communique avec S/4HANA via des services OData V4 Released. Maximum d'isolation, mais aussi maximum d'effort d'architecture.

Sur S/4HANA Cloud Public Edition, seuls les Tiers 1 et 3 sont possibles. Sur S/4HANA on-premise et Cloud Private Edition, les trois sont disponibles, mais le mode classique pre-ABAP Cloud reste autorisé pour le legacy. SAP encourage explicitement à privilégier ABAP Cloud sur tous les nouveaux développements.

Released vs Non-Released, exemples concrets

Le passage de la théorie à la pratique se fait à coup d'exemples. Voici ce qu'on rencontre régulièrement en audit.

La règle pratique : toute lecture directe de table standard SAP est aujourd'hui non-released. Il faut passer par une CDS View Interface SAP (préfixe I_) ou une CDS Projection View dédiée. Pareil pour les BAPI : la plupart ont une API RAP équivalente désormais.

Comment auditer son code custom : la méthode

L'audit se fait en deux temps : un inventaire automatique avec ATC, puis une lecture qualitative pour prioriser.

ATC en variante Cloud Development

Dans Eclipse ADT, on lance l'ABAP Test Cockpit sur le code Z avec la variante CLOUD_DEVELOPMENT (ou ABAP_CLOUD_FOR_PUBLIC_CLOUD si la cible est S/4HANA Cloud Public Edition). Le check produit la liste exhaustive des objets non released utilisés dans le code, classés par sévérité.

La transaction ATCDFL permet de configurer la variante par défaut au niveau système. Sur S/4HANA récent, le check est aussi disponible dans les requêtes de transport, ce qui empêche en amont l'ajout de nouveau code non conforme.

Priorisation des remédiations

Tous les objets non released n'ont pas le même poids. On priorise dans cet ordre :

1. Code critique production appelé fréquemment : à corriger en premier (risque de casse)
2. Code avec équivalent Released évident (BAPI vers RAP API) : effort faible, gain immédiat
3. Code peu utilisé ou en fin de vie fonctionnelle : décommissionnement plutôt que remédiation
4. Code sans équivalent Released aujourd'hui : wrapper class temporaire et demande de mise en Released via Customer Influence SAP

Retex : audit ABAP custom chez Kuhn Group

Sur la migration S/4HANA Greenfield de Kuhn Group (industrie agricole, fabricant de matériel pour l'agriculture), l'audit de conformité Released a été un chantier dédié de 4 mois avant le démarrage des développements.

Le périmètre de départ : environ 180 objets Z hérités de l'ancien système ECC, mélange de reports, batchs, BAPI custom et user-exits.

Méthodologie appliquée :

• Inventaire ATC global sur le système sandbox S/4HANA, variante CLOUD_DEVELOPMENT. Résultat brut : 1 200 findings de non-conformité.
• Catégorisation par type de finding (SELECT direct, CALL FUNCTION non released, type global non released, include non released).
• Pareto : 80% des findings concernaient 22 objets Z, soit moins de 15% du parc. Pareto classique.
• Plan de remédiation en trois vagues : critique (15 objets, 6 semaines), important (40 objets, 10 semaines), accessoire (le reste, traité au fil de l'eau pendant 6 mois).

Résultat à 12 mois post-migration : code custom à 95% Released-compliant, les 5% restants encapsulés dans des wrappers traçables avec ticket Customer Influence ouvert chez SAP. Aucune régression sur les deux premiers Service Packs S/4HANA appliqués depuis le go-live.

Le vrai bénéfice de ABAP Cloud n'est pas le label. C'est de pouvoir appliquer un Service Pack SAP sans se demander si quelque chose va casser dans le custom.

Pièges fréquents qu'on voit en mission

1. Confondre "présent" et "released"

Un Function Module peut exister dans la transaction SE37 sans pour autant être Released. Toujours vérifier le release state, pas juste l'existence de l'objet.

2. Released-for-cloud ≠ Released-for-on-premise

Un objet peut être Released pour S/4HANA on-premise sans être Released pour S/4HANA Cloud Public Edition. Adapter la variante ATC à la vraie cible du système.

3. Sous-estimer les includes et types globaux

Beaucoup d'équipes pensent uniquement aux SELECT et aux CALL FUNCTION. Les types globaux SAP utilisés en référence dans le code Z peuvent aussi être non released. ATC les remonte, ne pas les ignorer.

4. Croire que la remédiation est binaire

Tout n'est pas remédiation immédiate. Pour un objet utilisé une fois par an dans un batch peu critique, attendre que SAP publie une version Released peut être plus économique que de réécrire maintenant.

5. Oublier les Customer Influence tickets

Quand un objet n'a pas d'équivalent Released et est largement utilisé dans la communauté SAP, ouvrir un ticket Customer Influence pour demander sa promotion. SAP suit ces demandes pour décider quoi Released en priorité.