Die asynchrone Verarbeitung erhöht die Skalierbarkeit, da höhere Obergrenzen pro Kontext zulässig sind. Asynchrone Anforderungen werden in ihren eigenen Threads im Hintergrund ausgeführt, sodass Benutzer weiterhin clientseitig arbeiten können, während die asynchronen Aufgaben im Hintergrund ausgeführt werden.

Die Salesforce Lightning Platform bietet eine Vielzahl asynchroner Technologien, mit denen ein bestimmter Anwendungsfall gelöst werden kann. Jede Technologie weist Vorteile und Obergrenzen auf, die Sie bei der Auswahl eines Ansatzes für jeden Anwendungsfall berücksichtigen müssen.

Bei der Auswahl einer Technologie für die Implementierung sind drei wichtige Überlegungen zu beachten:

1. Die asynchrone Verarbeitung ist nicht für jedes Problem der beste Ansatz. Es kann verlockend sein, jeden Prozess, für den nicht direkt eine Benutzerinteraktion erforderlich ist, als guten Kandidaten für die asynchrone Verarbeitung zu betrachten. Es gibt jedoch einige Nachteile. Erstens weisen asynchrone Prozesse kein SLA auf. Das bedeutet, dass es keine Garantie dafür gibt, dass ein asynchroner Prozess innerhalb einer festgelegten Zeit abgeschlossen wird. Zweitens gibt es keine Garantie für eine einheitliche Antwortlatenz. Wenn ein asynchroner Prozess innerhalb einer bestimmten Zeit abgeschlossen wird, kann der Abschluss eines nachfolgenden Prozesses unterschiedlich lange dauern. Selbst wenn ein Benutzer nicht direkt auf eine Antwort wartet, ist die asynchrone Verarbeitung daher möglicherweise nicht für Ihr Szenario geeignet, wenn Sie über nachfolgende Prozesse verfügen, die von einer Antwort abhängen, oder wenn Sie befürchten, dass zu lange Antwortzeiten dazu führen könnten, dass Ihre Daten nicht mehr mit den Daten in einem externen System synchron sind.
2. Es gibt verschiedene Möglichkeiten, asynchrone Anforderungen auf der Salesforce Platform zu verarbeiten. Stellen Sie daher sicher, dass Sie den besten Ansatz wählen. Technologien, die die asynchrone Verarbeitung auf der Salesforce Platform unterstützen, funktionieren anders und einige wurden für sehr spezifische Anwendungsfälle entwickelt.
3. Wenn eine Technologie clientseitig asynchron ist, bedeutet dies nicht zwangsläufig, dass die gesamte durchgängige Verarbeitung parallel erfolgt. Abhängig von Ihren Entscheidungen werden die Nachrichten des Clients manchmal trotzdem serverseitig serialisiert.

Wenn Sie die falschen Technologien oder die falschen Kombinationen von Technologien für einen Auftrag verwenden, kann es zu unerwünschten Konsequenzen kommen, die die Vorteile der asynchronen Verarbeitung beeinträchtigen. Dieser Leitfaden enthält Erläuterungen und Empfehlungen sowie potenzielle Nachteile und Anti-Patterns für verschiedene asynchrone Anwendungsfälle und die Gründe für diese Empfehlungen. Sie bietet auch Statistiken dazu, wie verschiedene asynchrone Implementierungstechniken auf der Salesforce Platform funktionieren und reguliert werden.

Wenn Sie eine Entscheidung darüber treffen, welche Technologie verwendet werden soll, finden Sie im Asynchronous Processing Decision Guide (Leitfaden zur Entscheidung über die asynchrone Verarbeitung) eine schnelle Zuordnung typischer Anwendungsfälle zur am besten geeigneten Technologie.

Bei der Salesforce Lightning Platform handelt es sich um eine umfassende AI-gestützte Plattform, die Mitarbeiter, autonome AI-Agenten, Unternehmensdaten und Anwendungen in einem einzigen, vertrauenswürdigen System zusammenführt, um die Produktivität und die Kundenerfahrung zu steigern. Durch die Verbindung von Customer 360-Anwendungen, Data Cloud und Slack für eine durchgängige Automatisierung kann ein "Agentenunternehmen" erstellt werden.

In diesem Dokument werden keine Technologien in anderen Ökosystemen wie MuleSoft, Informatica, Commerce Cloud, Tableau und Marketing Cloud behandelt.

Beachten Sie, dass sich dieser Leitfaden ausschließlich auf die asynchrone Verarbeitung innerhalb der Salesforce Lightning Platform konzentriert. Informationen zu asynchronen Integrationsmustern finden Sie unter Ereignisgesteuerte Architektur.

