Dieser Text wurde mit dem automatisierten Übersetzungssystem von Salesforce übersetzt. Nehmen Sie an unserer Umfrage teil, um Feedback zu diesem Inhalt zu geben und uns mitzuteilen, was Sie als Nächstes sehen möchten.

Die Salesforce Customer 360 Platform bietet jeder einzelnen Salesforce-Mandanteninstanz (auch als "Organisation" bezeichnet) eine leistungsstarke mandantenfähige metadatengestützte Architektur. Dieses grundlegende Dokument zur Architektur bietet einen Überblick über die Bereiche, in denen die zugrunde liegende Architektur der Salesforce Platform eine wichtige Überlegung für die Architekturen der auf der Plattform basierenden Lösungen darstellt.

Beim Entwerfen von Architekturen auf Salesforce Platform sind drei wichtige Bereiche zu verstehen:

Auf der Salesforce Platform kann eine Transaktion durch Codeausführung und/oder einen Datenbankvorgang instanziiert werden. Eine grundlegende Kompetenz für die Salesforce-Architektur besteht darin, zu verstehen, wie die Plattform Transaktionen für Mandanten definiert und steuert. Um Ressourcen für alle Mandanten zu verwalten, legt Salesforce für jeden Mandanten Obergrenzen fest, die auf Transaktions- und Organisationsbasis berechnet werden.

Auf Transaktionsebene legt Salesforce Obergrenzen für die Ausführung fest, um sicherzustellen, dass einzelne Instanzen der Codeausführung und Datenbanktransaktionen gemeinsam genutzte Rechenressourcen nicht monopolisieren. Auf organisationsweiter Ebene legt Salesforce Obergrenzen auf der Grundlage der Edition und des Funktionstyps fest. Organisationsweite Obergrenzen umfassen auch eine fortlaufende Berechnung der API-Nutzung für alle Transaktionen in der Organisation, für die API-Obergrenzen gelten.

Sehen wir uns zwei wichtige Teile von Transaktionen auf Salesforce Platform genauer an: Ausführungskontext und Datenbankmanipulation.

Salesforce berechnet Transaktionsobergrenzen anhand des Konzepts des Ausführungskontexts. Es ist wichtig zu wissen, dass dies bei Salesforce-Anwendungen nicht ausschließlich für die Ausführung von benutzerdefiniertem Code in einer einzelnen Salesforce-Organisation gilt. Der Ausführungskontext basiert auf dem Plattform-Laufzeitmodul und dem gesamten Code, der dem Laufzeitmodul für einen bestimmten Mandanten zur Verfügung steht. Das bedeutet, dass benutzerdefinierter Code, der in der Organisation eines Mandanten definiert ist, Code aus Paketen, die in dieser Organisation installiert sind, sowie Code, der in Salesforce Platform-Services enthalten ist, eine Transaktion instanziieren können. Die Plattform unterscheidet zwischen verschiedenen Apex Code-Typen und berechnet anhand dieser Unterschiede Obergrenzen.

Weitere Informationen zu Apex Transaktionsobergrenzen finden Sie im Apex Developer Guide.

Wenn eine Transaktion Datenbankmanipulationen beinhaltet, wird in einer integrierten Ausführungsreihenfolge das Verhalten der verschiedenen Teile der Konfiguration und des Codes Ihrer Organisation festgelegt. Ein Schlüssel zum Verständnis der richtigen Verwendung der Ausführungsreihenfolge in Ihren Salesforce-Anwendungen besteht darin, die zuverlässige Datenintegrität zu verstehen, die dieses Verhalten für Ihre Salesforce-Anwendungen bietet.

Salesforce Order of Execution Diagram

Die Plattform stellt Kontextvariablen für den Status von Datenbankvorgängen in Form von Auslöserkontextvariablen zur Verfügung. Es ist wichtig zu wissen, dass diese Auslöserkontextvariablen den Laufzeitstatus für alle Datenbanktransaktionen in der Salesforce-Organisation beschreiben, unabhängig davon, ob in dieser Organisation benutzerdefinierte Apex-Auslöser definiert wurden. Sie sind für deklarative Tools wie Salesforce Flow verfügbar.

In Salesforce werden die Daten erst übernommen (und auch die Datentransaktionen werden nicht abgeschlossen), nachdem das in der Ausführungsreihenfolge beschriebene endgültige Verhalten nach dem Auslösen erfolgreich abgeschlossen wurde. Dies bedeutet, dass alle fatalen Fehler oder disqualifizierenden Verhaltensweisen während einer Datentransaktion, die in vorherigen Kontexten oder nachherigen Kontexten auftreten, dazu führen, dass die Plattform alle Datenvorgänge innerhalb der Transaktion zurücksetzt. Angeforderte Änderungen an Datensatzdaten werden nicht in die Datenbank übernommen und es wird keine Logik nach dem Commit ausgeführt. (Apex stellt Datenbankmethoden zur Verfügung, um Speicherpunkte und das Rollback-Verhalten genauer steuern zu können.)

Ein wichtiges Anti-Pattern, das in Ihrer Salesforce-Architektur vermieden werden sollte, ist der Versuch, die integrierte Ausführungsreihenfolge der Plattform zu verkürzen oder zu ersetzen.

