Skip to main content
Join the Agentforce Hackathon on Nov. 18-19 to compete for a $20,000 Grand Prize. Sign up now. Terms apply.

Eigenschaften der Datenänderungserfassung

Lernziele

Nachdem Sie diese Lektion abgeschlossen haben, sind Sie in der Lage, die folgenden Aufgaben auszuführen:

  • Bestimmen, welche Objekte für die Datenänderungserfassung verfügbar sind
  • Auflisten der Felder, die im Header eines Änderungsereignisses zurückgegeben werden, und beschreiben, welche Felder für jeden Vorgang im Ereignistext enthalten sind
  • Erstellen eines Namens für den Änderungsereigniskanal
  • Nennen der Berechtigungen, die erforderlich sind, um Änderungsereignisse zu abonnieren

Objektunterstützung

Die Datenänderungserfassung kann Änderungsereignisse für alle in Ihrer Salesforce-Organisation definierten benutzerdefinierten Objekte und eine Teilmenge von Standardobjekten generieren. Die Funktion unterstützt Änderungsereignisse für die gängigsten Standardobjekte wie Account, Kontakt, Lead, Benutzer, Auftrag, OrderItem, Product2 und andere. Eine Liste der Objekte, die Änderungsereignisse unterstützen, finden Sie in Object Reference for Salesforce and Lightning Platform unter StandardObjectNameChangeEvent.

Um Benachrichtigungen über Datensatzänderungen zu erhalten, wählen Sie die benutzerdefinierten Objekte und unterstützten Standardobjekte, die Sie interessieren, auf der Seite "Datenänderungserfassung" in Setup aus. Die Schritte zur Auswahl von Objekten werden später in diesem Modul behandelt.

Beispiel für ein Änderungsereignis

Erinnern Sie sich noch an Robert? Sein Beratungskunde hat ein benutzerdefiniertes Objekt namens Employee__c definiert, das Teil einer benutzerdefinierten HR-Anwendung zur Verwaltung von Mitarbeiterdaten ist. Um Mitarbeiterdaten in Salesforce mit dem externen HR-System zu synchronisieren, hat Robert eine Anwendung erstellt, die Änderungsereignisse zu neuen und geänderten Employee-Datensätzen empfängt und integriert. 

Sehen wir uns ein Beispiel für eine Ereignisnachricht an, die diese Anwendung mit der Pub/Sub-API empfängt. Sie enthält die Daten für einen neuen Employee-Datensatz, den ein Benutzer in Salesforce angelegt hat. Die Änderungsereignis-Nutzlast enthält Header-Felder in ChangeEventHeader, die Informationen über die Änderung, Datensatzfelder und Systemfelder enthalten. Diese Beispielnachricht über das Änderungsereignis enthält Vorname, Nachname und Anstellungsdauer des Mitarbeiters sowie Systemfelder wie CreatedDate. Das Feld Tenure (Anstellungsdauer) ist leer, da es nicht festgelegt wurde. Mit der Pub/Sub-API empfangene Änderungsereignisse enthalten alle Datensatzfelder, einschließlich leere Felder (NULL). Im ChangeEventHeader enthält das Feld entityName den Namen des Salesforce-Objekts und das Feld changeType gibt an, dass es sich der Änderung um eine Datensatzerstellung handelt.

{
  "ChangeEventHeader": {
    "entityName": "Employee__c",
    "recordIds": [
      "a00aj000006yrE7AAI"
    ],
    "changeType": "CREATE",
    "changeOrigin": "com/salesforce/api/soap/60.0;client=SfdcInternalAPI/",
    "transactionKey": "000033a1-751e-415e-47bc-60f581b7e049",
    "sequenceNumber": 1,
    "commitTimestamp": 1712601294000,
    "commitNumber": 1712601294485905400,
    "commitUser": "005aj0000032E1yAAE",
    "nulledFields": [],
    "diffFields": [],
    "changedFields": []
  },
  "OwnerId": "005aj0000032E1yAAE",
  "Name": "e-100",
  "CreatedDate": 1712601294000,
  "CreatedById": "005aj0000032E1yAAE",
  "LastModifiedDate": 1712601294000,
  "LastModifiedById": "005aj0000032E1yAAE",
  "Last_Name__c": "Smith",
  "First_Name__c": "Patricia",
  "Tenure__c": null
}

Das Feld ChangeEventHeader enthält Header-Felder, die Informationen über die Änderung enthalten. Nachfolgend werden einige wichtige Header-Felder aufgeführt:

entityName

Dieses Feld enthält den Namen des Standard- oder benutzerdefinierten Objekts für diese Datensatzänderung. In unserem Beispiel lautet er "Employee__c".