• Vergewissern Sie sich vor der Verwendung der asynchronen Verarbeitung, dass Ihre Anwendungsfälle dem Muster entsprechen. Asynchrone Muster weisen kein SLA auf, unterliegen mehreren Reglermechanismen, können Kapazitätsobergrenzen basierend auf Lizenzen definieren und aufgrund der begrenzten Beschaffenheit der Ressourcen, die der asynchronen Infrastruktur innerhalb der Salesforce Platform zugewiesen sind, zu Verarbeitungsverzögerungen führen. Berücksichtigen Sie diese Einschränkungen ernsthaft, wenn Sie die asynchrone Verarbeitung in Szenarien verwenden, in denen ein Benutzer eine Antwort vom System benötigt, bevor er seine Arbeit fortsetzen kann.
• Die asynchrone Verarbeitung mit Salesforce ist keine Lösung für grenzenlose Skalierungsanforderungen. Die Salesforce Platform kann nicht unbegrenzt skaliert werden und asynchrone Muster unterliegen weiterhin Einschränkungen. Bei der asynchronen Verarbeitung werden Threads verwendet, die die Kontextinformationen enthalten, die eine CPU zum Ausführen eines Streams von Anweisungen benötigt. Threads können parallel ausgeführt werden. Die Anzahl der verfügbaren Threads in CPUs ist begrenzt. Daher verfügt die Plattform über Mechanismen, die sicherstellen, dass ihre verfügbaren Threads so effizient wie möglich verwendet werden. Der Flow-Kontrollmechanismus der Plattform verhindert, dass Organisationen zu viele Threads verwenden und sich negativ auf andere Organisationen auswirken. Der Algorithmus für die faire Nutzung der Plattform steuert die Anzahl der Threads, die in einer Organisation für jeden bestimmten Nachrichtentyp verfügbar sind.
• Ermitteln Sie, wann Transaktionen wirklich asynchron sind. Einige Architekturmuster verhalten sich durchgängig asynchron. Andere Prozesse verhalten sich jedoch client- oder browserseitig asynchron, serialisieren jedoch serverseitige Anforderungen, die dann synchronen Obergrenzen unterliegen.
• Verwenden Sie Plattformereignisse und zuverlässige Middleware anstelle von Callouts über asynchrones Apex, um umfangreiche ausgehende Integrationen von Salesforce Platform zu erstellen. Da auf der Plattform eine begrenzte Anzahl asynchroner Threads verfügbar ist, sind ausgehende Integrationen über asynchrones Apex nur begrenzt skalierbar. Wenn Ihre Organisation über ausgehende Integrationen verfügt, die ein hohes Nachrichtenvolumen aufweisen, die Anzahl der verfügbaren Threads überschreiten und lange Verarbeitungszeiten aufweisen, führt die Verwendung von asynchronem Apex zwangsläufig zu Verzögerungen.
• Achten Sie bei der Verwendung der asynchronen Verarbeitung darauf, die Überwachung einzubeziehen. Mit der Überwachung können Sie Probleme so früh wie möglich erkennen und beheben, bevor größere Leistungsvorfälle auftreten.
• Berücksichtigen Sie Ereignisse, die zu extremen Belastungen führen können. Stellen Sie beim Entwerfen asynchroner Prozesse sicher, dass sie Arbeitslastspitzen und -lupen vorhersehbar verwalten können. Überlegen Sie, wie Ihre Implementierung mit unerwarteten Ereignissen wie Stromausfällen und Design-Sicherungen umgeht, die Datenverlust oder Funktionsverlust minimieren.

Wenn Sie einen Ansatz für die serverseitige asynchrone Verarbeitung auswählen, sollten Sie zunächst die Anforderungen und verfügbaren Ressourcen Ihrer Organisation auswerten. Ihr Ziel ist es, einen Ansatz auszuwählen, der die Implementierungs- und Wartungskosten minimiert und gleichzeitig die Skalierbarkeit und die Wahrscheinlichkeit von Obergrenzenverstößen minimiert. Dieses Ziel hängt von den technischen Überlegungen ab, die in den nächsten Abschnitten beschrieben werden, sowie von der Zusammensetzung Ihres Teams. Überlegen Sie beispielsweise, ob Sie Apex-Entwickler in Ihrem Team haben, die Ihre Pro-Code-Lösung verwalten können. Andernfalls kann ein deklarativer Ansatz sinnvoller sein. Beachten Sie außerdem, dass für verschiedene Tools unterschiedliche Obergrenzen gelten können.

Stellen Sie sich den Anwendungsfall eines asynchronen Bestellprozesses in Salesforce vor. Wenn ein Auftrag gespeichert wird, wird eine Meldung an ein externes Lagerverwaltungssystem mit speziellen Anweisungen zum Verpacken und Versenden eines Artikels ausgelöst. Der Benutzer, der den Auftrag erteilt, benötigt keine sofortige Antwort vom Lagerverwaltungssystem, sodass die Anforderung asynchron gesendet werden kann. Durch die asynchrone Verarbeitung kann der Benutzer seine Arbeit ohne Verzögerungen fortsetzen.

Überlegungen zu Ihrer Architektur:

• Wie viele gleichzeitige Prozesse sind erforderlich?
• Wie interagiert der gleichzeitige Prozess miteinander?
• Wie viele SOQL-Abfragen werden in jedem Prozess ausgeführt?
• Wie viele DML-Vorgänge werden in jedem Prozess ausgeführt?
• Wie lange wird jeder Prozess ausgeführt?
• Wie sensibel sind Prozesse auf bestimmte Zeiteinteilungen?

Die Mandantenarchitektur der Salesforce Platform isoliert die unterschiedlichen Anforderungen vieler Mandanten (Organisationen) und unterstützt sie gleichzeitig. Alle in diesem Handbuch behandelten asynchronen Apex-Methoden werden in derselben asynchronen Infrastruktur in Salesforce Platform ausgeführt. Sie verwenden ein Nachrichtenwarteschlangen-Framework, das durch zwei primäre Erzwingungsmechanismen geregelt wird: die Flow-Steuerung und die faire Nutzung.

Die Flow-Steuerung und die Mechanismen für die faire Nutzung verhindern, dass ein einzelner Mandant zu viele Serverressourcen verwendet und nicht genügend Ressourcen für die verbleibenden Mandanten übrig lässt. Auch wenn es hilfreich ist, zu verstehen, wie diese Mechanismen funktionieren, sollten Sie als wichtigstes Beispiel dafür angeben, dass die Einhaltung bewährter Vorgehensweisen für die asynchrone Verarbeitung, wie sie in den nächsten Abschnitten beschrieben sind, die Wahrscheinlichkeit, dass Probleme mit ihnen auftreten, erheblich reduziert.

Der Flow-Steuermechanismus der Plattform verhindert, dass eine Organisation einen bestimmten Nachrichtentyp überschwemmt, was zu viele Threads verbraucht und sich negativ auf andere Organisationen auswirkt. Bevor das Framework der Warteschlange, die einem Nachrichtentyp zugeordnet ist, neue Einträge hinzufügt, überprüft es die ersten mehreren Tausend vorhandenen Einträge in der Warteschlange. Wenn die Mehrheit der vorhandenen Einträge derselben Organisation zugeordnet ist und diese Organisation bereits auch Einträge in Worker-Threads aufweist, werden die neu hinzugefügten Einträge in die Warteschlange verschoben. Dieser Prozess wird als erneute Warteschlange bezeichnet. Die erneute Warteschlangenerstellung erfolgt in der Regel bei Batch-Apex- und Bulk-API-Prozessen, da sie oft eine große Anzahl von Einträgen gleichzeitig in ihre Warteschlangen einfügen.

