Package géré et préfixe d’espace de noms
Un package géré est un ensemble de métadonnées Salesforce distribué à d’autres orgs et mis à niveau par son éditeur. Son préfixe d’espace de noms est un identifiant unique de 1 à 15 caractères alphanumériques que Salesforce ajoute au nom d’API de chaque composant du package, par exemple acme__Invoice__c, afin d’éviter toute collision avec les personnalisations de l’org abonnée.
Le fonctionnement de l’espace de noms
Avec les packages de deuxième génération, l’espace de noms est attribué au package géré lors de sa création et ne peut plus être modifié ensuite. Plusieurs packages gérés peuvent partager un même espace de noms, mais un package ne peut appartenir qu’à un seul. Dans l’org d’installation, c’est le préfixe qui permet de distinguer un champ, un objet ou une classe issus d’un package de ceux créés sur place.
Salesforce destine les packages gérés aux éditeurs partenaires (ISV) qui distribuent leurs solutions à de nombreux clients ; pour une entreprise qui met en package ses propres métadonnées, l’outil recommandé est le package non verrouillé.
Ce que l’abonné peut voir et modifier
Le code d’une classe Apex, d’un déclencheur, d’un composant Visualforce ou Lightning inclus dans un package géré est masqué et ne peut pas être consulté dans l’org d’installation, même si les signatures des méthodes globales peuvent rester visibles par l’abonné. Une signature visible ne donne pas accès au corps de la méthode. À l’inverse, le détail des objets personnalisés, des liens personnalisés, des rapports et des autres éléments installés reste visible, tandis que les données d’un paramètre personnalisé protégé sont masquées.
Les règles de gestion des composants (manageability rules) déterminent, type de composant par type de composant, si les mises à niveau de l’éditeur mettent à jour le composant, si l’abonné peut le supprimer, si l’éditeur peut le retirer, et s’il bénéficie d’une protection de la propriété intellectuelle qui masque ses métadonnées.
Pourquoi c’est important quand on reprend une org
Les composants dotés d’un espace de noms peuvent représenter une grande partie des métadonnées d’une org tout en échappant à votre contrôle : vous pouvez en dépendre, mais pas lire ni modifier leur code. Séparer ce qui appartient à l’org de ce qu’apportent les packages installés est généralement la première étape pour la comprendre.
Ce qu’apporte aprity
aprity lit les métadonnées de l’org en lecture seule et calcule son graphe de dépendances : les relations extraites peuvent ainsi aider à repérer les frontières des packages. Les détails d’implémentation inaccessibles restent en dehors de cette vue. Les objets, les champs, les automatisations et les règles métier sont documentés en termes métier, chaque règle étant reliée au composant dont elle provient.
Termes liés
- API de dépendance Salesforce (Dependency API) — L’objet MetadataComponentDependency de l’API Tooling, qui indique quels composants de métadonnées d’une org en référencent d’autres.
- Dette technique Salesforce — Le coût accumulé des raccourcis passés dans la configuration et le code d’une org Salesforce, qui rend chaque évolution plus lente et plus risquée.
- Déclencheur Apex — Du code Apex exécuté automatiquement avant ou après l’insertion, la mise à jour, la suppression ou la restauration d’enregistrements d’un objet.
Sources
La documentation officielle de Salesforce sur laquelle cette définition a été vérifiée (pages en anglais). Le comportement de la plateforme évolue d’une version à l’autre : la page citée fait foi.