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 empfängt. Sie enthält die Daten für einen neuen Employee-Datensatz, den ein Benutzer in Salesforce angelegt hat. Beachten Sie die Feldwerte changeType und entityName.

{
  "schema": "-pszPCNGMHqUPU1ftkjxEA",
  "payload": {
    "ChangeEventHeader": {
      "commitNumber": 65824495947,
      "commitUser": "005RM000001vI4mYAE",
      "sequenceNumber": 1,
      "entityName": "Employee__c",
      "changeType": "CREATE",
      "changedFields": [],
      "changeOrigin": "com/salesforce/api/soap/47.0;client=SfdcInternalAPI/",
      "transactionKey": "0005163c-8d04-d729-39bd-b917b035a66c",
      "commitTimestamp": 1569436136000,
      "recordIds": [
        "a00RM0000004ICOYA2"
      ]
    },
    "First_Name__c": "Jane",
    "Tenure__c": 2.0,
    "Name": "e-100",
    "Last_Name__c": "Smith",
    "CreatedDate": "2019-09-25T18:28:55.000Z",
    "LastModifiedDate": "2019-09-25T18:28:55.000Z",
    "OwnerId": "005RM000001vI4mYAE",
    "CreatedById": "005RM000001vI4mYAE",
    "LastModifiedById": "005RM000001vI4mYAE",
  },
  "event": {
    "replayId": 1
  }
}

Die Beispielnachricht über das Änderungsereignis enthält die Mitarbeiterfelder für Vorname, Nachname und Beschäftigungsdauer sowie Systemfelder wie das Erstellungsdatum. Bei einem neuen Datensatz werden Felder, die ein Benutzer nicht festgelegt hat, aus der Ereignisnachricht ausgeschlossen. Wenn der Benutzer beispielsweise das Feld für die Beschäftigungsdauer nicht ausfüllt, wird es aus der Ereignismeldung ausgeschlossen. 

Das Feld ChangeEventHeader enthält Header-Felder, die Informationen über das Ereignis 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"].

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 clientID GetCloudy den Mitarbeiterdatensatz über die SOAP-API erstellt, lautet der Wert des Felds changeOrigin wie folgt: com/salesforce/api/soap/47.0;client=GetCloudy. In unserem Beispiel lautet der Wert com/salesforce/api/soap/47.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.

Feld mit der Wiedergabe-ID des Ereignisses

Der letzte Teil der Ereignisnachricht enthält ein Feld namens "replayId". Dieses Feld enthält eine ID für die Ereignisnachricht, die Sie verwenden können, um vergangene Ereignisse der letzten maximal drei Tage wiederzugeben. Die erneute Wiedergabe von Ereignissen wird in diesem Modul nicht behandelt. Weitere Informationen finden Sie im Abschnitt "Ressourcen".

Felder im Text einer Ereignisnachricht

Die Felder, die Salesforce in eine Ereignisnachricht aufnimmt, die ein CometD-Client empfängt, hängen vom durchgeführten Vorgang und Abonnententyp ab. Beispielsweise enthält eine Ereignisnachricht, die in einem CometD-Client für einen neuen Datensatz empfangen wird, alle nicht leeren Datensatzfelder und Systemfelder. In einem Apex-Auslöser oder einem Pub/Sub-API-Client enthält die Ereignisnachricht jedoch alle Datensätze, ob leer oder nicht, sowie Systemfelder. Weitere Informationen finden im Change Data Capture Developer Guide unter Change Event Body Fields.

Feldreihenfolge in der Ereignisnachricht

Die Reihenfolge der Felder in der JSON-Ereignisnachricht ist nicht garantiert. Die Reihenfolge richtet sich nach dem zugrunde liegenden Apache Avro-Schema, einem Datenserialisierungssystem, auf dem Änderungsereignisse basieren. Wenn ein Ereignis in das JSON-Format erweitert wird, stimmt die Reihenfolge der Felder möglicherweise nicht mit dem Schema überein, je nachdem, mit welchem Client das Ereignis empfangen wurde.

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.

Anreichern von Änderungsereignissen mit zusätzlichen Feldern

Wählen Sie Felder aus, um die an CometD-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 im Change Data Capture Developer Guide unter Gap Events, Overflow Events und High-Level Replication Steps.

Abonnieren eines Ereigniskanals

Nachdem Sie nun wissen, wie eine Änderungsereignisnachricht aussieht, sehen wir uns nun an, wie Sie die Änderungsereignisse empfangen können. Salesforce bietet mehrere Möglichkeiten, einen Änderungsereigniskanal zu abonnieren. Für Anwendungen außerhalb von Salesforce können Sie die Streaming-API oder Tools und Bibliotheken verwenden, die auf CometD basieren, einer Open Source-Bibliothek zur Simulation von Push-Technologie. Die Streaming-API bietet einen Abonnementmechanismus auf der Grundlage von CometD. 

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 mithilfe der Streaming-API eine eigene Anwendung erstellen möchten, finden Sie weitere Einzelheiten dazu im Streaming API Developer Guide. Das Handbuch enthält Codebeispiele für Abonnements mithilfe von CometD. 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.

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

• Change Data Capture Developer Guide
• Lightning-Komponentenbibliothek: lightning-emp-api-Webkomponente
• Lightning-Komponentenbibliothek: lightning:empApi-Komponente
  
• Streaming API Developer Guide
• Externe Website: CometD
• Externe Website: Apache Avro