Der Mechanismus für die faire Nutzung der Plattform implementiert ein stufenbasiertes System. Das System stellt sicher, dass jede Organisation auf der Salesforce Platform einen angemessenen Teil der Verarbeitungszeit für einen bestimmten Nachrichtentyp erhält, einschließlich der Nachrichtentypen "Zukunft", "Warteschlange" und "Batch". Wenn eine Organisation einen bestimmten Nachrichtentyp dominiert, während andere Organisationen darauf warten, Arbeit an demselben Nachrichtentyp auszuführen, reduziert der Algorithmus für die faire Nutzung die Anzahl der Threads, die der Organisation für diesen bestimmten Nachrichtentyp zur Verfügung stehen.

Ein Vorteil der Verwendung asynchroner Apex-Methoden besteht darin, dass einige Obergrenzen, beispielsweise SOQL-Abfrageobergrenzen und Obergrenzen für die Heap-Größe, höher sind. Verlassen Sie sich jedoch nicht zu sehr auf diese Methoden. Aufgrund der begrenzten Ressourcen, die der asynchronen Infrastruktur zugewiesen sind, kann die starke Nutzung von Future, Queueable und Batch Apex zu Verarbeitungsverzögerungen führen, die auf Einschränkungen aufgrund der fairen Nutzung und der Flow-Steuerung zurückzuführen sind.

Ausgehende Callouts, die asynchrones Apex verwenden, werden auf die Obergrenze für asynchrones Apex angerechnet. Die tägliche Obergrenze beträgt derzeit das 250.000- oder 200-fache der Anzahl der anwendbaren Benutzerlizenzen, je nachdem, welcher Wert höher ist. Diese Obergrenze kann bei Anwendungsfällen mit hohem Volumen ein Problem darstellen. Wenn Sie die Obergrenze überschreiten, schlagen Ihre asynchronen Apex-Aufträge und die zugehörigen ausgehenden Callouts fehl.

Da die Plattform über eine begrenzte Anzahl asynchroner Threads verfügt, sind ausgehende Integrationen über asynchrones Apex zudem nur eingeschränkt skalierbar. Alle ausgehenden Integrationen mit hohem Volumen, die die Anzahl der verfügbaren Threads überschreiten, können lange Verarbeitungszeiten aufweisen und zu Verzögerungen führen.

Bei Anwendungsfällen mit hohem Volumen sollten Sie die folgenden alternativen Ansätze in Betracht ziehen. API-Aufrufe mit diesen Ansätzen werden auf die tägliche Obergrenze für API-Anforderungen angerechnet, die deutlich über der täglichen Obergrenze für asynchrones Apex liegt. Dadurch sind diese Ansätze besser skalierbar. Beachten Sie jedoch, dass die Anzahl der gleichzeitigen Anforderungen, die von einer CPU verarbeitet werden können, weiterhin physisch begrenzt ist.

• Geplanter Pull für Middleware. Vermeiden Sie Verzögerungen bei ausgehenden Integrationsaufträgen mit hohem Volumen, indem Sie Middleware verwenden, um die Daten planmäßig abzurufen, statt sie über asynchrones Apex zu übertragen. Middleware wie die MuleSoft Anypoint Platform kann die native SOAP-API oder die REST-API synchron verwenden, sodass nur wenige oder gar keine Verzögerungen auftreten. Middleware kann auch die native Bulk-API für große Datenmengen verwenden.

• Middleware-Abruf über Plattformereignisbenachrichtigung. Statt Future, Queueable oder asynchronen Apex-Batch in die Warteschlange zu stellen, um ausgehende Integrationen auszuführen, können Sie Plattformereignisse verwenden. Das Plattformereignis kann die ausgehenden Informationen entweder selbst bereitstellen oder ein Middleware-Tool anweisen, die erforderlichen Informationen über eine native API abzurufen und an sein endgültiges Ziel zu liefern. Keiner dieser Ansätze unterliegt den Verzögerungen, die für asynchrones Apex gelten. Es gelten jedoch weiterhin Obergrenzen für Plattformereignisse.

Mit Queueable Apex können Sie Apex Prozesse, die umfangreiche Datenbankvorgänge oder Callouts für externe Webservices beinhalten, asynchron ausführen. Implementieren Sie zum Verwenden von Queueable Apex die Schnittstelle Queueable und fügen Sie dann der Apex Auftragswarteschlange einen Auftrag hinzu. Durch diesen Ansatz wird sichergestellt, dass der asynchrone Apex-Auftrag in einem eigenen isolierten Thread im Hintergrund ausgeführt wird und die Ausführung Ihrer Apex-Hauptlogik nicht verzögert wird. Jeder in die Warteschlange gestellte Auftrag wird ausgeführt, wenn Systemressourcen verfügbar sind.

Warteschlangenfähiger Apex stellt die Entwicklung von asynchronem Apex dar. Sie bietet Funktionen, die für zukünftige Apex-Methoden nicht verfügbar sind, darunter:

• Auftrags-IDs: Wenn Sie einen Auftrag durch Aufrufen der Methode System.enqueueJob senden, gibt die Methode die ID des neuen Auftrags zurück. Anhand dieser ID können Sie Ihren Auftrag identifizieren. Zeigen Sie zum Überwachen des Fortschritts die Seite "Apex Aufträge" im Salesforce-Setup an oder fragen Sie das Objekt "AsyncApexJob" ab.
• Unterstützung für nicht primitive Typen: Warteschlangenklassen können Mitgliedsvariablen von nicht primitiven Datentypen wie sObjects oder benutzerdefinierte Apex enthalten.
• Unterstützung der Auftragsverkettung: Sie können warteschlangenfähige Aufträge miteinander verketten, indem Sie einen zweiten Auftrag über einen ausgeführten Auftrag starten. Mit dieser Technik können Sie Szenarien mit Prozessabhängigkeiten bewältigen.
• Maximale Tiefenkontrolle: Sie können warteschlangenfähige Aufträge mit einer maximalen Stapeltiefe konfigurieren, um sicherzustellen, dass Auftragsketten nicht zu unerwarteten Rekursen führen.
• Duplikatsignaturen: Warteschlangenfähige Aufträge bieten eine optionale Signatur zum Erkennen und Entfernen doppelter Aufträge.
• Konfigurierbare Verzögerung: Sie können eine Verzögerung von bis zu 10 Minuten definieren, bevor der Queueable-Auftrag ausgeführt wird.
• Transaktions-Finalizer: Sie können eine Nachaktionssequenz an einen Queueable-Auftrag anhängen und basierend auf dessen Ergebnis relevante Aktionen ausführen. Beispielsweise kann ein Transaktions-Finalizer einen Queueable-Auftrag, der aufgrund einer nicht bearbeiteten Ausnahme fehlgeschlagen ist, bis zu fünf Mal erneut in die Warteschlange einreihen.

