Applications transactionnelles

Une application SAP Fiori est transactionnelle lorsque sa finalité principale est de modifier des données métier : créer un document, le modifier, exécuter une action comme une libération ou un rejet, et enregistrer le résultat dans le back-end. La lecture des données fait partie du travail, mais l'application existe pour mener à bien une tâche.

Les premières documentations SAP Fiori de SAP décrivaient trois types d'application : les applications transactionnelles, les applications analytiques et les fact sheets. Dans SAP S/4HANA, le rôle des fact sheets est largement repris par les object pages, et la SAP Fiori Apps Reference Library désigne désormais ce type par « SAP Fiori - Object page / Fact sheet ». La classification décrit ce que fait une application, et non la manière dont elle est construite : une application transactionnelle peut être une application SAP Fiori elements ou une application SAPUI5 freestyle. Une application est transactionnelle parce qu'elle permet à un utilisateur de mener à terme une tâche métier, et non en raison de la technologie qui la sous-tend.

Une application transactionnelle typique dans SAP S/4HANA suit ces étapes :

1. L'utilisateur ouvre l'application depuis une tile ou un lien ; le SAP Fiori Launchpad résout l'intent vers l'application.
2. L'application charge la liste ou l'objet via un service OData.
3. Lorsque l'utilisateur commence à modifier, de nombreuses applications actuelles créent un draft, si bien que le travail en cours est enregistré sans être comptabilisé.
4. À l'enregistrement ou lors d'une action comme l'approbation, le service OData appelle la logique métier du back-end, qui exécute les contrôles, la vérification des autorisations et la comptabilisation.
5. Le statut du document change dans le système de référence, et des processus en aval, comme un Flexible Workflow, peuvent démarrer.

Pour les nouveaux développements, SAP positionne l'ABAP RESTful application programming model comme la manière de construire et d'étendre les applications SAP Fiori transactionnelles. Les applications plus anciennes utilisent des modèles antérieurs basés sur Gateway. Quel que soit le modèle, une application transactionnelle est un front-end de la logique métier du back-end, là où résident réellement les règles.

La SAP Fiori Apps Reference Library est le principal outil de recherche. Une séquence pratique :

1. Recherchez par tâche métier ou par la transaction SAP GUI que vous souhaitez remplacer.
2. Filtrez le type d'application sur « SAP Fiori - Transactional ».
3. Vérifiez la version du produit : une application disponible dans la release SAP S/4HANA Cloud actuelle peut ne pas exister dans une release on-premise plus ancienne.
4. Lisez les informations d'implémentation : services OData, business catalogs et business roles requis.
5. Vérifiez le libellé de technologie d'interface, qui distingue les applications SAP Fiori elements des autres applications SAPUI5.

Les libellés ne sont pas exclusifs. La Procurement Overview Page (F1990), par exemple, est classée à la fois comme transactionnelle et comme analytique. Pour les applications transactionnelles, le type d'application est un premier filtre utile, et non une description complète de ce que fait une application.

• SAP S/4HANA Cloud Public Edition : SAP livre et met à jour les applications à chaque release cloud. Les clients les mettent à disposition via des business roles et les étendent avec les outils key user ou l'extensibilité développeur ; modifier le code SAP n'est pas possible.
• Private Edition et on-premise : le client active les applications, leurs services OData et leur contenu de launchpad, et maîtrise l'arrivée des nouvelles versions d'application via les upgrades. Les modifications classiques restent techniquement possibles, mais vont à l'encontre de l'approche clean core.
• Base de données : dans SAP S/4HANA, toutes les applications s'exécutent sur SAP HANA. Dans l'ancienne SAP Business Suite, les applications transactionnelles pouvaient s'exécuter sur d'autres bases de données, tandis que les applications analytiques et les fact sheets nécessitaient SAP HANA.

Exemple : Alder Manufacturing, en Private Edition, doit activer les services sous-jacents à Manage Purchase Orders avant que les acheteurs puissent utiliser la tile ; un client Public Edition se contente d'attribuer le business role. L'application transactionnelle est le même concept dans toutes les éditions ; ce qui diffère, c'est qui l'active et qui la modifie.

1. Supposer qu'une application standard couvre toute la transaction SAP GUI. De nombreuses applications se concentrent sur les étapes les plus courantes. Comparez les champs et les actions avec la manière dont les utilisateurs travaillent réellement avant de les faire basculer.
2. Accorder la tile mais pas l'autorisation back-end. Les utilisateurs voient alors l'application mais ne peuvent pas enregistrer. Vérifiez à la fois le contenu du launchpad et les rôles back-end.
3. Vérifier le nom de l'application mais pas la release. Les versions et fonctionnalités des applications diffèrent selon les releases et les éditions.
4. Ignorer les successeurs des applications. Certaines applications existent en plusieurs versions, comme Manage Purchase Orders (Version 2) ; retenez la version actuelle dans le périmètre.
5. Considérer une application comme l'ensemble du processus. Une application transactionnelle accomplit une tâche sur un business object ; les étapes qui la précèdent et la suivent relèvent d'autres applications, de workflows ou de personnes.

La plupart des problèmes liés aux applications transactionnelles viennent du cadrage et des autorisations, et non des applications elles-mêmes.