Erfassen Sie Ihre Fortschritte
Trailhead-Startseite
Trailhead-Startseite

Abfragen von Ereignisprotokolldateien

Lernziele

Nachdem Sie diese Lektion abgeschlossen haben, sind Sie in der Lage, die folgenden Aufgaben auszuführen:
  • Sicherstellen, dass Sie über die richtigen Berechtigungen für die Ereignisüberwachung verfügen
  • Anmelden bei Workbench und Navigieren zu verschiedenen Workbench-Tools
  • Abfragen eines "EventLogFile"-Objekts mit dem Abfrage-Editor SOQL und dem REST Explorer
  • Vergleichen und Gegenüberstellen der SOAP- und REST-APIs zum Abfragen von Ereignisprotokolldateien
  • Beschreiben des Datentyps, der zum Speichern der zugrunde liegenden Protokolldaten verwendet wird

Abfragen von Ereignisprotokolldateien in Workbench

Betrachten wir einen der bereits beschriebenen Beispielfälle. Ein Vertriebsmitarbeiter namens Rob Burgle hat vor ein paar Wochen von Ihrem Unternehmen zu einem Ihrer wichtigsten Mitbewerber gewechselt. Und plötzlich verlieren Sie Geschäfte an diesen Konkurrenten. Sie haben den Verdacht, dass Rob Burgle einen Bericht mit vertraulichen Leadinformationen heruntergeladen und seinem neuen Arbeitgeber offengelegt hat. Im Normalfall lässt sich ein solcher Verdacht nicht belegen. Dank der Ereignisüberwachung können Sie jedoch alle notwendigen Beweise zusammentragen, um den Verdacht zu belegen. Dies sehen wir uns im Folgenden genauer an.

Prüfen Sie bitte zuvor, dass Sie über die erforderlichen Berechtigungen für die Abfrage von Ereignisprotokolldateien verfügen. Für die Ereignisüberwachung sind die Berechtigungen "API aktiviert” und “Ereignisprotokolldateien anzeigen” erforderlich.
Hinweis

Hinweis

In Developer Edition-Organisationen ist das Shield Event Monitoring kostenlos verfügbar. Für alle anderen Editionen ist der Kauf einer Lizenz erforderlich.

Jetzt kann es losgehen. Der Schritt unserer Untersuchung besteht in der Anmeldung bei Workbench.
  1. Melden Sie sich bei Ihrer Developer Edition-Organisation für Trailhead an und navigieren Sie zu Workbench.
  2. Wählen Sie als Umgebung Production (Produktion) aus. Wählen Sie als API-Version die höchste verfügbare Versionsnummer aus. Aktivieren Sie unbedingt das Kontrollkästchen I agree to the terms of service (Ich akzeptiere die Servicebedingungen).
  3. Klicken Sie auf Login with Salesforce (Mit Salesforce-Daten anmelden).
Daraufhin wird die Workbench-Startseite angezeigt. In diesem Modul werden nicht alle Funktionen des Tools beschrieben, sondern die Teile behandelt, die für die Ereignisüberwachung hilfreich sind. Als erstes verwenden wir den Abfrage-Editor SOQL, damit Sie ein paar Daten zur Verfügung stehen.
  1. Wählen Sie im oberen Menü queries | SOQL Query (Abfragen -> SOQL Query) aus.
  2. Wählen Sie unter "Object" (Objekt) den Eintrag EventLogFile aus. Unter "Fields" (Felder) wählen Sie count() aus. Wie Sie sehen, wird Abfragetext in den Editor eingetragen.
  3. Klicken Sie auf Query (Abfragen).

Die Anzeige sollte etwa wie folgt aussehen:

Die Funktion ‘count()‘ im Abfrageeditor ‘SOQL‘

Die Funktion count() gibt zurück, wie viele EventLogFile-Datensätze in Ihrer Organisation vorhanden sind. Lautet die Antwort "Query would return 0 records" (Abfrage ergibt 0 Datensätze) bedeutet dies, dass keine gespeicherten Ereignisse vorliegen. Vergessen Sie nicht, dass es 24 Stunden dauert, bis Ereignisse erfasst werden, und die Protokolldateien in Developer Edition-Organisationen nur 24 Stunden gespeichert werden. Falls Ihre Abfrage keine Datensätze zurückgeben würde, versuchen Sie es einfach morgen noch einmal.

Was genau wird im Objekt EventLogFile gespeichert? Das finden wir mithilfe der so genannten Objektbeschreibung heraus:
  1. Wählen Sie im oberen Menü info | Standard & Custom Objects (Info -> Standard- & benutzerdefinierte Objekte) aus.
  2. Wählen Sie im Dropdown-Menü den Eintrag EventLogFile aus.
  3. Erweitern Sie das Menü Attributes (Attribute), um die Objekteigenschaften anzuzeigen. Das Objekt EventLogFile ist abfragbar, das heißt, Sie können Informationen über das Objekt von der Datenbank anfordern. Außerdem ist es abrufbar, was bedeutet, dass Sie einen EventLogFile-Datensatz anhand seiner ID suchen können.
  4. Erweitern Sie das Menü Fields (Felder). Von den 17 verfügbaren Feldern interessieren uns die beiden folgenden ganz besonders: EventType und LogFile.
    • EventType: Dieses Feld zeigt an, welchen der Ereignistypen ein Datensatz repräsentiert. Wenn Sie EventType | Picklist Values (EventType -> Auswahllistenwerte) erweitern, werden die unterschiedlichen Ereignistypen angezeigt. In unserem Fall interessieren uns Datensätze mit dem Ereignistyp "Report Export".
    • LogFile: In diesem Feld werden die konkreten Informationen gespeichert, die Sie suchen. Der Inhalt einer Protokolldatei hängt vom EventType ab. Bei "Report Export" speichert dieses Feld alles von der ID des Benutzers, der den Bericht in den Browser exportiert hat bis hin zum Betriebssystem, das dazu verwendet wurde.