Salesforce verwendet ein warteschlangenbasiertes Framework zum Verarbeiten asynchroner Prozesse. Diese Warteschlange wird verwendet, um die Arbeitslasten von Anforderungen organisationsübergreifend auszugleichen. So stellen Sie sicher, dass Ihre Organisation diese Warteschlange so effizient wie möglich verwendet:

• Vermeiden Sie es, künftige oder warteschlangenfähige Methoden direkt aus Aktionen in die Warteschlange zu stellen, die durch große Mengen an Endbenutzeraktivitäten oder Integrations-API-Aufrufen generiert werden. Dieser Ansatz kann die täglichen asynchronen Apex-Obergrenzen schnell ausschöpfen, was schwerwiegende Auswirkungen auf das Geschäft hat.
• Vermeiden Sie es, mehrere asynchrone Aktionen pro synchroner Aktion in die Warteschlange zu stellen. Wenn mehrere asynchrone Methoden aus einer einzelnen synchronen Aktion in die Warteschlange gestellt werden, werden die asynchronen Aktivitäten oft zur gleichen Zeit ausgeführt und tragen zu Fehlern bei Zeilensperren und/oder Zeitüberschreitungen bei.
• Vermeiden Sie es, der asynchronen Warteschlange eine große Anzahl künftiger oder warteschlangenfähiger Methoden hinzuzufügen.
• Stellen Sie sicher, dass zukünftige und warteschlangenfähige Methoden schnellstmöglich ausgeführt werden. Je länger die Ausführung einer zukünftigen Methode dauert, desto wahrscheinlicher ist es, dass sich dahinter stehende Anforderungen in der Warteschlange verzögern. Minimieren Sie Webservice-Callout-Zeiten, optimieren Sie die in Ihren künftigen Methoden verwendeten Abfragen und optimieren Sie andere Objektautomatisierungen, einschließlich Prozessgenerator-Prozessen, Workflow-Regeln, Flows und Apex-Auslösern.
• Testen Sie Ihre asynchronen Methoden im richtigen Maßstab. Verwenden Sie eine Umgebung, die die maximale Anzahl an Methoden generiert, die Sie voraussichtlich verarbeiten werden. Mit diesen Tests können Sie feststellen, ob in Ihrer Produktionsumgebung Probleme mit der Leistung oder Obergrenzen auftreten. Beachten Sie auch die Auswirkungen auf die kumulierten täglichen Obergrenzen.
• Verwenden Sie Batch-Apex anstelle der Methoden future oder Queueable, um eine große Anzahl von Datensätzen zu verarbeiten. Batch-Apex kann komplexe, langfristige Prozesse verarbeiten, die für Tausende von Datensätzen ausgeführt werden, und kann so geplant werden, dass sie außerhalb der Geschäftszeiten ausgeführt werden, wenn mehr Ressourcen verfügbar sind.

Verwenden Sie geplantes Apex, um es zu einem angegebenen Zeitpunkt und mit einer wiederholten Häufigkeit auszuführen, wie durch einen Cron-Ausdruck definiert. Obwohl es sich bei der Planung von Apex über den Ausdruck cron um einen asynchronen Prozess handelt, wird der zugrunde liegende Code synchron ausgeführt, wenn der Auftrag gestartet wird. Geplantes Apex ist ideal für tägliche oder wöchentliche Wartungsaufgaben.

• Sie können nur über 100 geplante Apex Aufträge gleichzeitig verfügen. Um diese Einschränkung zu vermeiden, sollten Sie anstelle von geplantem Apex einen durch einen Zeitplan ausgelösten Flow verwenden, der Apex Code aufruft.
• Seien Sie äußerst vorsichtig, wenn Sie planen, eine Klasse über einen Auslöser zu planen. Sie müssen garantieren können, dass der Auslöser nicht mehr geplante Klassen als die Obergrenze hinzufügt. Berücksichtigen Sie insbesondere API-Massenaktualisierungen, Importassistenten, Massendatensatzänderungen über die Benutzeroberfläche und alle Fälle, in denen mehrere Datensätze gleichzeitig aktualisiert werden können.
• Verwenden Sie für einmalige Aufgaben, die bis zu 10 Minuten in der Zukunft geplant werden müssen, einen verzögerten warteschlangenfähigen Auftrag. Dieser Ansatz wird nicht auf die Obergrenze von 100 geplanten Aufträgen angerechnet.
• Geplanter Apex wird in einem synchronen Kontext mit synchronen Obergrenzen ausgeführt.
• Überlegen Sie, wie lange der geplante Auftrag ausgeführt wird. Ein langfristiger Auftrag kann sich mit dem Start des nächsten geplanten Auftrags überschneiden.
• Salesforce plant die Ausführung der Klasse zum angegebenen Zeitpunkt. Die tatsächliche Ausführung kann sich je nach Serviceverfügbarkeit verzögern. Aufträge, deren Ausführung während der Ausfallzeit der Servicewartung geplant ist, werden so geplant, dass sie nach der Wiederherstellung des Service ausgeführt werden.
• Verwenden Sie System.scheduleBatch zum Planen von Batchaufträgen, statt über einen geplanten Auftrag zu verfügen, der ausschließlich dazu dient, einen Batchauftrag in die Warteschlange zu stellen.

Bisher unterlagen synchrone Callouts, die über eine Apex Methode vorgenommen wurden, die in einem synchronen Apex Transaktionskontext ausgeführt wird, beispielsweise ein Visualforce Steuerfeld oder ein Lightning Komponentensteuerfeld, der Apex Gleichzeitigkeitsobergrenze für langfristige Anforderungen. Ab der Version Winter '19 werden synchrone Callouts nicht mehr als langfristige Callouts gezählt. Obwohl Apex-Fortsetzungen ursprünglich als Lösung für synchrone Callouts erstellt wurden, die zu langfristigen Anforderungen führten, bieten sie auch einige zusätzliche Vorteile.