Einen genaueren Einblick in die Logik hinter diesen integrierten Verhaltensweisen zur Datenintegrität finden Sie unter Innen und Außen: Transaktionen im Salesforce Engineering-Blog.

Wenn Sie auswählen, wie Sie eine Salesforce-Organisation anpassen und erweitern, ist es wichtig, zu verstehen, was als Daten und was als Metadaten aus Sicht der Salesforce Platform betrachtet wird. Einen detaillierten Einblick in die zugrunde liegende Architektur hinter dieser Unterscheidung von Daten/Metadaten erhalten Sie im Grundlagendokument zur Plattform-Mandantenarchitektur.

Diese Unterscheidung wirkt sich auf viele Aspekte des Entwicklungslebenszyklus Ihrer Anwendung aus, beispielsweise ob ein Artefakt in Sandbox-Entwicklungsumgebungen kopiert wird oder nicht, wie es in andere Umgebungen migriert werden kann oder ob es Teil eines Pakets sein kann.

Die folgende Tabelle bietet einen schnellen Vergleich der Leistung von Daten im Vergleich zu Metadaten, da sie sich auf wichtige Teile des Anwendungslebenszyklus bezieht:

Verhalten Daten Metadata
Aus der Produktion in Sandbox-Umgebungen kopiert Nein* Ja
Migrieren nach Metadaten-API Nein Ja**
Migrieren nach Datenladevorgang Ja Nein
Kann in Pakete aufgenommen werden Nein Ja**
Wird auf Datenspeicherobergrenzen angerechnet Ja Nein
* Vollständige und Teilkopie-Sandbox-Instanzen ermöglichen den Abgleich von Daten aus der Produktion.
** Einige Metadatentypen sind nicht für die Verwendung mit der Metadaten-API und/oder Paketen verfügbar. Ausnahmen finden Sie im Bericht zur Metadatenabdeckung.

Manchmal ist dieser Unterschied ziemlich offensichtlich. Beispielsweise sind einzelne Datensätze in einer Salesforce-Organisation Daten. Bei den verschiedenen sObjects in einer Organisation handelt es sich um Metadaten.

Unterscheidungen können komplexer sein, wenn es um Organisationskonfigurationsfunktionen geht. Ein wichtiges Beispiel ist "Benutzerdefinierte Einstellungen" im Vergleich zu "Benutzerdefinierte Metadatentypen". Mit diesen beiden Funktionen können Sie Informationen in einer Organisation konfigurieren, sodass sie zur Laufzeit einfach verfügbar sind und auf ähnliche Weise wie Datenbankdatensätze bearbeitet und verwaltet werden können. Beide Funktionen sollen lose gekoppelte, hochflexible Designmuster in Code und Automatisierung ermöglichen. Benutzerdefinierte Einstellungen werden jedoch in einer Organisation als Daten und benutzerdefinierte Metadatentypen als Metadaten gespeichert.

Sie können bestimmen, ob es sich bei etwas um Metadaten handelt, indem Sie sehen, ob es im Bericht zur Metadatenabdeckung angezeigt wird. In diesem Bericht werden Sie auch über wichtige Entwicklungs- und Bereitstellungsverhaltensweisen für einen bestimmten Metadatentyp informiert.

Es gibt viele Salesforce Platform-APIs. Salesforce Platform-APIs unterstützen unterschiedliche Datenformate und Protokolle, verschiedene Vorgangstypen und Zeiteinteilungen. Einige APIs ermöglichen Ihnen die Interaktion mit den Daten in einer Salesforce-Organisation, während andere Interaktionen mit den Metadaten in einer bestimmten Organisation unterstützen. Einige APIs wurden speziell für die Verarbeitung großer Transaktionsvolumen entwickelt, andere nicht. Salesforce aktualisiert die Versionsnummer für alle Salesforce Platform-APIs mit jeder Version.

Ein wichtiger Teil einer soliden Anwendungsarchitektur besteht darin, sicherzustellen, dass Anwendungsentwickler für einen bestimmten Anwendungsfall die richtige API (und API-Version) verwenden. Sie müssen die integrierten API-Obergrenzen für Ihre Salesforce-Organisationen berücksichtigen, von denen viele durch die Edition und die Funktionsaktivierung bestimmt werden. Die Salesforce Platform-APIs unterstützen die abwärtskompatible Nutzung. Das bedeutet, dass Implementierungen mit einer bestimmten Version stabil und konsistent ausgeführt werden sollten, selbst wenn neue API-Versionen veröffentlicht werden. Wenn Sie neue oder geänderte Funktionen aus einer neuen API-Version integrieren möchten, müssen Sie Ihre Anwendung möglicherweise neu faktorisieren, bevor Sie Verweise auf die neue API-Version aktualisieren.

Die vielen verschiedenen Salesforce Platform-APIs und die Geschwindigkeit der Salesforce-API-Versionen erhöhen den Lebenszyklus von Anwendungen, die Salesforce-APIs verwenden, erheblich. Sie müssen regelmäßige Auswertungen der Salesforce Platform-API-Referenzen in Ihren Anwendungen planen und geplante API-Wartungszyklen priorisieren, damit Anwendungen vorhersehbar und ordnungsgemäß ausgeführt werden.