Abonnieren von Plattformereignissen

• Beschreiben, wie Nachrichten zu Plattformereignissen abonniert werden
• Abonnieren eines Ereignisses auf der Plattform und in externen Anwendungen
• Testen von Plattformereignissen in einer Apex-Testmethode
• Abonnieren von Plattformereignissen mithilfe von CometD

Hinweis

Lernen Sie auf Deutsch? In diesem Badge ist für die praktischen Trailhead-Aufgaben Englisch als Bearbeitungssprache festgelegt. Übersetzungen werden zur Referenz in Klammern angegeben. Vergewissern Sie sich, dass Sie in Ihrem Trailhead-Playground (1) das Gebietsschema auf USA und (2) die Sprache auf Englisch festgelegt haben. (3) Verwenden Sie zum Kopieren und Einfügen nur die englischen Werte. Die zugehörigen Anweisungen finden Sie hier.

Weitere Details dazu, wie Sie die übersetzte Trailhead-Umgebung optimal nutzen können, finden Sie unter dem Badge "Trailhead in Ihrer Sprache".

// Trigger for listening to Cloud_News events.
trigger CloudNewsTrigger on Cloud_News__e (after insert) {
    // List to hold all cases to be created.
    List<Case> cases = new List<Case>();
    // Get queue Id for case owner
    Group queue = [SELECT Id FROM Group WHERE Name='Regional Dispatch' AND Type='Queue'];
    // Iterate through each notification.
    for (Cloud_News__e event : Trigger.New) {
        if (event.Urgent__c == true) {
            // Create Case to dispatch new team.
            Case cs = new Case();
            cs.Priority = 'High';
            cs.Subject = 'News team dispatch to ' +
                event.Location__c;
            cs.OwnerId = queue.Id;
            cases.add(cs);
        }
   }
    // Insert all cases corresponding to events received.
    insert cases;
}

Einrichten der Debug-Protokollierung

Im Gegensatz zu Standard- oder benutzerdefinierten Objekten werden Auslöser für Plattformereignisse nicht in derselben Apex-Transaktion ausgeführt wie derjenigen, in der das Ereignis veröffentlicht wurde. Der Auslöser wird in einem eigenen Prozess unter der Einheit "Automatisierter Prozess" (Systembenutzer) ausgeführt. Demzufolge werden Debug-Protokolle, die zur Ausführung des Auslösers gehören, von der Einheit "Automatisierter Prozess" erstellt und stehen nicht in der Entwicklerkonsole zur Verfügung. Fügen Sie zum Erfassen von Protokollen für Plattformereignisauslöser in Setup einen Verfolgungskennzeichnungseintrag für die Einheit "Automatisierter Prozess" hinzu.

1. Geben Sie unter "Setup" im Feld "Schnellsuche" den Text "Debug-Protokolle" ein und klicken Sie dann auf Debug-Protokolle.
2. Klicken Sie auf Neu.
3. Wählen Sie Automatisierter Prozess für "Typ der verfolgten Einheit" aus.
4. Wählen Sie das Anfangs- und Ablaufdatum für die Protokolle aus, die Sie erfassen möchten.
5. Geben Sie für "Debugebene" * ein und klicken Sie auf Suchen.
6. Wählen Sie eine vordefinierte Debugebene wie SFDC_DevConsole aus oder klicken Sie auf Neu, um eine eigene Debugebene zu erstellen.
7. Klicken Sie auf Speichern.

Debug-Protokolle für Apex-Tests sind eine Ausnahme. Sie enthalten eine Protokollierung für Ereignisauslöser im selben Testausführungsprotokoll.

Hinweise zu Plattformereignisauslösern

Themenliste "Abonnements" auf der Seite "Ereignisdefinition"

Den Status aller Ereignisauslöser können Sie in Setup auf der Detailseite der Plattformereignisdefinition anzeigen. Unter "Abonnements" wird jeder aktive Auslöser zusammen mit Informationen zur Ausführung und Status aufgeführt. Zu den Informationen gehören die Wiedergabe-ID der letzten veröffentlichten und verarbeiteten Ereignisse. Der Status gibt an, ob der Auslöser ausgeführt wird oder aufgrund nicht zu korrigierender Fehler oder unzureichender Berechtigungen vom Abonnement getrennt ist. Der Status "Fehler" wird nur erreicht, wenn ein Auslöser mit der maximal zulässigen Anzahl wiederholt wurde. Der folgende Screenshot zeigt die Themenliste "Abonnements" auf der Ereignisdetailseite "Cloud News"

