{"id":8426,"date":"2025-05-14T17:39:09","date_gmt":"2025-05-14T15:39:09","guid":{"rendered":"https:\/\/sapinnov.com\/?p=8426"},"modified":"2025-05-14T17:41:16","modified_gmt":"2025-05-14T15:41:16","slug":"fonction-imports-actions-functions-segw-rap-cap-partie-2","status":"publish","type":"post","link":"https:\/\/sapinnov.com\/index.php\/2025\/05\/14\/fonction-imports-actions-functions-segw-rap-cap-partie-2\/","title":{"rendered":"SAP SEGW vs RAP vs CAP : Tirer le meilleur parti des fonction imports, des actions et des fonctions (Partie 2)"},"content":{"rendered":"\n
Apr\u00e8s avoir travaill\u00e9 sur plusieurs projets SAP, j\u2019ai remarqu\u00e9 une tendance r\u00e9currente : une multitude de projets SEGW remplis de fonction imports qui sont g\u00e9n\u00e9ralement mal utilis\u00e9s ou inutiles. Fort de mon exp\u00e9rience \u2014 et apr\u00e8s avoir \u00e9tudi\u00e9 la documentation SAP \u2014 j\u2019ai d\u00e9cid\u00e9 d\u2019\u00e9crire ce blog afin de faire la lumi\u00e8re sur les fonction imports. J\u2019expliquerai ce qu\u2019ils sont, \u00e0 quoi ils servent, quand les utiliser et quand il vaut mieux les \u00e9viter. Je le ferai non seulement pour les projets SAP SEGW, mais aussi pour leurs \u00e9quivalents dans les frameworks plus r\u00e9cents que sont SAP RAP et CAP \u2014 car je m\u2019investis activement dans ces approches de d\u00e9veloppement modernes et je travaille sur des projets m\u00e9tiers qui les exploitent. Pour rendre cela plus concret, je pr\u00e9senterai un exemple pratique, que j\u2019ai mis \u00e0 disposition sur GitHub.<\/p>\n\n\n\n
\u00c9claircissons cette confusion ensemble. Alors, attrapez votre caf\u00e9 et plongeons dans le sujet !<\/p>\n\n\n\n
Les nouveaux frameworks de SAP<\/h2>\n\n\n\n
SAP RAP (RESTful ABAP Programming Model) et SAP CAP (Cloud Application Programming Model) sont deux frameworks modernes de SAP con\u00e7us pour la cr\u00e9ation d\u2019applications.<\/p>\n\n\n\n
Les deux frameworks permettent d\u2019\u00e9tendre les op\u00e9rations CRUD standard en permettant aux d\u00e9veloppeurs de d\u00e9finir des logiques personnalis\u00e9es \u2014 commun\u00e9ment appel\u00e9es actions ou fonctions. Dans RAP, ces logiques sont introduites dans les d\u00e9finitions de comportements, tandis que dans CAP, elles sont mod\u00e9lis\u00e9es dans la couche de service. Cette similarit\u00e9 fonctionnelle rend naturel de les aborder ensemble.<\/p>\n\n\n\n
Une petite pr\u00e9cision pour le contexte : ce blog ne rentrera pas dans les diff\u00e9rences entre les impl\u00e9mentations statiques et bas\u00e9es sur des instances, ainsi que les actions et fonctions li\u00e9es et non li\u00e9es\u2026 car ces sujets d\u00e9passent le cadre de cet article \u2014 bien qu’ils puissent faire l\u2019objet d’un futur blog.<\/p>\n\n\n\n
Contexte SAP RAP<\/h2>\n\n\n\n
SAP RAP est le framework moderne de SAP pour d\u00e9velopper des services OData et des applications m\u00e9tier en utilisant ABAP. Il sert le m\u00eame objectif de base que SAP SEGW (Service Gateway), qui est d\u2019exposer les donn\u00e9es et les op\u00e9rations des syst\u00e8mes SAP via OData.<\/p>\n\n\n\n
Contrairement \u00e0 SEGW, qui repose fortement sur la programmation manuelle et des mod\u00e8les s\u00e9par\u00e9s, RAP utilise une approche rationalis\u00e9e et bas\u00e9e sur des mod\u00e8les, avec une meilleure int\u00e9gration dans l\u2019environnement ABAP RESTful, en exploitant CDS (Core Data Services) pour d\u00e9finir et g\u00e9rer les mod\u00e8les de donn\u00e9es de mani\u00e8re plus d\u00e9clarative.<\/p>\n\n\n\n
Contexte SAP CAP<\/h2>\n\n\n\n
SAP CAP est le framework moderne de SAP pour la cr\u00e9ation de services et d’applications, particuli\u00e8rement optimis\u00e9 pour la SAP Business Technology Platform (BTP). Il offre une exp\u00e9rience de d\u00e9veloppement simplifi\u00e9e, de bout en bout, avec un support int\u00e9gr\u00e9 pour d\u00e9finir des mod\u00e8les de donn\u00e9es, des API de services et de la logique personnalis\u00e9e \u00e0 l’aide de Core Data Services (CDS), Node.js ou Java.<\/p>\n\n\n\n
Alors que SAP RAP est plus centr\u00e9 sur ABAP et adapt\u00e9 aux syst\u00e8mes sur site ou S\/4HANA, CAP est natif du cloud et id\u00e9al pour d\u00e9velopper des applications dans l’environnement BTP.<\/p>\n\n\n\n
Contrairement aux approches traditionnelles comme SEGW ou m\u00eame ABAP RAP, qui sont profond\u00e9ment ancr\u00e9es dans la pile ABAP, CAP est ouvert et orient\u00e9 services par conception. Il favorise une forte int\u00e9gration avec SAP HANA, SAP Fiori et des services externes via des standards ouverts tels que OData et REST.<\/p>\n\n\n\n
Op\u00e9rations standard vs non-standard dans RAP et CAP<\/h2>\n\n\n\n
Les deux frameworks SAP RAP et SAP CAP distinguent les op\u00e9rations standard des op\u00e9rations non-standard dans OData. Les op\u00e9rations standard font r\u00e9f\u00e9rence aux fonctionnalit\u00e9s CRUD, qui sont g\u00e9r\u00e9es automatiquement par les frameworks. En plus des op\u00e9rations CRUD, les deux frameworks g\u00e8rent \u00e9galement le comportement transactionnel, la gestion des brouillons, la validation et la persistance avec une configuration minimale.<\/p>\n\n\n\n
Les op\u00e9rations non-standard, quant \u00e0 elles, sont utilis\u00e9es pour impl\u00e9menter des logiques m\u00e9tier personnalis\u00e9es au-del\u00e0 du CRUD, suivant le m\u00eame mod\u00e8le conceptuel que les Function Imports dans l\u2019approche classique SEGW.<\/p>\n\n\n\n
Actions et Fonctions dans RAP et CAP<\/h2>\n\n\n\n
Dans RAP et CAP, les Actions et Fonctions repr\u00e9sentent des op\u00e9rations non-standard qui int\u00e8grent de la logique personnalis\u00e9e dans l\u2019application. Les Actions sont utilis\u00e9es pour des logiques qui peuvent modifier les donn\u00e9es ou entra\u00eener des effets secondaires, tandis que les Fonctions sont des op\u00e9rations en lecture seule qui retournent des donn\u00e9es.<\/p>\n\n\n\n
Dans RAP, ces \u00e9l\u00e9ments sont d\u00e9finis dans la d\u00e9finition de comportement et impl\u00e9ment\u00e9s dans la classe de pool de comportement, assurant ainsi une gestion correcte des transactions et des autorisations.<\/p>\n\n\n\n
Dans CAP, ils sont d\u00e9finis dans la d\u00e9finition de service CDS, et l\u2019impl\u00e9mentation r\u00e9side dans des handlers de services (Node.js ou Java).<\/p>\n\n\n\n
Les deux frameworks assurent que ces op\u00e9rations sont enti\u00e8rement conformes \u00e0 OData V4 et peuvent \u00eatre consomm\u00e9es sans probl\u00e8me par Fiori Elements ou d\u2019autres clients OData.<\/p>\n\n\n\n
Diff\u00e9rence fondamentale entre SEGW et SAP RAP\/CAP<\/h2>\n\n\n\n
SAP SEGW (SAP Gateway Service Builder) repose sur une approche flexible pour la gestion des op\u00e9rations CRUD. Lors de la cr\u00e9ation ou de la mise \u00e0 jour d\u2019un service, le framework g\u00e9n\u00e8re des m\u00e9thodes standard telles que CREATE_ENTITY, UPDATE_ENTITY, DELETE_ENTITY, etc., que les d\u00e9veloppeurs peuvent red\u00e9finir pour incorporer une logique m\u00e9tier plus complexe r\u00e9pondant aux exigences fonctionnelles.<\/p>\n\n\n\n
Lorsqu\u2019un appel de batch est effectu\u00e9 depuis le front-end, par exemple via une op\u00e9ration SubmitChanges, les op\u00e9rations group\u00e9es (cr\u00e9ation de l’entr\u00e9e C, mise \u00e0 jour de l’entr\u00e9e A, suppression de l’entr\u00e9e B, etc.) sont envoy\u00e9es individuellement en back-end. En d’autres termes, chaque op\u00e9ration est trait\u00e9e s\u00e9par\u00e9ment par la m\u00e9thode correspondante (CREATE_ENTITY, UPDATE_ENTITY, etc.).<\/p>\n\n\n\n
Cependant, cette approche introduit certaines limitations, notamment en mati\u00e8re de gestion des erreurs dans le traitement par lot. \u00c9tant donn\u00e9 que chaque op\u00e9ration est trait\u00e9e ind\u00e9pendamment, g\u00e9rer des sc\u00e9narios impliquant des rollback partiels ou une propagation coh\u00e9rente des erreurs \u00e0 travers le lot devient plus complexe.<\/p>\n\n\n\n
SAP RAP et SAP CAP adoptent une approche structur\u00e9e, bas\u00e9e sur des mod\u00e8les, pour la gestion des donn\u00e9es et de la logique m\u00e9tier. Les deux reposent sur OData v4 et Core Data Services (CDS) pour d\u00e9finir les entit\u00e9s, leurs relations et leurs comportements.<\/p>\n\n\n\n
Les op\u00e9rations CRUD comme CREATE et UPDATE sont d\u00e9finies au niveau de l\u2019entit\u00e9 et sont con\u00e7ues pour \u00eatre trait\u00e9es individuellement, ce qui signifie qu\u2019elles sont ex\u00e9cut\u00e9es sur une seule instance \u00e0 la fois. Pour g\u00e9rer des traitements plus complexes ou des sc\u00e9narios impliquant plusieurs entit\u00e9s, RAP et CAP recommandent l\u2019utilisation d\u2019actions ou de fonctions, qui permettent d\u2019encapsuler la logique m\u00e9tier sans l\u2019int\u00e9grer directement dans les op\u00e9rations standard.<\/p>\n\n\n\n
Cependant, si aucune logique sp\u00e9cifique n’est requise, il est toujours possible de r\u00e9aliser un traitement par lot (mise \u00e0 jour en masse) en utilisant les op\u00e9rations CRUD standard. Cela dit, cette approche n’est pas recommand\u00e9e, car les op\u00e9rations CRUD sont destin\u00e9es au traitement des enregistrements individuels, avec des validations, des hooks de cycle de vie (comme avant, apr\u00e8s, v\u00e9rification, etc.), et un traitement des erreurs ligne par ligne. Utiliser le traitement par lot via CRUD peut entra\u00eener un comportement incoh\u00e9rent, des rollbacks partiels difficiles \u00e0 contr\u00f4ler, et une perte de contr\u00f4le sur la logique m\u00e9tier et transactionnelle globale.<\/p>\n\n\n\n
De plus, l’utilisation des actions pr\u00e9sente de nombreux autres avantages, tels que :<\/p>\n\n\n\n
\n
G\u00e9n\u00e9ration automatique d’interface : Les actions sont automatiquement expos\u00e9es sous forme de boutons ou d’\u00e9l\u00e9ments de menu dans les interfaces Fiori Elements. Elles peuvent \u00eatre d\u00e9clench\u00e9es sur plusieurs s\u00e9lections (multi-s\u00e9lection) avec un comportement UX coh\u00e9rent, et permettent de nommer explicitement des processus m\u00e9tier sp\u00e9cifiques (par exemple, \u00ab\u00a0Valider tout\u00a0\u00bb, \u00ab\u00a0Envoyer les factures\u00a0\u00bb).<\/li>\n\n\n\n
Contr\u00f4le pr\u00e9cis sur la logique m\u00e9tier : Une action encapsule clairement la logique m\u00e9tier, s\u00e9par\u00e9e des op\u00e9rations CRUD g\u00e9n\u00e9riques. Vous pouvez facilement inclure des validations personnalis\u00e9es, des r\u00e8gles complexes, des appels \u00e0 d’autres services, et plus encore.<\/li>\n\n\n\n
Gestion robuste des transactions et des erreurs : Les actions permettent une gestion centralis\u00e9e des exceptions, le retour de messages utilisateurs structur\u00e9s, et le support des rollbacks globaux lorsque n\u00e9cessaire.<\/li>\n\n\n\n
\u2026<\/li>\n<\/ul>\n\n\n\n
Un principe fondamental dans RAP et CAP est la s\u00e9paration claire entre les op\u00e9rations CRUD de base et la logique m\u00e9tier. Cette distinction am\u00e9liore la coh\u00e9rence des donn\u00e9es, la lisibilit\u00e9 du code et, surtout, la maintenabilit\u00e9 \u00e0 long terme des applications. Chaque action repr\u00e9sente une intention m\u00e9tier claire, int\u00e9gr\u00e9e dans une structure de service bien d\u00e9finie.<\/p>\n\n\n\n
En r\u00e9sum\u00e9, SAP SEGW offre une plus grande libert\u00e9 d’impl\u00e9mentation, ce qui peut \u00eatre adapt\u00e9 pour des cas d’utilisation simples avec une logique m\u00e9tier minimale. Cependant, il manque un cadre structur\u00e9 pour g\u00e9rer des sc\u00e9narios complexes ou des traitements par lot. En revanche, SAP RAP et CAP imposent une architecture plus rigoureuse, assurant une gestion des applications plus fiable et \u00e9volutive \u2014 tant en back-end qu’en front-end.<\/p>\n\n\n\n
Maintenant que nous avons couvert la th\u00e9orie, explorons quelques exemples pratiques pour voir comment cette approche est impl\u00e9ment\u00e9e dans ces frameworks modernes.<\/p>\n\n\n\n
Exemple d’impl\u00e9mentation RAP<\/h2>\n\n\n\n
Voici un exemple d’impl\u00e9mentation montrant comment appeler une action et une fonction statique d\u00e9finies dans SAP RAP.<\/p>\n\n\n\n
Dans le front-end (par exemple, Fiori Elements), l\u2019action setStatusToCanceled est d\u00e9clench\u00e9e via l’interface utilisateur \u00e0 l’aide d’un appel OData POST vers \/EntitySet(\u2026)\/setStatusToCanceled. Cela est trait\u00e9 dans le back-end en red\u00e9finissant la m\u00e9thode setStatusToCanceled dans la classe d’impl\u00e9mentation du comportement (lhc_ZFM_C_FLIGHTS), o\u00f9 la logique modifie le statut de l\u2019entit\u00e9.<\/p>\n\n\n\n
Pour la fonction statique GetNumberOfDelayedFlights, elle est d\u00e9clench\u00e9e par un appel GET comme \/EntitySet\/GetNumberOfDelayedFlights, et sa logique est impl\u00e9ment\u00e9e dans la m\u00e9thode getnumberofdelayedflights, retournant une structure de r\u00e9sultat avec les donn\u00e9es calcul\u00e9es.<\/p>\n\n\n\n
managed implementation in class zbp_fm_c_flights unique;\nstrict ( 2 );\ndefine behavior for ZFM_C_FLIGHTS\npersistent table zfm_flights\nlock master\nauthorization master ( instance )\n{\n create;\n update;\n delete;\n\n\n field ( numbering : managed, readonly ) Flight;\n\n\n action setStatusToCanceled result [1] $self;\n static function GetNumberOfDelayedFlights result [1] ZD_GETDELAYEDFLIGHTS_RESULT;\n\n\n mapping for zfm_flights {\n Flight = flight_id;\n Origin = origin_code;\n Destination = destination_code;\n Departure = departure;\n Arrival = arrival;\n Delay = delay;\n Status = status_code;\n }\n}<\/code><\/pre>\n\n\n\n
Behavior Projection<\/em><\/p>\n\n\n\n
projection;\nstrict ( 2 );\ndefine behavior for ZFM_P_FLIGHTS\n{\n use create;\n use update;\n use delete;\n use action setStatusToCanceled;\n use function GetNumberOfDelayedFlights;\n}<\/code><\/pre>\n\n\n\n
Behavior Implementation Class (ABAP)<\/em><\/p>\n\n\n\n
CLASS lhc_ZFM_C_FLIGHTS DEFINITION INHERITING FROM cl_abap_behavior_handler.\n PRIVATE SECTION.\n METHODS get_instance_authorizations FOR INSTANCE AUTHORIZATION\n IMPORTING keys REQUEST requested_authorizations FOR zfm_c_flights RESULT result.\n METHODS setstatustocanceled FOR MODIFY\n IMPORTING keys FOR ACTION zfm_c_flights~setstatustocanceled RESULT result.\n METHODS getnumberofdelayedflights FOR READ\n IMPORTING keys FOR FUNCTION zfm_c_flights~getnumberofdelayedflights RESULT result.\nENDCLASS.\nCLASS lhc_ZFM_C_FLIGHTS IMPLEMENTATION.\n METHOD get_instance_authorizations.\n ENDMETHOD.\n METHOD setStatusToCanceled.\n MODIFY ENTITIES OF zfm_c_flights IN LOCAL MODE\n ENTITY zfm_c_flights\n UPDATE FROM VALUE #( FOR key IN keys\n ( Flight = key-Flight\n Status = 'CAN' \" Cancelled\n %control-Status = if_abap_behv=>mk-on ) )\n FAILED failed\n REPORTED reported.\n \"Read changed data for action result\n READ ENTITIES OF zfm_c_flights IN LOCAL MODE\n ENTITY zfm_c_flights\n ALL FIELDS WITH\n CORRESPONDING #( keys )\n RESULT DATA(flights).\n result = VALUE #( FOR flight IN flights\n ( %tky = flight-%tky\n %param = flight ) ).\n ENDMETHOD.\n METHOD getNumberOfDelayedFlights.\n DATA: ls_delayedflights TYPE zd_getdelayedflights_result.\n \" Read all flights where status_code = 'CAN'\n SELECT COUNT( * ) FROM zfm_flights\n WHERE delay > 0\n INTO _delayedflights .\n \" Count how many were found\n APPEND VALUE #( %param = CORRESPONDING #( ls_delayedflights ) ) TO result.\n ENDMETHOD.\nENDCLASS.<\/code><\/pre>\n\n\n\n
Exemple d’impl\u00e9mentation CAP<\/h2>\n\n\n\n
Si tu es arriv\u00e9 jusqu’ici, cela signifie que tu es vraiment int\u00e9ress\u00e9 par le sujet \u2014 super !<\/p>\n\n\n\n
Pour illustrer les diff\u00e9rences fondamentales entre SEGW et CAP\/RAP, j’ai mis en place un projet CAP plus complet. Dans cette impl\u00e9mentation, l\u2019utilisation d\u2019une action plut\u00f4t que d\u2019une mise \u00e0 jour par lot prouve clairement sa valeur gr\u00e2ce \u00e0 son int\u00e9gration transparente avec Fiori Elements, ainsi que sa capacit\u00e9 \u00e0 encapsuler la logique m\u00e9tier et \u00e0 g\u00e9rer efficacement les erreurs pendant les traitements en masse.<\/p>\n\n\n\n
Pour rendre les choses un peu plus int\u00e9ressantes, voici trois cas d\u2019utilisation que j\u2019ai impl\u00e9ment\u00e9s dans l’exemple CAP suivant. Essayez de deviner pour chaque cas s’il devrait \u00eatre g\u00e9r\u00e9 avec une fonction ou une action. Les r\u00e9ponses d\u00e9taill\u00e9es sont fournies juste en dessous de l’impl\u00e9mentation \u2014 mais essayez d’abord !<\/p>\n\n\n\n
\n
Ajouter un retard \u00e0 un vol \u2013 Cela met \u00e0 jour le retard du vol et ajuste l’heure d’arriv\u00e9e et\/ou de d\u00e9part en fonction du statut du vol.<\/li>\n\n\n\n
Ajouter un retard \u00e0 une liste de vols \u2013 Les m\u00eames r\u00e8gles s’appliquent, mais maintenant tu boucles \u00e0 travers plusieurs vols, recalculant les heures, les mettant \u00e0 jour, et affichant \u00e9ventuellement des messages de succ\u00e8s ou d’avertissement.<\/li>\n\n\n\n
R\u00e9cup\u00e9rer le nombre de vols retard\u00e9s \u2013 Retourne le nombre de vols actuellement retard\u00e9s.<\/li>\n<\/ul>\n\n\n\n
CDS Service Definition (srv\/service.cds)<\/em><\/p>\n\n\n\n
using { flightManagement as fm } from '..\/db\/schema'; \n\nservice FlightsService @(path: '\/flights') {\n\n .draft.enabled\n entity Flights as projection on fm.Flights actions {\n action addDelay(\n delay: Integer \n @label: '{i18n>addDelayAction_delayParameter}' ) returns Flights; };\n\n function getNbOfDelayedFlights() returns Integer;\n}<\/code><\/pre>\n\n\n\n
Service Implementation (srv\/service.js)<\/em><\/p>\n\n\n\n
const cds = require('@sap\/cds');\nconst TextBundle = require('@sap\/textbundle').TextBundle;\n\nmodule.exports = cds.service.impl(srv => {\n\n const { Flights } = srv.entities;\n\n \/\/ Validate and adjust flight data before update\n srv.before('UPDATE', 'Flights.drafts', async (req) => {\n \n \/\/ Recalculate departure\/arrival if delay is updated\n if ('delay' in req.data) {\n try {\n let { departure, arrival } = await this._recalculate_departure_arrival(req.data.ID, req.data.delay);\n if (departure === undefined && arrival === undefined) {\n req.reject(400, 'ERR_UPDATING_CAN_OR_LAN', 'delay'); \n }\n req.data.departure = departure;\n req.data.arrival = arrival;\n } catch (error) {\n req.reject(400, 'ERR_UPDATING_DELAY', 'delay');\n }\n }\n });\n\nsrv.on('addDelay', async (req) => {\n const locale = req.locale;\n const bundle = new TextBundle('.\/i18n\/i18n', locale);\n\n \/\/ Loop through all flights\n for (let flight of req.params) {\n let { departure, arrival } = await this._recalculate_departure_arrival(flight.ID, req.data.delay);\n \n if (departure === undefined && arrival === undefined) {\n \/\/ If calculation failed, send a failure notification for this flight\n req.warn({\n message: bundle.getText('WARNING_UPDATING_DELAY_CAN_OR_LAN', [flight.ID])\n })\n continue; \/\/ Skip updating this flight\n }\n \n \/\/ Update the flight with the new delay, departure, and arrival times\n const result = await UPDATE(Flights) .where({ ID: flight.ID }) .set({ delay: req.data.delay, departure, arrival });\n \n if (result === 1) {\n \/\/ Success: 1 row was affected\n req.notify({\n code: 1,\n message: bundle.getText('SUCCESS_UPDATING_DELAY', [flight.ID, req.data.delay, departure, arrival])\n });\n } else {\n \/\/ Failure: no rows were updated\n req.error({\n message: bundle.getText('FAILURE_UPDATING_DELAY', [flight.ID])\n });\n }\n }\n }); \n\n \/\/ Function: Return the number of delayed flights\n srv.on('getNbOfDelayedFlights', async () => {\n const result = await SELECT `count(*) as count` .from(Flights) .where `delay > 0`;\n return (Array.isArray(result) && result.length > 0) ? result[0].count : 0;\n });\n};<\/code><\/pre>\n\n\n\n
Vous avez probablement d\u00e9j\u00e0 devin\u00e9 les r\u00e9ponses en observant l’impl\u00e9mentation, mais permettez moi de vous expliquer la logique derri\u00e8re chaque choix :<\/p>\n\n\n\n
Pour le premier cas d\u2019utilisation, \u201cAjouter un retard \u00e0 un vol\u201d, c’\u00e9tait un peu un pi\u00e8ge \u2014 cela peut \u00eatre facilement g\u00e9r\u00e9 dans un hook before UPDATE, ce qui en fait un candidat naturel pour la logique CRUD standard.<\/p>\n\n\n\n
En revanche, l\u2019action \u201cAjouter un retard \u00e0 une liste de vols\u201d introduit plus de complexit\u00e9. Puisqu\u2019elle implique l\u2019application de logique m\u00e9tier sur plusieurs enregistrements ainsi que l\u2019int\u00e9gration avec le front-end, il est pr\u00e9f\u00e9rable de l\u2019impl\u00e9menter en tant qu’action personnalis\u00e9e. Cette approche permet \u00e9galement de g\u00e9n\u00e9rer un bouton directement dans l\u2019en-t\u00eate du tableau, accompagn\u00e9 d\u2019une fen\u00eatre contextuelle pour la saisie, d\u2019une gestion des erreurs am\u00e9lior\u00e9e, et \u00e0 la fin du processus, d’une fen\u00eatre contextuelle r\u00e9capitulant les op\u00e9rations qui ont \u00e9t\u00e9 trait\u00e9es dans l\u2019interface utilisateur.<\/p>\n\n\n\n<\/figure>\n\n\n\n
Il est possible d’activer la gestion standard de la suppression en masse dans Fiori Elements, g\u00e9r\u00e9e par le framework. Cela est possible car cela peut \u00eatre envoy\u00e9 en lot sans aucune logique m\u00e9tier, comme dans l’application que j’ai d\u00e9velopp\u00e9e. Nous pouvons \u00e9galement constater la facilit\u00e9 d’int\u00e9gration de l’action dans Fiori Elements via des annotations. Enfin, avec la complexit\u00e9 m\u00e9tier et la gestion des erreurs, nous recevons des retours, qu’il s’agisse de succ\u00e8s ou d’\u00e9chec, ce qui aurait \u00e9t\u00e9 compliqu\u00e9 avec un envoi par lot. Cet exemple illustre pourquoi ces nouveaux frameworks recommandent d’utiliser des actions pour de tels cas.<\/p>\n\n\n\n<\/figure>\n\n\n\n
Enfin, le cas le plus simple, \u201cR\u00e9cup\u00e9rer le nombre de vols retard\u00e9s\u201d<\/strong>, retourne simplement des donn\u00e9es sans effets secondaires. Cela en fait un choix parfait pour une fonction<\/strong>.<\/p>\n\n\n\n
![\"\"](\"https:\/\/sapinnov.com\/wp-content\/uploads\/2025\/05\/image.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/sapinnov.com\/wp-content\/uploads\/2025\/05\/image-1.png\")
<\/figure>\n\n\n\n