Implement Your First Azure AI Search Solution

You should already be logged into the Azure portal, using the credentials provided with the lab. When you first log in to the Azure Portal, you will land on the overview page for the resource group already deployed for you. Note the location/region for the resource group.

Using the Azure portal, create an Azure AI Search service with the following configuration:

• Create the service in the existing resource group, and in the same location as that resource group.
• Use any valid name you choose.
• Create the service in the Basic pricing tier. Do not choose the Free tier, as only one is allowed per subscription, and your lab environment is on a shared subscription with other students.

Navigate to the newly deployed Azure AI Search service, and on the "Overview" page, select "Import Data."

• Import from the existing "Samples" provided by Microsoft and choose the Cosmos DB dataset called "hotels-sample."
• Skip the option to add cognitive skills
• Customize the target index by applying the suggester to the HotelName field (the suggester will already be named for you).
• Take note of the other features enabled for each field, such as which ones can be used for sorting, filtering, and so on. Do not change any of the settings other than the HotelName field. If you do, a change may impact the expected outcomes of the search query examples you run in the next objective of this lab.
• Create the indexer, leaving all defaults in place.
• When the indexer run is complete, navigate to the indexer to view the execution history metrics and to get a look at how the indexer is expressed in JSON.
• Navigate to the index populated by the indexer and note the number of JSON documents created and the storage size. There should be about 50 documents, each containing the data related to a single hotel.

Tip: If the Index Shows No Documents

• If there are no documents, make sure the indexer has completed running. You can also perform quick query by putting an asterisk (*) in the search bar and running the query. If the query returns documents, the UI just hasn't caught up with the underlying data statistics; you can proceed with the next objective.

To complete this objective, you should have have already navigated to the index you populated in the last objective; this screen includes the Search Explorer.

Important Notes

• Keep in mind that the Search Explorer is not designed to mimic the end user's search experience. All but the first couple of queries will require specialized OData syntax embedded in JSON, and the results will be returned in JSON. This tool is designed for app developers to test an index, using the syntax that will be used programmatically — which will not often look like what the user enters on the app user interface.

• Select the "Fields" tab to get the names of the index fields and their configurations for your use in queries. Note, in particular, that Address is a complex type. If you want to refer to the City field in your query results, use this form: Address/City.

• In the JSON results, you can use the browse bar on the right to quickly jump to a document or JSON block, as an alternative to scrolling through results.

• IMPORTANT: Use the "View" control to swap to the JSON query editor, before constructing the suggested queries, below.

• ABOUT QUOTES AND COMMAS: Note the example in the query editor pane; in well-formed JSON, both the key ("search") and the value ("*") must be wrapped on double-quotes. Then, within those double-quotes required by JSON, in the OData sytax used for the query solutions, references to field names in the source data do not quotes, but strings will require either single-quotes or double-quotes — the latter of which you will need to escape with back slashes. Additionally, each key-value pair is separated by a comma. For example:

   {
    "myKey": "SomeField eq 'some thing'",      <-This is OData syntax, using single quotes
    "anotherKey": "\"some thing\"",           <-This will search only the entire phrase
    "anotherKey": "some thing"                <-This will search for "some" OR "thing"
   }
  

Use the Search Explorer to construct queries that return the following results:

1. All fields for all documents. Returns: The same number of documents as indicated near the top of the screen, probably about 50.
2. A search for the phrase 'Santa Fe' wrapped in escaped double-quotes. Returns: All fields for one hotel, located in Nashville, called "Santa Fe Stay."
3. A search for Santa Fe — without quotes (except for the double-quotes required for a valid JSON string value). Returns: All fields for two hotels, one called "Santa Fe Stay" and one located in Santa Clara, CA.
4. A filtered search of all hotels located in the city of Santa Fe. Returns: No documents. There are no hotels in the index located in Santa Fe.
5. A filtered search for a hotel name of Santa Fe Stay. Returns: An error. Check in the "Fields" tab to note that HotelName is not a filterable field.
6. A filtered search of all hotels located in the city of Redmond. Returns: All fields for two documents.
7. A filtered search of all hotels located in the city of Redmond, but only returning the hotel name, city, and description. Returns: The same two documents from the prior search, but with only the three fields indicated.

Query Solutions

Sample syntax for each of the queries is provided in the Additional Information and Resources section of the lab.

Optional

Choose "Create a Demo App" to see an example of how the index might be integrated into your own applications. You might recall the "suggester" setting you worked with in the prior objective; the demo app allows you to see how the type-ahead feature works for fields where you applied that setting. In particular, try searching on one of the cities or hotel names you worked with in the Search Explorer. Note that there are no thumbnail images in the sample data for this lab, so skip that field.