Azure search

TRAINING CONTENT
Introduction
Creating search services
Azure Search Concepts
Creating Azure Search Indexes
Managing Documents
Azure Search Queries
Filtering and Scoring Search Results
Navigating Search Results
Demo

INTRODUCTION
Azure Search is a search-as-a-service cloud solution that gives developers API and
tools for adding a rich search experience in application.
There are some important features of Azure search which is as follows:
1. Scalability
2. Query abilities
3. Scoring profiles
4. Search Navigation

INTRODUCTION
1. Scalability : We can easily scale-up and scale down azure search service based on requirement. Scalability can
be done manually by azure portal or programmatically using azure search management API.
2. Query abilities : Azure search following features for query processing:
a) Natural language processing: This features helps to understand query used for search.
NLP helps to understand the variations of term given for search. For ex if try to search term “GO”. It will
not only search for occurrence for “GO” in text. It will also provide result having “Went” in text because
“Went” is variations of “GO”.
a) Search Recommendations: This feature provided search suggestions so that user can jump to the result
fast.
b) Geosearch Support: We can search items in a particular geographical area using this feature. For ex. We
can search hotels with five kms for a particular point.
c) Scoring profiles: This feature helps to find most relevant search result.
3. Search Navigation : This feature provides different options to navigate search result:
a) Faceted Navigation: It provides categories along with search result which helps to narrow down search.
b) Paging: Azure search provides facility to divide results in smaller chunks in form of pages.
c) Hit Highlighting: This provides facility to highlight relevant text in search result.

CREATE AZURE SEARCH
Following steps are required to create Azure Search:
1. Go to portal.Azure.com
2. Go to New->Data+Storage+Azure Search

CREATE AZURE SEARCH
3. Fill the fields e.g. Service Name, Subscription, Resource Group, Pricing Tier and
location.
Note: Azure search service Name should follow the naming convention
For ex: Organization-application-location-Environment.

AZURE SEARCH CONCEPTS
There are two important components of Azure Search:
1. Search Indexes : It is similar as table in relational database. It is highly optimized
for search. User search query is broken down in terms and compared to records
in indexes.
2. Search Document.

CREATING AZURE SEARCH INDEXES
There are two ways to create Azure Search Index:
1. Using Portal.azure.com
2. Using Azure search management API
There are two properties of Index:
Name: It is used to declare name for Azure search. This property will be used
to identify Azure index while working with Azure management API.
Name of index should be between 2 and 200 characters.
Dashes, numbers and lowercase letters can be used only declare index name.

Fields: It described the data stored in the indexes. It is similar as column definition in
relational table. Each search index may contain maximum 1000 fields. Each field
name must have name and data type. One field must be marked as Key.
Following steps are required to create search index at design time:
1. Go to portal.azure.com
2. Navigate to search service using Browse and filter search service name.
3. Click on search service.
4. Click on Add index.
5. Provide index Name.
6. Click on fields tab to create fields.

7. Provides field name and data type using following screen:

Some of the important points to consider while creating fields:
1. One of the default field “id” is added automatically. It will be used as key.
2. There are eight types of data is supported for creating fields.
3. There is collection(Edm.string) data type is provided in which we can store list of string
up to 16 Mb.
4. Data type (Edm.geographypoint) is used to store location in form of longitude and
latitude.
5. Retrieval property of field can be used to enable field to return data as result of search
query. By default value of this property id False.
6. Searchable property enable field to be full text searchable. By default the value of this
property is False. We can only enable this property for field having data type Edm.String
and Collection(Edm.string). We should be careful to used this property. After enabling
this property indexes takes more space in storage.

7. We can use Natural language abilities of Azure search by configuring Analyzer
settings.
8. It is used when we use property “Searchable”.
9. We can configure Analyzer option by using following screen shot

We can create Azure search index using Azure Search API. The following post
request can be used to create New Azure search index.
We have to add API key in header to execute query. We can get API key from
management portal.