• Eine einzelne synchrone Aktion kann bis zu drei Fortsetzungsaktionen ausführen. Die vorherige Fortsetzung muss abgeschlossen sein, bevor eine neue Fortsetzungsaktion ausgeführt wird.
• Jede Fortsetzungsaktion kann bis zu drei Callouts ausführen, die parallel ausgeführt werden.
• Wenn alle von einer Fortsetzungsaktion ausgeführten Callouts abgeschlossen sind, ruft die Plattform die Methode für die Rückmeldung zur Fortsetzung auf, um die Ergebnisse zu verarbeiten.

Obwohl Fortsetzungen in Bezug auf die ursprüngliche synchrone Aktion asynchron ausgeführt werden, gibt es wichtige Unterschiede zwischen Apex Continuations (Fortsetzungen) und anderen asynchronen Apex-Techniken wie "Zukünftige Methoden", "Queueable" (Warteschlange) oder "Batch". Wichtige Unterschiede sind:

• Fortsetzungen werden in keiner Weise in die Warteschlange gestellt.
• Fortsetzungen tragen nicht zur Obergrenze für die tägliche asynchrone Apex Ausführung bei.
• Bei Fortsetzungen wird der Threadkontext auf dem Anwendungsserver von einem schweren Apex Platform-Thread zu einem leichten Thread umgeschaltet, der nur Callouts ausführt. Zum Ausführen von Callouts, die bis zu 120 Sekunden dauern können, bieten Fortsetzungen erhebliche Einsparungen beim Arbeitsspeicher des Anwendungsservers.
• Ursprünglich konnten Fortsetzungen nur über einen Visualforce JavaScript-Remote-Aufruf ausgeführt werden. In der Version Summer '19 wurden dem Lightning Component Framework jedoch offiziell Erweiterungen hinzugefügt, wodurch Visualforce nicht mehr benötigt wurde.

Plattformereignisse sind die Implementierung einer rein ereignisgesteuerten Architektur durch Salesforce Platform. Weitere Details zu den Komponenten, die diesem Architekturtyp zugeordnet sind, finden Sie im Architektenhandbuch zur ereignisgesteuerten Architektur.

Plattformereignisse und Auslöser/Flows für Plattformereignisse sind oft gute Alternativen zur Ausführung von asynchronem Apex. Sie sind auch eine großartige Möglichkeit, die Verarbeitung außerhalb der Plattform aufzurufen. Beispielsweise können Sie eine Kombination aus Amazon Web Services-Ereignisweiterleitungen und Plattformereignissen verwenden, um serverlose Rechenfunktionen in AWS Lambda aufzurufen. Arbeiten, die relativ schnell und ohne Callouts ausgeführt werden (was über einen Plattformereignisauslöser oder -Flow nicht möglich ist), eignen sich hervorragend für eine Kombination aus Plattformereignis/Auslöser oder Ereignis/Flow.

Die Ereignisse, die nach dem Commit per Veröffentlichung auf dem Bus veröffentlicht werden, werden der Reihe nach zugestellt und können vom Auslöser oder Flow in einem separaten synchronen Kontext per Massenvorgang verarbeitet werden. Der Kontext ist synchron und erzwingt alle synchronen Obergrenzen. Wählen Sie den Plattformereignisauslöser/die Flow-Batchgröße sorgfältig aus, um zu vermeiden, dass Obergrenzen erreicht werden.

• Da Ereignisse im Ereignis-Bus veröffentlicht werden, sind sie für Verbraucher verfügbar. Bei Ereignisauslösern (Apex oder Flow) werden diese Ereignisse an verfügbare synchrone Threads auf Anwendungsebene (ein Thread pro Ereignisauslöser/Flow) disponiert. Beachten Sie, dass dieser Prozess kein SLA aufweist.
• Wenn der Warteschlange Veröffentlichungsvorgänge hinzugefügt werden, wird das Ergebnis des Warteschlangenvorgangs im Objekt Database.SaveResult gespeichert. Diese Einträge geben nur an, ob der Warteschlangenvorgang erfolgreich war. Implementieren Sie eine Apex-Veröffentlichungsrückmeldung, um das Endergebnis eines über den Ereignis-Bus veröffentlichten Ereignisses zu erhalten. Mit diesen zusätzlichen Informationen können Sie Entscheidungen über weitere Aktionen treffen, beispielsweise den Versuch, fehlgeschlagene Ereignisse erneut zu veröffentlichen.
• Plattformereignisse unterliegen zwar nicht denselben Obergrenzen wie asynchrones Apex, sie verfügen jedoch über eigene Obergrenzensätze. Wenn Sie auf Probleme mit Obergrenzen stoßen, können Sie erweiterte Ereignisnutzungskennzahlen aktivieren, um zu bestimmen, ob bestimmte Ereignisse Ihre Zuteilungen stärker auslasten als geplant. Wenn Sie einen höheren Durchsatz an Ereignisauslösern benötigen, sollten Sie parallele Abonnements verwenden, um Ereignisse gleichzeitig und nicht in einem einzelnen Stream zu verarbeiten. Mit parallelen Abonnements können Sie Apex Platform-Ereignisauslöser so skalieren, dass sie große Mengen an Ereignissen verarbeiten. Parallele Abonnements sind für benutzerdefinierte Plattformereignisse mit hohem Volumen verfügbar, jedoch nicht für Standardereignisse oder Änderungsereignisse.
• Plattformereignisse haben zwei Optionen für das Veröffentlichungsverhalten:
  • Sofort veröffentlichen: Ereignisse werden unmittelbar während der Transaktion veröffentlicht, bevor der endgültige Datenbank-Commit vorgenommen wird. Ereignisse, die auf diese Weise veröffentlicht werden, können nicht garantiert werden, dass sie ordnungsgemäß veröffentlicht werden.
  • Nach Commit veröffentlichen: Ereignisse werden zu dem Zeitpunkt veröffentlicht, zu dem die Datenbanktransaktion erfolgreich übernommen wurde. Ereignisse, die auf diese Weise veröffentlicht werden, werden garantiert in der richtigen Reihenfolge veröffentlicht.