• In der Themenliste "Abonnements" sind auch Flows und Prozesse aufgelistet, die für das Ereignis abonniert sind.
• Die Themenliste "Abonnements" enthält keine Abonnenten, die CometD, die Pub/Sub-API oder die Lightning-Komponente empApi verwenden. Die anderen Typen von Abonnenten lernen Sie im weiteren Verlauf dieser Einheit kennen.
• Für Plattformereignisse mit hohem Volumen ist der Wert "Zuletzt veröffentlichte ID" nicht verfügbar und wird stets als "Nicht verfügbar" angezeigt.

Verwalten der Abonnenten von Apex-Auslösern eines Ereignisses

Setzen Sie ein ausgesetztes Abonnement an der Stelle fort, an der es unterbrochen wurde, beginnend mit der frühesten Ereignisnachricht, die im Ereignisbus verfügbar ist Wenn Sie Ereignisnachrichten umgehen möchten, die Fehler verursachen oder nicht mehr benötigt werden, können Sie das Abonnement von der Spitze aus fortsetzen und mit neuen Ereignisnachrichten beginnen.

Klicken Sie zum Verwalten des Abonnements eines Auslösers in der Themenliste "Abonnements" neben dem Apex-Auslöser auf Verwalten.

• Zum Aussetzen eines ausgeführten Abonnements klicken Sie auf Suspend (Aussetzen).
  
  
• Zum Fortsetzen eines ausgesetzten Abonnements beginnend mit der frühesten Ereignisnachricht, die im Ereignisbus verfügbar ist, klicken Sie auf Fortsetzen.
• Zum Fortsetzen eines ausgesetzten Abonnements ab neuen Ereignisnachrichten klicken Sie auf Resume from Tip (Ab Spitze fortsetzen).
  
  

Wenn Sie einen Auslöser speichern, wird das Abonnement des Auslösers automatisch fortgesetzt. Weitere Informationen finden Sie im Platform Events Developer Guide unter View and Manage an Event’s Subscribers on the Platform Event’s Detail Page.

// Create test events
Test.startTest();
// Publish events
Test.stopTest();
// Perform validation here

@isTest
public class PlatformEventTest {
    @isTest static void test1() {
        // Create test event instance
        Cloud_News__e newsEvent = new Cloud_News__e(
            Location__c='Mountain City',
            Urgent__c=true,
            News_Content__c='Test message.');
        Test.startTest();
        // Call method to publish events
        Database.SaveResult sr = EventBus.publish(newsEvent);
        Test.stopTest();
        // Perform validation here
        // Verify that the publish was successful
        System.assertEquals(true, sr.isSuccess());
        // Check that the case that the trigger created is present.
        List<Case> cases = [SELECT Id FROM Case];
        // Validate that this case was found.
        // There is only one test case in test context.
        System.assertEquals(1, cases.size());
    }
}

Abonnieren in einer Lightning-Webkomponente

Um die empApi-Methoden in Ihrer Lightning-Webkomponente zu verwenden, importieren Sie die Methoden wie folgt aus dem Modul lightning/empApi.

import { subscribe, unsubscribe, onError, setDebugFlag, isEmpEnabled }
    from 'lightning/empApi';

Rufen Sie dann die importierten Methoden in Ihrem JavaScript-Code auf.

Ein Beispiel der Nutzung des Moduls lightning/empApi und eine vollständige Referenz finden Sie in der Lightning Component Library in der Dokumentation zu lightning-emp-api.

Abonnieren in einer Aura-Komponente

<lightning:empApi aura:id="empApi"/>

/event/<EventName>__e

/event/Cloud_News__e

// Connect to the CometD endpoint
    cometd.configure({
               url: 'https://<Salesforce_URL>/cometd/48.0/',
               requestHeaders: { Authorization: 'OAuth <Session_ID>'}
    });

Abonnieren von Benachrichtigungen zu Plattformereignissen mithilfe der Pub/Sub-API