UPDATING AZURE SEARCH INDEXES
We can update Azure search index using PUT request to Azure search API.
For ex. We can add other fields in Azure search index by using following request to
Azure search API:

UPDATING AZURE SEARCH INDEXES
Some of the important points to be considered while updating Azure search index:
1. We have to supply the existing field name along with new fields in body of PUT
request.
2. We can not rename fields while updating Azure Search Index.
3. We can not change field types while updating Azure Search Index.
4. We can not remove field while updating Azure Search Index.
5. To change or remove field in Azure Search Index following actions are required:
a. Remove Search Index
b. Re-Create the Search Index.
c. Repopulate the documents.

SHARING AZURE SEARCH INDEXES
We can share Azure search indexes to different application. To enable this feature we
have to CORS origin policy. Application hosted in different domain can not use the
search service without configuring CORS.
1. CORS options specifies which domains a search index can accept request from.
2. This option is only required when search experience is used by client side java
script.
3. We can configure this option using Azure search API by using following request:

SHARING AZURE SEARCH INDEXES
We can change allowed origins to “*” in development stage. It is not recommended
to use “*” in production environment.

LISTING AZURE SEARCH INDEXES
We can get list of Azure Search Indexes using Azure Search API (GET) Request.
Sample request is as follows:

RETRIEVING AZURE SEARCH INDEX
We can get a particular Azure Search Index using Azure Search API (GET) Request
with index name. Sample request is as follows:

REMOVING AZURE SEARCH INDEX
We can delete Azure Search Index by sending Delete request to Azure Search API.
Please find sample request as follows:

DOCUMENT INTRODUCTION
Document represents record of index. Data for index is also known as document. It
can be created by push or pull model.
Pull Model: The pull model retrieves data from external data sources. It is supported
through indexers that streamline and automate aspects of data ingestion, such as
connecting to, reading, and serializing data. Indexers are available for Azure cosmo
DB, Azure SQL Database, Azure blob storage and SQL server hosted in Azure VM. We
can configure indexer for on demand on scheduled data refresh.
Push Model : The push model is provided through the SDK or REST APIs, used for
sending updated documents to and index. We can push data from virtually any
dataset using the JSON format.

UPLOAD DOCUMENT
We can create document using Azure search management API. We can use following
request to search management API to create document.

UPLOAD DOCUMENT
Important points:
1. We have to use POST request to upload document.
2. API key is required in request header for this request.
3. Request body can contain array of documents. The maximum value for documents in
request is 1000.
4. There is one of the property used in value of document which is “@search.action”. It is
used to define which type of action is going to perform with this document.
5. There are four values of property “@search.action”:
upload, delete, merge, mergeOrUpload
6. “@Search.action=upload” means it will create a document in index if it is not existing. In
case existing document is found it will be replaced by new document.

REMOVE DOCUMENT
We can delete document of a index service using following request:

REMOVE DOCUMENT
Important points:
1. To remove document “@search.action=delete” id required in request body.
2. To remove document only “@search.action” and “id” properties are only
required in request body.

MERGING DOCUMENT
Merging document is used to append some fields to existing document. TO merge
document we “@search.action=merge”. The following request can be used to merge
document.

MERGING DOCUMENT
Important Points:
1. Merging document doesn’t replace document. It only append fields and its value for
existing document.
2. There is no need to send all the fields in request body for merging document. We send
only the fields which needs to appended. Id property is required for this action.
3. In upload we have to send all the fields in request body to append or modify records. It
replace all fields with new values supplied in request. It consumes more bandwidth in
comparison of Merge Action. Upload action is slower than merge.
4. Merge can be used to delete Property level data from document. It is different from
delete action. Delete is used to delete entire document from index.
5. Merge action can not be completed in case of document doesn’t exist. It returns “207”
status code. The error message in request body represents that document id not found.

MERGE OR UPLOAD DOCUMENT
We can use “@search.action=mergeOrUpload” to upload or merge document. This
action will upload document, if it is not existing other wise it will be merged with
existing document found.
It will not give better performance. It should be used only when there is no priority
of performance.