Es ist hilfreich, "Sofort veröffentlichen" für Anwendungsfälle wie die Protokollierung zu verwenden, in denen Sie das Protokollierungsereignis veröffentlichen möchten, unabhängig davon, ob die Transaktion erfolgreich ist und übernommen wird oder fehlschlägt und zurückgesetzt wird. Es ist möglich, ein Plattformereignis, das von einem Plattformereignisauslöser verwendet wird, sofort zu veröffentlichen. Der Plattformereignisauslöser konkurriert dann mit der Transaktion, die ihn veröffentlicht hat, um eine Datenbankzeilensperre. Überprüfen Sie alle Designs sorgfältig, bevor Sie Plattformereignisse sofort veröffentlichen, um sicherzustellen, dass Sie dieses Szenario vermeiden.

Asynchrone Flows bieten Low-Code-Alternativen zu asynchronem Apex. Wie bei anderen Formen der asynchronen Verarbeitung werden sie im Hintergrund ausgeführt, wenn Ressourcen verfügbar sind. Asynchrone Flows weisen zudem keine SLAs auf und können unvorhersehbare Wartezeiten aufweisen.

Geplante Pfade werden auf Cron-Auslösern basierend zu einem bestimmten Zeitpunkt ausgeführt. Sie werden beim Erstellen, Aktualisieren oder Löschen von Datensätzen ausgeführt und geben Ihnen genaue Kontrolle darüber, wann die Automatisierung in Bezug auf die Datensatzänderung ausgeführt werden soll. (Beispiel: Senden Sie eine Stunde vor Fälligkeit einer Aufgabe eine E-Mail an einen Benutzer.) Im Gegensatz zu künftigen Apex-Methoden, die auf maximal 50 in einer synchronen Transaktion in die Warteschlange gestellte Methoden begrenzt sind, gilt für geplante Flow-Aktionen derzeit keine maximale Warteschlangenobergrenze pro Transaktion. Es gibt jedoch eine Batchgrößenkonfiguration innerhalb der Definition des geplanten Pfads, die eine gewisse Kontrolle darüber ermöglicht, wie viele Datensätze von der Ausführung des geplanten Pfad-Flows verarbeitet werden.

Asynchrone Pfade können durch einen Datensatz ausgelösten Flows hinzugefügt werden. Sie werden im Hintergrund ausgeführt und verzögern nicht die Ausführung der Transaktion, die den Flow ursprünglich ausgelöst hat. Sie können einen asynchronen Pfad verwenden, um einen langfristigen Vorgang oder einen beliebigen Vorgang auszuführen, den Sie selbst ausführen möchten. Mithilfe von asynchronen Pfaden können gemischte DML-Fehler vermieden werden, die auftreten, wenn Sie einen Wert in einem verwandten Datensatz aktualisieren müssen, der nicht Teil des Datensatzes ist, der den Flow ausgelöst hat.

Hinweis: "Ausgehende Nachrichten" ist eine veraltete Funktion und Plattformereignisse (wie im vorherigen Abschnitt beschrieben) sind ein modernerer Ansatz und bieten mehr Flexibilität. Plattformereignisse sind das empfohlene Muster von Salesforce für die ereignisgesteuerte Integration.

Ausgehende Nachrichten bieten eine Möglichkeit der asynchronen ausgehenden Kommunikation über die SOAP-API. Wenn die Definition für ausgehende Nachrichten in Salesforce konfiguriert ist, wird eine SOAP-WSDL generiert, die von einem externen Webserviceanbieter verwendet werden kann. Ausgehende Nachrichten können über Workflow-Regeln, Prozessgenerator-Prozesse oder Lightning-Auslöser nach dem Speichern ausgelöst werden. Eine ausgehende SOAP-Nachricht kann bis zu 100 Benachrichtigungen enthalten. Jede Benachrichtigung enthält die Objekt-ID und einen Verweis auf die zugeordneten sObject-Daten. Wenn sich die Informationen im zugrunde liegenden Objekt ändern, nachdem die Benachrichtigung in die Warteschlange gestellt wurde, aber bevor sie gesendet wird, werden nur die neuesten Daten zugestellt und nicht die Zwischenänderungen.

Wenn ein Listener für ausgehende Nachrichten (der Webservice, den Sie mit der generierten WSDL konfiguriert haben) eine Nachricht erhält, verwendet er die enthaltenen Sitzungs-ID-Informationen, um die Lightning Platform-API aufzurufen und den Datensatz in Salesforce zu aktualisieren, der die ausgehende Nachricht ausgelöst hat.

• Ausgehende Nachrichten werden nicht über die warteschlangenbasierte asynchrone Infrastruktur in Salesforce verarbeitet, die Aktivitäten wie künftige Methoden, warteschlangenfähigen Apex, Batch Apex, Bulk API usw. ausführt. Stattdessen werden Datensätze lokal im Objekt "OutboundMessage" gespeichert. Nachrichten werden über einen lokalen geplanten Hintergrundprozess versendet und erneut versucht.
• Nachrichten werden nicht synchron gesendet, wenn die Aktion für ausgehende Nachrichten von der initiierenden Automatisierung (z. B. einem Flow-Auslöser nach dem Speichern) ausgeführt wird. Stattdessen verbleiben sie im Objekt "OutboundMessage", bis sie erfolgreich gesendet werden oder nach 24 Stunden erfolgloser Zustellung verworfen werden.
• Stellen Sie zum Vermeiden einer Endlosschleife ausgehender Nachrichten sicher, dass der Benutzer, der die Objekte aktualisiert, nicht über die Berechtigung "Ausgehende Nachrichten senden" verfügt.

Die Erfassung von Kundenvorgängen über E-Mail funktioniert normalerweise synchron. Es gibt eine Obergrenze von vier synchronen Threads für eingehende Anforderungen zur Erfassung von Kundenvorgängen über E-Mail. Das synchrone Formular des Handlers hält eine Verbindung mit dem eingehenden Salesforce-Mail-Server (MTA) aufrecht, der die E-Mail empfängt. Es gibt jedoch Gründe, warum die E-Mail-Vorgangserfassung asynchron verarbeitet werden kann:

• Für die E-Mail-Vorgangserfassung gelten Thread-Obergrenzen, insbesondere 10 Handler-Threads insgesamt pro Anwendungsserver: vier Threads für die synchrone Verarbeitung und sechs Threads für die asynchrone Verarbeitung.
• Wenn ein synchroner E-Mail-Handler die Ausführungszeit von 15 Sekunden überschreitet, wird diese bestimmte E-Mail-Serviceadresse für einen Zeitraum von 30 Minuten als asynchron markiert. Nachfolgende Handler-Anforderungen für diese Serviceadresse führen zu einer Meldung, die zusammen mit einem Verweis auf den E-Mail-Inhalt für MessageTypeName = MAILCATCHER_EMAIL_TO_CASE in die Warteschlange gestellt wird.
• Wenn bereits ein synchroner Thread für eine bestimmte Organisation und Serviceadresse verwendet wird, werden zusätzliche Anforderungen für diese Serviceadresse asynchron in die Warteschlange gestellt.
• Wenn bei einer synchron verarbeiteten E-Mail ein Fehler auftritt, beispielsweise eine Zeitüberschreitung bei der Zeilensperre, wird die Anforderung asynchron gespeichert und in die Warteschlange gestellt.
• Wenn keine synchronen Handler-Threads verfügbar sind, wird die Anforderung asynchron in die Warteschlange gestellt.

• Es gibt eine Deduplizierungsoption, wenn Sie die Erfassung von Kundenvorgängen über E-Mail konfigurieren. Anhänge werden jedoch erst nach der Verarbeitung der E-Mail dedupliziert. Diese Deduplizierung spart Platz in der Datenbank, verkürzt jedoch nicht die Verarbeitungszeiten für E-Mails. Sie können die Leistung jedoch verbessern, indem Sie einen benutzerdefinierten Apex-Handler für die Erfassung von Kundenvorgängen über E-Mail für die Nachrichtenverarbeitung implementieren. Diese Implementierung wirkt sich nicht auf Obergrenzen aus, gewährt dem Handler jedoch Zugriff auf die E-Mail-Nachricht und alle ihre Anhänge, bevor etwas in die Datenbank übernommen wird. Mit diesem Zugriff können Sie Prüfsummen für alle enthaltenen Anhänge berechnen und alle, die Sie als unnötig erachten, wie Duplikate, bekannte Signaturbilder oder unerwünschte Dateitypen, verwerfen.
• Das Übernehmen von E-Mail-Anhängen an Salesforce Files ist für den Großteil der E-Mail-Verarbeitungszeit verantwortlich. Wenn die Antworten auf oder vom Kontakt zunehmen und die E-Mail-Kette größer wird, wird auch die Verarbeitungszeit für jede E-Mail größer. Wenn die E-Mail-Option "Nur mit neuem Inhalt antworten" nicht ausgewählt ist, wachsen die E-Mail-Ketten mit jeder Antwort. Daher wird empfohlen, einen Apex-Handler für die Erfassung von Kundenvorgängen über E-Mail mit Logik zu verwenden, der die Anhangsdeduplizierung zum Zeitpunkt der Verarbeitung implementiert.
• Trotz des Aufrufs von Apex-Auslösern im Rahmen der Verarbeitung sind E-Mail-Vorgangserfassungs-Handler von der Obergrenze für gleichzeitige Apex ausgenommen.

Wenn Sie große Datensatzmengen asynchron verarbeiten möchten, sollten Sie einen der folgenden Ansätze verwenden.

Sie können Batch Apex verwenden, um komplexe, langfristige Prozesse zu erstellen, die Tausende von Datensätzen umfassen. Batch Apex funktioniert, indem Ihr Datensatz in überschaubare Blöcke aufgeteilt und verarbeitet wird. Beispielsweise können Sie eine Archivierungslösung erstellen, die nachts ausgeführt wird und einem Archiv Datensätze hinzufügt, die älter als ein bestimmtes Datum sind. Alternativ können Sie einen Datenbereinigungsvorgang erstellen, der alle Accounts und Opportunities auf nächtlicher Basis betrachtet und alle erforderlichen Aktualisierungen anhand einer Reihe vordefinierter Kriterien durchführt.