Die Pub/Sub-API bietet eine zentrale Schnittstelle zum Veröffentlichen und Abonnieren von Plattformereignissen. Basierend auf der gRPC-API und HTTP/2 veröffentlicht und übermittelt die Pub/Sub-API binäre Ereignisnachrichten effizient im Apache Avro-Format. gRPC ist ein Open Source Remote Procedure Call-Framework (RPC), das das Verbinden von Geräten, mobilen Anwendungen und Browsern mit Back-End-Services ermöglicht. Weitere Informationen finden Sie in der Dokumentation zu gRPC. Apache Avro ist ein System zur Serialisierung von Daten. Weitere Informationen finden Sie unter Apache Avro.

Die Pub/Sub-API verwendet ein Pull-Abonnement-Modell, bei dem der Client eine Anzahl von Ereignissen vom Server anfordert, die seiner Verarbeitungskapazität entspricht. Im Gegensatz zu Push-Abonnements, bei denen ein Client auf den Empfang neuer Ereignisse wartet, die vom Server gepusht werden, fordert ein Client bei einem Pull-Abonnement proaktiv Ereignisse vom Server an. Diese Steuerung des Ereignisflusses stellt sicher, dass der Client nicht mit mehr Ereignissen überlastet wird, als er verarbeiten kann, wenn es zu einer Spitze bei der Veröffentlichung von Ereignissen kommt.

Es folgen einige der Vorteile der Pub/Sub-API:

• Veröffentlichen, Abonnieren und Abrufen von Ereignisschemas in einer einzigen API
• Endgültige Veröffentlichungsergebnisse von Veröffentlichungsvorgängen und keine Zwischenergebnisse in der Warteschlange
• Flusskontrolle, mit der Sie festlegen können, wie viele Ereignisse in einem Abonnentenaufruf empfangen werden sollen, basierend auf der Geschwindigkeit der Ereignisverarbeitung im Client
• Leistungsstarkes Datenstreaming in Echtzeit mit Komprimierung durch HTTP/2
• Unterstützung von 11 Programmiersprachen im Client, die von der gRPC-API angeboten werden, z. B. Python, Java, Node und C++ Alle unterstützten Sprachen finden Sie unter https://grpc.io/docs/languages/.

Wie bei CometD-Clients können Sie Plattformereignisse abonnieren, indem Sie einen Ereignis- oder benutzerdefinierten Kanal angeben.

Plattformereignisnachricht im JSON-Format in einem CometD-Client

Die Nachricht eines übermittelten Plattformereignisses sieht so ähnlich aus wie das folgende Beispiel eines Cloud News-Ereignisses.

{
  "data": {
    "schema": "_2DBiqh-utQNAjUH78FdbQ",
    "payload": {
      "CreatedDate": "2017-04-27T16:50:40Z",
      "CreatedById": "005D0000001cSZs",
      "Location__c": "San Francisco",
      "Urgent__c": true,
      "News_Content__c": "Large highway is closed due to asteroid collision."
    },
    "event": {
      "replayId": 2
    }
  },
  "channel": "/event/Cloud_News__e"
}

Das Schemafeld in der Ereignisnachricht enthält die ID des Plattformereignisschemas (in diesem Beispiel "schema":"_2DBiqh-utQNAjUH78FdbQ") Das Schema unterliegt der Versionierung, d. h., wenn sich das Schema ändert, ändert sich auch die Schema-ID.

Um zu bestimmen, ob sich das Schema eines Ereignisses geändert hat, rufen Sie das Schema über die REST-API ab. Nutzen Sie die Schema-ID zum Anwenden einer GET-Anforderung auf diese REST-API-Ressource: /vXX.X/event/eventSchema/Schema_ID. Alternativ können Sie das Ereignisschema abrufen, indem Sie für diesen Endpunkt den Ereignisnamen angeben: /vXX.X/sobjects/Platform_Event_Name__e/eventSchema. Weitere Informationen finden Sie im REST API Developer Guide.

Nachdem Sie erfahren haben, wie Plattformereignisse auf der Salesforce-Plattform und in externen Anwendungen verwendet werden, sind Ihre Möglichkeiten endlos! Nutzen Sie Plattformereignisse für eine beliebige Anzahl von Anwendungen und Integrationen, wie z.B. Geschäftstransaktionen oder Engagement in einem proaktiven Kundenservice. Mithilfe von Plattformereignissen können Sie ein ereignisbasiertes Programmierungsmodell übernehmen und in den Genuss der Vorteile einer ereignisbasierten Softwarearchitektur kommen.