Back to List

How to Use Azure Search Services

Steven Nelson Steven Nelson  |  
Apr 10, 2018
Azure has a unique service offering aptly named “Azure Search”. This is a search-as-a-service cloud solution that lets you add a rich search service to your apps.
The search service abstracts the complexities of document retrieval through both a REST API and a .NET SDK. Imagine, if you will, the search engines of Google, Bing, Yahoo, etc. The Azure search service provides many of the same benefits and ease-of-use that these major search engines do. In addition to the API surface, the Azure portal contains all the management and administration you will need to control the indexes over your data.

Connect to any data sources and index out of your database

One of the cool features of the Azure Search service is that it can connect to any of your data sources and index data directly out of your database. The search service can connect to a view in your database, pull the results from the view, and create searchable documents out of the results. The data source can be an Azure SQL database, a SQL server on an azure VM, a Cosmos DB, Azure blob or Azure table storage.

Control field definitions

You can control the definition of the fields in the document. You can decide which fields you want to search over, which data type the field is (text, number, bool, timestamp, geography, or collections), which fields you want to use as sortable, and so on.

Built-in Search Explorer

There is a Search Explorer tool built into the Azure portal you can use to inspect the documents and verify that your search process worked correctly. The Search Explorer is accessible directly from the Azure portal within your search service.
Another side-benefit of this being an Azure service is that there is built-in support for DevOps PowerShell scripts that can be used for automation and deployment of your search services.  In a DevOps script you can create the service, define the index, connect to your database, and run the indexer from PowerShell. This makes it very easy to add to existing automated deployment processes.

Let’s dive in and look around

I’m going to create a search index of restaurants. The restaurant data contains the name and address of the restaurant, along with GPS latitude and longitude coordinates for mapping.
Once you find the “Search Services” on the Azure portal, it’s easy to create a new service by simply giving it a name and assigning it to a resource group (all standard stuff, and the same as all other Azure services).  
The magic comes from the Import Data wizard on the Search Service blade. Here is a screenshot:
import data wizard
In this wizard, you can specify the data source to connect to your data. In my case, I’m going to connect to a SQL Azure database. After you select the data source, it will allow you to pick a table, or view from the database to use for the search index.
sql azure database
Now the search service connects to the database and reads the schema from the table or view. In my case, I’m going to use a view because it aggregates different tables to select the columns I want to use in the search index.
The next screen is Customize Target Index. This is where you define the fields you want exposed from the search index and define what the fields can do. Here is what mine looks like:
custom target index
I’ve selected all fields from my view as Retrievable. I’ve set the Name, City, County and PostalCode fields as searchable. The Name and PostalCode are also marked as sortable so I can allow the results to be ordered by either of these fields.
With this configuration, I have a search index where the user can find restaurants by name, postal code, city, or county. With search criteria of “apple”, this will look for restaurants with a name that contains the word “apple”, a city or county that contains the word “apple”, or a zip code as well (but that won’t have results because the zip codes are standard U.S. numeric zip codes).
The final step, called Import Your Data, lets you define an indexer that can run periodically and update the documents in the index. The indexer can be run on a schedule, on-demand, or via code. When the indexer runs, it will connect to your database and update the documents in your search index.

Using the Azure Search SDK in .NET

From the .NET side, when you want to run queries against your search index to retrieve documents, you use the Nuget package Microsoft.Azure.Search (version 3.0.5 is current at this time).
With that package dependency installed, you use the SearchIndexClient object to form queries to fetch documents. Here is an example of what the code looks like:
search index client
Line 31 is where the search is performed using whatever searchString is provided. This will have the effect of querying the search index for any restaurant where the name, city, county or postal code contains the search string. It will match if the search string is anywhere in the field. If I search on the searchTerm of ‘taco’, then I get the following results:
search string term
Notice that most of the hits are on the Name field, but there is one ‘Hamburger Hut’ in the city of ‘Taconite’. Notice that the city of ‘Taconite’ contains the phrase ‘taco’ in it. Nice!


This is just the tip of the iceberg on the Azure Search Service. There is an extensive query language you can use, as well as a REST API to execute queries if .NET isn’t your thing. 
Keep in mind that if the data is changing, then the indexer needs to be run so that changes are reflected in the index. The indexer can be run on a schedule, be invoked programmatically, run via PowerShell, or run manually from the Azure portal.
Now, go visit Taconite, Minnesota to find the fictional Hamburger Hut and create your own Azure Search Service!

Where to Learn More

General info on Azure Search:
Azure Search Explorer:
How to get started with Azure PowerShell:
Azure.Net Programming


Love our Blogs?

Sign up to get notified of new Skyline posts.


Related Content

Blog Article
Traditional vs. Cloud Assets for Your Business Continuity Plan
Skyline Technologies  |  
Mar 12, 2019
Let's consider how we have historically implemented IT assets to satisfy our business continuity plan.   Traditional Cold Site A traditional cold site is in a second owned or rented location. It’s typically not as nice as the primary site, and it's often at your business...
Blog Article
Essential Business Continuity Terms Your Business Should Know
Skyline Technologies  |  
Feb 26, 2019
A strong business continuity plan is something we all want for our organizations. We get and set our requirements with the business for what this is going to look like, and then we work to build a budget and a design to ensure that we're meeting our business continuity strategy. Unfortunately...
Blog Article
Async, Await, and ConfigureAwait – Oh My!
Dan LorenzDan Lorenz  |  
Dec 11, 2018
In .NET Framework 4.5, async/await keywords were added to the language to make async programming easier to work with. In order to maximize device resources and not block UI, you should really try to use asynchronous programming wherever you can. While async/await has made this much easier than...
Blog Article
How to Protect PHI Data by Limiting External Access to Power BI
Paul FullerPaul Fuller  |  
Nov 06, 2018
It was a second-latte-kind-of-day for health claims processor, Jane. Unknowingly, as she was waiting for the barista to work his magic, Nosy Pete looked over at her laptop screen five feet away and saw that his second cousin’s brother-in-law’s nephew’s ex-girlfriend’s...
Blog Article
Utilizing Azure Regions
Tyler StelzerTyler Stelzer  |  
May 08, 2018
Often when people hear Azure, they think “cloud”. But they should be thinking “clouds”. Azure has datacenters across the world that can be thought of as independent clouds. This gives organizations multiple options when determining the best utilization of a cloud-based...