READING DOCUMENT FROM INDEX
The following query can be used to get detail of particular document.

SELECT DOCUMENT FIELDS FROM INDEX
The following query can be used to select fields of document.

AZURE SEARCH QUERY
Types of Azure search query:
1. Simple Query
2. Full Query.
There are two approaches to execute query using Azure Search:
1. GET approach:
 In this approach we can execute query by passing parameters in query string.
 Each parameter value must be URL-Encode.
 Length should be limited to 8 kb.
2. Post Approach:
 In this approach we can execute query using parameters in request body.
 We can use up to 16 MB of characters in request body.
 It is easier to read parameters.
 URL-Encoding is not needed

AZURE SEARCH QUERY
We can execute query by using following steps in Post approach:
1. Use any REST client to execute query on Azure Search For ex. POSTMAN
2. Use Azure search url. Append “/docs” in search service Url. “docs” represents
documents of index.
3. Append “Search” parameter in URL to execute any query.
4. Append “api-version” parameter in URL as query string parameter.
For ex: ……/indexes/<<index Name>>/docs/search?api-version=2015-02-28

AZURE SEARCH QUERY
The following example will return all index records which is starting from letter “I”

AZURE SEARCH QUERY OPERATORS
Azure Search supports six simple query operators:
 Star (*)
 And (+)
 Or (|)
 Phrase (“…”)
 Parenthesis (…)
 Not (-)

Suffix (*) operator: some of the important characteristics of this operator is as
follows:
 It is always used after as phrase. For ex: “search”:”L*”. It will result all the
documents in which search field contains started with character “L”
 By default Azure search set search parameter as “*”. It will return all the results.
The query performance is slower in this case. It is recommended that always use
long prefix with suffix operator to get result faster and accurate.
 Suffix operator doesn’t work as wild card character. It is always used with some
prefix. For ex: *r and *pale* is not valid query.

OR (|) operator: some of the important characteristics of this operator is as follows:
 It is used to search documents which matches either term besides “|”. For ex:
“{“search”:”Porter”|”Stout”}. It will return all documents in which searchable term
contains either “Porter” or “Stout”.

AND (|) operator: some of the important characteristics of this operator is as follows:
 It is used to search documents with multiple terms. For ex: “{“search”:”Pale + ale”}.
It will return all documents in which searchable term contains both “pale” and
“ale”.
 The more terms AND together, the faster the queries.

Phrase (“..”) operator: some of the important characteristics of this operator is as
follows:
 It is used to group multiple terms together. It is used to search a pattern in
documens. For ex: “{“search”:””Pale ale””}. It will return all documents in which
searchable term contains “pale” and “ale” in given order in search parameter.
 Phrase query is expensive. It is slower than keyword queries.

Important points:
 We can use multiple query operators in single query.
 Simple query order of operation is right to left.
Precedence Operator (…):
 Controls order of operations.
 Useful for complex searches.
 Helps with readability.
Not Operator (-):
 Exclude terms of searches. For ex: -stout, -(porter|stout)

Query Interpretations:
Query: -pale ale
It can have multiple interpretations:
1. Return everything that does not have the word “pale” or has the word “ale”.
2. Return everything that does not have the word “pale” but may have the word “ale”
Both interpretations are possible by using search mode operator. It dictates whether terms
with NOT operator get ANDed or ORed with other terms in query.
By default search mode parameter is set to “any”. In this mode search query “-pale ale” will
return everything that does not have the word “pale” or has the word “ale”.
We can set search mode parameter to “all”. In this mode search query “-pale ale” will return
everything that does not have the word “pale” and “ale”

AZURE SEARCH FULL QUERY
Full Query: This type of query is more advances than simple query. Some of the
important feature of full query is as follows:
1. We can write field-level query.
2. It can handle misspellings.
3. It boost terms.
4. We can use regular expression in full query.
Query Type Parameter:
This parameter is used to specifies which query language to use. The default value
for this query parameter is “simple”. To use more powerful it requires to set
parameter to “full”.
When query parameter is set to “full”, it notifies Azure search to use “lucene” query
syntax.

