Suivez votre progression
Accueil Trailhead
Accueil Trailhead

Organisation de vos métadonnées

Objectifs de formation

Une fois cette unité terminée, vous pourrez :
  • Énumérer les stratégies clés pour organiser les métadonnées non empaquetées dans des packages.
  • Identifier comment les package déverrouillés peuvent être interdépendants.
  • Décrire les 3 modèles de développement de package et le moment de les utiliser.

Mise en pratique des principes du développement de package

Félicitations ! Dans l'unité précédente, vous avez créé un package et installé l'application DreamHouse dans votre Trailhead Playground. Maintenant, nous allons vous montrer comment mettre en pratique certains des principes clés du développement de packages. Rappelez-vous, c'est normal de commencer modestement et de poursuivre sur la lancée de vos succès.

L’organisation de vos métadonnées en packages :

  • est souvent un processus itératif.
  • N’est pas une proposition tout ou rien.

Organiser les métadonnées pour une application personnalisée nouvelle ou existante

DreamHouse est un excellent exemple de création d'une nouvelle application à partir de zéro et de l'empaquetage dans un package déverrouillé afin que vous puissiez introduire l'application dans votre organisation et gérer les personnalisations futures. Mais vous pouvez également suivre ce même processus lors de la mise à jour de nouvelles fonctionnalités pour une application personnalisée existante.

En résumé, nous avons créé DreamHouse pour montrer comment :

  • Intégrer les CLI, les projets et les packages déverrouillés de Salesforce dans le cycle de vie de votre application.
  • Adopter les meilleures pratiques en matière d'organisation des métadonnées et de création de limites de package.
  • Implémenter des packages déverrouillés lorsque vous créez une nouvelle application.

Que pouvez-vous faire maintenant que vous avez créé un package déverrouillé pour DreamHouse ?

  • Tester et déployer la source pour l'application de manière indépendante.
  • Isoler le schéma de l'application (objets personnalisés) des autres métadonnées.
  • Continuer à apporter des améliorations à l'application en répétant le processus et en ajoutant de nouvelles fonctionnalités.
  • Faire une version de l’application.
  • Installer une deuxième version en tant que mise à niveau d'une version existante.

Métadonnées DreamHouse

Métadonnées Description
Schéma Inclut des objets personnalisés pour Courtier, Propriété et Favori.

Exemples : Broker__c, Property__c, Favorite__c

Composants et applications Lightning Explorer les propriétés et voir les détails de la propriété.

Exemples : Property_Explorer.flexipage-meta.xml, Property_Record_Page.flexipage-meta.xml

Processus (flux) Envoyer des notifications lorsque de nouvelles propriétés sont ajoutées, ou que le prix a changé.

Exemples : Advertise_New_Property-2.flow-meta.xml, Price_Change_Push_Notification-1.flow-meta.xml

Services Einstein Appliquer un traitement d'image pour discerner automatiquement les détails de l’accueil des images téléchargées.

Exemple : EinsteinVisionController.cls

Robots Permettre aux clients de se connecter via Facebook Messenger, Slack ou Alexa pour rechercher des propriétés.

Exemple : HandlerFindProperties.cls

Décomposition des métadonnées existantes de votre organisation

Comme vous pouvez le voir, l'utilisation du cycle de vie du développement de package pour de nouveaux projets est très judicieuse. Cependant, nous savons que les clients existants, qui ont utilisé le développement d'ensembles de modifications sur une période de plusieurs versions, voire de plusieurs années, réclament des conseils pour savoir par où commencer. Comment pouvez-vous démêler le contenu de votre organisation en projets séparés et, en fin de compte, en répertoires de packages ?

Bien que nous aimerions vous donner l’ingrédient secret, il n'y a pas de plan d'action normatif. La façon dont vous envisagez de décomposer les métadonnées non empaquetées est un mélange de science et d'art. Vous êtes le meilleur juge pour déterminer les éléments de métadonnées qui correspondent aux projets Salesforce DX.

Pour commencer, répondez à ces questions :

  • Souhaitez-vous que vos équipes de développement puissent publier des applications, de nouvelles fonctionnalités et des personnalisations de manière indépendante ?
  • Pouvez-vous identifier la métadonnée qui représente une application ?
  • Pouvez-vous organiser vos métadonnées en modules pour des fonctionnalités distinctes ?
  • Lorsque vous créez un package non géré pour cette fonctionnalité ou cette application, quelles dépendances voyez-vous ?