changeType

Dieses Feld enthält den Vorgang, der die Änderung verursacht hat. Bei gängigen Änderungsereignissen kann dieses Feld einen der folgenden Werte haben: 

  • CREATE
  • UPDATE
  • DELETE
  • UNDELETE

In unserem Beispiel wurde das Änderungsereignis von einer Datensatzerstellung ausgelöst, weshalb der Wert CREATE lautet.

changedFields

Anhand dieses Felds können Sie herausfinden, welche Felder bei einem Aktualisierungsvorgang geändert wurden. Bei anderen Vorgängen ist dieses Feld leer. Da das Beispiel für das Änderungsereignis für einen neuen Datensatz gilt, ist dieses Feld leer. Wenn Sie ein oder mehrere Felder aktualisieren, werden die Feldnamen zusammen mit LastModifiedDate in changedFields aufgenommen. Wenn beispielsweise First_Name__c geändert wird, lautet der Feldwert ["LastModifiedDate", "First_Name__c"].

diffFields

Ist nur in Ereignissen, die in der Pub/Sub-API empfangen wurden, und in Apex-Auslösern verfügbar. Enthält die Namen von Feldern, deren Werte als einheitlicher Unterschied ("Unified Diff") übermittelt werden, da sie große Textwerte enthalten.

nulledFields

Ist nur in Ereignissen, die in der Pub/Sub-API empfangen wurden, und in Apex-Auslösern verfügbar. Enthält die Namen von Feldern, deren Werte bei einem Update-Vorgang in NULL geändert wurden. Mit diesem Feld können Sie feststellen, ob ein Feld bei einem Update in NULL geändert wurde und kein unverändertes Feld darstellt.

changeOrigin

Finden Sie anhand dieses Felds heraus, was die Änderung verursacht hat. Wenn Ihre Integrationsanwendung einen Datensatz als Reaktion auf eine Datensatzänderung desselben Objekts ändert, können Sie in einen nicht enden wollenden Zyklus von Änderungen geraten. Um das zu vermeiden, verwenden Sie dieses Feld, um festzustellen, ob Ihre Anwendung die Änderung verursacht hat, und falls ja, verarbeiten Sie die Änderung nicht noch einmal, womit Sie einen potenziell tiefgreifenden Änderungszyklus vermeiden. Dieses Feld enthält die Salesforce-API und die API-Client-ID, die die Änderung bewirkt hat, sofern diese vom Client festgelegt wurde. Dieses Feld wird bei Änderungen durch API-Anwendungen oder durch Lightning Experience ausgefüllt und ist ansonsten leer.

Wenn beispielsweise eine Anwendung mit der clientIDGetCloudy den Mitarbeiterdatensatz über die SOAP-API erstellt, lautet der Wert des Felds changeOrigin wie folgt: com/salesforce/api/soap/60.0;client=GetCloudy. In unserem Beispiel lautet der Wert com/salesforce/api/soap/60.0;client=SfdcInternalAPI/, was bedeutet, dass die Änderung des Datensatzes auf der Salesforce-Benutzeroberfläche vorgenommen wurde.

Transaktionsbezogene Header-Felder

Die folgenden Header-Felder enthalten Informationen über die Transaktion der aktuellen Änderung. 

  • transactionKey
  • sequenceNumber

Verwenden Sie die Transaktionsfelder, um eine exakte Replik der Daten Ihrer Organisation in einem anderen System zu pflegen. Das Feld "transactionKey" enthält eine eindeutige Bezeichnung für die Transaktion, zu der die Änderung gehört. Das Feld "sequenceNumber" gibt die Sequenznummer der Änderung innerhalb einer Transaktion an. Die Sequenznummer ist nützlich für Vorgänge mit mehreren Schritten wie etwa die Leadkonvertierung oder die Erstellung verwandter Datensätze in einem Apex-Auslöser des Typs "after insert". Wenn nicht alle an einer Transaktion beteiligten Objekte für "Datenänderungserfassung" aktiviert sind, entsteht eine Lücke in den Sequenznummern. Wir empfehlen Ihnen, alle in einer Transaktion stattfindenden Änderungen als Einzel-Commit in Ihrem System zu replizieren. 

Wenn Sie sich dafür entscheiden, keinen transaktionsbasierten Replikationsprozess zu verwenden, sind Ihre replizierten Daten möglicherweise nicht vollständig, wenn Ihr Abonnement endet. Endet Ihr Abonnement beispielsweise in der Mitte eines Ereignis-Streams für eine Transaktion, wird nur ein Teil der Änderungen der Transaktion in Ihrem System repliziert.

Felder im Text einer Ereignisnachricht