Syntactical difference between simple query and full query:
Star operator (*):
 In full query star operator is not only used as suffix, it is used as wildcard
character.
 There are two wildcards character supported in full query:
a) Question (?) operator: It is used as placeholder for single character. For ex A?e will return all
the records which stars from “A”, ends with “e” and contain any single character between
“A” and “e”.
b) Star (*) operator : It is used as placeholder for zero or more characters. For ex : P*e will
return all the records which starts from “P” and ends with “e”. In simple query star operator
is can not be used without any prefix.

Syntactical difference between simple query and full query:
And operator (*):
 In full query And operator is represented as (&&).
Not Operator (-):
 In full query Not operator is represented as (-) and (!).
Field Level Query:
 It restricts Fields level query.
 It search at a more granular level.
 Example of filed level Query :
“search”:”name:porter”
“search”:”name:(porter|stout)

Fuzzy searches: It adds forgiveness to query. It means that it can return search results in case there is misspell
in search query. It is used by using tild sign (~).
For ex:
{
“search”:”puckwudgie~”,
“queryType”:”full”,
“select”:”id,name”
}
In above query there is minor spelling mistake for search parameter value. It is containing wrong character “c”. In this case search result will be
returned. For ex : “Pukwudgie” will be returned as result. In this example a single character is misspelled and it is handled by Fuzzy search. It may
possible that misspelled in search query is due to multiple characters. It can be handled by fuzzy searches by adding number with tild sign. We have
to careful while using numbers after tild sign, it may result in irrevelant result. For ex:
For ex:
{
“search”:”puckwudgie~2”,
}

Term boosting: It is used to give more importance to a particular term in comparison
of other. It is represented by (^) sign. For ex:
{
“search”:”pale^2 ale”,
}
In above query pale has more importance than ale. By default it’s value is 1 and it
can be less than 0.

Regular Expression: It is used to find terms that match patterns. It is represented by
forward “/” sign . For ex:
{
“search”:”name:/.*col.*/”,
}

AZURE SEARCH QUERY STATISTICS
We can get the number of results and time consumed to execute query form Azure
Search.
Count Parameter: This parameter specifies whether to include total number of
results. It returns count in response if this parameter is set to “true”. It’s value is an
approximation.
By default count parameter sets to false. There is small, negative performance impact
when it’s value is set to true.
Query Duration: Azure search doesn’t provide information about query processing
time. It depends on various factors. We ca calculate query duration by using code.
Pseudo code for this is as follows:
Var QueryStartTime=GetCurrentMilliSeconds();
Var Results=ExecuseSearch();
Var QueyDuration=GetCurrentMilliSeconds()-QueryStarttime

FILTERING SEARCH RESULT
Filter is applied after matching documents are found. It is generally used when we
want to narrow down search result further. Sample for filter is as follows:
{
“search”:”*”,
“filter”:”ibu lt 75.0”
“select”:”id, name, ibu”
}

ODATA OPERATOR FOR FILTERING
We can use ODATA expression and grammar to filter results using Azure search. There are
some of ODATA commonly used are discussed below:
1. Comparison Operators
2. Logical Operators
3. “Any” and “All”
Comparison Operator: There are six comparison operator which are discussed below:
 Equal (eq)
 Not Equal (ne)
 Greater Than (gt)
 Less Than (lt)
 Greater than or equal to (ge)
 Less than or equal to (le)

ODATA OPERATOR FOR FILTERING
Logical Operator: There are three logical operators in ODATA expression:
 AND (and)
 OR (or)
 NOT (not)
Lambda operators: There are two lambda operators used for collection filtering.
 Any : Ex: “filter”:”flavors/any(f : f eq ‘chocolate’)
 All : Ex: “filter”:”flavors/all (f: f ne ‘smokey’)

