Applications spécifiques (Z-apps)

Le nom vient de la règle de nommage ABAP : sans espace de noms préfixe enregistré, les objets du référentiel créés dans les systèmes clients doivent commencer par Y ou Z. « Z-app » est devenu un raccourci pour désigner toute application que le client construit et possède, quelle que soit sa technologie :

• applications SAPUI5 freestyle pour des tâches qu'aucune application standard ne couvre ;
• applications SAP Fiori elements sur des vues CDS et des services spécifiques ;
• copies d'applications livrées par SAP, renommées dans l'espace de noms Z et modifiées ;
• transactions, rapports ou applications Web Dynpro ABAP spécifiques lancés depuis le launchpad ;
• applications side-by-side sur SAP BTP qui étendent des processus SAP S/4HANA.

Certaines organisations enregistrent leur propre espace de noms préfixe au lieu d'utiliser Z ou Y, ce qui évite les conflits de noms entre projets. Le trait déterminant est la propriété, et non la lettre : une Z-app est toute application dont le cycle de vie relève de la responsabilité du client, et non de SAP.

Une application spécifique on-stack typique touche toutes les couches situées sous le launchpad :

1. Données et logique : des vues CDS et, pour les applications transactionnelles, un business object construit avec l'ABAP RESTful application programming model ; les applications plus anciennes utilisent l'ABAP classique.
2. Service : un service OData, publié via un service binding RAP ou, dans les applications plus anciennes, construit dans le Gateway Service Builder (SEGW) et activé dans /IWFND/MAINT_SERVICE.
3. Interface : une application SAP Fiori elements ou SAPUI5 freestyle, déployée dans le référentiel ABAP SAPUI5, où chaque application est stockée comme application BSP avec un nom en Z ou Y.
4. Contenu du launchpad : une tile et un target mapping dans un technical catalog créé avec le launchpad app manager (/UI2/FLPAM), référencés dans un business catalog et attribués via un rôle dans PFCG.
5. Transport : tous les objets transitent ensemble dans le paysage de transport.

Chacune de ces cinq étapes crée un objet que le client devra maintenir cohérent par la suite. Une application SAP Fiori spécifique est donc un petit produit composé de plusieurs éléments interdépendants, et non un fichier unique.

• Adéquation exacte : une application spécifique peut modéliser une étape de processus comme le métier la pratique réellement, y compris des étapes que SAP ne livre pas.
• Différenciation : les processus qui distinguent une entreprise sont ceux que les applications standard ont le moins de chances de couvrir.
• Même expérience utilisateur : construite avec SAP Fiori elements ou SAPUI5, une application spécifique a l'apparence et le comportement des applications SAP et utilise le même launchpad, les mêmes rôles et la même navigation.
• Options modernes compatibles avec les upgrades : les applications construites avec ABAP Cloud sur des API libérées, ou side-by-side sur SAP BTP, peuvent rester stables d'un upgrade à l'autre.

Exemple : Alder Manufacturing construit une petite application permettant à ses acheteurs de confirmer les créneaux de livraison de Bright Freight, une étape qu'aucune application standard ne propose, et la relie à la commande d'achat. Là où le standard s'arrête mais pas le processus, une application spécifique est souvent le moyen le plus direct de combler l'écart.

• La responsabilité ne s'arrête jamais. Chaque upgrade SAPUI5, chaque release back-end et chaque revue de sécurité touche l'application. Quelqu'un doit la tester, la corriger et savoir pourquoi elle existe.
• Les dépendances déterminent le coût. Les applications qui utilisent des objets SAP non libérés relèvent des niveaux clean core inférieurs et peuvent casser lors des upgrades ; les applications reposant sur des API libérées présentent beaucoup moins de risques.
• Le savoir part avec les personnes. De nombreuses applications spécifiques ont été construites par un seul développeur ou partenaire ; lorsqu'il part, la finalité et la logique de l'application deviennent souvent difficiles à reconstituer.
• Les copies divergent. Une application SAP copiée ne reçoit pas les corrections ni les améliorations de SAP, et l'écart se creuse à chaque release.
• Lacunes d'inventaire. Les organisations sont souvent incapables de dire combien d'applications spécifiques elles exploitent ou qui les utilise, ce qui est une plainte fréquente dans les communautés de praticiens.

Ces limites ne sont pas des défauts techniques ; elles sont le prix de la possession d'un logiciel que SAP ne maintient pas.

Descendez l'échelle d'extension et arrêtez-vous à la première étape qui convient :

1. Standard : cherchez dans la SAP Fiori Apps Reference Library une application ou un successeur qui couvre le besoin.
2. Extensibilité key user : un champ, un contrôle ou une valeur par défaut manquants relèvent de ce niveau, et non d'une nouvelle application.
3. Variante d'application plutôt que copie : pour modifier une application livrée par SAP, un SAPUI5 adaptation project crée une variante qui continue de recevoir les mises à jour SAP ; SAP le prend en charge en Public Edition depuis la release 2402.
4. Extensibilité développeur on-stack : une nouvelle application sur des API libérées avec ABAP Cloud.
5. Side-by-side sur SAP BTP : lorsque l'application couvre plusieurs systèmes, a besoin de ses propres données ou suit un cycle de vie différent.

Une erreur fréquente consiste à copier une application standard pour modifier deux champs ; la solution est un adaptation project ou l'extensibilité key user. Une application spécifique se justifie lorsque c'est l'étape de processus elle-même qui manque, et non un champ.

• On-premise et Private Edition : l'ABAP classique et ABAP Cloud sont tous deux disponibles ; les applications spécifiques vont donc d'un clean core intégral à des modifications profondes. C'est la gouvernance, et non le système, qui fixe les limites.
• SAP S/4HANA Cloud Public Edition : l'extensibilité développeur permet aux clients de construire des applications SAP Fiori spécifiques dans un sous-ensemble d'ABAP optimisé pour le cloud, uniquement sur des API libérées ; le développement Z classique avec accès sans restriction n'est pas possible.
• SAP BTP : les applications side-by-side vivent dans leur propre subaccount et suivent leur propre cycle de vie, et n'accèdent à SAP S/4HANA que par des API.

La question de la responsabilité est la même dans toutes les options ; ce qui diffère, c'est dans quelle mesure la plateforme restreint ce dont une application spécifique peut dépendre.