• Batch Apex kann große Datenmengen am besten verarbeiten, da für asynchrones Apex höhere Obergrenzen gelten als für synchrones Apex. Batch-Apex funktioniert auch effizienter, wenn es mehr Elemente pro Batch verarbeitet, da Massenvorgänge verwendet werden, die weniger Aufwand durch die Warteschlangenverwaltung verursachen. Erstellen Sie daher keine Batches mit kleinen Umfangsgrößen oder mit schnellen Verarbeitungszeiten, um zu vermeiden, dass der Flow-Steuerungsmechanismus über Warteschlangenüberflutungen ausgelöst wird und die tägliche Obergrenze für asynchrones Apex nicht ausgeschöpft wird.
• Vermeiden Sie es, Batchaufträge direkt aus Aktionen in die Warteschlange zu stellen, die durch große Mengen an Endbenutzeraktivitäten oder Integrations-API-Aufrufen generiert werden. Dieser Ansatz kann die flexible Warteschlange schnell erschöpfen. Wenn Sie einen Batchauftrag über einen Auslöser aufrufen möchten, müssen Sie sicherstellen, dass der Auslöser nicht mehr Batchaufträge als die Obergrenze hinzufügt.
• Batch Apex ist auf maximal fünf gleichzeitige Threads begrenzt, was seinen Durchsatz viel stärker einschränkt als künftige Methoden oder warteschlangenfähiger Apex.
• Batchaufträge mit großen Datenmengen sollten idealerweise so geplant werden, dass sie außerhalb der Hauptverkehrszeiten ausgeführt werden, um Ressourcen für Prozesse freizugeben, die Antworten in Echtzeit oder nahezu in Echtzeit erfordern.
• Wenn Sie System.scheduleBatch aufrufen, plant die Plattform die Ausführung Ihres Auftrags zu dem von Ihnen angegebenen Zeitpunkt. Die tatsächliche Ausführung erfolgt je nach Serviceverfügbarkeit zu oder nach diesem Zeitpunkt.
• Die Planung wird im Systemkontext ausgeführt. Alle Klassen werden ausgeführt, unabhängig davon, ob der Benutzer, der die Ausführung geplant hat, berechtigt ist, die Klasse auszuführen.
• Für Batchaufträge, die mit System.scheduleBatch geplant sind, gelten alle geplanten Apex-Obergrenzen. Nachdem der Batchauftrag in die Warteschlange gestellt wurde (mit dem Status "Halten" oder "In die Warteschlange gestellt"), gelten alle Obergrenzen für Batchaufträge und der Auftrag wird nicht mehr auf die geplanten Apex-Obergrenzen angerechnet.
• Beachten Sie bei einem Batchauftrag mit einem wiederkehrenden Zeitplan das richtige Verhalten, wenn der vorherige Auftrag noch ausgeführt wird, wenn der neue Auftrag ausgeführt wird.
• Batchaufträge, die aus synchronen Apex Transaktionen in die Warteschlange gestellt werden, verwenden die flexible Warteschlange. Die flexible Warteschlange ist jederzeit auf maximal 100 Elemente begrenzt. Wenn eine Transaktion versucht, weitere Einträge hinzuzufügen, generiert die Plattform Fehler und sendet den Batchauftrag nicht.
• Callouts und andere nicht transaktionale Vorgänge aus Batchaufträgen müssen idempotenten Designüberlegungen folgen. Batchaufträge, die vor einer Ausfallzeit der Salesforce-Servicewartung in die Warteschlange gestellt wurden, verbleiben in der Warteschlange. Nach Beendigung der Serviceausfallzeit und Verfügbarkeit der Systemressourcen werden die in die Warteschlange gestellten Batchaufträge ausgeführt. Wenn ein Batchauftrag bei Ausfallzeiten ausgeführt wird, wird die Batchausführung zurückgesetzt und nach der Wiederherstellung des Service neu gestartet. Da Ausführungsmethoden daher mehrfach ausgeführt werden können, können nicht transaktionale Vorgänge wie Callouts wiederholt werden.
• Konfigurieren Sie den Batchauftrag so, dass BatchApexErrorEvent-Ereignisse ausgelöst werden, um Fehler- und Ausnahmeszenarien zu verarbeiten.

Bei einem durch einen Zeitplan ausgelösten Flow handelt es sich um einen Flow, der zu einem angegebenen Zeitpunkt und mit wiederholter Häufigkeit (täglich, wöchentlich oder einmal) ausgeführt werden soll, um Aktionen für einen Datensatzbatch auszuführen. (Beispiel: Aktualisieren Sie ein Feld in allen Fällen mit dem Status "Offen" jede Nacht um 2 Uhr.) Geplante Flows werden über den Cron-Auslösermechanismus ausgeführt und per Massenvorgang verarbeitet.

• Ein durch einen Zeitplan ausgelöster Flow führt 200 Datensätze pro Aufruf aus, wird jedoch mit mehreren gleichzeitigen Threads ausgeführt, wenn mehr als 200 Datensätze vorhanden sind.
• Durch einen Zeitplan ausgelöste Flows werden in einem synchronen Kontext mit synchronen Obergrenzen ausgeführt.
• Es gibt derzeit keine Möglichkeit, die Anzahl der pro geplantem Flow-Aufruf verarbeiteten Datensätze zu steuern. Wenn die Ausführung für mehr als 200 Datensätze erfolgt, besteht eine echte Gefahr von gleichzeitigen Apex Fehlern.

Die Bulk-API basiert auf REST-Prinzipien und ist für die Arbeit mit großen Datensets optimiert. Sie können damit viele Datensätze asynchron einfügen, aktualisieren, aktualisieren, einfügen, abfragen oder löschen und die Ergebnisse später verarbeiten. Die Salesforce Platform verarbeitet die Anforderung im Hintergrund. Im Gegensatz dazu verwenden die SOAP-API und die REST-API synchrone Anforderungen und sind für Echtzeit-Client-Anwendungen optimiert, die mehrere Datensätze gleichzeitig aktualisieren. Sie können beide APIs für die Verarbeitung vieler Datensätze verwenden. Wenn die Datensets jedoch Hunderttausende von Datensätzen enthalten, sind sie weniger praktisch. Das asynchrone Framework der Bulk-API wurde entwickelt, um die Verarbeitung von Daten aus einigen Tausend bis Millionen Datensätzen einfach und effizient zu gestalten.

Die Bulk-API lässt sich am einfachsten verwenden, indem Sie sie für die Verarbeitung von Datensätzen in Data Loader mithilfe von CSV-Dateien aktivieren. Mit Data Loader müssen Sie keine eigene Client-Anwendung schreiben. Manchmal müssen jedoch aufgrund spezifischer Anforderungen benutzerdefinierte Anwendungen erstellt werden.

Innerhalb der Salesforce Platform sind zwei Bulk-APIs verfügbar.

• Die Bulk-API 2.0 ist die neuere API. Sie bietet einen optimierten und benutzerfreundlicheren Workflow und ist der Schwerpunkt für Verbesserungen.
• Die ursprüngliche Bulk-API wird weiterhin vollständig unterstützt, jedoch nicht mehr erweitert. Es wird empfohlen, nach Möglichkeit die Bulk-API 2.0 zu verwenden.

Weitere Informationen zu API-Obergrenzen finden Sie unter Bulk API Limits and Bulk API 2.0 Limits (Obergrenzen für Bulk-API 2.0).

Lesen Sie diese Anleitung, wenn Sie eine asynchrone Verarbeitung auf Salesforce Platform erstellen oder in Betracht ziehen. Es empfiehlt sich immer, den vollständigen Umfang der für Sie verfügbaren Optionen zu verstehen und zu erfahren, wie sie zu Ihrem speziellen Anwendungsfall passen. Achten Sie darauf, Ihre aktuelle Landschaft sorgfältig zu bewerten, bevor Sie Änderungen an Ihren vorhandenen Architekturen vornehmen, insbesondere wenn Ihre aktuelle Lösung gut funktioniert.