DOCUMENT RELEVANCY IN SEARCH RESULT
Azure search returns most relevant result after executing query against search. Some
of the important point related to document relevancy is as follows:
1. There is one of the property “@search.score” returned in search result which
shows document relevancy against query.
2. Higher the score, the more relevant the document.
3. More relevancy means higher ranking.
4. By default results are displayed in descending order of score.

SEARCH SCORE IN SEARCH RESULT
Search score in search result is calculate by algorithm (TF-IDF).
It means TERM FREQUENCY-INVERSE DOCUMENT FREQUENCY.
This algorithm works on following parameter:
1. Looks at how often tem appears in document.
2. Looks at how often it appears in other document.
3. The more frequent a term appears, the more relevant the document.

SCORING PROFILE IN AZURE SEARCH
The default algorithm for calculation for scoring in search result can be overridden
according to business requirement. It can be overridden by creating scoring profile.
It provides following features:
1. It allows to promote one or more fields
2. We can give priority to some of the fields in comparison of others. It is also
known as boosting.
3. It connects search results with business goals.

CREATING SCORING PROFILE
Scoring profile is the part of index definition. To create scoring profile we have to do
following steps:
1. Get the current index definition.
2. Update the index definition.
To retrieve the index definition the following request is required:

CREATING SCORING PROFILE
To update the index definition we can use the following request:

USING SCORING PROFILE
To use scoring profile in azure search query following query is required:
{
“search”:”north”,
“count”:”true”,
“select”:”name, breweryName”,
“scoringProfile”:”breweryName”
}
Note: Each index can have up to 16 scoring profile. If the scoring profile is not found
as per request. It will throw “result not found”.
After running this query order for scoring result is going to be change. The ranking
value is going to be impacted after this implementation.

CUSTOMIZING SCORING PROFILE
Azure search provides configuration based approach for customizing scoring profile.
There are five ways to customize scoring profile:
1. Text
2. Numeric values
3. Data Freshness
4. Proximity
5. Collection of strings

BOOSTING TEXT FIELD
Text based scoring profile:
To boost field of string we can use text base scoring profile. The following syntax can be used for this configuration.
“scoringProfiles”:[
{
“name”:”brewery name”,
“text”:”{
“weights”:{
“breweryName”:5
}
}}]
In above example name field is the populated for scoring profile name.
Text property is encapsulated with other property weights. It is populated with the name of the field along with magnitude. In above example brewery name field is boosted with magnitude of 5. It
means the specified field is more valuable than others.
We can add multiple fields in scoring profile with different weightage according to the requirement. To include multiple fields the following syntax is required:
{
“name”:”brewery name”,
“text”:”{
“weights”:{
“name”:5
“breweryName”:2.5
}
}}]

BOOSTING NUMERIC FIELD
Number based scoring profile: Scoring profile provide feature to boost numeric based fields. To boost numeric field
magnitude Function is required. Syntax for magnitude function is as follows:
{
“name”:”abv”,
“functions”:[
{
“type”:”magnitude”,
“fieldname”:”abv”,
“boost”:2.5
“magnitude”:{
“boostingRangeStart”:0
“boostingRangeEnd”:100
}
}]}]
It will impact result order. The scoring value is going to be changed.

BOOSTING NUMERIC FIELD
Fields used for number based scoring profile.
1. Type field is to be assigned to “magnitude” in case of number based scoring profile. It is required to
be set to implement scoring profile.
2. It should be in smaller case only.
3. Field name identifies the name of field for which scoring profile is to be created. It is required to be
set to implement scoring profile.
4. Only filterable filed is allowed in scoring function.
5. All azure search field is filterable by default.
6. The property boost is used to define a multiplier. It can be any positive value greater than 0 not 1.
7. If we try to set value 1.0. Azure search provides error because it will not have any impact.
8. Boost property is required field for all scoring functions.
9. Magnitude property contains two more properties. BoostingRangeStart and BoostingRangeEnd.
These two values are define to represent boost scope. Any values which are not in this range is not
going to be boosted up.
10. Boosting range can be any positive or negative value.

