適切な検索ソリューションの選択
学習の目的
この単元を完了すると、次のことができるようになります。
- どのような場合にカスタマイズした検索ソリューションを作成するかを説明する。
- SOSL と SOQL の相違点を説明する。
- 検索に使用できる API プロトコルを特定する。
Salesforce 方式での検索
最もよく使用される Salesforce 機能は何か知っていますか? Chatter に猫の写真を投稿することではありませんよ。
そう、検索です。何千件ものデータの中から 1 つのレコードを見つける方法がほかにあるでしょうか? 閲覧ですって? そんな時間がある人はいないでしょう。
時間と言えば、この Trailhead モジュールを学習しているのは賢い時間の使い方です。ここでは、Salesforce 検索のしくみの概要と、カスタム検索ソリューションが適しているかどうかを判断する方法について学習します。また、いくつかの一般的な使用事例について、Salesforce API を使用してカスタムソリューションを作成 (または再作成) する方法についても学習します。最後に、検索クエリを最適化して、より絞り込んだ関連性の高い結果を得る方法について学習します。つまり、このモジュールを修了すると、検索と、それがユーザの生産性向上にどのように役立つかについて、理解を深めることができます。
まず始めに、検索全体のしくみについて説明します。
すべてのレコードは、組織のデータベース内にデータ項目として保存されています。レコードを更新または作成すると、検索エンジンが連動してデータのコピーを作成し、コンテンツをトークンと呼ばれる小さな要素に分割します。これらのトークンは、元のレコードへのリンクと共に検索インデックスに保存されます。
ユーザの観点から見ると、検索プロセスはレコードが作成されるときと似ています。ユーザが検索項目に検索語を入力すると (1)、検索エンジンが検索語をトークンに分割します (2)。そして、それらのトークンを検索インデックスに保存されているレコード情報と照合し (3)、関連するレコードを関連性によってランク付けし (4)、ユーザがアクセスできる結果を返します (5)。
ここで、検索インデックスについて考えてみましょう。組織のデータベースを検索できるのに、なぜわざわざトークンを作成するのでしょう。それは、検索エンジンには凄い力があるからです。世界を乗っ取るような力ではありませんが、インデックスがどの結果をユーザに返すかを非常にスマートに決定するには十分な力です。
検索インデックスとトークンを使用することによって、検索エンジンは、スペル修正、ニックネーム、見出語化、シノニムグループなどの高度な機能を適用することができます。これらの機能を使用することで、ユーザの検索語のバリエーションが含まれるレコードも表示して、検索結果の幅を広げることができます。(ところで、見出語化 (lemmatization) は、ふわふわした動物のレミング (lemming) とは何の関係もありません。見出語化とは、検索結果内の検索語のバリエーション (add、adding、added など) を識別して返すことです。)
また、検索インデックスによって、関連性ランキングを導入することができます。これが、ユーザが探しているレコードを見つけて順位を付けるための秘伝のタレです。そのタレの特別な材料は、検索語の頻度、順序、ユニーク性をひとつまみ、レコードアクティビティを少々、アクセス権限を 1 さじ、その他の要素をひとつかみです。おいしそうですね。
比較してみましょう。「bunny slippers (ウサギのスリッパ)」のデータベース検索では、「bunny slippers」に正確に一致するレコードのみが返されます。基本的な「検索」機能で、特に驚くようなことはありません。一方、検索インデックスを使用すれば、「bunny slippers」を含むレコードも得られますが、それだけではなく、「rabbit slippers」や「bunny slipper」(単数形) などの類似する語句を含むレコードも表示されます。さらに、「slippers bunny」と入力したり、bunny のスペルを間違えたとしましょう (そういうことも起こり得ます)。その場合も、順不同一致とスペルチェックによって、関連する結果が表示されます。そして、すべての結果は、検索を実行した個々のユーザへの関連性の順に表示されます。画期的ですよね?
こんなふうに思われているかもしれません。「Salesforce の標準検索は優れているように思える (実際にそうです) し、ほとんどの使用事例でうまくいくのに、なぜカスタムソリューションが必要になるのだろう?」
一般的には、カスタム検索ソリューションが必要になるのは、組織で標準の Salesforce UI の代わりにカスタム UI が使用されている場合です。自家製 UI の例は、顧客向けの知識ベースや従業員向けの社内商品データサイトなどです。ただし、カスタムユーザインターフェースの構築は、誰にでも適したものではなく、追加作業が必要です。幸いにも、カスタム検索を使用すれば、Salesforce 検索の高度な機能の一部を利用できます。ですから、会社がカスタム UI を構築することを決定し、カスタム検索が必要な場合は、このモジュールを学習してください。
Salesforce 検索の基礎を説明したので、次はカスタム検索ソリューションでレコードを見つけるための API について説明します。
API を使用した検索への接続
2 つの主な API について覚えておく必要があります。あと 2 つあるおまけの APIについては後ほど説明します。その 2 つは、食事で出される無料の付け合わせのようなものです。
- Salesforce Object Query Language (SOQL)
- Salesforce Object Search Language (SOSL)
SOQL と SOSL の両者とも、指定された API 内でテキストクエリの形式を設定するものですが、似ているのはそこまでです。SOQL クエリは、SQL の SELECT ステートメントと同等で、組織のデータベースを検索します。一方、SOSL は、プログラムによって検索インデックスに対するテキストベースの検索を実行する方法です。SOSL では、前述した検索インデックスの優れた機能をすべて使用します。
SOQL と SOSL は構文も異なります。「リソース」セクションに、開発者向けドキュメントへのリンクがあります。今はそれについて心配する必要はありませんが、参照用に知っておくと後で便利です。そう、新しいウサギのスリッパを履いて、夜更けに API について読みたい場合などです。
概要は説明したので、次に、どのような場合に SOQL と SOSL のどちらを使用するかについて、ガイドラインを示します。
データがどのオブジェクトまたは項目に存在しているかがわかっていて、次のことを実行したい場合は、SOQL を使用します。
- 1 つのオブジェクトまたは互いに関連付けられている複数のオブジェクトからデータを取得する。
- 指定した条件を満たすレコード数を数える。
- クエリの一部として結果を並び替える。
- 数値、日付、またはチェックボックス項目からデータを取得する。
データがどのオブジェクトまたは項目に存在しているかが不明で、次のことを実行したい場合は、SOSL を使用します。
- 項目内に存在することがわかっている、特定の語のデータを取得する。SOSL は 1 つの項目内の複数の語をトークン化してそこから検索インデックスを構築できるので、SOSL 検索ではより高速でより多くの関連する結果を返すことができます。
- 相互に関連している、または関連していない複数のオブジェクトおよび項目を効率的に取得する。
- ディビジョン機能を使用して、組織の特定のディビジョンのデータを最も効率的な方法で取得する。
あと 2 つ、API 種別があると言ったのを覚えていますか? 嘘ではありません。まずは、推奨レコード API をご紹介します。別の名前で推奨レコードをすでにご存知かもしれません。自動推奨、インスタント結果、先行入力などです。
その動作にも馴染みがあるでしょう。最高に格好良いランニングシューズを販売している Web サイトを使用しているとします。そのサイトでは、ランナーのコミュニティを促進するために、知識ベースにカスタマイズされた Salesforce 検索ソリューションが使用されています。この Trailhead モジュール以外に最近熱中しているトレイルランニング用に、どの靴を購入すべきか知りたいとあなたは思っています。検索バーに「trail running (トレイルランニング)」と入力し始めると、タイトルに検索語を含む記事の選択肢が表示されます。
検索ボックスは、あなたが何を読みたいか正確に知っていました!
Search Suggested Records および Search Suggested Articles REST メソッドを使用すれば、これと同じようにユーザを即座に満足させることができます。これらのメソッドの使用方法については後ほど詳しく説明します。
Salesforce 内でレコードを検索する方法について説明してきましたが、ユーザが業務のためにアクセスするレコードが Salesforce の外部に保存されている場合はどうなるでしょうか? もちろんソリューションは用意されています。Salesforce 統合検索を紹介しましょう。これは、ユーザが Salesforce の外部に保存された項目を検索するための新しい方法で、最大の特長は、Salesforce Classic、Salesforce コンソール、または Lightning Experience に留まったままで実行できることです。それだけではありません。
Salesforce 統合検索を使用すれば、グローバル検索ボックスが外部検索エンジンになります。Salesforce 統合検索が設定されていると、ユーザのクエリは外部エンジンに転送され、そこで外部ソースが検索されます。結果は、Salesforce 検索結果に直接返されます。この機能は、Salesforce 統合検索コネクタを通じて実現されます。コネクタは OpenSearch 仕様を用いて構築されているため、この業界標準に準拠する任意の検索エンジンに接続できます。
Salesforce 統合検索では、Salesforce 検索インデックスが使用されないため、Salesforce のさまざまな便利で高度な機能は適用されないことに留意してください。代わりに、結果は外部検索プロバイダに従って返されます。それもまた便利ですね。
次に、プロトコルを使用して SOSL クエリと SOQL クエリを送信する方法について学習しましょう。検索の達人に休んでいる暇はありません。
プロトコルを使用したクエリの送信
いくら素晴らしい検索クエリを書いたとしても、REST、SOAP、Apex といった API プロトコルを使用して実際に送信しなければ何の役にも立ちません。それは、ラブレターを書いて、自分の机の上に置いたままにしておくようなものです(ため息)。なんともったいないことでしょう。
友達グループなどと同じように、プロトコルと API には相性があります。ここでは全般的に、SOQL によるクエリと SOSL による検索について説明します。
- Query (REST) および query() (SOAP) — 指定されたオブジェクトに対して SOQL クエリを実行し、指定された条件に一致するデータを返します。
- Search (REST) および search() (SOAP) — 組織のデータに対して SOSL テキスト文字列検索を実行します。
レコード、記事、クエリの自動推奨など、その他の一般的な検索タスクを実行するリソースも使用できます。そして、SOSL や SOQL を使用したくない場合は、REST で Parameterized Search を使用することを検討します。その場合、URL 内で検索文字列を使用する代わりに、URL 内でパラメータ (名前はここから来ています) を使用します。
Apex では、ステートメントを角括弧で囲んで、SOQL または SOSL をその場で使用できます。また、Search クラスを使用して動的 SOSL クエリを実行したり、Search 名前空間を使用して検索結果や推奨結果を取得したりできます。
「リソース」セクションに、便利なリストがあります。さらに、次の単元では、作業を開始できるように、プロトコルの使用方法についての概要を説明します。開発者用ドキュメントをよく読んで、すべての情報や例について把握してください。ただし、今すぐではありません。今は、テストを受けましょう!
