Lightning Web Components

Q: Mes composants survivront-ils aux mises à niveau du package ?

Si vous vous êtes appuyé sur la surface stable — objets refin__ via LDS/UI API, classes Apex globales, composition au niveau de la page —, oui, en vertu du contrat des packages gérés. Ce qui casse, c’est de dépendre des mécanismes internes des composants du package ou de ses classes publiques ; c’est pourquoi cet article ne cesse de vous en détourner.

Développeur 5 min de lecture Mis à jour en juillet 2026

Créer une interface personnalisée autour de REDA Financials relève du travail LWC ordinaire — les objets sont des objets personnalisés, les services de données sont les services standard, et vos composants côtoient ceux du package sur n’importe quelle page Lightning. Tout l’art réside dans ce sur quoi vous vous appuyez.

Accès aux données depuis vos composants

Lightning Data Service d’abord : lightning-record-form, les adaptateurs wire et UI API gèrent parfaitement les objets refin__ — opérations CRUD avec présentations de page, FLS et validations prises en charge d’office.
Votre Apex là où réside la logique : un contrôleur qui interroge les factures, ou qui appelle refin.GlobalTaxService pour un aperçu de la taxe en temps réel dans votre propre interface de devis (voir Développement Apex sur REDA).
Changement de statut depuis l’interface = comptabilisation : un bouton de votre composant qui passe le Statut à Comptabilisé par un PATCH via LDS exécute l’intégralité du moteur — construisez votre gestion des erreurs autour du message DML, qui est un texte prêt à être présenté à l’utilisateur.

Composer avec les pages du package

Les pages d’enregistrement sont ouvertes : déposez vos composants sur les pages d’enregistrement du package (ou clonez la FlexiPage et réorganisez-la) — un panneau personnalisé « contexte du bail » à côté de la facture, une fiche de bien immobilier sur l’immobilisation.
Les formulaires s’étendent sans code : avant d’écrire un composant pour « ajouter un champ au formulaire de facture », pensez aux ensembles de champs — les formulaires du package s’enrichissent de colonnes de manière déclarative.
La navigation est standard : vos composants créent des liens directs vers n’importe quel enregistrement ou liste REDA grâce au service de navigation de la plateforme ; les écrans du package font de même en sens inverse.

Traitez les composants du package comme des pages, pas comme des pièces détachées. Les LWC du package (formulaires, espaces de travail, le Centre financier) sont des surfaces du produit — placez-les, ne les programmez pas. La surface programmatique stable, c’est le modèle de données + l’API Apex globale ; votre interface innove autour de ces éléments, et les mises à niveau ne cassent jamais rien chez vous.

Des modèles qui font leurs preuves

Panneaux de contexte sectoriel — les données de votre secteur (bien immobilier, projet, requête) affichées à côté du document financier qui y fait référence.
Création guidée — un assistant qui recueille les données propres à votre métier, puis crée le document en brouillon via LDS et renvoie l’utilisateur vers le formulaire standard pour la partie comptable.
Tableaux de bord en lecture seule — des requêtes par adaptateur wire sur les factures et le grand livre, avec la visualisation de votre choix, en complément des tableaux de bord standard.

Un composant commenté : l’aperçu de taxe des devis de bail de Meridian

L’équipe de location de Meridian Properties Group voulait afficher le loyer taxes comprises pendant la négociation, avant qu’aucune facture n’existe. Le composant est un LWC REDA d’école : votre interface, votre contrôleur, le moteur du package. Le contrôleur assemble une requête pour refin.GlobalTaxService à partir des données saisies dans le devis :

refin.GlobalTaxService.TaxRequest req = new refin.GlobalTaxService.TaxRequest();
req.entityId        = quote.entityId;
req.accountId       = quote.tenantAccountId;
req.transactionDate = Date.today();
req.side            = 'Sales';

refin.GlobalTaxService.TaxLineRequest line = new refin.GlobalTaxService.TaxLineRequest();
line.lineKey   = 'rent-1';          // echoed back for correlation
line.amount    = quote.monthlyRent;
line.productId = quote.rentProductId;
req.lines      = new List<refin.GlobalTaxService.TaxLineRequest>{ line };

refin.GlobalTaxService.TaxResponse res = refin.GlobalTaxService.calculateTax(req);

La réponse contient totalTaxAmount et les résultats par ligne (taux, montant, comptes généraux résolus), rattachés grâce à lineKey. Comme le contrat n’effectue aucune opération DML et ne lève jamais d’exception vers l’appelant, le composant vérifie res.success, affiche res.errorMessage lorsqu’il est faux, et copie les valeurs dont il a besoin dans sa propre structure de réponse pour le wire. Lorsque le bail est signé et que la vraie facture est comptabilisée des mois plus tard, les montants correspondent au centime près — un seul moteur, deux consommateurs.

Les garde-fous dont hérite votre interface