BOOSTING DATE RANGE
Boosting Date Range Values: To boost date range values there is freshness function in Azure search. It returns most recent data as the relevant data. For ex:
{
“name”:”freshBeers”,
“functions”:[
{
“name”:”freshness”,
“fieldname”:”lastTappenOn”,
“boost”:10,
“freshness”:{
“boostingDuration”: “P90D”
}
}]
}
 BoostingDuration property defines the time span in which the values are boosted.
 This time span begins when query gets executed.
 The end time decides by the value of boostingduration. It is used to set when boosting expires.
 The value for boosting duration is provided in format of ISO 8601 Format.
 Example for ISO 8601 format is (1Day=P1D), (12Hrs=PT12H), (30Minutes=PT30M), (10.123 seconds=PT10.123S)
 To boost future dates we can use negative sign. –P90.

BOOSTING STRING IN COLLECTION
To implement boosting for collection of string data type we can use tag function.
It works with collection(Edm.String).
For ex:
{
“name”:”prefferedFlavors”,
“functions”:[
{
“type”:”tag”,
“fieldName”:”flavors”,
“boost”:10,
“tag”:{
“tagsParameter”:”myBelovedFlavors”
}
}
}]}
In above example tagsParameter field is like placeholder. We can pass value to place holder from search request.
For ex:
{
“search”:”Ale”,
“scoringProfile”:”prefferdFlavors”,
“scoringParameters”:”[“myBelovedFlavors:pine”]
}

BOOSTING MATRIX AS PER DATA TYPE
We can set the default scoring profile to our custom scoring profile. It can be
done by setting property “defaultScoringProfile”. In this case Azure search is
not going to worked on TDFIF. Approach.
Summary

NAVIGATING SEARCH RESULT
To navigate search results the following techniques are provided by Azure Search:
1. Sort search result.
2. Paging in search result.
3. Faceted Navigation.
4. Query suggestion.

SORTING SEARCH RESULT
 Sorting in Azure Search can be done on any Sortable Field.
 By default all fields are sortable except collection(edm.string).
 Collection(Edm.string) can’t marked as sortable.
 We can implement sorting by using orderby parameter in queystring.
 By default search results are sorted in descending order on @search.score value.
 Orderby property can be used to override this default behavior.
 Example for orderby is as follows:
{
“orderby”:”name”
}

SORTING SEARCH RESULT
 The default sorting direction is ascending.
 We can use suffix (asc or desc) to sort results in a particular direction.
 To combine sort on multiple fields we can provide comma delimited list to orderby.
 The default sorting direction is Left to right. It means the result is going to sort on first field
then others in sequence of left to right.
 As we discussed earlier there is “Score” property in the results which helps to get relevant
results. It may possible that multiple items has same score. The result sequence in this
scenario is not relevant to the user. To handle this we can update or add scoring profile.
 One of the important point to be noted that @search.score field can not be used in order
by parameter.

PAGING SEARCH RESULT
 It may possible that we have larger index. In this case volume of search result is bigger. To navigate search result in this case we can use paging.
 By default Azure search return 50 search result per query.
 There is “Top” parameter in Azure search where we can set maximum result to be returned from Azure search. For ex:
{
“select”:”name”,
“top”:5
}
 There is “Skip” parameter to specify how many documents to pass over. It is used to navigate from one page to another. For ex:
{
“select”:”name”,
“top”:5
“skip”:5
}
 The max value for skip parameter is 100,000.

FACETED NAVIGATION IN SEARCH RESULT
Facets: Set of items displayed with counts along with results is known as facets. It helps to navigate results faster.
We can understand facets in following diagram:
Facets are define from filter. It is returned from Azure search with counts. It is not pre-defined.

 To include “Facets” in search result include the “facets” parameter in query.
 Fields should be facetable in index to include in facets.
 By default all fields are facetable in Azure search index.
 To include Facets we can provide multiple fields in facets parameter in form of array for ex:
{
“facets”:[“breweryName”]
}
 After implementing this query facets is going to be returned along