Si vous avez plusieurs applications et personnalisations dans votre organisation, attendez-vous à voir des dépendances parmi les projets Salesforce DX.

Trois modèles pour démêler vos métadonnées

Dans des scénarios concrets, vous devrez probablement adopter une combinaison de ces stratégies et et les affiner pour mieux répondre aux besoins de votre entreprise.

Modèle Description
Basé sur une application Identifier la métadonnée qui représente une application. Cette approche est semblable à la création d'un package pour l’application DreamHouse, à l’exception que la métadonnée existe déjà dans votre organisation.
Basé sur des personnalisations Organiser des métadonnées non empaquetées pour les modifications apportées aux personnalisations et fonctionnalités de votre organisation de production, telles que les personnalisations à Sales Cloud, Service Cloud ou à une application AppExchange.
Bibliothèque partagée Lorsque des interdépendances existent, utilisez un package Salesforce DX commun pour organiser un ensemble de classes Apex ou d'objets personnalisés couramment utilisés. Les autres packages que vous construisez peuvent dépendre de ce package commun.

Utilisation d’un package non géré comme point de départ

Voici un bon flux de travail de départ pour organiser vos métadonnées non gérées en plusieurs packages :

  1. Sélectionnez un petit ensemble de métadonnées autonomes et non empaquetées dans votre organisation de production. Sélectionnez les métadonnées qui représentent une application, une personnalisation d'une application existante, une fonctionnalité ou une unité fonctionnelle ou des personnalisations d'objets standard.
  2. Créez un package non géré pour isoler les métadonnées que vous avez identifiées à partir de la collection globale des métadonnées d'organisation. Lorsque vous y ajoutez des métadonnées, identifiez les métadonnées dépendantes qui sont automatiquement récupérées par le système. Cette étape permet de révéler certaines dépendances qui ne sont pas si évidentes parmi vos métadonnées.
  3. Récupérez la source de votre package non géré en utilisant force:mdapi:retrieve.
  4. Configurez un projet Salesforce DX et un dépôt git pour gérer les métadonnées du package.
  5. Convertissez la source au format Salesforce DX en exécutant force:mdapi:convert.
  6. Poussez cette métadonnée vers une organisation test en utilisant force:source:push et validez que ce sont les métadonnées que vous souhaitez voir dans un package déverrouillé.
  7. Créez un package déverrouillé à l'aide de l'indicateur --nonamespace.
  8. Testez et déployez le package déverrouillé
  9. Une fois que le package déverrouillé a réussi toutes les exécutions CI et UAT dans les sandbox, promouvez la version de package.
  10. Installez le package déverrouillé dans l'organisation de production.

Une fois que vous avez créé un package pour cette métadonnée, elle est automatiquement déplacée dans le package. Puisque le nom complet de l'entité identifie les métadonnées dans l'organisation et dans le package, nous remplaçons les métadonnées déjà dans l'organisation et mettons à jour les références internes pour montrer qu'elles sont maintenant contenues dans le package.

À propos des dépendances de package

Le développement et la gestion d’un ensemble de packages interdépendants est une valeur clé des packages déverrouillés.

  • Un package déverrouillé peut dépendre d'un package AppExchange. Si vous utilisez un package AppExchange, vous pouvez mettre votre propre personnalisation pour ce package dans un package déverrouillé. Lorsque vous installez le package déverrouillé, le package AppExchange doit être présent.
  • Un package déverrouillé peut dépendre d'un autre package déverrouillé. Imaginons que vous créez une nouvelle application que les employés peuvent utiliser pour envoyer des notes de frais. Cette application partage certaines fonctionnalités d'intégration backend avec votre application de paie existante. Dans ce scénario, le package déverrouillé du rapport de dépenses dépendra du package déverrouillé de l'application de paie.
  • Un package déverrouillé peut dépendre d'un autre package déverrouillé, et ce package déverrouillé peut, à son tour, dépendre d'un package déverrouillé différent. Plusieurs niveaux de dépendances sont pris en charge.

Vous exprimez des dépendances dans la section packageDirectories du fichier sfdx-project.json En prenant en charge les dépendances, les packages déverrouillés favorisent le développement modulaire avec un cadre de dépendance riche. Reportez-vous au Guide pour développeurs de Salesforce DX pour plus d’informations sur le fichiers de projet Salesforce DX.