Die Felder, die Salesforce in eine Ereignisnachricht aufnimmt, die ein Client empfängt, hängen vom durchgeführten Vorgang und Abonnententyp ab. Zum Beipiel in einem Apex-Auslöser oder einem Pub/Sub-API-Client enthält die Ereignisnachricht alle Datensätze, ob leer oder nicht, sowie Systemfelder. Weitere Informationen finden im Change Data Capture Developer Guide unter Change Event Body Fields.

Zusammengeführte Änderungsereignisse

Aus Effizienzgründen werden Änderungsereignisse für eine Transaktion mitunter zu einem Ereignis zusammengeführt, wenn dieselbe Änderung in mehreren Datensätzen desselben Objekttyps innerhalb einer Sekunde aufgetreten ist. Wenn Änderungsereignisse zusammengeführt werden, sendet Salesforce ein Änderungsereignis für alle betroffenen Datensätze und das Feld recordIds enthält die IDs aller Datensätze mit derselben Änderung. Weitere Informationen finden im Change Data Capture Developer Guide unter Merged Change Events (Zusammengeführte Änderungsereignisse).

Anreichern von Änderungsereignissen mit zusätzlichen Feldern

Wählen Sie Felder aus, um die an Pub/Sub-API-Abonnenten übermittelten Änderungsereignisse anzureichern. Die ausgewählten Felder werden in die Änderungsereignisnachrichten aufgenommen, auch wenn sie unverändert bleiben. Verwenden Sie die Anreicherung zum Beispiel, wenn Ihre Anwendung ein externes ID-Feld für den Abgleich von Datensätzen in einem externen System benötigt. Oder fügen Sie stets ein Feld ein, das wichtige Informationen zum geänderten Datensatz liefert. Weitere Informationen finden im Change Data Capture Developer Guide unter Enrich Change Events with Extra Fields und diesem Trailhead-Projekt zum Thema: Erstellen eines benutzerdefinierten Kanals und Anreichern von Änderungsereignissen.

Andere Ereignistypen: GAP- und Überlaufereignisse

Andere Typen von Änderungsereignissen werden zur Bewältigung spezieller Situationen generiert. Salesforce generiert GAP-Ereignisse, wenn Änderungsereignisse nicht generiert werden können oder um Abonnenten über Fehler zu informieren. Salesforce generiert Überlaufereignisse, wenn das Volumen der Änderungen groß ist. GAP- und Überlaufereignisse enthalten keine Datensatzdaten. GAP-Ereignisse enthalten die Datensatz-ID, wodurch das Abrufen von Datensätzen ermöglicht wird. Weitere Informationen finden Sie im Change Data Capture Developer Guide unter Gap Events, Overflow Events und High-Level Replication Steps in the .

Abonnieren eines Ereigniskanals

Nachdem Sie nun wissen, wie eine Änderungsereignisnachricht aussieht, sehen wir uns nun an, wie Sie die Änderungsereignisse empfangen können. Dieses Modul verwendet die Pub/Sub-API und Apex-Auslöser zum Abonnieren von Änderungsereignissen. Salesforce bietet mehrere Möglichkeiten, einen Änderungsereigniskanal zu abonnieren.

Für Anwendungen außerhalb von Salesforce können Sie die Pub/Sub-API, eine effiziente gRPC-basierte API und HTTP/2 verwenden, das binäre Ereignisnachrichten veröffentlicht und übermittelt.

Um auf der Lightning-Plattform Datenänderungen asynchron zu verarbeiten, schreiben Sie für das Änderungsereignis einen Apex-Auslöser. Mit Apex-Auslösern für Änderungsereignisse befassen wir uns in diesem Modul später noch eingehender.

Wenn Sie Sofortbenachrichtigungen über Salesforce-Datenänderungen in einer Anwendung erhalten möchten, die auf der Lightning-Plattform ausgeführt wird, können Sie die Lightning-Komponente "empApi" verwenden.

Sie abonnieren mit der Anwendung einen Kanal, um anzugeben, welche Ereignisse sie erhalten möchten. Ihre Streaming-Anwendung empfängt Ereignisse in Echtzeit, sobald eine Änderung in Salesforce erfolgt. 

Wenn Sie eine eigene Anwendung mit der Pub/Sub-API erstellen möchten, finden Sie weitere Einzelheiten dazu im Pub/Sub API Developer Guide. Informationen zum Erstellen einer Lightning-Plattformanwendung mit empApi finden Sie in der Dokumentation zur Webkomponente "lightning-emp-api oder der Aura-Komponente "lightning:empApi".   

Abonnementkanäle