Comportement de la plateforme ou du package	Conséquence pour la conception de votre composant
Les documents comptabilisés sont verrouillés, à l’exception des champs de workflow autorisés	Désactivez les commandes de modification lorsque le Statut est Comptabilisé — l’enregistrement échouerait de toute façon, avec le message du package
Comptabiliser = la mise à jour Brouillon→Comptabilisé, moteur et contrôles compris	Votre bouton « Comptabiliser » se résume à une mise à jour LDS plus un affichage fidèle des erreurs ; ne réimplémentez jamais la logique de comptabilisation côté client
Les utilisateurs sans licence se voient refuser toute écriture dans les données comptables, avec un message affiché tel quel	Affichez le message tel quel — il invite déjà l’utilisateur à contacter son administrateur
Les erreurs DML contiennent un texte de validation prêt pour l’utilisateur	Votre toast peut afficher le message brut ; aucune table de correspondance des codes d’erreur n’est nécessaire
Les ensembles de champs pilotent les formulaires du package	Alignez-vous sur eux : construisez vos éditeurs de lignes à partir des mêmes descriptions d’ensembles de champs, afin que votre interface et le formulaire du package ne divergent jamais sur les colonnes

Erreurs courantes à éviter

Erreur	Pourquoi c’est pénalisant	À faire plutôt
Reconstruire le formulaire de facture parce qu’il « manque un champ »	Des semaines de travail pour dupliquer une surface du produit déjà maintenue	Les ensembles de champs ajoutent le champ en quelques minutes ; réservez les composants à ce que les ensembles de champs ne savent pas faire
Calculer la taxe côté client « pour la réactivité »	Votre JavaScript et le moteur de comptabilisation finiront par diverger — devant un client	Appelez `GlobalTaxService` via votre contrôleur ; mettez le résultat en cache dans le composant si nécessaire
Écrire dans `refin__Accounting_Transaction__c` depuis un contrôleur	Des lignes de grand livre fabriquées à la main sont précisément ce que les contrôles existent pour empêcher	Créez les documents et comptabilisez-les ; le grand livre s’alimente tout seul
Supposer que les composants du package peuvent être intégrés dans votre DOM	Leurs cibles d’exposition et leurs mécanismes internes ne font l’objet d’aucun contrat documenté	Composez au niveau de la page Lightning ; traitez les LWC du package comme des surfaces du produit
Tester uniquement en tant qu’administrateur	Les vrais utilisateurs se heurtent à la FLS, aux ensembles d’autorisations et à la licence utilisateur — les chemins d’erreur de votre composant n’ont jamais été éprouvés	Testez en tant qu’utilisateur disposant exactement de l’ensemble d’autorisations du package qu’aura votre public

Pour aller plus loin

Extensibilité par ensembles de champs — l’alternative sans code à envisager en premier.
Développement Apex sur REDA — la couche logique.
Intégration avec les flux Salesforce — le juste milieu déclaratif.

Documentation officielle Salesforce Les Lightning Web Components sont un framework Salesforce standard — la référence qui fait autorité est le Guide du développeur Lightning Web Components. Les liens s’ouvrent dans un nouvel onglet.

Questions fréquentes

Composez au niveau de la page (régions du Générateur d’application Lightning) plutôt que par imbrication programmatique. Les cibles exposées déterminent où les composants du package peuvent être placés ; considérez leurs mécanismes internes comme privés.

Privilégiez LDS/UI API (contrôles d’accès intégrés) ; dans les contrôleurs Apex personnalisés, utilisez des requêtes USER_MODE. Le package utilise USER_MODE pour les lectures qui servent un utilisateur et SYSTEM_MODE là où le moteur doit avoir une vue complète, quels que soient les accès de l’utilisateur en cours — comptabilisation, séquencement, cumuls. Dans votre propre code d’interface, utilisez USER_MODE par défaut et ne recourez à SYSTEM_MODE que là où vous savez justifier pourquoi.

Oui. Aucun ensemble d’autorisations du package n’accorde l’accès à la classe refin.GlobalTaxService (seules PDFGeneratorAPI et EInvoiceTrailCreator sont accordées, car des actions de flux du package les appellent) ; l’accès doit donc être accordé explicitement à l’utilisateur en cours. Vérifiez-le avec le véritable ensemble d’autorisations dans une sandbox : en cas d’échec, l’erreur est visible et immédiate.

Si vous vous êtes appuyé sur la surface stable — objets refin__ via LDS/UI API, classes Apex globales, composition au niveau de la page —, oui, en vertu du contrat des packages gérés. Ce qui casse, c’est de dépendre des mécanismes internes des composants du package ou de ses classes publiques ; c’est pourquoi cet article ne cesse de vous en détourner.

Tels quels. Les messages des contrôles sont rédigés comme des phrases destinées à l’utilisateur (« Ce document exige une approbation avant comptabilisation. » et consorts) — un toast affichant le message DML brut offre réellement la meilleure expérience utilisateur, et il reste correct à mesure que le package fait évoluer ses règles.

Cet article vous a-t-il été utile ?