with this search result in following format:

 We can represent in the form of ranges. It is useful for creating facets for fields of numeric type or
datetime.
 To represent facets in ranges we have to create buckets. We can define range for facets as follows:
 We can define buckets for following data types:
Edm.int32
Edm.int64
Edm.Double
Edm.DateTimeOffset

 We can create automatically buckets based on regular syntax by using following syntax:
{
“facets”:[
“abv,interval:4”
]
}
 Empty buckets are not included in facets list returned with search result.
 We cannot use fractional values to assign interval.
 For setting interval for DatTimeOffset we can provide value in form of (minute, hour, day, week, month,
quarter, year)
 Date time offset example { “facets”:”lastTappedOn,interval:month”}

 In Azure search by default facet labels are returned as per data available in index.
 Azure search API is not responsible to format labels of facets.
 We can format facets by using our own custom logic in application.
 There is option for sorting facet values. Syntax is as follows:
{
“facets”:[
“breweryName,sort:value”
]
}
 To review the sort order we can use negative sign with value.
 To sort facet based on result count we can use following syntax:
“facets”:[“breweryName,sort:-count”]
 We can limit the count of facets options by using count parameter. For ex:
“facets”:[“breweryName,sort:count,count:3”]. It limit facets options to 3
 The higher the number of facets options, it will impact the performance of search. It is good practice to limit the number of
facets options to improve search performance.
 To get results based on facets options we have to implement filter for facets.
 It can be used as navigation pattern or filter pattern in application.

HIGHLIGHT RESULT DATA
 To highlight result data we have to configure “highlight” property. We can provide field names in form of
comma delimeted string to highlight multiple fields in search result. For ex:
{
“search”:”North”,
“highlight”:”name,breweryName”
}
 The above query only defines what to highlight in search result. To provide information for how to highlight
items in search result we have to use “highlightPreTag” and “highlightPostTag” parameters. These
parameters are used to provide values in form of HTML tags. For ex:
{
“search”:”North”,
“highlight”:”name,breweryName”,
“highlightPreTag”:”<span style=‘background-color:orange;’>”,
“highlightPostTag:”</span>”
}

SEARCH SUGGESTION IN AUTO-COMPLETE
 Suggesters are part of Azure index. To configure search suggestion we have to configure Azure search
index.
 Suggesters are defined by two required fields : name and source fields
 Source fields in suggester specifies which fields are examined for suggestions. It can accept multiple field
names in the form of array.
 We can define suggester while building index. For ex:

 To request search suggestion from Azure search append suggest path For ex:
/indexes/{indexName}/docs/suggest
 The above endpoint can be requested by GET or POST request.
 We can use search parameter with above endpoints to which suggestions we are looking for.
 It can only between 1 and 100 characters.
 It can not use simple and full query search features.
 We can also specify field names for which we are looking suggestions. Fields names must be included in suggestion
definition.
 We can enable fuzzy searches for getting suggestions. Fuzzy searches helps to forgive spelling error provided for search.
 Syntax for query is as follows:
{
“search”:”Ale*”,
“suggesterName”:”beerSuggestions”,
“searchFields”:”name”,
“fuzzy”:”true”
}

 To return additional fields in suggestions. We can use “select” parameter for this purpose.
 Top parameter is used to specify max number of suggestions to return.
 Five is the default value to return suggestion result.
 Scoring profiles or relevancy is not used with suggestions.
 We can sort suggestion result by using “order by”
{
“search”:”north”,
“suggesterName”:”beerSuggestions”,
“select”:”name, breweryName, abv, ibu”,
“top”:3,
“orderby”:”name”
}

Azure search

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Azure search

Similar to Azure search (20)

Recently uploaded

Recently uploaded (20)

Azure search