Salesforce Customer 360 Platform fournit une puissante architecture multitenante pilotée par les métadonnées à chaque instance locataire Salesforce (alias «organisation»). Ce document de base sur l'architecture présente une vue d'ensemble des domaines dans lesquels l'architecture sous-jacente de Salesforce Platform crée une considération clé pour les architectures de solutions élaborées sur la plate-forme.

Il existe trois domaines essentiels à comprendre lors de la conception d'architectures sur Salesforce Platform :

• Transactions
• Métadonnées par rapport aux données
• API de plate-forme

Sur Salesforce Platform, une transaction peut être instanciée par une exécution de code et/ou une opération de base de données. Une compétence fondamentale pour l'architecture dans Salesforce est de comprendre comment la plate-forme définit et contrôle les transactions pour les locataires. Afin de préserver les ressources de tous les locataires, Salesforce impose à chaque locataire des limites calculées par transaction et par organisation.

Au niveau transactionnel, Salesforce définit des limites de gouvernance et d'exécution afin d'éviter que des instances individuelles d'exécution de code et de transactions de base de données monopolisent les ressources de calcul partagées. Au niveau de l'organisation, Salesforce définit des limites basées sur l'édition et le type de fonctionnalité. Les limites à l'échelle de l'organisation comprennent également un calcul progressif de l'utilisation d'API dans toutes les transactions de l'organisation, qui sont soumises à des limites en API.

Examinons de plus près deux parties importantes des transactions sur Salesforce Platform : le contexte d'exécution et la manipulation de la base de données.

Salesforce calcule les limites transactionnelles en fonction d'un concept de contexte d'exécution. Il est important de comprendre que pour les applications Salesforce, cela n'est pas exclusif aux exécutions de code personnalisé dans une seule organisation Salesforce. Le contexte d'exécution est basé sur le moteur d'exécution de la plate-forme et sur tout le code disponible pour un locataire particulier. Cela signifie que le code personnalisé défini dans l'organisation d'un locataire, le code des packages installés avec cette organisation, ainsi que le code contenu dans les services de plate-forme Salesforce peuvent tous instancier une transaction. La plate-forme distingue les différents types de code Apex et calcule les limites du gouverneur en fonction de ces distinctions.

Voir le guide du développeur Apex pour plus d’informations sur les limites en transactions Apex.

Lorsqu'une transaction implique une manipulation de la base de données, un ordre d'exécution intégré définit le comportement des différentes parties de la configuration et du code de votre organisation. Pour comprendre comment utiliser correctement l'ordre d'exécution dans vos applications Salesforce, il est essentiel de comprendre l'intégrité des données robuste que ce comportement fournit à vos applications Salesforce.

La plate-forme expose des variables de contexte pour l'état des opérations de base de données sous la forme de variables de contexte de déclenchement. Il est important de comprendre que ces variables de contexte de déclencheur décrivent les états d'exécution de toutes les transactions de base de données dans l'organisation Salesforce, que des déclencheurs Apex personnalisés aient été définis ou non dans cette organisation. Ils sont disponibles pour les outils déclaratifs tels que Salesforce Flow.

Dans Salesforce, les données ne sont pas validées (et les transactions de données ne sont pas finalisées) tant que les comportements de déclenchement final après décrits dans l'ordre d'exécution n'ont pas réussi. Cela signifie que toute erreur fatale ou comportement disqualifiant pendant une transaction de données qui se produit dans des contextes antérieurs ou postérieurs entraîne l'annulation par la plate-forme de toutes les opérations de données dans la transaction. Les modifications demandées aux données d'enregistrement ne sont pas engagées dans la base de données et aucune logique post-engagement n'est exécutée. (Apex expose les méthodes de base de données pour permettre un contrôle plus précis des points d'enregistrement et du comportement d'annulation.)

Un anti-schéma clé à éviter dans votre architecture Salesforce est de tenter de raccourcir ou de remplacer le comportement d'exécution intégré de la plate-forme.

Pour un examen approfondi de la logique qui sous-tend ces comportements d'intégrité des données intégrés, consultez Inside and Out: Transactions sur le blog Salesforce Engineering.

Lors du choix de la personnalisation et de l'extension dans une organisation Salesforce, il est important de comprendre ce qui sera considéré comme des données et ce qui sera considéré comme des métadonnées du point de vue de Salesforce Platform. Pour une exploration approfondie de l'architecture sous-jacente derrière cette distinction données/métadonnées, consultez le document Platform Multitenant Architecture basics doc.

Cette distinction affectera de nombreux aspects du cycle de vie de développement de votre application, notamment : si un artefact sera copié ou non dans des environnements de développement sandbox, comment il peut être migré vers d'autres environnements, s'il peut faire partie d'un package ou non.

Le tableau ci-dessous présente une comparaison rapide des performances des données par rapport aux métadonnées en ce qui concerne les principales parties du cycle de vie de l'application :

Cette distinction est parfois assez évidente. Par exemple, les enregistrements individuels d'une organisation Salesforce sont des données. Les divers sObjects d'une organisation sont des métadonnées.

Les distinctions peuvent être plus complexes en ce qui concerne les fonctionnalités de configuration de l'organisation. Un exemple clé est Paramètres personnalisés par rapport aux types de métadonnées personnalisées. Ces deux fonctionnalités permettent de configurer des informations dans une organisation pour qu'elles soient facilement disponibles à l'exécution, et qu'elles puissent être manipulées et gérées de manière similaire aux enregistrements de base de données. Les deux fonctionnalités sont conçues pour permettre des modèles de conception peu couplés et très flexibles dans le code et l'automatisation. Cependant, les paramètres personnalisés sont stockés en tant que données dans une organisation et les types de métadonnées personnalisées sont stockés en tant que métadonnées.

Vous pouvez déterminer si des métadonnées sont affichées dans le Rapport de couverture des métadonnées. Ce rapport présente également les principaux comportements de développement et de déploiement d'un type particulier de métadonnées.

Il existe de nombreuses API Salesforce Platform. Les API Salesforce Platform prennent en charge différents formats et protocoles de données, divers types d'opération et calendriers. Certaines API permettent d'interagir avec les données d'une organisation Salesforce, tandis que d'autres prennent en charge les interactions avec les métadonnées d'une organisation donnée. Certaines API sont spécialement conçues pour gérer les volumes de transactions importants, d'autres non. Salesforce met à jour le numéro de version de toutes les API Salesforce Platform à chaque version.

Un élément clé d'une architecture d'application saine est de s'assurer que les développeurs d'applications utilisent l'API (et la version d'API) appropriée pour un cas d'utilisation donné. Vous devez tenir compte des limites en API intégrées pour vos organisations Salesforce, dont beaucoup sont déterminées par l'activation de l'édition et de la fonctionnalité. Les API Salesforce Platform prennent en charge l'utilisation rétrocompatible, ce qui signifie que les implémentations avec une version particulière doivent fonctionner avec stabilité et cohérence, même lorsque de nouvelles versions d'API sont publiées. Si vous souhaitez incorporer une fonctionnalité nouvelle ou modifiée à partir d'une nouvelle version d'API, il peut être nécessaire de refactoriser votre application avant de mettre à niveau les références à la nouvelle version d'API.

Les nombreuses API Salesforce Platform différentes, ainsi que la vitesse des versions d'API Salesforce, ajoutent une complexité importante au cycle de vie de toutes les applications qui utilisent des API Salesforce. Vous devrez planifier des évaluations régulières des références d'API Salesforce Platform dans vos applications et prioriser les cycles de maintenance d'API planifiés afin de garantir l'exécution prévisible et correcte des applications.