Wählen der richtigen Suchlösung
Lernziele
Nachdem Sie diese Lektion abgeschlossen haben, sind Sie in der Lage, die folgenden Aufgaben auszuführen:
- Erläutern, wann eine angepasste Suchlösung erstellt werden sollte
- Beschreiben der Unterschiede zwischen SOSL und SOQL
- Angeben, welche API-Protokolle für die Suche verfügbar sind
Suchen nach Salesforce-Art
Wissen Sie, welche Salesforce-Funktion am meisten genutzt wird? Hätten Sie "Suchen" gesagt, hätten Sie recht. Mit der Suchfunktion sollen Benutzer den einen Datensatz, den sie brauchen, unter Tausenden anderer Datensätze finden.
In diesem Trailhead-Modul erfahren Sie, wie die Salesforce-Suche funktioniert und wie Sie bestimmen, ob eine benutzerdefinierte Suchlösung das Richtige für Sie ist. Sie erfahren weiterhin, wie Sie mithilfe der Salesforce-API für einige gängige Anwendungsfälle eine benutzerdefinierte Lösung erstellen (bzw. neu erstellen). Schließlich lernen Sie, wie Sie Suchabfragen für Ergebnisse optimieren, die zielgerichteter und relevanter sind. Sie machen sich also kurz gesagt umfassend mit der Suchfunktion und ihren Möglichkeiten vertraut, die Produktivität der Benutzer zu verbessern.
Lassen Sie uns zum Einstieg erörtern, wie diese Suche überhaupt funktioniert.
Alle Datensätze sind als Datenfelder in der Datenbank der Organisation gespeichert. Wenn Sie einen Datensatz erstellen oder aktualisieren, erstellt die Suchmaschine eine Kopie der Daten und untergliedert den Inhalt in kleinere Segmente, die Token genannt werden. Diese Token speichern wir zusammen mit einem Link zum ursprünglichen Datensatz im Suchindex.
Aus Sicht der Benutzer ist der Suchprozess vergleichbar mit dem Erstellen eines Datensatzes. Beim Eingeben eines Suchbegriffs in das Suchfeld (1) unterteilt die Suchmaschine den Suchbegriff in Token (2). Sie gleicht diese Token mit den Datensatzinformationen ab, die im Suchindex gespeichert sind (3), stuft die zugehörigen Datensätze nach Relevanz ein (4) und gibt die Ergebnisse zurück, auf die Benutzer Zugriff haben (5).
Lassen Sie uns einen Moment einen Blick auf den Suchindex werfen. Warum beschäftigen wir uns überhaupt mit dem Erstellen von Token, wenn wir die Organisationsdatenbank durchsuchen könnten? Der Grund dafür ist, dass der Suchindex über Superintelligenz hinsichtlich der Ergebnisse verfügt, die an den Benutzer zurückgegeben werden.
Der Suchindex und die Token ermöglichen der Suchmaschine das Arbeiten mit erweiterten Funktionen wie Rechtschreibkorrektur, Spitznamen, Lemmatisierung und Synonymgruppen. All dies bedeutet, dass wir Datensätze präsentieren können, bei denen Variationen des Suchbegriffs des Benutzers einbezogen werden, um das Ergebnisangebot zu erweitern. (Falls Sie sich wundern sollten, Lemmatisierung hat nichts mit flaumigen Lemmingen zu tun. Es geht vielmehr um das Bestimmen und Zurückgeben von Varianten des Suchbegriffs, wie z. B. hinzufügen, hinzufügend und hinzugefügt, in Suchergebnissen.)
Der Suchindex ermöglicht auch das Einführen einer Relevanzrangordnung in die Ergebnismenge. So geht die Suchfunktion beim Auffinden und Einstufen der Datensätze vor, die Benutzer suchen. Was ist dafür nötig? Nötig sind Dinge wie Suchbegriffhäufigkeit, Reihenfolge und Eindeutigkeit, Datensatzaktivität, Zugriffsberechtigungen und eine Handvoll anderer Faktoren.
Nehmen wir zum Veranschaulichen einen Vergleich. Eine Datenbanksuche nach bequeme Hausschuhe gibt nur Datensätze mit einer exakten Übereinstimmung mit "bequeme Hausschuhe" zurück. Ja, auch beim Arbeiten mit dem Suchindex werden Ihnen Datensätze mit bequeme Hausschuhe zurückgegeben. Sie bekommen aber auch Datensätze mit ähnlichen Begriffen wie bequem Hausschuhe oder bequemer Hausschuh (Singular) angezeigt. Angenommen, Sie haben Hausschuhe bequem eingegeben oder "bequem" falsch geschrieben (was vorkommen kann). Dank reihenfolgenunabhängiger Übereinstimmungssuche und Rechtschreibprüfung werden dennoch relevante Ergebnisse zurückgegeben. Und alle Ergebnisse werden danach sortiert, was für den jeweiligen Benutzer relevant ist, der die Suche ausgeführt hat.
Vielleicht fragen Sie sich gerade: Die Standardsuchfunktion von Salesforce hört sich toll an (was sie auch ist) und funktioniert für die meisten Anwendungsfälle. Wann brauche ich dann eine benutzerdefinierte Lösung?
Allgemein benötigen Sie eine benutzerdefinierte Suchlösung. wenn Ihre Organisation anstatt mit der Standardbenutzeroberfläche von Salesforce mit einer angepassten Benutzeroberfläche arbeitet. Beispiele solcher Benutzeroberflächen sind eine Knowledge Base für Kunden oder eine interne Produktdaten-Website für Ihre Mitarbeiter. Aber Vorsicht: Das Erstellen einer angepassten Benutzeroberfläche ist nicht für jeden etwas und ist mit zusätzlichem Aufwand verbunden. Die gute Nachricht ist, dass eine benutzerdefinierte Suche Ihnen weiter erlaubt, einige der erweiterten Funktionen der Salesforce-Suche zu nutzen. Wenn sich also Ihr Unternehmen entschieden hat, eine benutzerdefinierte Oberfläche zu erstellen, und eine benutzerdefinierte Suchfunktion benötigt, sind Sie bei diesem Modul richtig.
Lassen Sie uns nun nach dieser Kurzeinführung in die Salesforce-Suche über die APIs sprechen, mit deren Hilfe Sie in Ihrer benutzerdefinierten Suchlösung Datensätze finden.
Verbinden mit der Suchlösung mithilfe von APIs
Zunächst beschäftigen wir uns mit den beiden Haupt-APIs. (Auf zwei zusätzliche APIs kommen wir etwas später zu sprechen.)
- Salesforce Object Query Language (SOQL)
- Salesforce Object Search Language (SOSL)
Von SOQL und SOSL werden Textabfragen in einer angegebenen API formatiert. Doch hier hören die Gemeinsamkeiten schon auf. Eine SOQL-Abfrage entspricht einer SELECT SQL-Anweisung zum Durchsuchen der Organisationsdatenbank. SOSL ist dagegen eine programmgesteuerte Möglichkeit des Anwendens einer textbasierten Suche auf den Suchindex. SOSL nutzt alle die tollen, zuvor erwähnten Merkmale des Suchindexes.
SOQL und SOSL haben außerdem eine unterschiedliche Syntax. Im Abschnitt "Ressourcen" finden Sie Links zur Dokumentation für Entwickler, damit Sie dort nachschlagen können. Hier folgen jetzt jedoch einige großartige Leitlinien für die Nutzung von SOQL oder SOSL.
Wählen Sie SOQL, wenn Sie wissen, in welchen Objekten oder Feldern sich die Daten befinden und Sie Folgendes tun möchten:
- Daten aus einem einzelnen oder mehreren Objekten abrufen, die in Bezug zueinander stehen
- Die Anzahl der Datensätze zählen, die die angegebenen Kriterien erfüllen
- Ergebnisse als Teil der Abfrage sortieren
- Daten aus Zahlen-, Datums- oder Kontrollkästchenfeldern abrufen
Wählen Sie SOSL, wenn Sie nicht wissen, in welchem Objekt oder Feld sich die Daten befinden und Sie Folgendes tun möchten:
- Daten für einen bestimmten Begriff abrufen, der Ihres Wissens nach in einem Feld vorhanden ist. Da SOSL mehrere Begriffe in einem Feld in Token unterteilen und aus diesen einen Suchindex erstellen kann, sind SOSL-Suchen schneller und können relevantere Ergebnisse zurückgeben.
- Mehrere Objekte und Felder effizient abrufen, wobei die Objekte in Bezug zueinander stehen können oder nicht
- Mithilfe der Funktion "Geschäftsbereich" Daten für einen bestimmten Geschäftsbereich in einem Unternehmen so effizient wie möglich abrufen
Sehen wir uns nun zwei weitere API-Typen an.
Da wäre zuerst die API "Search Suggested Records". Vielleicht kennen Sie diese API bereits unter ihren Pseudonymen: automatischer Vorschlag, sofortige Ergebnisse oder Textvervollständigung. Sie sind damit bestimmt schon vertraut. Angenommen, Sie nutzen eine Website, auf der die coolsten Laufschuhe auf dem Markt angeboten werden. Die Website verwendet eine angepasste Salesforce-Suchlösung für ihre Knowledge Base, um eine lebendige Läufer-Community zu fördern. Sie möchten wissen, welche Schuhe Sie für den Querfeldeinlauf (engl. "trail running") kaufen. Sie beginnen mit der Eingabe von "trail running" in die Suchleiste, woraufhin Optionen für Artikel angezeigt werden, die die Suchbegriffe im Titel enthalten.
Das Suchfeld weiß genau, was Sie lesen möchten!
REST-Methoden des Typs "Search Suggested Records (Suche – Vorgeschlagene Datensätze)" und "Search Suggested Article Title Matches (Suche – Vorgeschlagene Übereinstimmungen von Artikeltiteln)" stehen Ihnen zur Verfügung, damit Ihre Benutzer bei ihren Suchen in den gleichen Genuss kommen. Wir zeigen Ihnen später, wie Sie mit diesen Methoden arbeiten.
Wir haben viel darüber geredet, wie Datensätze in Salesforce gefunden werden können. Doch was ist, wenn es außerhalb von Salesforce gespeicherte Datensätze gibt, auf die Benutzer für ihre Aufgaben zugreifen? Nun, auch hierfür haben wir eine Lösung: Wir nennen sie "verbundene Salesforce-Suche". Dies ist eine neue Möglichkeit für Benutzer, außerhalb von Salesforce nach gespeicherten Elementen zu suchen, ohne dabei Salesforce Classic, die Salesforce-Konsole oder Lightning Experience verlassen zu müssen.
Dank der verbundenen Salesforce-Suche können Sie aus dem Feld "Globale Suche" eine externe Suchmaschine machen. Nach Einrichtung der verbundenen Suche übertragen wir die Abfrage des Benutzers in die externe Suchmaschine, die die externen Quellen durchsucht. Die Ergebnisse werden direkt in den Salesforce-Suchergebnissen zurückgegeben. Dazu verwenden wir den Konnektor für die verbundene Salesforce-Suche. Der Konnektor basiert auf der OpenSearch-Spezifikation, weshalb Sie alle Suchmaschinen einbinden können, die diesem Branchenstandard entsprechen.
Wichtig ist der Hinweis, dass die verbundene Salesforce-Suche nicht den Salesforce-Suchindex durchforstet, was bedeutet, dass alle dessen coolen erweiterten Salesforce-Funktionen nicht zum Tragen kommen. Stattdessen werden Ergebnisse entsprechend dem externen Such-Provider zurückgegeben, was auch cool ist.
Als Nächstes sehen wir uns an, wie Protokolle zum Senden von SOSL- und SOQL-Abfragen verwendet werden.
Senden von Abfragen mithilfe von Protokollen
Sie können Ihre Suchabfragen so schön schreiben, wie Sie wollen. Sie sind nichts wert, wenn Sie kein API-Protokoll wie REST, SOAP oder Apex nutzen, um sie tatsächlich zu senden.
Bitte denken Sie daran, dass einige Protokolle mit einigen APIs besser zurecht kommen als mit anderen. Im Allgemeinen sprechen wir bei SOQL von Abfragen (query) und bei SOSL von Suchen (search).
- Query (REST) und query() (SOAP): Hiermit wird eine SOQL-Abfrage auf das angegebene Objekt angewendet und es werden Daten zurückgegeben, die mit den angegebenen Kriterien übereinstimmen.
- Search (REST) und search() (SOAP): Hiermit werden die Daten Ihrer Organisation von SOSL nach einer Textzeichenfolge durchsucht.
Es stehen noch weitere Ressourcen zur Verfügung, um andere gängige Suchaufgaben wie das automatische Vorschlagen von Datensätzen, Artikeln und Abfragen auszuführen. Wenn Sie lieber nicht mit SOSL oder SOQL arbeiten möchten, können Sie die parametrisierte Suche in REST erwägen. Anstelle einer Suchzeichenfolge verwenden Sie Parameter im URL (daher der Name).
Bei Apex können Sie SOQL oder SOSL direkt verwenden, indem Sie die Anweisung in eckige Klammern setzen. Sie können auch die Klasse "Search" für dynamische SOSL-Abfragen und den Namespace "Search" zum Abrufen von Such- und vorgeschlagenen Ergebnissen nutzen.
Im Abschnitt "Ressourcen" in dieser Lektion finden Sie eine praktische Liste. Außerdem bieten wir in der nächsten Lektion zum Einstieg eine Einführung in diese Protokolle. Sie sollten unbedingt die Informationen und Beispiele in der Entwicklerdokumentation lesen.
Ressourcen
- SOQL and SOSL Reference
- REST API Developer Guide
- SOAP API Developer Guide
- Apex Developer Guide
- Salesforce-Hilfe
- Federated Search Developer Guide