Wir sind dem Bösewicht dicht auf den Fersen! Sammeln wir noch weitere Beweise mit einem weiteren Tool in Workbench, dem REST Explorer.

Anzeigen von Ereignissen im REST Explorer

Der REST Explorer gibt Ihnen Zugriff auf die Salesforce REST-API, einen Webservice, mit dem Sie Daten aus Ihrer Organisation abrufen können.

So erhalten Sie weitere Informationen über die "Report Export"-Ereignisse Ihrer Organisation in Workbench:
  1. Wählen Sie im oberen Menü utilities | REST Explorer (Dienstprogramme - REST Explorer) aus.
  2. Ersetzen Sie den vorhandenen Text durch /services/data/v<APIversion>.0/query?q=SELECT+Id+,+EventType+,+LogDate+,+LogFileLength+,+LogFile+FROM+EventLogFile+ WHERE+EventType+=+'ReportExport', wobei <APIversion> die von Ihnen verwendete API-Version ist, z. B. 46.
  3. Klicken Sie auf Execute (Ausführen).

Wenn in den letzten 24 Stunden keine Berichte aus Ihrer Organisation exportiert wurden, hat das Feld totalSize den Wert Null. Bedenken Sie, dass es 24 Stunden dauert, bis Ereignisse verfügbar werden. Sie können einen Bericht aus Ihrer Organisation exportieren und es morgen erneut versuchen. Alternativ können Sie ReportExport in Ihrer REST-Abfrage durch einen anderen Ereignistyp ersetzen (z. B. Login).

Wenn Berichtsexport-Ereignisse vorliegen, erhalten Sie bei der Ausführung der Abfrage etwa Folgendes:

Die Datensätze, die die REST-Abfrage zurückgibt.

Erweitern Sie einen der Datensätze und klicken Sie auf den Link LogFile. Der Protokollinhalt sollte in etwa wie folgt aussehen:

Die Ereignisprotokolldatei zu einem der zurückgegebenen Datensätze

Na toll! Wie soll man denn daraus schlau werden? Keine Sorge – wir sind noch nicht ganz fertig.

Vergleichen der Abfragemethoden für die Ereignisüberwachung

Sie haben nun verschiedene Tools in Workbench verwendet. Zuerst haben Sie mit dem Abfrageeditor SOQL festgestellt, ob überhaupt Ereignisse in Ihrer Organisation gespeichert sind. Außerdem haben Sie die Objektbeschreibung abgerufen, um mehr über das Objekt "EventLogFile" zu erfahren. Zum Schluss haben Sie den REST Explorer verwendet, um Ihre EventLogFile-Datensätze anzuzeigen. Alle diese Tools rufen Informationen aus Ihrer Organisation ab – worin unterscheiden sie sich also?

Die Antwort wird Sie nicht sehr überraschen: Der Unterschied besteht in der zugrunde liegenden API.

Der Abfrageeditor SOQL und die Objektbeschreibung verwenden die so genannte SOAP-API. Sie unterscheidet sich etwas von der REST-API, die Sie im REST Explorer verwendet haben. Ein Unterschied besteht darin, dass das Schreiben einer Abfrage im Abfrageeditor SOQL einfacher als im REST Explorer ist. Angenommen, Sie möchten eine unserer Protokolldateien abrufen.

In SOAP sieht dies wie folgt aus:

Eine einfache Abfrage im SOQL-Abfrageeditor mit der SOAP-API

In REST verwenden wir dazu:

Eine komplexere Abfrage im REST Explorer unter Verwendung der REST-API

Die SOQL-Abfrage ist leichter verständlich. Warum haben wir also stattdessen für REST entschieden? Schauen wir uns an, was passiert, wenn wir diese Abfragen ausführen und eine der Protokolldateien anzeigen.

In SOAP gibt die Abfrage etwa Folgendes zurück:

Die unleserliche Protokolldatei aus der SOQL-Abfrage

So sieht das Ergebnis der REST-Abfrage aus:

Die etwas weniger unleserliche Protokolldatei aus der REST-Abfrage

Hier sehen wir den anderen wichtigen Unterschied zwischen SOAP und REST beim Abfragen von Ereignisprotokolldateien. Die zurückgegebenen Protokolldateien sind dieselben, sie werden jedoch in unterschiedlichen Formaten dargestellt. Beim Abrufen der Ereignisprotokolldateien mit SOAP ist das Ergebnis eine serialisierte Base64-Zeichenfolge. Wenn Ihre Organisation plant, Tools wie MuleSoft oder Informatica für die Arbeit mit Ereignisprotokolldateien zu verwenden, sollten Sie die Daten mit SOAP abrufen. REST dagegen deserialisiert die Protokolldatei. Das Ergebnis ist noch immer nicht perfekt, doch wie Sie im nächsten Abschnitt erfahren werden, können andere Tools das REST-Ergebnis in ein gut lesbares Format umwandeln.