Ein Abonnementkanal ist ein Datenstrom mit Änderungsereignissen, die einer oder mehreren Einheiten entsprechen. Sie können den Kanal abonnieren, um Benachrichtigungen zu Änderungsereignissen für Vorgänge zum Erstellen, Aktualisieren, Löschen und Wiederherstellen von Datensätzen zu empfangen. Die Datenänderungserfassung bietet vordefinierte Standardkanäle. Sie können jedoch auch eigene benutzerdefinierte Kanäle erstellen. 

Standardkanäle

Der Standardkanal ChangeEvents enthält Änderungsereignisse von einer oder mehreren ausgewählten Einheiten in einem einzigen Datenstrom, den Sie abonnieren können. Wenn Sie Änderungsereignisse von mehr als einer Einheit erwarten, verwenden Sie den Standardkanal ChangeEvents. Um Änderungsereignisse über den Kanal ChangeEvents zu empfangen, wählen Sie die Einheiten für die Datenänderungserfassung aus. In der nächsten Einheit erfahren Sie, wie Sie eine Einheit für Änderungsereignisse auswählen.

Wenn Sie Änderungsereignisse nur für eine einzelne Einheit erwarten, verwenden Sie den Kanal für einzelne Einheiten. Bei Kanälen für einzelne Einheiten können Sie Änderungsereignisse von nur einem benutzerdefinierten oder Standardobjekt abonnieren.

Diese Tabelle zeigt, wie Sie den Abonnementkanal angeben, der den Datensätzen entspricht, für die Sie Änderungen erfassen möchten.

Abonnieren Sie Änderungsereignisse für:

Kanal

Beispiel

Standardkanal für ausgewählte Einheiten

Alle ausgewählten Objekte

/data/ChangeEvents

entfällt

Kanäle für einzelne Einheit

Ein Standardobjekt

/data/<Name_des_Standardobjekts>ChangeEvent

Für Accounts lautet der Kanal: /data/AccountChangeEvent

Ein benutzerdefiniertes Objekt

/data/<Name_des_benutzerdefinierten_Objekts>__ChangeEvent

Für Employee__c-Datensätze lautet der Kanal: /data/Employee__ChangeEvent

Benutzerdefinierte Kanäle

Erstellen Sie einen benutzerdefinierten Kanal, wenn Sie mehrere Abonnenten haben und jeder Abonnent Änderungsereignisse von einer anderen Gruppe von Einheiten empfängt. Verwenden Sie auch einen benutzerdefinierten Kanal mit Ereignisanreicherung , um das Senden angereicherter Felder bei Änderungsereignissen auf einem bestimmten Kanal zu isolieren. Benutzerdefinierte Kanäle gruppieren und isolieren Änderungsereignisse für jeden Abonnenten, sodass Abonnenten nur die Arten von Ereignissen empfangen, die sie benötigen. Einheiten werden automatisch für die Datenänderungserfassung aktiviert, wenn Sie einen benutzerdefinierten Kanal erstellen, der sie enthält. Ein benutzerdefinierte Kanal hat das folgende Format:

/data/YourChannelName__chn

Wenn der Kanalname beispielsweise SalesEvents lautet, ist der Abonnementkanal wie folgt:

/data/SalesEvents__chn

Weitere Informationen finden Sie im Change Data Capture Developer Guide unter Compose Streams of Change Data Capture Notifications with Custom Channels.

Berechtigungen zum Empfangen von Änderungsereignissen

Bei der Datenänderungserfassung werden Freigabeeinstellungen ignoriert und Änderungsereignisse für alle Datensätze eines Salesforce-Objekts gesendet. Um Änderungsereignisse auf einem Kanal empfangen zu können, muss der abonnierte Benutzer je nach den Einheiten, die den Änderungsereignissen zugeordnet sind, über eine oder mehrere Berechtigungen verfügen. Weitere Informationen finden im Change Data Capture Developer Guide unter Required Permissions for Change Events.

Feldebenensicherheit

Bei der Datenänderungserfassung werden die Einstellungen zur Feldebenensicherheit in Ihrer Organisation respektiert. Gesendete Ereignisse enthalten nur die Felder, für die ein Abonnementbenutzer anzeigeberechtigt ist. 

In der nächsten Einheit zeigen wir Ihnen, wie Sie ein Open-Source-Beispieltool namens EMP Connector verwenden, um einen Kanal zu abonnieren und Ereignisse zu empfangen.

Ressourcen

Teilen Sie Ihr Trailhead-Feedback über die Salesforce-Hilfe.

Wir würden uns sehr freuen, von Ihren Erfahrungen mit Trailhead zu hören: Sie können jetzt jederzeit über die Salesforce-Hilfe auf das neue Feedback-Formular zugreifen.

Weitere Infos Weiter zu "Feedback teilen"