Introduction
Search is one of the most important features in an e-commerce application.
Imagine an online store containing hundreds of thousands or millions of products. When a customer searches for:
Nike Running Shoesthe application needs to quickly return relevant products and allow the customer to narrow the results using filters such as:
- Brand
- Category
- Size
- Color
- Price
- Availability
- Rating
Executing a complex database query for every customer search can become expensive.
This is where Apache Solr comes into the SAP Commerce architecture.
SAP Commerce uses the solrfacetsearch functionality to provide search and faceted navigation over indexed Commerce data. SAP documentation describes it as supporting faceted search over items such as products and WCMS content.
In this article, we will understand Solr from both a developer and SAP Commerce interview perspective.
1. What Is Solr?
Apache Solr is a search platform designed for fast searching and indexing of large amounts of data.
Instead of searching the Commerce database directly for every customer request, SAP Commerce can index relevant product information into Solr.
Conceptually:
SAP Commerce Database
|
| Indexing
v
Solr
|
| Search
v
Customer Search RequestFor example, your database may contain:
Product
---------------------------------
code
name
description
price
brand
category
color
size
stockDuring indexing, selected information is transformed into a Solr document.
Conceptually:
{
"code": "NIKE-001",
"name": "Nike Running Shoes",
"brand": "Nike",
"category": "Running Shoes",
"color": "Black",
"price": 5999
}The important point is that not every database attribute automatically becomes searchable.
The attributes that should be indexed have to be configured as indexed properties.
2. Solr in SAP Commerce Architecture
A simplified architecture looks like this:
Customer
|
v
Storefront/OCC
|
v
Search Service
|
v
Solr Server
|
+--------+--------+
| |
v v
Search Results Facets
|
v
Product PKs
|
v
SAP Commerce
ProductThe major components include:
- SAP Commerce
solrfacetsearch- Solr server
- Indexed Types
- Indexed Properties
- Search configuration
- Indexer
- Search services
- Facet configuration
SAP's documentation separates search configuration, indexed types, indexed properties, and server configuration as core parts of the Search and Navigation functionality.
3. Why Does SAP Commerce Need Solr?
Consider a catalog containing:
2,000,000 ProductsA customer enters:
laptopand expects results within a fraction of a second.
A database query may have to perform complex operations involving:
Product
Category
Price
Inventory
Brand
Classification
Language
Catalog Versionand potentially large text-search operations.
Solr is optimized specifically for search workloads.
The advantages include:
Fast text search
Search terms can be matched across indexed fields efficiently.
Full-text search
For example:
running shoescan search relevant product text.
Fuzzy search
A misspelled term such as:
nikcan potentially return:
Nikedepending on the configured query behavior.
Faceted search
Customers can narrow results by:
Brand
Color
Size
Price Range
CategorySorting
Results can be sorted by:
Price
Name
Relevance
Rating
Stock4. What Is Solr Indexing?
Indexing is the process of taking data from SAP Commerce and creating searchable Solr documents.
For example:
ProductModel
|
v
Indexer
|
v
Value Providers / Resolvers
|
v
Solr Document
|
v
Solr IndexSuppose we have:
ProductModel productwith:
code = IPHONE-001
name = iPhone 17
price = 79999
brand = AppleThe indexing process converts relevant information into Solr fields.
Conceptually:
ProductModel
|
+---- code ------> code_string
|
+---- name ------> name_text
|
+---- price -----> price_double
|
+---- brand -----> brand_string5. What Is an Indexed Type?
An Indexed Type defines what type of Commerce data is going to be indexed.
A common example is:
ProductThe Indexed Type identifies the Commerce item being indexed and is associated with indexer/search configuration.
You can think of it as:
Indexed Type
|
+---- Product
|
+---- Indexed Properties
|
+---- Indexer Configuration
|
+---- Search Configuration6. What Are Indexed Properties?
An Indexed Property represents a property of the indexed type that should be available in Solr.
For example:
Product.code
Product.name
Product.description
Product.price
Product.brand
Product.colorThe property configuration determines how the value should be indexed and potentially searched, filtered, faceted, or returned.
SAP Commerce documentation provides different configurations for strings, dates, numbers, enums, localized values and other types.
7. Example of an Indexed Property
A simplified ImpEx-style example might look like:
INSERT_UPDATE SolrIndexedProperty;
name[unique=true];
solrIndexedType(identifier)[unique=true];
type(code);
localized[default=false];
facet[default=false]
;name;Product;TEXT;true;false
;code;Product;TEXT;false;false
;brand;Product;STRING;false;true
;price;Product;DOUBLE;false;trueThe exact configuration can vary by SAP Commerce version and project.
The important concept is:
Commerce Attribute
|
v
SolrIndexedProperty
|
v
Solr Field8. Text vs String in Solr
This is an important interview topic.
Suppose you have:
Product Name = Nike Running ShoesIf you want full-text search behavior, the property typically needs to be configured appropriately as a text-search field.
For example:
name → textA string field behaves differently from a text field because text processing/analyzers can be applied to searchable text.
SAP's documentation specifically notes that string indexing can behave differently with filters and may result in case-sensitive searching compared with appropriately configured text fields.
9. Free-Text Search
Free-text search allows users to enter search terms without explicitly specifying a field.
Example:
red nike shoesThe search engine attempts to identify matching indexed content.
Typical searchable properties might include:
name
description
code
brand
categorySAP Commerce search property configuration supports different query behaviors, including free-text, fuzzy, wildcard, and phrase queries.
10. Fuzzy Search
Customers frequently make spelling mistakes.
For example:
runing shoesinstead of:
running shoesFuzzy search can help identify terms that are similar.
Conceptually:
runing
|
v
runningThis can improve the customer's search experience.
However, fuzzy searching should be used carefully because aggressive fuzzy queries can increase search cost and return less precise results.
11. Wildcard Search
Wildcard search allows partial matching.
Example:
nik*could potentially match:
nike
nikonDepending on the configured search behavior.
Wildcard queries should be used carefully, especially with leading wildcards such as:
*shoebecause they can be expensive depending on the Solr/query configuration.
12. Phrase Search
Suppose the customer enters:
running shoesA phrase-oriented search can treat the complete phrase as a meaningful sequence rather than simply searching the individual words independently.
This can improve relevance for certain use cases.
13. What Are Facets?
Facets are filters that allow customers to narrow search results.
Suppose a customer searches:
shoesThe application might display:
Brand
----------------
Nike (120)
Adidas (90)
Puma (50)
Color
----------------
Black (100)
White (75)
Red (40)
Price
----------------
₹0 - ₹2,000
₹2,000 - ₹5,000
₹5,000+These are facets.
The customer can select:
Brand = Nike
Color = Blackand the results become narrower.
SAP Commerce's search configuration supports facet settings on indexed properties.
14. Facet Example
Consider:
Product
-------------------
Brand
Color
Size
Price
CategoryConfigure:
brand → facet
color → facet
size → facet
price → facet/rangeThen the search UI could display:
Brand
Nike 120
Adidas 90
Puma 50and:
Color
Black 100
White 80
Blue 4015. Range Facets
Some values are better represented as ranges.
Price is the most common example.
Instead of:
₹1499
₹1699
₹1899
₹1999
₹2499the customer can see:
₹0 - ₹2,000
₹2,000 - ₹5,000
₹5,000 - ₹10,000
₹10,000+These are range facets.
They are especially useful for:
- Price
- Age
- Weight
- Rating
- Size
- Numeric attributes
16. Full Index vs Incremental/Partial Updates
This is one of the most important Solr interview questions.
Full Index
A full index rebuild processes the complete dataset configured for the index.
Conceptually:
All Products
|
v
Indexer
|
v
New Solr IndexFull indexing may be used after:
- major configuration changes
- new indexed properties
- catalog changes
- initial setup
- index corruption
- significant data/configuration changes
Partial or Incremental Update
A partial update updates only the required information rather than rebuilding an entire document.
For example:
Product 1001
Old:
price = 5000
stock = 20
New:
stock = 5Instead of rebuilding everything, the update process can target the necessary change.
SAP documents partial updates as a way to update a subset of Solr document attributes rather than rebuilding the entire document, which is useful for large catalogs.
17. When Should You Run a Full Index?
A common scenario:
You add a new indexed property:
materialThe existing Solr index doesn't automatically contain the new field for every existing product simply because you changed the configuration.
A full indexing operation is commonly required so the existing dataset gets indexed according to the new configuration.
Typical flow:
Change Indexed Property
|
v
Update Configuration
|
v
Run Full Index
|
v
Validate Search18. Solr Indexer CronJob
SAP Commerce provides indexing functionality that can be executed through CronJobs.
For example:
System
|
+-- Background Processes
|
+-- CronJobs
|
+-- Solr IndexerYou can configure execution schedules and indexing operations through the administration tooling. SAP documentation also describes configuring Solr index update CronJobs and their operation settings.
19. Why Is My Product Available in the Database but Not in Search?
This is one of the most common production issues.
You execute:
SELECT * FROM Productand find:
Product existsbut searching through storefront/OCC doesn't return it.
Do not immediately assume FlexibleSearch is the problem.
The product may not be correctly represented in the Solr index.
Check:
1. Product exists
2. Correct catalog
3. Correct catalog version
4. Product is indexed
5. Indexed property configuration
6. Indexing job status
7. Solr configuration
8. Query configuration
9. Search restrictions
10. Facet/search configuration20. Troubleshooting: Product Not Showing in Solr
A practical troubleshooting sequence is:
Step 1: Check the Product
Verify:
code
catalog
catalogVersion
approvalStatus
onlineDate
offlineDateStep 2: Check Indexed Type
Confirm that the relevant product type is included in the indexed type configuration.
Step 3: Check Indexed Properties
If you're searching:
brand = Nikeverify that:
brandis configured as an indexed property.
Step 4: Check Indexing Job
Look for indexing errors in:
Backoffice
HAC
logs
CronJobsStep 5: Run a Full Index
When configuration changes or stale index data is suspected, run the appropriate full indexing operation.
Step 6: Validate Solr
Confirm that the expected Solr document exists and contains the expected fields.
21. Database Data vs Solr Data
A very important concept:
Database ≠ Solr IndexThe database contains the source Commerce data.
Solr contains the indexed/search-oriented representation.
Therefore:
Product exists in DBdoes not necessarily mean:
Product exists correctly in SolrThis distinction is extremely important when debugging production search problems.
22. What Is a Value Provider?
During indexing, SAP Commerce needs to determine where an indexed value comes from.
For example:
Product.pricemay be directly available from the Product model.
But a complex property could require custom logic.
Conceptually:
ProductModel
|
v
Value Provider
|
v
Solr FieldA custom value provider may be appropriate when the indexed value must be calculated or assembled from multiple sources.
For example:
Product
|
+-- Brand
+-- Category
+-- Classification
|
v
Custom Calculated Search Value23. Example Custom Value Provider Concept
Suppose the business wants a searchable field:
searchKeywordsgenerated from:
product name
brand
category
classificationA custom provider could conceptually do:
public class CustomSearchValueProvider
{
public Object getFieldValue(ProductModel product)
{
StringBuilder value = new StringBuilder();
value.append(product.getName());
if (product.getManufacturerName() != null)
{
value.append(" ");
value.append(product.getManufacturerName());
}
return value.toString();
}
}The exact SAP Commerce interface and method signature depend on the platform/version and project setup, so the implementation should follow the corresponding version's Solr indexing API.
24. Localized Indexed Properties
E-commerce applications are often multilingual.
For example:
English:
Running Shoes
German:
Laufschuhe
French:
Chaussures de courseProduct names can therefore require localized indexing.
The indexing configuration needs to account for localization.
This is especially important when troubleshooting a problem such as:
Search works in English
Search fails in GermanCheck whether the property is configured correctly as localized and whether the required language data was indexed.
SAP's Solr property configuration explicitly supports localized properties.
25. Currency-Dependent Properties
Price is another special case.
Consider:
India → INR 79,999
USA → USD 999
Europe → EUR 949Search/index configuration needs to account for currency where relevant.
A price field should not simply be treated like an ordinary string.
This is why SAP Commerce Solr indexed properties support currency-specific configuration.
26. Search Restrictions and Solr
Another tricky area is Search Restrictions.
A product may exist in the Solr index, but additional Commerce-side restrictions can still affect what a particular user sees.
This can produce confusing behavior such as:
Solr contains product
+
Search restriction applies
=
Product not visible to userSAP documentation also notes that search restrictions can affect Solr result counts in some situations.
27. Solr and OCC
In a headless SAP Commerce implementation, OCC APIs may expose search functionality.
A conceptual request might look like:
GET /occ/v2/{baseSiteId}/products/search?query=shoesThe flow can be represented as:
Mobile/Web Client
|
v
OCC Controller
|
v
Facade
|
v
Search Service
|
v
Solr
|
v
Search Results
|
v
Product Data / DTOThis is an important connection between your OCC knowledge and Solr knowledge.
28. Pagination in Solr Search
Suppose there are:
50,000 productsThe API should not return all of them.
Instead:
Page 0
size = 20returns:
Products 1 - 20and:
Page 1
size = 20returns:
Products 21 - 40Pagination helps reduce:
- response size
- network traffic
- memory usage
- rendering time
29. Sorting Search Results
Customers may want:
Relevance
Price Low → High
Price High → Low
Newest
NameSolr can support configured sorting behavior.
For example:
search=shoes
sort=price-ascThe exact OCC query parameters depend on your API/version/customization, but the important architectural concept is:
Customer Sort Selection
|
v
Search Query
|
v
Solr Sorting30. Solr Performance Optimization
Solr performance becomes increasingly important as catalog size grows.
1. Index only required data
Do not blindly index every Product attribute.
More indexed data can mean:
larger index
more storage
more processing
more indexing timeSAP also recommends avoiding sensitive/confidential data in Solr indexing because indexed data can introduce information disclosure risks.
2. Avoid unnecessary facets
Do not make every property a facet.
For example, these may not make sense as customer-facing facets:
internalCreationTimestamp
internalERPFlag
internalProcessingStatusUse facets where customers actually need filtering.
3. Optimize indexed properties
Only index fields that have a business/search purpose.
Ask:
Do customers search this?
Do customers filter by this?
Does sorting need this?
Does the response require this?If the answer is no, reconsider indexing it.
4. Use pagination
Avoid returning huge result sets.
Prefer:
pageSize = 20or another business-appropriate value instead of thousands of results.
5. Avoid unnecessary full indexing
For a large catalog:
Full Indexcan be expensive.
Use the appropriate update strategy for smaller changes where supported.
SAP documents partial updates specifically as a way to avoid rebuilding complete documents for small changes.
31. A Common Production Scenario
Imagine you receive this incident:
"Customer updated the product price, but the storefront still shows the old price."
The database shows:
Product Price = ₹4,999But storefront shows:
₹5,499What do you check?
Step 1
Verify the database:
Product price = ₹4,999Step 2
Check whether the price is Solr-driven for the particular storefront/search response.
Step 3
Check the relevant Solr document.
Step 4
Check the indexing/update process.
Step 5
Check whether the update job executed successfully.
Step 6
Check whether a cache is contributing to the stale result.
Step 7
If necessary, trigger the appropriate index update/full index according to the project's configuration.
The important debugging principle is:
Database
↓
Indexing
↓
Solr
↓
Search Service
↓
Cache/API
↓
StorefrontFind where the stale value first appears.
32. Another Real-World Scenario
Problem
The product exists in Backoffice.
FlexibleSearch returns it.
But:
/search?query=ABCreturns no result.
Investigation
Check:
Product
↓
Catalog Version
↓
Indexed Type
↓
Indexed Property
↓
Solr Index
↓
Search QueryPossible root causes:
Product wasn't indexedor:
Product property isn't indexedor:
Index is staleor:
Search configuration doesn't use that propertyor:
Search restriction/filter removes itThis type of scenario is excellent for senior SAP Commerce interviews.
33. Full Index vs Partial Update — Interview Answer
Question
What is the difference between full indexing and partial indexing/update in SAP Commerce?
Answer
Full indexing processes the complete set of configured data and creates/updates the Solr index according to the indexing configuration.
Partial updates can update only selected portions of an existing Solr document, avoiding unnecessary processing for unchanged attributes.
Use full indexing for major configuration/data changes, while partial updates can be useful for targeted changes in large catalogs.
SAP specifically documents partial updates as a way to update only a subset of document attributes.
34. Interview Question: Why Is Solr Faster Than Database Search?
Answer
Solr is specifically designed and optimized for search workloads.
It provides capabilities such as:
Inverted indexing
Full-text search
Faceting
Relevance
Fuzzy matching
Sorting
FilteringA relational database can certainly perform search operations, but Solr is purpose-built for large-scale search and navigation use cases.
35. Interview Question: Product Exists in DB but Not in Solr. Why?
Strong Senior-Level Answer
I would check the complete indexing pipeline:
Product data
→ Indexed Type
→ Indexed Properties
→ Value Providers
→ Indexer
→ Solr document
→ Search queryThen I would check:
Catalog Version
Approval Status
Online/Offline Dates
Indexing CronJob
Indexer logs
Solr configuration
Search configuration
Search restrictionsI would also compare the Commerce database representation with the actual Solr document rather than assuming the database is the source of the search response.
36. Interview Question: What Is a Facet?
Answer
A facet is a search-navigation mechanism that allows users to filter search results based on indexed properties.
For example:
Search: Shoes
Brand:
Nike
Adidas
Color:
Black
White
Price:
₹0-₹2,000
₹2,000-₹5,000Facets improve product discovery and allow customers to progressively narrow search results.
37. Interview Question: Why Would You Avoid Making Every Property a Facet?
Answer
Because unnecessary facets increase search complexity and can increase index/query overhead.
I would create facets only for business-relevant customer filtering requirements.
For example:
brand → Yes
color → Yes
size → Yes
internalERPCode → No
internalProcessingFlag → No38. Interview Question: What Happens When You Add a New Indexed Property?
A good answer is:
1. Define the indexed property
2. Configure its type
3. Configure its provider/resolver if needed
4. Update search configuration if needed
5. Build/deploy changes
6. Reindex existing data
7. Validate the Solr document
8. Test search/OCC/storefrontThe exact deployment/reindex procedure depends on the Commerce version and project architecture.
39. Interview Question: How Do You Troubleshoot Solr Issues?
My preferred troubleshooting flow is:
Issue
|
v
Is product in DB?
/ \
No Yes
| |
Fix source data Is it indexed?
/ \
No Yes
| |
Check index Check query
process config
|
v
Check restrictions
|
v
Check response
|
v
Cache/APIThis avoids randomly triggering full indexes without understanding the problem.
40. Important Solr Best Practices
Keep these principles in mind when working on SAP Commerce projects:
Do not index everything.
Index only what is required.
Do not make everything a facet.
Create meaningful customer-facing filters.
Understand the difference between DB and Solr.
They are different representations of the data.
Always check indexing after configuration changes.
A configuration change doesn't automatically guarantee that all existing Solr documents reflect the new structure.
Monitor indexing jobs.
An apparently successful deployment can still have failed indexing.
Be careful with custom value providers.
Poorly designed providers can make indexing expensive.
Avoid sensitive information in Solr.
SAP explicitly warns against indexing confidential data because it can create information disclosure risks.
41. SAP Commerce Solr Architecture — Quick Revision
Remember this flow:
SAP Commerce
|
v
Product Data
|
v
Indexer
|
+-----------+-----------+
| |
v v
Indexed Properties Value Providers
| |
+-----------+-----------+
|
v
Solr Index
|
v
Search Query
|
+-------------+-------------+
| | |
v v v
Results Facets Sorting
|
v
OCC / StorefrontThis diagram is worth remembering for SAP Commerce interviews.
42. Key Terms You Should Know
| Term | Meaning |
|---|---|
| Solr | Search platform |
| Indexed Type | Type of Commerce data being indexed |
| Indexed Property | Attribute indexed in Solr |
| Indexer | Process that creates/updates index data |
| Facet | Customer-facing search filter |
| Value Provider | Provides/calculates indexed values |
| Full Index | Indexes the complete configured dataset |
| Partial Update | Updates part of an existing Solr document |
| Free-Text Search | Search using general text terms |
| Fuzzy Search | Search tolerant of spelling differences |
| Range Facet | Facet based on numeric ranges |
| Search Configuration | Configuration controlling search behavior |
| Search Restriction | Restriction affecting what data a user can access |
43. Final Takeaway
Solr is a fundamental part of SAP Commerce search architecture.
The most important relationship to remember is:
Commerce Database
↓
Indexer
↓
Indexed Properties
↓
Solr Index
↓
Search Query
↓
Results + Facets
↓
OCC / StorefrontWhen debugging search issues, don't stop at FlexibleSearch.
A product can exist correctly in the Commerce database and still be missing or incorrect in Solr.
For senior SAP Commerce developers, understanding indexing, indexed properties, value providers, facets, search configuration, full vs partial updates, search restrictions, and Solr troubleshooting is essential.
